Awesome, as per usual.
Jepsen articles are less exciting when the database doesn’t start on fire and kill your dog. I like less exciting in this case.
Yeah, kinda like watching car racing: you feel bad about wanting to see crashes, but that potential is certainly one of its attractions.
The tone’s markedly different on this one, given the results (defaults broken by design, only maximalist safety configuration gives you linearizability). Huh.
I don’t think that consistency modes other than linearizable consistency are “broken by design,” they just make a different tradeoff. Imagine that you’re lobsters, and decide to build it on top of rethinkdb. Someone writes a post, and publishes it. You check new posts and don’t see your post immediately because you end up talking to a primary that was partitioned away.
This is the absolute worst case scenario that can happen under the default (majority write, single read), and it only happens when a primary is partitioned away and doesn’t realize it yet.
So this is still a pretty strong consistency guarantee. And as soon as the primary realizes it’s not the primary any more, it’ll get the new information.
With that said, I don’t think the takeaway from Aphyr’s blog should be, “Never use anything that doesn’t have strong consistency”. I think it should probably be, “make sure you understand your consistency guarantees, because sometimes it matters–eg folks will end up unhappy if you give two people the same handle”. There are significant latency and throughput disadvantages to requiring linearizable consistency for every single request, so make sure you understand your business requirements and engineer to what you need.
For what it’s worth, I don’t usually look at a persistence problem and think, “Oh yeah, I really need this to be linearizable.” In fact, there are probably a lot of use cases of rethinkdb where I would rather use single write and single read.
Sorry, it was a snarky reference to https://aphyr.com/posts/322-jepsen-mongodb-stale-reads. I understand consistency pretty well, was just having a bad day and decided to be an ass.
In addition to what moses said, also note that RethinkDB is functioning exactly as documented. They don’t make claims they can’t back up, unlike some previously analyzed systems.
Choosing your guarantee on a per-request basis is fairly common as it puts more power in the user’s hands. For example, DynamoDB’s reads are eventually consistent. You must explicitly ask for a strongly consistent read in your request if that’s what you want.
I always felt the tone differences between the mongodb and cassandra reviews were odd, given that the results seemed very similar.
He recently announced that he would be writing these articles in exchange for payment. I believe they are his customers.