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
Thursday, 27 January 2011
‹ Back

On Document Databases or Is MongoDB Lacking a Sweet Spot?

About:
,
,
,
,
,

Rob Ashton published an article comparing the major NoSQL document databases: CouchDB, MongoDB, and RavenDB, from the perspective that “it’s all about sweet spots”. His conclusions about MongoDB are very interesting:

Mongo on the other hand, is very similar to our traditional databases – with the core difference that data is stored as documents instead of being split out (normalised) across multiple tables. The rest of it all looks very similar – except we lose the ability to do joins across our tables (so complex reporting is out). Reads are fast, but only because Mongo has been micro-optimised to the hilt (just like most database engines), writes are fast, but only because the system doesn’t wait to find out if writes have been successful before carrying on with the next job.

I don’t see it, I don’t see the sweet spot – even if the durability issues are sorted out it’s still just a traditional database with a few less features in the name of gaining a few milliseconds that most of us don’t need.

It achieves fast query speed by storing indexes in memory, which means what Mongo actually gives us is a really slow way to query in memory objects – and heaven forbid you run out of enough RAM to store these indexes on your production servers (ala Foursquare a few months ago). If you’re going to go for an in-memory query store then you’re probably going to use Redis because that’s its sweet spot…

Taking a step back, the two most visible differences between MongoDB and a relational database are:

  • data model (relational vs document-based, non-relational)
  • a different querying language

In reality there are more than just these two — think in terms of ACID — but they are not that obvious upfront.

So, as I said it before, I think MongoDB would be much better positioned if it would be using SQL. That would offer it a “sweet spot”: applications that haven’t worked with relational databases due to the data model. Think about (prototype) applications that are evolving rapidly their data model. Or applications where JOINs have become too complicated, too slow.

Original title and link: On Document Databases or Is MongoDB Lacking a Sweet Spot? (NoSQL databases © myNoSQL)

via: http://codeofrob.com/archive/2011/01/26/ravendb-vs-mongodb-why-i-dont-usually-bother.aspx