I believe this makes Amazon S3 behave more similar to Azure blob storage[1] and Google Cloud Storage[2], which is pretty convenient for folks who are abstracting blob stores across different offerings. For what it’s worth, consistency in S3 was usually pretty good anyways, but I ran into issues where it could vary a bit in the past. If you designed your application with this in mind, of course, it shouldn’t be an iss…
S3 Strong Consistency
51–60 of 240 posts
Re: S3 Strong Consistency
#52[deleted]
Re: S3 Strong Consistency
#53Disclosure: I work on Google Cloud.
This is super awesome for customers. I am also beyond excited for all the open-source connectors to finally be simplified so that they don't have to deal with the "oh right, gotta be careful because of list consistency". It was super awesome when we were able to delete a huge chunk of the GCS Connector for Hadoop, and I hope to see the same across the S3-focused connectors.
I'm now much more inclined to make my GCS FUSE rewrite in Rust also support S3 directly :).
Re: S3 Strong Consistency
#54we use s3 in a repo pattern pretty heavily and I had no idea they didn't have read-after-write consistency. I've noticed s3 will hold connections open by sending back blank lines and always assumed it was synchronizing for consistency.
Re: S3 Strong Consistency
#55It's interesting to read all these comments here that talk about the eventual consistency like it was some kind of bug.
Re: S3 Strong Consistency
#56[deleted]
Re: S3 Strong Consistency
#57Earlier quoted context omitted.
I think it was already strongly consistent within regions? like if you had tried to read a non-existent key, then wrote to it, it might continue to appear to not exist for a minute?
Their previous consistency was RAW, but not RAU (for most regions. I think us-east-1 was missing RAW consistency for quite a while). After a write, you would _always_ be able to read the key you just wrote. After an update, you could get a stale copy of the key if your subsequent read hit a different server.
Not quite _always_. There were some documented caveats... the one I hit before was:
Read nonexistent key, followed by a write of that same key, and then a subsequent read could return a stale read saying it didn’t exist. (even though it had just been written for the first time.)
Anyway I am glad to see these gaps and caveats have been closed.
Re: S3 Strong Consistency
#58Has anyone ever seen S3 behave eventually consistent? I have not seen a lot of eventual consistency in the real world but I wonder if I'm just working on the wrong problems?
Yes, we have. Specifically: 1. LIST 2. PUT 3. LIST would trigger situations where (3) wouldn't include the object inserted in (2). This is well-known however.
Also:
1. HEAD key -> 404
2. PUT key -> 200
3. GET key -> 404 (what? But I just put it!)
Re: S3 Strong Consistency
#59Neat! Would this make it possible in the future for S3 to support CAS like operations for PutObject? Something like supporting `if-match` and `if-none-match` headers on the etag of an object would be so useful.
Re: S3 Strong Consistency
#60This was a problem with data lakes / analytics. Small inconsistencies would trash runs; that problem now goes away and removes a lot of janky half-fixes to work around the issue. For most common use cases it's not really an issue.
Of course the real issue there is those tool treating S3 as something it's not (a filesystem) and building things on it with the expectation of certain guarantees that it explicitly didn't provide before now. I dig the feature (strong consistency) but in some ways it just enables tools that were abusing it to just do so more easily.
Like RedShift? AWS uses S3 as a database, seems reasonable that their customers would.