Monday, July 1, 2013

MongoDB - How good, How bad?

I have been using MongoDB for last almost more than two years now. Here are some of my ramblings on MongoDB. I have used MongoDB to build a framework so as to be able to quickly build mobile apps. The framework is live on Amazon EC2, singapre cloud. It makes use of most of the MongoDB's advanced features such as sharding, replication, hidden replica for back-up.

What I like most about MongoDB is it’s proximity to RDBMS, extremely easy data modeling, and out of the box features such as sharding and replication. It also has recently added support for aggregation framework which also eased the pain of using map-reduce for every aggregation type of queries.

But there are some pit-falls as well and one needs to be very aware of that while building on top of MongoDB. 

MongoDB is not good if there is any transactional aspect involved in your data model. In that case, MongoDB is not a good technology choice. And that’s clearly mentioned as MongoDB philosophy. There is also a good article about Two Phase Commits using MongoDB (http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits) but IMO, moment you try to do things like these, you are bound to end-up into performance issues same with any RDBMS. Also, moment you take relationships, joins and transactions  out of the picture, you end-up with a very limited set of application types. So, a word of caution about the nature of your data! 

I think, as NoSql technology, MongoDB works really great if you have data which is mostly non-relational in nature, non-critical or non-transactional, write once and read multiple times and yea - voluminous. Typically, the nature of the data which mostly gets generated from social networking apps, gaming apps or mobile apps or some specific categories as listed on Mongo website. If you see the data in such apps, it is not frequently changing, mostly non-relational and also non-critical. Even for the apps I mentioned, if there is billing related data, you could still be able to manage that through embedded documents very easily. Though, on embedded documents, MongoDB has some artificial limits (due to the way it’s implemented) on the size of the embedded documents. IMO, some of the limitations (as described on the Mongo website) are so annoying and they look like plain simple bugs or design issues and it’s perplexing as to why these limitations exist in the first place.


No comments:

Post a Comment