6 ms·

> But this is not the case! Some of these parts have never been the case - MongoDB has never been "eventually consistent" - updates are streamed and applied seq

> But this is not the case! Some of these parts have never been the case - MongoDB has never been "eventually consistent" - updates are streamed and applied sequentially to secondary nodes, so although they might be behind, they're never inconsistent. 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.

Cojen 6y ago
The definition of "eventually consistent" is somewhat vague in this respect, or at least easily misunderstood. When updates are streamed and applied sequentially, "eventual" is easily determined as the number of messages that the stream is behind. I'd say that this model is "deterministically consistent", because we know at which point the replicas will all agree with each other without having to perform a full comparison.
- vorpalhex 6y ago
  > Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. [1] That is literally the definition of eventual consistency. How you achieve it doesn't matter to being eventually consistent, just that it is. [1] - https://en.wikipedia.org/wiki/Eventual_consistency https://en.wikipedia.org/wiki/Eventual_consistency
  - Cojen 6y ago
    This makes me wonder how it's possible how to replicate data without being eventually consistent. I can't transmit data faster than the speed of light. It seems that the definitions here need more clarity, because eventual consistency in the broadest sense applies to everything. Is there a good example of replication consistency which isn't "eventual", but is instead immediate?
    - amluto 6y ago
      SQLite, appropriately configured, is trivially linearizable — everything is protected under one lock on one machine.
    - rubiquity 6y ago
      It’s all about when you acknowledge back to the client, whether you accept writes at a single writer or multiple writers, and whether reads can be served from any node. Most EC systems tend to be multi writer with async replication. This means clients get acks immediately and reads to other nodes for those values can contain various values. The speed of the network doesn’t matter from a theoretical perspective. Network speed only affects potential convergence times. Time is time regardless of the unit of measurement. See my other comment above for distinguishing between EC and Sequential.
    - eindiran 6y ago
      This explains it pretty well: https://www.cs.princeton.edu/courses/archive/spr18/cos518/docs/L3-strong-consistency.pdf https://www.cs.princeton.edu/courses/archive/spr18/cos518/do...
    - irjustin 6y ago
      I don't think the OP is arguing that replicated data is not "eventually consistent" because it is as you say. 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.
    - Jasper_ 6y ago
      Here's an overly simple, impractically slow, but immediately consistent model for you: for every request from a client, ask all other nodes in the network the same query. If you get 100% consensus, return the answer, otherwise, ask again.
- rubiquity 6y ago
  Sequential Consistency is the name for this model. Writes don’t get lost but it is weaker than linearizability because you can read after a commit and not get the latest value but eventually (not the same eventual as eventual consistency) you will. Typically data systems provide this to optimize for read scale out, otherwise all reads have to go to the leader. 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.
  - pritambaral 6y ago
    > Sequential Consistency is the name for this model. Writes don’t get lost but ... Writes can get lost if the primary dies and the secondary is promoted in the meanwhile.
    - rubiquity 6y ago
      Yes but this is dependent upon the specific replication protocol. Primary-Backup has this problem but Majority Quorums and Chain Replication do not.
      - pritambaral 6y ago
        The parent is talking specifically about 'Sequential Consistency'.
        rubiquity 6y ago
        My point is that Sequential Consistency isn’t a replication protocol, it’s a consistency model that you can have under various different replication protocols.
nemothekid 6y ago
It's par the course for MongoDB. 10 years later and they still use sales tactics to lie about the capabilities of their database. MongoDB might be a solid database when properly used, but their marketing material, again, promises things that the software just doesn't support. This is literally their "we are the fastest database just turn off commits" claim, but now in a distributed manner.
- threeseed 6y ago
  > This is literally their "we are the fastest database just turn off commits" claim I don't recall them ever saying this.
  - rrdharan 6y ago
    They said they were the fastest. 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-write-concern-values-affect-performance-on-a-single-node/ https://shekhargulati.com/2011/12/08/how-mongodb-different-w...
    - threeseed 6y ago
      It seems quite similar to what MySQL/PostgreSQL is doing with its WAL. Those don't sync to disk on every write.
      - pritambaral 6y ago
        PG fsyncs on every commit. By default. 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.
a13n 6y ago
I mean to be fair, in a single node MongoDB database (one primary, no secondaries), it would be impossible to read stale values as well. 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.
- zaptheimpaler 6y ago
  Yeah I don't know much about MongoDBs past transgressions as a company or have any experience using it so it wasn't intended as a criticism of the company. I just spent a lot of time learning exactly what all these DB terms mean and wanted to point out an inaccuracy so its clearer to people reading. 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.
- pritambaral 6y ago
  > I mean to be fair, in a single node MongoDB database (one primary, no secondaries), it would be impossible to read stale values as well. 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
  - a13n 6y ago
    > 1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it. 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.
ykevinator 6y ago
Yeah that was the one thing I didn't like about this but the rest is good. I love mongo

Cojen 6y ago

The definition of "eventually consistent" is somewhat vague in this respect, or at least easily misunderstood. When updates are streamed and applied sequentially, "eventual" is easily determined as the number of messages that the stream is behind. I'd say that this model is "deterministically consistent", because we know at which point the replicas will all agree with each other without having to perform a full comparison.

vorpalhex 6y ago
> Eventual consistency is a consistency model used in distributed computing to achieve high availability that informally guarantees that, if no new updates are made to a given data item, eventually all accesses to that item will return the last updated value. [1] That is literally the definition of eventual consistency. How you achieve it doesn't matter to being eventually consistent, just that it is. [1] - https://en.wikipedia.org/wiki/Eventual_consistency https://en.wikipedia.org/wiki/Eventual_consistency
- Cojen 6y ago
  This makes me wonder how it's possible how to replicate data without being eventually consistent. I can't transmit data faster than the speed of light. It seems that the definitions here need more clarity, because eventual consistency in the broadest sense applies to everything. Is there a good example of replication consistency which isn't "eventual", but is instead immediate?
  - amluto 6y ago
    SQLite, appropriately configured, is trivially linearizable — everything is protected under one lock on one machine.
  - rubiquity 6y ago
    It’s all about when you acknowledge back to the client, whether you accept writes at a single writer or multiple writers, and whether reads can be served from any node. Most EC systems tend to be multi writer with async replication. This means clients get acks immediately and reads to other nodes for those values can contain various values. The speed of the network doesn’t matter from a theoretical perspective. Network speed only affects potential convergence times. Time is time regardless of the unit of measurement. See my other comment above for distinguishing between EC and Sequential.
  - eindiran 6y ago
    This explains it pretty well: https://www.cs.princeton.edu/courses/archive/spr18/cos518/docs/L3-strong-consistency.pdf https://www.cs.princeton.edu/courses/archive/spr18/cos518/do...
  - irjustin 6y ago
    I don't think the OP is arguing that replicated data is not "eventually consistent" because it is as you say. 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.
  - Jasper_ 6y ago
    Here's an overly simple, impractically slow, but immediately consistent model for you: for every request from a client, ask all other nodes in the network the same query. If you get 100% consensus, return the answer, otherwise, ask again.
rubiquity 6y ago
Sequential Consistency is the name for this model. Writes don’t get lost but it is weaker than linearizability because you can read after a commit and not get the latest value but eventually (not the same eventual as eventual consistency) you will. Typically data systems provide this to optimize for read scale out, otherwise all reads have to go to the leader. 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.
- pritambaral 6y ago
  > Sequential Consistency is the name for this model. Writes don’t get lost but ... Writes can get lost if the primary dies and the secondary is promoted in the meanwhile.
  - rubiquity 6y ago
    Yes but this is dependent upon the specific replication protocol. Primary-Backup has this problem but Majority Quorums and Chain Replication do not.
    - pritambaral 6y ago
      The parent is talking specifically about 'Sequential Consistency'.
      - rubiquity 6y ago
        My point is that Sequential Consistency isn’t a replication protocol, it’s a consistency model that you can have under various different replication protocols.

nemothekid 6y ago

It's par the course for MongoDB. 10 years later and they still use sales tactics to lie about the capabilities of their database. MongoDB might be a solid database when properly used, but their marketing material, again, promises things that the software just doesn't support. This is literally their "we are the fastest database just turn off commits" claim, but now in a distributed manner.

threeseed 6y ago
> This is literally their "we are the fastest database just turn off commits" claim I don't recall them ever saying this.
- rrdharan 6y ago
  They said they were the fastest. 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-write-concern-values-affect-performance-on-a-single-node/ https://shekhargulati.com/2011/12/08/how-mongodb-different-w...
  - threeseed 6y ago
    It seems quite similar to what MySQL/PostgreSQL is doing with its WAL. Those don't sync to disk on every write.
    - pritambaral 6y ago
      PG fsyncs on every commit. By default. 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.

a13n 6y ago

I mean to be fair, in a single node MongoDB database (one primary, no secondaries), it would be impossible to read stale values as well. 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.

zaptheimpaler 6y ago
Yeah I don't know much about MongoDBs past transgressions as a company or have any experience using it so it wasn't intended as a criticism of the company. I just spent a lot of time learning exactly what all these DB terms mean and wanted to point out an inaccuracy so its clearer to people reading. 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.
pritambaral 6y ago
> I mean to be fair, in a single node MongoDB database (one primary, no secondaries), it would be impossible to read stale values as well. 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
- a13n 6y ago
  > 1. Writes can be lost if the primary dies and a secondary is promoted before data from primary has been replicated to it. 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.

ykevinator 6y ago

Yeah that was the one thing I didn't like about this but the rest is good. I love mongo