How does this compare to Cloudflare's durable objects?
S3 Strong Consistency
191–200 of 240 posts
Re: S3 Strong Consistency
#192so many posts about amazon, i like AWS but this looks pretty much like advertising haha
The annual AWS re:Invent conference started this week hence the flood of announcements
Re: S3 Strong Consistency
#193Re: S3 Strong Consistency
#194This is really cool. We actually got burned on weak S3 consistency a few weeks ago when generating public download links for a customer. Took us a few hours of troubleshooting to realize they had downloaded a cached/older version of the software we had uploaded to the same URL just a few minutes prior. Resolution was to use unique paths per version to guarantee we were talking to the right files each time. One potent…
It would be a cool interface, I would love to see that.
Re: S3 Strong Consistency
#195I thought we had worked out in 2010-2012 that the CAP theorem, consistency, availability and partition tolerance ( https://en.wikipedia.org/wiki/CAP_theorem#History ) made this impossible? Where is the mistake.
S3 is almost certainly not fully partition tolerant at the node level and requires some sort of quorum. Other “magical” data stores like Spanner also retain this limitation, they just have very reliable replication strategies.
"almost certainly not fully partition tolerant at the node level"
Whoa hang on! You can't just say you're not tolerant of partitions...
I'm struggling to find the best post on aphyr.com about this but https://aphyr.com/posts/325-comments-on-you-do-it-to is a good one, specifically the line:
"CP and AP are upper bounds: systems can provide C or A during a partition, but might provide neither."
In short, Partitions happen, no matter what. No really, when you have multiple nodes they happen, you must tolerate them. You can't have CA.
Re: S3 Strong Consistency
#196The more I learn about S3 the more I feel the same awe I feel when looking at the Pyramids or Ankor Wat. > You can send 3,500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD requests per second per prefix in an S3 bucket.
One fun fact that I learned recently: a prefix is not strictly path-delimited. I would think of /foo/bar and /foo/baz and /bar/baz as having two prefixes, but it could be anywhere from one to three, depending on how S3 has partitioned your data.
I asked around and it seems, that `prefix` here is exact value for `prefix` or `key` query in the API. So you can make 5500 ListObject rps for prefix=/a/b and simultaneously make 5500 GetObject rps for key=/a/b/file1 and not be ratelimited.
In other word ratelimiting key is `${HTTP_METHOD}(${QURERY_PARAM_KEY}|${QUERY_PARAM_PREFIX})`
Re: S3 Strong Consistency
#197Earlier quoted context omitted.
yes for aws it was an issue, what i meant is that aws solved an issue that it itself created.
14 years ago. That is called tech debt. Not an issue. They designed it for the use case at the time. Nobody knew what the cloud was becoming.
I agree nobody knew what the cloud was becoming. But it feels like aws is selling an unfinished product and people are wasting money and time working around non issues. Aws is great for medium sized projects but as soon as your project grows, you bump into silly issues like this one. Given that s3 is more or less a file storage you don’t really expect issues such as “weak” consistency. You expect a file to be committed once written (yes aws can do queueing behind the scenes) but when it returns a 200 ok it means the file was stored. Otherwise the good folks at aws should return a 202 accepted response as all properly designed apis do and let the user know that a delay in reading is expected.
Re: S3 Strong Consistency
#198Earlier quoted context omitted.
Right, https://github.com/GoogleCloudDataproc/hadoop-connectors/rel... was apparently the release: > Delete metadata cache functionality because Cloud Storage has strong native list operation consistency already. If folks are actually interested in these connectors, I'd also recommend this blogpost from last year: https://cloud.google.com/blog/products/data-analytics/new-re... because even with consistency, GCS and S…
Do you have a link to the commits that removed the code. It'd be good to see what sort of complexity this sort of strong consistency can make redundant.
In the case of Hadoop's S3 connector, this could eliminate this entire directory, plus its tests, plus a bunch of hooks in the main code: https://github.com/apache/hadoop/tree/trunk/hadoop-tools/had.... There's an argument in favor of keeping it in case other S3-compatible stores need it (though you'd still need DynamoDB or some equivalent) and because it makes metadata lookups so much faster than S3 scans, which helps with query planning performance. But I imagine even fewer people will take the trade-off now that Amazon S3 itself is consistent.
Re: S3 Strong Consistency
#199It's interesting to read all these comments here that talk about the eventual consistency like it was some kind of bug.
It wasn’t a bug, it was well-documented behavior. However, it was the root of many bugs by people building on top of S3 that did not take the eventual consistency into account.
I’ll bet this release is going to fix a lot of weird bugs in systems out there using S3.
Re: S3 Strong Consistency
#200Earlier quoted context omitted.
S3 is almost certainly not fully partition tolerant at the node level and requires some sort of quorum. Other “magical” data stores like Spanner also retain this limitation, they just have very reliable replication strategies.
"almost certainly not fully partition tolerant at the node level" Whoa hang on! You can't just say you're not tolerant of partitions... I'm struggling to find the best post on aphyr.com about this but https://aphyr.com/posts/325-comments-on-you-do-it-to is a good one, specifically the line: "CP and AP are upper bounds: systems can provide C or A during a partition, but might provide neither." In short, Partitions hap…
I’m not claiming it’s a CA system, and the terminology “partition intolerant” is not verboten by Kyle Kingsbury. From your link: “Specifically, partition-intolerant systems must sacrifice invariants when partitions occur. Which invariants?”
The answer in this case is that availability is sacrificed, unless Amazon is making a very misleading claim of strong consistency (per the submission title/link). So it’s CP.
In case “not fully partition tolerant” is what is throwing you off, all I mean by that is that there are likely network partitions of the S3 nodes that will not cause outward failure (e.g. partition of a single node), though some will (e.g. too many partitions to form a quorum, or whatever their underlying consensus implementation relies on).