An intro to MongoDB for MySql Developers

Throughout my many years hacking away on countless different web projects in many different languages (php, python, perl, java etc) there has always been one constant… MySQL. I have always been a dyed in the wool MySQL fan. It’s a good relational database with a ton of features, easy to get setup (at least for simple deployments) and we all know the price is right.

All that being said, we have had some real issues with MySQL on some of our bigger projects lately. Once you move outside of the simple one server setup to working with replication and millions of rows of data MySQL quickly becomes something you really need an expert to manage effectively. That’s all well and good if you have a team with a kick ass MySQL db admin or the budget to go out and hire one as needed but that’s simply not always the case. So we have started exploring other options lately. Namely MongoDb.

For those of you that aren’t familiar with MongoDB it’s an open source non relational database created by 10Gen. Here is how they describe themselves…

Combining the best features of JSON databases, key-value stores, and RDBMSes.

MongoDB (from “humongous”) is a scalable, high-performance, open source, schema-free, document-oriented database. Written in C++

MongoDB bridges the gap between key-value stores (which are fast and highly scalable) and traditional RDBMS systems.

MongoDB is simple to setup, has drivers for most popular programming languages (php, python, java etc), scales really well and is fast… REALLY FAST. For those of you that are like me and come from a MySQL background, the no schema approach can be a bit of a mental hurdle to get over. You have to abandon some fundamental beliefs of how databases “should” work. For instance you don’t define tables. Everything is a collection and the collection is created automatically when you insert into it. And there is no enforced structure to the data (Mongo calls them Documents – which would be the equiv to a table row in MySQL) that you store in the collection. To me that was a big change and it took me a while to get used to it.

Now there are ways to add a schema layer on top of everything. We use the pymongo python driver and there is a nice add on module called MongoKit that allows you to enforce a schema (with or without validation) on top of the Mongo documents. Basically meaning that when you retrieve a Document from a Collection you get a Model object back instead of a python dict. This can be really helpful and also personally gave me back a bit of my comfort zone.

Now don’t get me wrong MongoDB isn’t the necessarily the right back end for all projects. One glaringly obvious drawback is the lack of transactions. This can be a big issue depending on your app logic. There are ways to program around this but it takes much more code to do so. Bottom line, there are still some things MySQL will be much better suited to.

Don’t take my word for it, give it a shot yourself.