MongoDB — A comment on recent developments

Over the past week there’s been a lot of bad press about MongoDB in various discussions. One example is the anonymous Don’t use MongoDB and a reply from 10gen itself. The competition also put in a plug for itself, of course, though it later set the record straight. In short, MongoDB is designed with certain characteristics. You can accept them and plan for them, or you can be in for an unpleasant surprise.

One major design decision was turning off write acknowledgment by default. From your point of view you’ve written the data, but that doesn’t mean it has actually made it to disk. The designers believed that not every write is critical enough to hold up the client. If you use MongoDB to collect log events, for example, you probably won’t mind if some aren’t written permanently under certain conditions. What matters is that the client can control acknowledgment. You can require a write to reach a specified number of Mongo replica instances in the cluster, for example.

Another common criticism of MongoDB’s design is that a server crash can corrupt the data file. MongoDB uses memory-mapped files and periodically calls fsync to write the current state to disk. If you kill MongoDB at just the right moment, the data can lose integrity and you have to run recovery. From version 1.6 you can use journaling and avoid that problem. It hurts write performance, but in a setup without replication it’s your only option. If you run MongoDB in master/slave mode or in a replica set, you can resynchronize the corrupted node from the master or the other replicas. That’s the theory, anyway. I haven’t tried it yet.

The last design decision often criticized is the global read/write lock. While a write is in progress, nobody else gets a look in. That’s unfortunate, but it depends on how many writes you have relative to reads. My guess is they chose a global lock because it’s the simplest way to lock data without using more memory, a disadvantage of MVCC. Each new version improves performance by shortening the critical path so the lock is held for as little time as possible.

Those are the most frequently cited “shortcomings,” or design characteristics, of MongoDB. The discussion reminds me of the debate over Ruby on Rails versus the rest of the world about three years ago. “Sure, you’ve done it nicely, but it’s unusable because requests are processed one at a time. Nobody could ever use that on a real project.” If you’re looking for a stick to beat a dog with, you’ll always find one. What became clear then was that if there’s a technical solution, it’s no problem at all. Back to MongoDB, 10gen is well aware of these things and is working hard to fix defects and improve the database.

NoSQL changes the way we’ve developed web applications for the past decade. Relational databases are being replaced by alternative stores for various well-known reasons. If you’re eyeing a NoSQL solution now, expecting a finished product like a relational database is a recipe for disappointment. Keep these points in mind if you plan to use MongoDB.