4 ms·
In case of mutation either the replicas will be out of sync (so no C), or you'll need to synchronously mutate the replicas (so bad A due to latency).
by ismailmaj 2y ago
In case of mutation either the replicas will be out of sync (so no C), or you'll need to synchronously mutate the replicas (so bad A due to latency).
- UltraSane 2y agodelaying writes by a factor longer than the max clock skew of the cluster is a pretty common strategy. It is what Google Spanner does.
- ismailmaj 2y agoRight but it's not magic as you cannot predict networking delays. The max clock skew also has to pick between A and C, in underestimates you lose serializability, in overestimates you pay in write latency.
- UltraSane 2y agoWhat if you use CockroachDB for your log? They do something pretty clever: https://www.cockroachlabs.com/blog/living-without-atomic-clocks/ https://www.cockroachlabs.com/blog/living-without-atomic-clo...
- ismailmaj 2y agoThanks for the link, not much familiar with CockroachDB but I worked on a similar system that wanted to provide strong consistency when reading from many databases, some of which where Spanner but not all of them. Eventually the system implemented something similar to "find transaction timestamp at execution time" + optimistic locking, as the article states you lose global linearizability and have to do some re-reads for writes. What I missed the most from Spanner compared to the system above is that its tricky to do client-side transaction chaining where there are many clients and the order is important.
- UltraSane 2y agoIf you put a atomic clock like OCP-TAP Time Card with GNSS receiver in every server and use precision time protocol to sync them you should be able to synchronize quite a few servers to less than 100 nanoseconds.