Clarifications about MongoDB decisions and trade-offs:
There are, however, a ton of differences due to the data model, scalability considerations, and MongoDB’s youth. This can lead to some not-so-pleasant surprises for users.
Kristina Chodorow mentions in her post 5 such “often-overlooked assumptions”:
- MongoDB assumes that you have a 64-bit machine
- MongoDB assumes that you’re using a little-endian system
- MongoDB assumes that you have more than one server
- MongoDB assumes you want fast/unsafe, but lets you do slow/safe
- MongoDB developers assume you’ll complain if something goes wrong
While I’d say the 1st two are not so big problems and the 5th is a non-issue, a MongoDB should definitely be aware of
MongoDB durability details and also about the default fire-and-forget behavior (point 4).
Commenter Prajwal Tuladhar ☞ suggested the addition of another 2:
- MongoDB assumes you have large (very large) amount of hard drive space
- MongoDB (Redis also) assumes RAM can be used instead of disk
Interestingly enough, there’s a ☞ Hacker News thread that quoted a comment coming from Kristina saying that “if MongoDB has to guarantee writes there will be a 900% drop in speed”. Unfortunately I cannot find this comment, so please take this with a large grain of salt for now.
Mathias Meyer has ☞ posted a caveat about MongoDB replica sets, which finally proved not to be so serious. And I am wondering what are the situations that can lead to MongoDB slaves going out of sync, a story briefly mentioned on the ☞ BoxedIce’s blog:
We recently had one of our MongoDB database slaves go out of sync which requires a full resync from scratch. Because we have our slaves in a different data centre, it takes quite a lot of time for the data to transfer, indexes to be built and the slave to get back up to date again;
Original title and link for this post: MongoDB: 5 Things to Keep in Mind (published on the NoSQL blog: myNoSQL)