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

S3 Strong Consistency

aws.amazon.com

Post reply on HN
Print view View original

141–150 of 240 posts

Re: S3 Strong Consistency

#141

Post by robotresearcher »

howlgarnish wrote: post #64
k__ wrote: post #55

It's interesting to read all these comments here that talk about the eventual consistency like it was some kind of bug.

Are there any scenarios where you would want eventual consistency over strong consistency? (Assuming pricing, performance, replication etc are the same.)

No. A magical do-everything datastore would have strong consistency. Eventual consistency is something you might settle for given the performance cost trade offs.

To see this, consider that strong consistency has all the guarantees of eventual consistency, plus some more. And the additional guarantees might make your application much easier to write.

Re: S3 Strong Consistency

#142

Post by sleepydog »

stubish wrote: post #85

Once libraries and tools start relying on this, it is going to make life interesting to the S3-compatible players. The API remains the same, but the behavior is quite different.

Google Cloud storage has behaved this way for years. According to other comments, so does Azure.

Re: S3 Strong Consistency

#143

Post by valenterry »

jrbancel wrote: post #126
valenterry wrote: post #123

Earlier quoted context omitted.

> (of their metadata database) With that you have just moved the question to: how do they ensure that the metadata database is available _and_ strongly consistent at the same time for all the requests? Because the metadata database is certainly also a distributed one, hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency (or availability if you choose to down the system…

> hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency I am not sure this is true. It is prohibitively expensive to read from all replicas. All you need to ensure is that any replica has the latest state. See how Azure Storage does it [0]. Another example is Spanner [1] that uses timestamps and not consensus for consistent reads. [0] https://sigops.org/s/conferences/so…

Yes, so to quote from it [0]:

> This decoupling and targeting a specific set of faults allows our system to provide high availability and strong consistency in face of various classes of failures we see in practice.

What that says is: for the failures we have seen so far, we guarantee consistency and availability. But how about the other kind of failures? The answer is clear: strong consistency only is guaranteed for _certain expected_ errors, not in the general case. Hence generally speaking, strong consistency is _not_ guaranteed. As simple as that. Saying it is guaranteed "in practice" is, pardon, stupid wording.

Re: S3 Strong Consistency

#144

Post by ramraj07 »

PetahNZ wrote: post #89
ramraj07 wrote: post #50

Earlier quoted context omitted.

That sounds _very_ wrong, what type of throughput are we talking about here?

Up to hundreds of images per second.

Okay that makes sense, when we have very low throughput it looks like consistency wasn't an issue but at that rate (especially if it occurs in bursts) I can see how the prior S3 implementation could fail to scale fast enough

Re: S3 Strong Consistency

#145

Post by toolslive »

valenterry wrote: post #123
YZF wrote: post #90

Earlier quoted context omitted.

While I don't know the specifics I can say that availability is down to engineering practices. Let's say that their consistency model is achieved via quorum, that is writes write to a quorum of nodes while reads read from a quorum of nodes (of their metadata database) then this guarantees read after write consistency. The availability aspect of this is just engineering, making sure you're never down to less than a qu…

> (of their metadata database) With that you have just moved the question to: how do they ensure that the metadata database is available _and_ strongly consistent at the same time for all the requests? Because the metadata database is certainly also a distributed one, hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency (or availability if you choose to down the system…

> hence you need to query _all_ the nodes or can end up in a split-brain situation and lose consistency (or availability if you choose to down the system or a part of the system).

No.Depending on the type of consensus algorithm you can get away with reading from a majority or nodes or even less: for example in a Multipaxos system you just read from the master.

Re: S3 Strong Consistency

#146

Post by bxji »

jabl wrote: post #137
marwan-nwh wrote: post #130

Earlier quoted context omitted.

And that latency means that some reads won't see the latest write, right? Do I understand this correctly?

If you want consistency, you have to pay for it with latency, since the system has to do work in the background to ensure that the data you read is really the latest. If you care more about latency than consistency you have an 'eventually consistent' system, where a write will eventually propagate, but a read might get stale data.

> If you care more about latency than consistency you have an 'eventually consistent' system, where a write will eventually propagate, but a read might get stale data.

Not just stale data, you can also have states which never actually existed. I'll steal the example from Doug Terry's paper "Replicated Data Consistency Explained Through Baseball" because it's really good. Linked below.

Say you have a baseball game which is scored by innings. It's the middle of the 7th inning, and the true write log for the state of the game is as follows:

  Write ("home", 1)
  Write ("visitors", 1)
  Write ("home", 2)
  Write ("home", 3)
  Write ("visitors", 2)
  Write ("home", 4)
  Write ("home", 5)
If you were to read the score at this point in time, and your system is strongly consistent, the score can only be 2-5 or a refusal to serve the request. If your system is eventually consistent, the score can be any of the following: 0-0, 0-1, 0-2, 0-3, 0-4, 0-5, 1-0, 1-1, 1-2, 1-3, 1-4, 1-5, 2-0, 2-1,2-2, 2-3, 2-4, 2-5.

Source paper: https://www.microsoft.com/en-us/research/wp-content/uploads/...

Re: S3 Strong Consistency

#148

Post by pas »

ultimoo wrote: post #105

> S3 consistency is available at no additional cost and removes the need for additional third-party, services, and complex architecture. I wonder whether any companies/businesses solely depended on offering eventual consistency workarounds that probably now need to pivot.

The hadoop companies spent quite some bucks on developing S3Guard, and selling it.

https://hadoop.apache.org/docs/r3.0.3/hadoop-aws/tools/hadoo...

Re: S3 Strong Consistency

#149

Post by awssucs »

“After a successful write of a new object or an overwrite of an existing object, any subsequent read request immediately receives the latest version of the object.” - being able to issue a read after a write has been the case in any system ever.

AWS solving a fabricated issue, and the crowd cheering it as progress. Have to love herd mentality.

Re: S3 Strong Consistency

#150

Post by throwaway_dcnt »

tutfbhuf wrote: post #139

Ask HN: I have a question regarding strong consistency. The question is related to all geo distributed strong consistent storages, but let me pick Google Spanner as example. Spanner has a maximum upper bound of 7 milliseconds clock offset between nodes, thx to TrueTime. To achieve external consistency, Spanner simply waits 7 ms before committing a transaction. After that amount of time the window of uncertainty is ov…

Partitioning.
Post reply on HN