I, too used to be a MongoDB naysayer and lets face it, in its early days and even up until recently MongoDB was a steaming pile of shit. Not only that, but completely forgoing things we take for granted in a traditional RDMS is something many have a hard time getting accustomed too (hello transactions).
Yes, prior to version 2.0 of MongoDB there were a few issues, one of those issues namely being the global write lock blocking all queries problem. In version 2.0 they basically addressed the issue, in version 2.2 they removed global write locks altogether.
After prototyping a little something-something I am working on in Node.js and MongoDB, I’ve changed my tune. I hadn’t used MongoDB in a while and decided to give it another shot on this project because I don’t need to define a schema, well I sort of do because I am using Mongoose JS, but that is besides the point.
Most of the hate directed at MongoDB is a lack of understanding of the tool being used. If you don’t understand what you’re using, why even bother using it? MongoDB is no different.
A bad mechanic will always blame his own tools. A bad developer or systems administrator will always blame the tools and or language instead of themselves. Blindly using something just because highscalability.com is talking about it and failing to understand how to appropriately use it is nobody’s fault but your own.
Sarah Mei, a Ruby developer who helped out on a project that tried to compete against Facebook and ultimately failed called Diaspora recently posted an article titled: Why You Should Never Use MongoDB.
Basically the TL;DR was: don’t use a non-relational database for relational data. This is an obvious misjudgement on the development teams part. It’s not the fault of MongoDB it was made to try and work for the wrong purpose.
Every time a feature changes or I want to add something new in or remove something old, I don’t need to fire up Navicat, write a migration file or use PHPMyAdmin to change my database structure. And herein lies the beauty of MongoDB and pretty much any other key/value store type database: the ability to rapidly prototype an evolving application.
I haven’t decided if MongoDB will be used for the end-result as it is a social networking type application, but so far I have not run into any problems using it and actually find it enjoyable.
While I am not currently using MongoDB at scale, for prototyping purposes it is more than adequate. And even if I only use it for this stage of the project, it has been more beneficial than MySQL ever could be in similar circumstances.
