Traackr’s original model included three distinct data buckets: 1) Influencers, 2) Channels (sites for published content), and 3) Posts (tweets, blogs, etc.). Traackr creates influencer listings based on mining these data sets for keywords. If the information was only loosely coupled or if the wrong type of relationship festered for too long, inaccurate, inconsistent influencer rankings would result. In order to provide higher quality lists to clients, Traackr needed to build stronger associations within their data model, and HBase lacked indexing and ad-hoc querying capabilities to make this happen.

A few other MongoDB features are mentioned in the post, but the key is indexing and ad-hoc queries.

Original title and link: MongoDB at Traackr: Indexing and Ad-Hoc Querying (NoSQL database©myNoSQL)

via: http://www.10gen.com/customers/traackr

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/

Why Graylog2 uses MongoDB:

So we need something in between: schema-less storage with indexes, everything else are bonuses. With Mongo DB we got a lot of them:

• capped collections, which preserve insertion order and maximum collection size, automatically removing old messages;
• tailed cursors, which are used to implement tail -f behavior;
• awesome performance;
• and an easy API.

Original title and link: Graylog2: MongoDB for Centralizing Logging (NoSQL databases © myNoSQL)

via: http://alexey-palazhchenko.tumblr.com/post/5070526903/graylog2-and-its-mongodb-usage