4 ms·

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 on

by 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.
  - pritambaral 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? 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.

by a13n 6y ago

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.
- pritambaral 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? 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.