Hacker News new | ask | show | jobs
by tlarkworthy 4113 days ago
Spanner is externally serializable so you do get a 'now'. You just don't know what the agreed now was until after the write.

The idea that there is no 'now' is of course, preposterous, we have very strict laws of physics supporting the concept of now (sans relativity) and eventually our engineering will be able to track that very accurately. Spanner is a step on that journey.

These kinds of 'impossible' articles will appear very dated in 10 years time, as they are really over exaggerating the rules-of-thumb of the previous 10 years.

1 comments

> we have very strict laws of physics supporting the concept of now (sans relativity)

Laws of physics "sans relativity" aren't the actual laws of physics in our universe. There very much is no now except the now that is also here. Its quite accurate to say that simultaneity does not exist in distributed systems, and simultaneity is less valid as even an approximation the more widely distributed a system is.

To add some context & numbers to dragonwriter's point, the speed-of-light delay from New York to San Francisco is about 21ms [1]. This is about 5 disk seeks, 1200 random SSD reads, 200K main memory reads (without caching), or 10M CPU cycles [2]. Speed of light delays absolutely matter in a distributed system.

[1] http://chimera.labs.oreilly.com/books/1230000000545/ch01.htm...

[2] http://www.eecs.berkeley.edu/~rcs/research/interactive_laten...

that's transmission delays not relativistic effects. The idea of spanner is you have a timestamp of when it was decided to commit. The quorum knows they can't contact each other quickly but they trust each others timestamps and resolve conflicts based on the trusted commit times (which are accurate through hardware). Transmission delays don't undermine the fact there is a very real concept of ordered time in the physical world which is exploitable[1]. Spanner exploits it faster than transmission delays, but with a clock error of 10 ms or something. We have better clocks than that so its probably going to improve...

[1] sans relativity effects which are TINY, and not the limiting factor at the moment.

Furthermore, at the timescales (nanoseconds) and distances (meters to thousands of kilometers) at which a distributed application operates, relativity is a much better approximation to reality than the intuitive Newtonian physics.

If 3D chip designs let us take a couple racks of hardware into a few centimeters, then perhaps there will be a more Newtonian "now" possible, but it seems that once we can do that we'll just want to build even bigger systems that can analyze more data, and get back to distributed systems again.

Delays do not affect ordering.

Relativity means that observers with different velocities view timings differently.

Mere distances do not matter.

Pick a reference frame for your protocol, and relativity stops being a problem. (Hint: If all endpoints are on Earth you probably won't have enough precision to even need to compensate for relativistic effects.)

Delays alone do affect the ordering perceived by receivers at different locations.
Only for a very misleading definition of ordering. Delays affect the order in which receivers see events, but the receivers can compensate for transmission factors and calculate the exact same times for all events.

Except when relativity kicks in from the observers moving at different speeds. Now events that are outside each other's light cones have no objective order.

That definition of ordering is of course the standard, everyday definition. And to guarantee correct compensation for transmission factors in the same frame, do we not require perfectly synchronized local clocks: impossible in general?
>That definition of ordering is of course the standard, everyday definition.

I would disagree and say the standard definition is the order things happen in, not when you feel the effects. There's rarely a different in practice, though, because people usually experience things via sight at a distance of miles at most. And in one of the few places where it differs, astronomy, people talk all the time about how events 'actually' happened a massive amount of time in the past.

But that doesn't matter. We're talking about relativity. Order, when talking about relativity, clearly means the timing of the events themselves, not the reception of the events.

You need such a definition before you can understand the ways even that can vary per observer. And importantly, the specific ways it can't vary per observer.

>And to guarantee correct compensation for transmission factors in the same frame, do we not require perfectly synchronized local clocks

Not at all. We do need to agree on a same reference frame (because different reference frames give different rates of time and different distances). Thankfully everyone on earth is in the same reference frame to a very very precise degree. And if that's not good enough you can do a few calculations to get nearly perfect compensation for different altitudes and latitudes and such.

Our clocks don't have to be in the same century to say that light A went on before light B. You just take the point in time you saw each fiber light up and subtract the distance of the fiber times propagation speed. And then you could set both clocks to be in sync by using A or B as a reference point, if you wanted.

The error bars on relativistic affects we can expect to experience on earth are pico seconds. So we can pack millions of transactions per second if we get our clocks syncs correct and reliable. The future dbs will be not like we have now.