ALL COVERED TOPICS

NoSQL Benchmarks NoSQL use cases NoSQL Videos NoSQL Hybrid Solutions NoSQL Presentations Big Data Hadoop MapReduce Pig Hive Flume Oozie Sqoop HDFS ZooKeeper Cascading Cascalog BigTable Cassandra HBase Hypertable Couchbase CouchDB MongoDB OrientDB RavenDB Jackrabbit Terrastore Amazon DynamoDB Redis Riak Project Voldemort Tokyo Cabinet Kyoto Cabinet memcached Amazon SimpleDB Datomic MemcacheDB M/DB GT.M Amazon Dynamo Dynomite Mnesia Yahoo! PNUTS/Sherpa Neo4j InfoGrid Sones GraphDB InfiniteGraph AllegroGraph MarkLogic Clustrix CouchDB Case Studies MongoDB Case Studies NoSQL at Adobe NoSQL at Facebook NoSQL at Twitter

NAVIGATE MAIN CATEGORIES

Close

Powered by MongoDB: All content tagged as Powered by MongoDB in NoSQL databases and polyglot persistence

MongoDB at Traackr: Indexing and Ad-Hoc Querying

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


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/


MongoDB at GOV.UK: The Power of the Document Model

The alpha version of GOV.UK was using MySQL and PostgreSQL. GOV.UK beta is based on Amazon RDS (MySQL) and MongoDB. In there words:

We started out building everything using MySQL but moved to MongoDB as we realised how much of our content fitted its document-centric approach. Over time we’ve been more and more impressed with it and expect to increase our usage of it in the future.

Here’s how GOV.UK architecture looks like:

GOV.UK architecture

Credit OReilly .

Original title and link: MongoDB at GOV.UK: The Power of the Document Model (NoSQL database©myNoSQL)


Graylog2: MongoDB for Centralizing Logging

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