4 ms·
> This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion
by nathan_long 8y ago
> This interpretation hinges on interpreting successful sub-majority writes as not necessarily successful: rather, a successful response is merely a suggestion that the write has probably occurred, or might later occur, or perhaps will occur, be visible to some clients, then un-occur, or perhaps nothing will happen whatsoever.
> We note that this remains MongoDB’s default level of write safety.
This sounds pretty scary. How does it compare to other distributed dbs, like Riak? My understanding is that Riak lets you specify how many nodes a write must succeed on to be considered successful. Are its responses more reliable? Is this just a "distributed computing is hard" situation?
- TheDong 8y ago> Is this just a "distributed computing is hard" situation? I think this is "gaming performance benchmarks and being right is hard". MongoDB has spent a lot of effort on making sure it looks good in benchmarks, and that includes using worse defaults than any other distributed data-store I know of. As long as MongoDB continues to wish to "win" at performance benchmarks by so much, they'll have trouble being able to provide a correct distributed system by default.
- chris_st 8y agoAnd this is why I appreciate the analysis by aphyr (and kit!) so much... it really shows what's actually happening. Just sad that it takes so long to do this depth of analysis...
- emmelaich 8y agoIt's not just distributed computing and being right is hard. Most consumers of computing are happier with value and computers being mostly right/useful/evailable. Evidence: the entire history of computing.
- nathan_long 8y agoThis isn't about distribution, but someone once wrote about getting PostgreSQL upsert performance to be better than MongoDB's by disabling some of PostgreSQL's safety features. https://markandruth.co.uk/2016/01/08/how-we-tweaked-postgres-upsert-performance-to-be-2-3-faster-than-mongodb https://markandruth.co.uk/2016/01/08/how-we-tweaked-postgres... This made me laugh. Snarky interpretation: "yeah, we can go fast and sloppy, too. We just usually don't."
- Thaxll 8y agoIt's the same for every DB, like you can say MySQL to ack a write but there was no fsync(). All those settings are usually tunable for various scenarios / performance you want.
- aphyr 8y agoIt is, in fact, not the same for every DB. Databases vary significantly in their default and maximum guarantees for successfully acknowledged writes; Mongo chooses fairly weak ones. By contrast, consider systems like VoltDB, which aims for strict serializability by default, or etcd, which offers linearizability/sequential reads by default.
- nvarsj 8y ago> etcd, which offers linearizability/sequential reads by default Not quite true - you have to opt-in to quorum reads in etcd. Otherwise it just returns the first read (which used to be the default in k8s and caused a lot of grief).
- aphyr 8y agoAh, yes, sorry! I forgot exactly how that all shook out. I thiiink that prevents dirty reads, and with client monotonicity you can recover sequential consistency? Not sure how many clients actually do that; maybe they just do regular reads at RC...
- ideal0227 8y agoThat is true. etcd v3 provides l-read by default. You have to opt-out that to improve latency.
- ideal0227 8y agoNo. You are wrong. etcdv3 enables l-read by default.
- jimktrains2 8y ago
- throwaway5752 8y agoBasho went bankrupt over a year ago. Riak is still around, but I encourage checking out the level of support for it. Redis, Cassandra, Couch, Influx might be good alternatives depending on your use case.