Why Badgeville Chose MongoDB

A brief post by Badgeville’s Jimmy Zhang explaining their choice of using MongoDB for a platform handling hundreds of millions/soon-to-be billions of documents:

1. We wanted a dynamic database schema. We are a Behavior Platform. We record arbitrary behaviors for our clients and do interesting things with them.
2. We wanted something that scaled easily. Given that we’re a platform and our data grows with the number of clients we have and over time, we aren’t your ordinary build-it-and-hope-they-will-come website. Our configuration started with Master-Slave, then Replica Sets, and now Sharding.
3. We wanted Map/Reduce. On top of flexibility in storing the data, we wanted flexibility in processing it.

All three very valid points, with the only comment that the MapReduce implementation of MongoDB and in general all solutions using the serialize values to external JavaScript engine model are not the most performant, but they come with the friendliness of the JavaScript language. Actually as far as I know most NoSQL databases providing a MapReduce implementation are using this approach.

While not implementing MapReduce, Redis preferred embedding Lua for allowing server-side code execution. Makes me wonder if this wouldn’t actually be better than the JavaScript engine approach. Thoughts?

Original title and link: Why Badgeville Chose MongoDB (NoSQL database©myNoSQL)

via: http://mankindforward.com/2012/03/09/when-you-should-use-mongodb-45-2/