5 ms·

Looking at the paper it looks like instead of dealing with exact moments in time (eg timestamps) they have ranges (they call them intervals). From the Spanner

by dhotson 14y ago

Looking at the paper it looks like instead of dealing with exact moments in time (eg timestamps) they have ranges (they call them intervals). From the Spanner paper: "TrueTime explicitly represents time as a TTinterval, which is an interval with bounded time uncertainty (unlike standard time interfaces that give clients no notion of uncertainty)" By representing time as intervals you can tell if one interval is definitely before or after another interval. If the intervals overlap however, then it means there's some uncertainty. I haven't quite got through the paper far enough to undersand how this kind of thing is handled. :-) But I'm guessing that this kind of design means they're always consciously designing with error in mind. There's probably some acceptable amount of error in timing that they're able to carefully manage. Edit: link to the paper for the lazy [pdf] http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/spanner-osdi2012.pdf http://static.googleusercontent.com/external_content/untrust... Edit 2: It looks like the error typically ranges from 0 to 7ms averaging around 4ms. Outages can cause spikes in this error margin.

snewman 14y ago
They handle uncertainty by delaying the transaction commit. Suppose you commit a transaction and at that moment, the error bar for time (on the server that handles your transaction) is 4 ms. The server will wait 4 ms to tell you the transaction completed. The result is that if two transactions commit near-simultaneously, it's random which will be assigned a lower timestamp, but guaranteed that no one will observe either transaction until after the timestamp at which that transaction is deemed to have committed. Basically, they handle the window of uncertainty by pausing access to the affected rows so that no one can peek into the window.
- toomuchtodo 14y ago
  Temporal row-level locking.

by dhotson 14y ago

snewman 14y ago

They handle uncertainty by delaying the transaction commit. Suppose you commit a transaction and at that moment, the error bar for time (on the server that handles your transaction) is 4 ms. The server will wait 4 ms to tell you the transaction completed. The result is that if two transactions commit near-simultaneously, it's random which will be assigned a lower timestamp, but guaranteed that no one will observe either transaction until after the timestamp at which that transaction is deemed to have committed. Basically, they handle the window of uncertainty by pausing access to the affected rows so that no one can peek into the window.

toomuchtodo 14y ago
Temporal row-level locking.