3 ms·
This depends on what you mean by "atomic". Prior to 5.0, MongoDB's defaults were to use a sub-majority write concern. This allowed all kinds of interesting atom
by aphyr 3y ago
This depends on what you mean by "atomic". Prior to 5.0, MongoDB's defaults were to use a sub-majority write concern. This allowed all kinds of interesting atomicity violations, even on single documents. For instance, you could write a value, some clients might read it, and then your write would be silently lost as if it never happened. Clients could disagree on whether the write happened or not. A single client could observe, then un-observe the write. It gets weird. :-)
- leoqa 3y agoThis is actually an evolved model, as the system has to handle data loss as a primitive upfront. Similar to how Rust forces you to reason about allocators.
- hnfong 3y agoAre you saying data loss is a positive feature of MongoDB because it forces systems that use it become more robust to deal with the data loss?
- leoqa 3y agoYes
- camgunz 3y agoNah they're super different. Rust failing at compile time means you fix the bug before you ship it, which is helpful. MongoDB failing in production means either you fix the bug via testing before shipping, or you discover the bug after shipping, which is at best extra work and at worst disastrous.
- Thaxll 3y agoBut this is not a design problem, all clustered DB work like that this is more a configuration issue.
- growse 3y agoUm, no they don't?
- Thaxll 3y agoWhen you have a multi master setup, usually they all work the same, see Cassandra: https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/dml/dmlConfigConsistency.html https://docs.datastax.com/en/cassandra-oss/3.0/cassandra/dml... https://opensource.docs.scylladb.com/stable/cql/consistency.html https://opensource.docs.scylladb.com/stable/cql/consistency....