5 ms·
> whether [Mongo] does/doesn't scale efficiently It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run
by arohner 13y ago
> whether [Mongo] does/doesn't scale efficiently
It doesn't. Three words: "global write lock". Writes block reads, reads block writes. Implications: if you run a query in production that doesn't hit an index, all traffic stops. The notablescan setting is a very, very good idea. This also means all queries must have an index, so Mongo ends up with more indexes than say, postgres would.
It's impossible to configure a clustered mongo environment to not lose data: http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb
Sharding configuration is baroque, and limited.
- francesca 13y agoThe global lock was removed in 2.2 https://blog.serverdensity.com/goodbye-global-lock-mongodb-2-0-vs-2-2/ https://blog.serverdensity.com/goodbye-global-lock-mongodb-2... Now locking is on the database level.
- MichaelGG 13y agoThat sorta makes it sound worse, honestly, if databases in MongoDB are anything like you'd use the word for in any other datastore. A global lock across all databases is mind-bogglingly confusing; what's one DB got to do with another? Couldn't you just work around that before by running a separate Mongo process per database? Saying it's now on the database still means any single-database app is globally locked. Or does using Mongo imply you're going to be making lots of databases so this actually means anything?
- nasalgoat 13y agoThat's what we do - dozens of databases, containing one collection. It's perverse.
- foobar1988 13y agoYou could say the same about multi-master environments. Those are prime opportunities for losing data (eventually consistent does not mean consistent, it means data loss)
- snmaynard 13y ago> Implications: if you run a query in production that doesn't hit an index, all traffic stops Even if Mongo did have a global write lock, which it doesn't as has already been covered, it yields on page faults which means that other queries are minimally impacted. See: http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-or-write-operation-ever-yield-the-lock http://docs.mongodb.org/manual/faq/concurrency/#does-a-read-...
- arohner 13y agoMongo does have a global write lock. A per-db lock does me very little good when I only have one DB. As to your linked doc, emphasis added: > In some situations, read and write operations can yield their locks. > Long running read and write operations, such as queries, updates, and deletes, yield under many conditions. In practice, I've been bitten hard by this. A new feature rolls out, and users can't log in anymore, because a query is taking 2 minutes to run.
- cbsmith 13y agoThat's solves the contention problem, but just by virtue of yields on page faults being a big feature you can see where Mongo does have some scaling issue.
- VintageCool 13y agoTokuMX. They ripped out the native MongoDB storage engine and replaced it with the TokuDB engine. http://www.xaprb.com/blog/2013/04/29/what-tokudb-might-mean-for-mongodb/ http://www.xaprb.com/blog/2013/04/29/what-tokudb-might-mean-...
- nasalgoat 13y agoTokuDB doesn't currently have a drop-in replacement strategy, so you'd need to migrate your whole cluster. A daunting task with hundreds of shards!
- leif 13y agoSuch a thing could never exist, because the point of tokumx is to change the storage system, so at some point you have to change the storage over and that's just going to be a rewrite of all your data. It sucks but that's the way it is.
- nasalgoat 13y agoYes, but if I could replace the replicas and let them refill one at a time, then replace the masters, I could do a rolling conversion. But replication from MongoDB to TokuDB does not work.
- leif 13y agoActually, you can do that. I wrote a tool to allow replication from MongoDB to TokuMX: http://www.tokutek.com/2013/07/tokumx-1-0-3-seamless-migrations-from-mongodb/ http://www.tokutek.com/2013/07/tokumx-1-0-3-seamless-migrati.... It doesn't allow TokuMX instances to satisfy write concern or to participate in elections, but you can slave a TokuMX replica set off a MongoDB replica set just fine, and this allows you to do a rolling migration where you replace one secondary at a time.