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



NoSQL Data Modeling

I sometimes read that NoSQL solutions are a better fit for prototyping applications as they don’t require any upfront data modeling work. I must confess that I pretty much disagree with that.

Even if we are talking about key-value stores or document databases, not to mentioned column-based stores and graph databases, the fact that they make it easy to throw in some data is not really an advantage (not to mention that you’d be able to take the same route using a RDBMS). This approach will just hide away any future issues and postpone discovering the real merits of the chosen NoSQL solution.

While we’ve learned over time that we cannot blindly apply GoF patterns and/or RDBMS data modeling patterns, I believe that each NoSQL project community would benefit a lot from having around some data modeling patterns[1]. Just to exemplify what I mean, you can check these discussions[2] to see that even simple data modeling problems can raise questions.

I’ll end up with a quote from MongoDB CTO, Eliot Horowitz:

I think the first question you have to ask about any database these days is: “What’s the data model?”

adding only that the next questions should be about access patterns of your application.