4 ms·
> The main reason we can not use system clocks is that system clocks across servers are not guaranteed to be synchronized. Data center/cloud system clocks can
by timf 3y ago
> The main reason we can not use system clocks is that system clocks across servers are not guaranteed to be synchronized.
Data center/cloud system clocks can be tightly synchronized now in practice. Still never perfect and race conditions abound.
But that doesn't mean you can't rely on a clock to determine ordering, Google popularized a different approach with TrueTime/Spanner: https://cloud.google.com/spanner/docs/true-time-external-consistency https://cloud.google.com/spanner/docs/true-time-external-con...
- preseinger 3y agoyou definitely cannot rely on clocks to determine (reliable) ordering across machines truetime doesn't provide precise timestamps, each timestamp has a "drift" window timestamps within the same window have no well-defined order, applications have to take this into account when doing e.g. distributed transactions
- erikerikson 3y agoThey do have a well defined order, just not one based on time.
- timf 3y agoI don't see how it isn't based on time. They use GPS and atomic clocks to establish the time, establish an uncertainty window, and in Spanner's case will have transactions wait out that uncertainty to guarantee an ordering (globally).
- erikerikson 3y agoLook up the case where two transactions affecting the same record share a timestamp (or have overlapping error ranges). An non-timestamp tiebreaker determines the order between the two overlapping commits. It is not unlike the pre-agreement on conflict resolution mechanisms for CRDTs. The context to my first comment included "timestamps within the same window"
- timf 3y agoAgree, and the timestamp comparisons you can make when the windows do not overlap are the basis of the ordering guarantees (across machines, even globally).
- preseinger 3y agokind of? not really? ordering is a logical property which can be informed by physical timestamps, but those timestamps aren't accurately described as "the basis" of that ordering
- dikei 3y ago> you definitely cannot rely on clocks to determine (reliable) ordering across machines You can if you consider "unknown/possibly concurrent" also a valid outcome: for any 2 events A and B, True Time can definitely answers whether A is before B, A is after B, or A is possibly concurrent with B.
- preseinger 3y ago"reliable ordering" usually implies a specific and well-defined order, without concurrent events :)
- deleted 3y ago[deleted]