Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There Is No Now – Problems with Simultaneity in Distributed Systems

queue.acm.org

Post reply on HN
Print view View original

41–50 of 72 posts

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#41

Post by chousuke »

olau wrote: post #37
logicallee wrote: post #35

Earlier quoted context omitted.

>Lots of people are brainwashed in college to think that all data must be consistent all the time, and that's just not necessary. I knew it! So a foolish consistency is the hobgoblin of little minds.

While I agree strict consistency is probably overkill in many if not most situations, the problem with not having consistency is that it potentially makes the application logic much more complicated. Take the database of customers - so if you don't have consistency, what happens in case someone changes the company address and another person simultaneously requests a delivery of something. Do you risk ending up with h…

"Lack of consistency" here doesn't have to imply lack of atomicity; In the case of your example, an eventually consistent system could return either the old address or the new address at some point in time X, but never a mixture of both. In your situation, the parcel could end up getting delivered to the old address, but there would be no corruption.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#42

Post by xxxyy »

marknadal wrote: post #31
xxxyy wrote: post #28

Earlier quoted context omitted.

Given a set of perfectly synchronized distributed clocks you may not even have to wait the 66ms. Incoming transactions (both local and remote) go into the write-ahead log, their ordering is given by the timestamps (which are consistent, because clocks are synchronized). Periodic heartbeats from other nodes give you a green light to commit or abort parts of the write-ahead log into permanent database. All nodes will m…

Warning, this is a very dangerous practice. The whole point of the article states that machines do fail and that networks are unreliable. He had a specific section in their that even Spanner has a 7ms uncertainty on time. Therefore: You CANNOT trust timestamps or your clock.

Yes, I know. This is a thought experiment, as there is really no such thing as perfectly synchronized clocks.

Also despite the need for futuristic clocks the system lacks resistance to failure (no heartbeat from arbitrary node -> no transaction gets commited and no transaction gets aborted -> a deadlock). Maybe this is fixable with Paxos, I'm not sure.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#43

Post by macintux »

ajarmst wrote: post #38

Doesn't appear to mention Lamport Timestamps ( https://en.wikipedia.org/wiki/Lamport_timestamps ) (Yes, THAT Lamport), which are one of the most elegant mechanisms to deal with the some of the discussed problems.

> Another such area of work is logical time, manifest as vector clocks, version vectors, and other ways of abstracting over the ordering of events.

Vector clocks and version vectors are variations on the Lamport clock concept (and that quote is from a paragraph that mentions Paxos, another Lamport invention, cited in the bibliography).

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#44

Post by jamespitts »

brianzelip wrote: post #21
jamespitts wrote: post #15

This is an excellent overview. Simultaneity isn't just for machines -- it is necessary for people being connected together online as well. Time sync is a huge part of creating a shared experience, and this will become more widely appreciated as virtual reality develops socially. We solved this in a very limited way at rapt.fm for our timed rap battles. We maintained a shared clock tick (with adjustment), allowing UI…

:) for the dude eating from a bowl of cereal at the end of the rapt.fm landing page background vid

Yes, that is me! We had a lot of good times in downtown Det.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#45

Post by nostrademons »

olau wrote: post #37
logicallee wrote: post #35

Earlier quoted context omitted.

>Lots of people are brainwashed in college to think that all data must be consistent all the time, and that's just not necessary. I knew it! So a foolish consistency is the hobgoblin of little minds.

While I agree strict consistency is probably overkill in many if not most situations, the problem with not having consistency is that it potentially makes the application logic much more complicated. Take the database of customers - so if you don't have consistency, what happens in case someone changes the company address and another person simultaneously requests a delivery of something. Do you risk ending up with h…

Note that the real world operates like this too: before computers, if someone changes their address and simultaneously sends a package, the package probably will end up at the wrong address. We have a number of mechanisms in place to mitigate this when it occurs (address forwarding, return-to-sender, customer support, credit card chargebacks), but they still don't always work, and sometimes packages just get lost.

The real world solution to this is the acceptance that yes, sometimes bad things happen for no reason at all. I suspect that the computer world will eventually move to this as well, with consumers becoming more tolerant of machines that simply give the wrong answer some of the time, as long as they give the wrong answer less frequently as a human would.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#46

Post by yodsanklai »

> One of the most important results in the theory of distributed systems is an impossibility result, showing one of the limits of the ability to build systems that work in a world where things can fail.

Layman question. I wonder how important this result really is. This is an impossibility result in a certain model, where processes are deterministic. It's certainly a nice theoretical result but in practice, there are probabilistic algorithm that solve this problem.

I don't know what are the probabilistic bounds of probabilistic consensus algorithms, but if it's arbitrary low, the impossibility result for deterministic processes is irrelevant isn't it?

After all, if we can live with a super low probability of a meteorite destroying the planet, so can we with a good probabilistic consensus algorithm.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#47

Post by hyperion2010 »

I really enjoy the perspective that "now" is often a useful abstraction for certain types of processes. The fact that it turns out that "now" is one hellishly leaky abstraction. My perspective coming from biology is that for many systems the only meaningful type of "clock" is a logical clock. The important thing is not "when," when is used as a proxy for an assumed state of a remote part of the system (even if remote is only 10cm away), logical clocks are the only source that can guarantee that the state of the system is what you expect it to be so that it will perform as expected. Thanks to the many hardware guys who have spent years working out the underlying logic for this we mostly ignore it for things like processors. Now we just need to solve it for arbitrarily large finite delays! This also reminds me of a very funny (or depressing) read on systems engineering by James Mickens [1].

1. http://research.microsoft.com/en-us/people/mickens/thenightw...

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#48

Post by threeseed »

rdtsc wrote: post #11

Keeping an always consistent state in a large distributed you are fighting against the law of physics. Like it is mentioned, Google did it with their F1/Spanner SQL database. But that also mean GPS receivers with antennas on the roofs of data centers. Which is yet another thing that can fail and it, either by itself or in a cascade of other failures will lead to unspecified and possibly undesirable behavior. Recently…

> Recently I see a lot of advocates of dropping NoSQL databases and moving back to Postgress or other SQL databases.

This is just from a vocal minority on HN. You just need to look at the facts.

Companies like Mongo, Datastax, Aerospike etc are growing bigger by the day, with increasingly higher valuations. Old school database companies like Teradata are now all about datalakes incorporating Hadoop and Mongo. And technologies like Spark, Impala are now on the front line for many data analytics and processing work.

In the enterprise at least SQL databases are increasingly being relegated to a small part of the whole data pipeline i.e. storing the consolidated, integrated data model.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#49

Post by threeseed »

bdamm wrote: post #24
logicallee wrote: post #19

Earlier quoted context omitted.

I'm not an expert, and it sounds like you are, so I appreciate your feedback here: what do you even mean by a consistent state? even in theory a person initiating a new additional record in Auckland, New Zealand at the same time somebody iniatiates a change in Gibraltar or London (which are antipodal to the former[1]) 66 milliseconds away, cannot have a confirmation in less than 120 milliseconds, right? So do you jus…

There are many systems which can work just fine in an eventually-consistent manner. A database of people (customers, users, etc) is a classic example of such a thing. In general I think consistency is over valued. There are plenty of cases where it is important. Lots of people are brainwashed in college to think that all data must be consistent all the time, and that's just not necessary.

Couldn't agree more. Most people don't know that many critical systems e.g. banking are eventually consistent and rely on other methods.

The concepts of CQRS and Event Sourcing really need to be taught at universities.

Re: There Is No Now – Problems with Simultaneity in Distributed Systems

#50

Post by nosuchthing »

stcredzero wrote: post #26
jchrisa wrote: post #20

Earlier quoted context omitted.

If you want to let a mature open source sync system do the heavy lifting we've recently added Unity 3D support to Couchbase Lite. http://developer.couchbase.com/mobile/unity/ Hello world is a game where players drop shapes into a world and they automatically sync / appear on other devices. Sorry about the plug -- great article Justin! I sent it to my team because I think it does a great job stepping back from the buz…

Interesting. However I'm not just looking for syncing stats and inventory. What I'm talking about is designing a new game mechanic around the realities of distributed gaming, then designing a more robust server around that. The server will be finalizing entity positions, damage, and collisions a half second behind "real-time," and the game mechanic will be designed around this in a way that preserves player autonomy…

In competitive video games, if you give the client a large open window of freedom sooner or later you'll notice that window being used as a door by swaths of your userbase.
Post reply on HN