Live data from Hacker News

Diving Deep on S3 Consistency

allthingsdistributed.com

21–30 of 55 posts

Re: Diving Deep on S3 Consistency

#21
Can someone elaborate on this Witness system OP talks about?

I'm picturing a replicated, in-memory KV store where the value is some sort of version or timestamp representing the last time the object was modified. Cached reads can verify they are fresh by checking against this version/timestamp, which is acceptable because it's a network+RAM read. Is this somewhat accurate?

Re: Diving Deep on S3 Consistency

#22

Recent S3 consistency improvements are welcome, but S3 still falls behind Google GCS until they support conditional PUTs. GCS allows object to be replaced conditionally with `x-goog-if-generation-match` header, which sometimes can be quite useful.

Vogels spoke briefly about why AWS prefers versioned objects instead here: https://queue.acm.org/detail.cfm?id=3434573 BTW, DynamoDB supports conditional PUTs if your data can fit under 400 KiB.

How do versioned objects make conditional puts unnecessary? I see little relation between them, except that you could use the version identifier in the condition.

Re: Diving Deep on S3 Consistency

#24

Here's what I take away from this post: > We built automation that can respond rapidly to load concentration and individual server failure. Because the consistency witness tracks minimal state and only in-memory, we are able to replace them quickly without waiting for lengthy state transfers. So this means that the "system" that contains the witness(es) is a single point of truth and failure (otherwise we would lose…

They've basically bolted on causal consistency.

It's a great change.

Re: Diving Deep on S3 Consistency

#26

I'm confused...did you fix the caching issue in S3 or not? The article seems to explain why there is a caching issue, and that's understandable, but it also reads as if you wanted to fix it. I would think the headliner and bold font if it was actually fixed. For those curious, the problem is that S3 is "eventually consistent", which is normally not a problem. But consider a scenario where you store a config file on S…

This is a general problem in all distributed systems, not just when pulling configuration from S3. Let's assume you had strong consistency in S3. If your app is distributed (tens, hundreds, or thousands of instances running) then all instances are not going to update at the same time, atomically. You still need to design flexibility into your app to handle the case where they are not all running the same config (or s…

The deeper in your stack you fix the consistency problem, the simpler the rest of your system needs to be. If you use S3 as a canonical store for some use case, that's pretty deep in the stack.

> Thus, once you've built a distributed system that is able to handle a phased rollout of software/config versions (and rollback), then having cache inconsistency in S3 is no big deal.

But this would also mean you can't use S3 as your source of truth for config, which is precisely what a lot of people want to do.

Re: Diving Deep on S3 Consistency

#27

Earlier quoted context omitted.

Vogels spoke briefly about why AWS prefers versioned objects instead here: https://queue.acm.org/detail.cfm?id=3434573 BTW, DynamoDB supports conditional PUTs if your data can fit under 400 KiB.

How do versioned objects make conditional puts unnecessary? I see little relation between them, except that you could use the version identifier in the condition.

Because they let AWS offload the hard part to you, which is what AWS does best :)

Re: Diving Deep on S3 Consistency

#28
post #7

I'm confused...did you fix the caching issue in S3 or not? The article seems to explain why there is a caching issue, and that's understandable, but it also reads as if you wanted to fix it. I would think the headliner and bold font if it was actually fixed. For those curious, the problem is that S3 is "eventually consistent", which is normally not a problem. But consider a scenario where you store a config file on S…

Yes, see my December 2020 post at https://aws.amazon.com/blogs/aws/amazon-s3-update-strong-rea... : "Effective immediately, all S3 GET, PUT, and LIST operations, as well as operations that change object tags, ACLs, or metadata, are now strongly consistent. What you write is what you will read, and the results of a LIST will be an accurate reflection of what’s in the bucket. This applies to all existing and new S3 obj…

Thanks for the link, it made the change being talked about clearer. However, I still don't understand how it was achieved. The explanation in the link appears truncated - lots of talk about the problem, then something about a cache and that's it. Is there an alternate link that talks about the mechanics of the change?

Re: Diving Deep on S3 Consistency

#29
post #13

Anyone else still seeing consistency problems w/S3 & EMR? The latest AWS re:Invent made it sound like this would be fixed but as of yesterday I was still using emrfs to correct S3 consistency problems.

Yeah, yesterday as well

Re: Diving Deep on S3 Consistency

#30

Recent S3 consistency improvements are welcome, but S3 still falls behind Google GCS until they support conditional PUTs. GCS allows object to be replaced conditionally with `x-goog-if-generation-match` header, which sometimes can be quite useful.

Vogels spoke briefly about why AWS prefers versioned objects instead here: https://queue.acm.org/detail.cfm?id=3434573 BTW, DynamoDB supports conditional PUTs if your data can fit under 400 KiB.

Why would AWS provide a feature that makes additional transaction and storage charges (as well as subsequent reads to see which is the correct version) irrelevant?
Post reply on HN