This is literally their "we are the fastest database just turn off commits" claim, but now in a distributed manner.
I don't recall them ever saying this.
They shipped with syncs turned off by default.
EDIT: actually it was journaling of writeconcerns. Later they backtracked and enabled it by default, but by then their reputation was cemented (or bifurcated into fast, or terrible, I suppose).
https://shekhargulati.com/2011/12/08/how-mongodb-different-w...
Those don't sync to disk on every write.
It will let you delay commits — if you ask it to — so it may batch multiple commits together on a single fsync, but it will NOT report to you that it has saved data durably when it hasn't. Because this is a safe operation, PG will let you do this easily: even on a per-session or per-transaction basis.
Similarly, you can ASK it to commit eagerly without waiting for fsync, again on a per-session or per-transaction basis. But it will never turn on by default, and the documentation of this option clearly calls out the risk: "an operating system or database crash might result in some recent allegedly-committed transactions being lost"
Or more too: you can ask it to turn off fsync (and all other kinds of sync) entirely and risk total database inconsistency — say, because you are running it on a filesystem that guarantees consistency, like ZFS — but it strongly recommends against it just on the off-chance that some over-eager user carelessly turns it off. Because this is generally not a safe thing to do, PG will NOT let you do this easily: you MUST change the server config on disk and restart the cluster.
I don't know about MySQL, but I'd be greatly surprised if they did anything like what MongoDB used to do. There's a reason MongoDB got that reputation, in a world where MySQL — and its surprising data-eating behaviours — already were popular.
Yes, but the product has been advertised from the beginning on the basis of how easy it is to grow horizontally; the whole "It's webscale!" argument.
----
> Eventual consistency only comes in when you introduce multiple nodes / secondaries. As long as you connect to the primary for reads, you'll never get stale data.
1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it.
2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
Is this any different than how things work in eg Postgres?
> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
The main driver behind secondaries is redundancy/durability. If the primary goes down, there's no/very little overall service interruption.
If you need the latest data, read from the primary. If you care more about faster reads than perfect data accuracy, read from a secondary.
> Is this any different than how things work in eg Postgres?
1. The comment of mine you are replying to applies to any DB that uses Eventual Consistency, as can be seen above it.
2. Yes, this is different in PG simply because PG doesn't do Eventual Consistency by default.
>> 2. The whole point of adding secondaries — again, the "webscale!" argument — is to scale read capacities
> The main driver behind secondaries is redundancy/durability.
In general, maybe — or even maybe in your specific use-cases. But Mongo's prescribed use-cases — the ones they marketed, heavily, even going so far as to make up terms like "webscale" — are about 'performance' and 'scale'. I specifically call this out in my comment.
As you say, eventual consistency only comes in with multiple nodes. And unless you are willing to sacrifice availability, eventual consistency is the only game in town in a multi-node scenario.
In “eventual consistency” you could read the committed value at some time, no value, or another committed value depending on the exact implementation. It’s a much, much weaker consistency model than Sequential Consistency and Session/Causal Consistency is the closest you can even get to sniffing a stricter model.
I had a longer comment about this new page and MongoDB as a whole but I’ll just swallow my words. They know what they’ve done and don’t really care.
Writes can get lost if the primary dies and the secondary is promoted in the meanwhile.
That is literally the definition of eventual consistency. How you achieve it doesn't matter to being eventually consistent, just that it is.
See my other comment above for distinguishing between EC and Sequential.
OP is arguing the blog post is trying to change the definition of "eventually consistent"... the author is saying the delay between the master and slave is not "eventually consistent"... when, exactly as you say, it is.
This is what eventually consistent means! If i wrote (key=X, value=Y) to a primary, then read X and see a value thats not Y (because the secondary node hasn't caught up yet), that is inconsistency. Strong consistency (e.g in a single node SQL database) would mean its impossible to read stale values.