MongoDB Performance & Durability

-----------

Full disclosure: I work for 10gen.

You strategically posted this when my air conditioning was broken, so here are a few thoughts before I go find somewhere cooler. Since CouchDB is "not a competitor" to MongoDB, it's nice of you to put all this time into a public service.

> MongoDB, by default, doesn’t actually have a response for writes.

Whoopsy, got your emphasis wrong there. We did this to make MongoDB look good in stupid benchmarks (http://www.snailinaturtleneck.com/blog/2009/06/29/couchdb-vs...).

Seriously, though, this "unchecked" type of write is just supposed to be for stuff like analytics or sensor data, when you're getting a zillion a second and don't really care some get lost if the server crashes. You can do an insert that not only waits for a database response, but waits for N slaves (user configurable) to have replicated that insert. Note that this is very similar to Cassandra's "write to multiple nodes" promise. You can also fsync after every write.

> MongoDB writes to a mem-mapped file and lets the kernel fsync it whenever > the kernel feels like it.

fsyncs are configurable. You can fsync once a second, never, or after every single insert, remove, and update if you wish.

> When you look at MongoDB more critically I don’t see how you could actually > justify using it for anything resembling the traditional role of a database.

This is because you assume you'll run it on single server. MongoDB's documentation clearly, repeatedly, and earnestly tells people to run MongoDB on multiple servers.

Also, as another commenter mentioned, full single-server durability is scheduled for the fall.

> Stories like this (http://www.korokithakis.net/node/119) are dubious not > because they expose a few bugs in MongoDB but because they show inherent > architectural problems you cannot overcome long term without something > append-only.

Stories "like this" show that MongoDB doesn't work for everyone, particularly people who give no specifics about their architecture, setup, what happened, or anything else. Isn't it irritating how people will write, "MongoDB lost my data" or "CouchDB is really slow" and provide no specifics?

That's not to say that things never go wrong, MongoDB is definitely not perfect and has lots of room for improvement. I hope that users with questions and problems will contact us on the list, our wiki, the bug tracker, or IRC (or, heck, write a snarky blog post). Anything to contact the community and let us try to help. I wish every person who tried MongoDB had a great experience with it.

Lots of users, hopefully most, love MongoDB and are using it happily and successfully in production.

How can this be? If no single server guarantees durability of the writes, how can a cluster of those types of machines suddenly cause those writes to be durable? Maybe it's a pedantic argument, but it seems to me that semantically speaking you are simply relying upon luck that your replicated nodes don't become corrupt or die for some systemtic reason.

The fact that there is not a replayable, append-only transaction log says to me that no matter what you build on top of it, it will never by definition be durable because the whole cannot be greater than the sum of its parts in this case.

He did go into several specifics as to why MongoDB might lose your data. Nice jab at CouchDB though!