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



On Why I Think These Pro MongoDB Arguments Are Not Unique…

A couple of days back I’ve read ☞ a blog post with what I’d call an extremely catchy title: “Why I Think Mongo is to Databases what Rails was to Frameworks“. While the 7 reasons presented in the article are not wrong by themselves, I think that the features mentioned are not so unique to MongoDB.

But let’s take them one by one…

1. Migrations are Dead

[…] migrations are so last year.

Throw a new key into any model and you can start adding data to it.

The whole thing about migrations is related to the complexity of mutating RDBMS imposed fixed schema. In other words, any schema-less solution, being it a document database or a key-value store or even a schema-less RDBMS will show the same benefit.

2. Single Collection Inheritance Gone Wild

By using inheritance, they all share the same base keys, validations, callbacks and collection.

Before looking at inheritance we’d need to firstly separate state and behavior. And then separate behavior into behavior that can be implemented close to the data by behavior that belongs to the object/app model.

Behavior characteristic to the object/app model is not important here as it has nothing to do with the data store. The kind of behavior that can be implemented close to the data (.f.e validations) have been long supported by RDBMS by means of simple data type definitions, constraints or even triggers.

So we are left with mapping inheritable state to data store. As we already know, key-value stores are most of the time completely unaware of the data structure and so inheritance has no meaning there. For approaches where the store must be aware in some way of the data structure, I’d say that over years RDBMS and ORMs have come up with an extremely well designed approach for handling it and I’ll just mention three basic strategies: table per class hierarchy, table per subclass, table per concrete class. In case you’d like to read more on this I’d recommend this Hibernate (Java ORM) ☞ doc.

5. Embedding Custom Objects/Hash Keys/Array Keys

For the next three points, I have reversed the order as I do see them as specialized cases of this more generic one.

Mongo natively understand arrays […] you can even index the values and perform efficient queries on arrays

As if array keys were not enough, hash keys are just as awesome.

What is that you say? Arrays and hashes just aren’t enough for you. Well go fly a kite… or just use an embedded object.

Storing custom object was “always” possible, even if we are including here key-value stores or even RDBMS (nb it is obvious that document stores can handle this scenario). Over time, the most concerns expressed related to custom objects where in terms of efficiency/performance of storing/fetching such data and data layout (nb what I mean is how transparent is to operate with such an object).

So I’d say that the real questions/feature here would be:

  • does the engine have an optimal strategy for storing/fetching this sort of ‘objects’? (f.e. how does it deal with array size modifications, etc.)
  • in case your app needs to access details of such ‘object’, does the store support it? (f.e. can I filter results based on such on ‘object’ field value(s)?)
  • in case such ‘objects’ are used to model relationships, how is your engine helping you avoid the N+1 query issue?

6. Incrementing and Decrementing

I see incrementation/decrementation as just a particular case of the generic “read and modify value” scenario, which is supported by both RDBMS and column-based stores (nb you can correct me on this one as I haven’t checked them all). There is an additional characteristic of this operation that is probably making the difference: atomicity. An even more generic feature that would fit this scenario is the ☞ compare-and-swap.

7. Files, aka GridFS

Mongo actually has a really cool GridFS specification that is implemented for all the drivers to allow storing files right in the database. I remember when storing files in the database was a horrible idea, but with Mongo this is really neat.

Well, I guess everyone tried at some point to store files into MySQL or other RDBMS. The whole issue related to it was the performance of the operation and how handy the API was.

In the end, please allow me say it once again that my intention is neither to argue against MongoDB features nor to deny how important these features can be for an application, but rather to clarify that these features are not unique to MongoDB. And if I misinterpreted any of these please feel free to correct me.