MongoDB is by far the most popular NoSQL database in Brazil (at least based on the amount of blog posts and articles writen about it here that I read). It’s really an amazing solution but what really bothers me is the fact that very few people know about it’s limitations. So I see the same story repeating itself: people unhappy with it treating his limitations as if they were bugs.
This post is about some of it’s limitations that really caught me by surprise, so that if you are thinking in adopting it at least you’ll be warned about them and so avoid these headaches.
Hungry for bytes
This was my first surprise: MongoDB consumes too much disk space. This is related to the way it is coded to avoid issues with disk fragmentation by pre-allocating space in large files. Here is how it works: when you create a database will be created a file named [db name].0 and it will have (by default) 64 Mb of size. When more than half of this file is used, another one will be created named [db name].1 with 128 Mb. This will happen again and again, so that files with 256, 512, 1024 and finally 2048 Mb will be written on your disk. All subsequent files will have 2048 Mb size.
If storage space is a restriction to your project you MUST take this in consideration. There’s a commercial solution for this problem: it’s named TokuMX. I didn’t tried it, but if it really works, so the storage consumption will decrease 90%. Also the repairDatabase and compact commands can help you on the long run.
Data replication with the replica-set strategy is amazing, but have it’s limitations.
The replica-set strategy for data replication in MongoDB is amazing. Easy to configure and works really well. But if your cluster have more than 12 nodes you have a problem. Replica-set in MongoDB have a limit of 12 nodes. There’s an issue to eliminate this restriction, so you can track to see if this problem will soon be only a sad memory.
Master-slave replication will not ensure to you high availability
Despite being considered deprecated, there’s another replication strategy that MongoDB implements which is the master slave. It solves the problem of the 12 nodes limitation but brings you another one: if you need to change the master node of your cluster, you must do it manually. Doubt me? Here is the link.
Avoid the 32 bit version
The 32 bit version of MongoDB is also considered deprecated because it can only handle 2 Gb of data. Remember the first limitation on this post? Very quickly you’ll face it with this version. Here is a blog post from MongoDB about this limitation.
Consulting prices are VERY expensive (at least for brazilian developers and companies)
I don’t know how this is considered outside Brazil, but at least here the consulting prices of MongoDB are infeasible. For the “Lightning Consult” plan it costs US$ 450,00 per hour, and you have to buy at least 2, so it cost at least US$ 900,00 to any company. We are used to contract companies like RedHat and Oracle for much better prices.
Bad administration tools
This is still a huge problem for beginners. The administration tools are in terrible shape. The best one I know is called RoboMongo, which is really handy for those who are taking the first steps with the tool. Unfortunetely it’s an exception.
Know the oficial limitations
It amazes me that so few people search on the limitations of the tools they are wanting to adopt. Fortunetely the staff of MongoDB have published a post with all those limitations so that you can know them in advance and avoid many unfortunate surprises on your adoption path. Hope that you are not caught by surprise by the limitations exposed on this post.