4 ms·

Google's Spanner, for instance, relies on their TrueTime design, which requires having a GPS clock and an atomic clock on each datacenter, I believe. Most desig

Google's Spanner, for instance, relies on their TrueTime design, which requires having a GPS clock and an atomic clock on each datacenter, I believe. Most designs simply rely on NTP or a similar time synchronization system. Another approach is to maintain total order of writes. Assuming some form of consensus protocol to determine write order, the unicity of the order ensures synchronization. That design, however, tends to preserve user intent less. Bitcoin has a form of that.

im_down_w_otp 10y ago
Time isn't a reliable resource in this context.
- espadrine 10y ago
  They mention striving to support many contexts. In the demo, they showcase offline editing of a single CSV entry. If the granularity is the atomic types, then a conflict only occurs when the very same field in the very same row is concurrently edited. Then, the system can show the conflict and offer a default that keeps the operation with the highest timestamp, or if the timestamps are identical, the one with the highest hash.
rdtsc 10y ago
> which requires having a GPS clock and an atomic clock on each datacenter, Right. I'll download an open source database, then buy a commercial GPS clock and attach to it. https://www.amazon.com/Spectracom-1200-033-SECURESYNC-MODULAR-TIMING/dp/B00C8GX96G https://www.amazon.com/Spectracom-1200-033-SECURESYNC-MODULA... Only $12k for a Spectracom. Granted they are nice. Well, I guess if it demonstrates anything is one fact -- if even Google needed GPS hardware to provide "latest" in a distributed system, then OP is right. Time in distributed systems is very hard. > Most designs simply rely on NTP or a similar time synchronization system. Not sure if "simply" was mean sarcastic or not. If reliability and deletion of user's data is important, and it relies on getting NTP time, I would strongly advice not to use that distributed db system.

im_down_w_otp 10y ago

Time isn't a reliable resource in this context.

espadrine 10y ago
They mention striving to support many contexts. In the demo, they showcase offline editing of a single CSV entry. If the granularity is the atomic types, then a conflict only occurs when the very same field in the very same row is concurrently edited. Then, the system can show the conflict and offer a default that keeps the operation with the highest timestamp, or if the timestamps are identical, the one with the highest hash.

rdtsc 10y ago

> which requires having a GPS clock and an atomic clock on each datacenter, Right. I'll download an open source database, then buy a commercial GPS clock and attach to it. https://www.amazon.com/Spectracom-1200-033-SECURESYNC-MODULAR-TIMING/dp/B00C8GX96G https://www.amazon.com/Spectracom-1200-033-SECURESYNC-MODULA... Only $12k for a Spectracom. Granted they are nice. Well, I guess if it demonstrates anything is one fact -- if even Google needed GPS hardware to provide "latest" in a distributed system, then OP is right. Time in distributed systems is very hard. > Most designs simply rely on NTP or a similar time synchronization system. Not sure if "simply" was mean sarcastic or not. If reliability and deletion of user's data is important, and it relies on getting NTP time, I would strongly advice not to use that distributed db system.