On: Cassandra vs MongoDB For Time Series Data

[arohner]

> 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

Sharding configuration is baroque, and limited.

[snmaynard → arohner]

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

[arohner → snmaynard]

Mongo 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 → snmaynard]

That'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.

[francesca → arohner]

The global lock was removed in 2.2

https://blog.serverdensity.com/goodbye-global-lock-mongodb-2...

Now locking is on the database level.

[MichaelGG → francesca]

That 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 → MichaelGG]

That's what we do - dozens of databases, containing one collection.

It's perverse.

[VintageCool → arohner]

TokuMX. 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-...

[nasalgoat → VintageCool]

TokuDB 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 → nasalgoat]

Such 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 → leif]

Yes, 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 → nasalgoat]

Actually, 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-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.

[foobar1988 → arohner]

You 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)