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

MongoDB Tips and Tricks: You Only Wish MongoDB Wasn't Relational

So when you read that MongoDB is a document store, you might get the wonderful idea to store your relationships in a big document. Since mongo lets you reach into objects, you can query against them, right?

Several times, we’ve excitedly begun a schema this way, only to be forced to pull the nested documents out into their own collection. I’ll show you why, and why it’s not a big deal.

I’m no MongoDB expert, but the suggested solution requires: 1) two network roundtrips; 2) an additional index.

The way I’d look at this problem is:

  1. what is the most frequent operation: reading a blog post and all its comments or displaying all the comments of a specific user?
  2. assuming the answer is reading a blog post and all its comments, I’d ask myself how frequent is the other operation.
    1. if it’s something that I need to perform just once in a while, I’d consider using MongoDB MapReduce, even if that would be suboptimal.
    2. if it’s a frequent operation, then I’d consider adding a separate collection for comments. Even better, I’d add a per user collection for comments.

Original title and link: MongoDB Tips and Tricks: You Only Wish MongoDB Wasn’t Relational (NoSQL database©myNoSQL)

via: http://seanhess.github.com/2012/02/01/mongodb_relational.html