3 ms·

I must admit, I always feel like I am missing something in these discussions. Like I didn't get some memo... I just don't expect a DB like MongoDB to guarantee

by bakhy 11y ago

I must admit, I always feel like I am missing something in these discussions. Like I didn't get some memo... I just don't expect a DB like MongoDB to guarantee consistency. The whole story around NoSQL and the likes was to enable crazy horizontal scaling needed for the web. Phrases like "eventual consistency" flew around. It seems so logical - you lose consistency, gain scalability. But somehow, people simply started using them everywhere? Assuming that these DBs are just like any other? And now, we're all bashing on MongoDB because it is - not consistent? What happened here? :) NB that I do not wish to attack the OP - if MongoDB now claims to be consistent in any way, that deserves scrutiny. And these analyses are always a really interesting read. But the general tone in the developer community about MongoDB seems a bit irrational.

Jweb_Guru 11y ago
"Eventual consistency" has a very particular meaning (when it's not being used as a buzzword). "Read uncommitted" doesn't even come close to the sorts of guarantees that people expect from an AP database. More importantly, MongoDB doesn't advertise itself as an AP database, it advertises itself as something you can use as the primary datastore for important information. Kyle has analyzed AP databases like Cassandra and Riak as well, and evaluates them according to their claims.
fennecfoxen 11y ago
> It seems so logical - you lose consistency, gain scalability. ... And now, we're all bashing on MongoDB because it is - not consistent? What happened here? :) There are ways to do "eventual consistency" responsibly. Mind you, it's obnoxiously tricky to do it right, even when someone has provided an underlying implementation that works exactly as promised. But if you design your data access patterns in the right way, the system can provide guarantees so that even if it doesn't have all your data at the moment, you can still ask questions about the the state of the data that is available, and get meaningful responses back that conform to a certain set of guarantees. What happened here -- why we make fun of MongoDB -- is that it doesn't provide many promises like that, and even when it does, its implementation does a very, very bad job of delivering them ... and it doesn't even do a good job of delivering scalability. (It's basically a mmap()'d series of b-trees of BSON documents, so as soon as you run out of RAM, you're at risk of having the kernel swap out all your indicies instead of your data, whereupon performance craters. Oh, and the much-mocked global write lock has finally been replaced with a per-database write-lock in recent versions.) In short, you sacrifice everything and gain... a modestly convenient API for document-storage, maybe.
darkarmani 11y ago
> if MongoDB now claims to be consistent in any way, that deserves scrutiny. And these analyses are always a really interesting read. But the general tone in the developer community about MongoDB seems a bit irrational. It has been sold that way. People believe with write-concern majority, they can use mongo replicas for primary data stores and not lose anything. Embed your relational data and use it for everything.

by bakhy 11y ago

Jweb_Guru 11y ago

"Eventual consistency" has a very particular meaning (when it's not being used as a buzzword). "Read uncommitted" doesn't even come close to the sorts of guarantees that people expect from an AP database. More importantly, MongoDB doesn't advertise itself as an AP database, it advertises itself as something you can use as the primary datastore for important information. Kyle has analyzed AP databases like Cassandra and Riak as well, and evaluates them according to their claims.

fennecfoxen 11y ago

> It seems so logical - you lose consistency, gain scalability. ... And now, we're all bashing on MongoDB because it is - not consistent? What happened here? :) There are ways to do "eventual consistency" responsibly. Mind you, it's obnoxiously tricky to do it right, even when someone has provided an underlying implementation that works exactly as promised. But if you design your data access patterns in the right way, the system can provide guarantees so that even if it doesn't have all your data at the moment, you can still ask questions about the the state of the data that is available, and get meaningful responses back that conform to a certain set of guarantees. What happened here -- why we make fun of MongoDB -- is that it doesn't provide many promises like that, and even when it does, its implementation does a very, very bad job of delivering them ... and it doesn't even do a good job of delivering scalability. (It's basically a mmap()'d series of b-trees of BSON documents, so as soon as you run out of RAM, you're at risk of having the kernel swap out all your indicies instead of your data, whereupon performance craters. Oh, and the much-mocked global write lock has finally been replaced with a per-database write-lock in recent versions.) In short, you sacrifice everything and gain... a modestly convenient API for document-storage, maybe.

darkarmani 11y ago

> if MongoDB now claims to be consistent in any way, that deserves scrutiny. And these analyses are always a really interesting read. But the general tone in the developer community about MongoDB seems a bit irrational. It has been sold that way. People believe with write-concern majority, they can use mongo replicas for primary data stores and not lose anything. Embed your relational data and use it for everything.