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



From MySQL to MongoDB: Migration Steps

It comes as no surprise that MongoDB people are speaking quite often about migrating from MySQL to MongoDB considering that is part of their strategy. Anyways this is not the main point that caught my attention in the linked interview.

When ☞ asked about migrating a project from a relational database to MongoDB, Kristina Chodorow and Michael Dirolf identified 4 phases:

  1. Get to know MongoDB. Download it, read the tutorials, try some toy projects.
  2. Think about how to represent your model in its document store.
  3. Migrate the data from the database to MongoDB, probably simply by writing a bunch of SELECT * FROM statements against the database and then loading the data into your MongoDB model using the language of your choice.
  4. Rewrite your application code to query MongoDB through statements such as insert() or find().

from which the most important/time consuming is the model:

Design is critical, and there are trade-offs that provide no simple answers but require a careful understanding of your application. Migrating the data and rewriting the application are straightforward by comparison.

This sounds extremely similar to what I’ve written in The role of data modeling with key-value stores (nb you can ignore for now the particularities of key-value stores) and also in NoSQL data modeling. It’s great to see such validation for our articles!

You’ll probably find interesting the following slides from Hayes Davis (@hayesdavis) which are emphasizing the following critical questions:

  1. Is my data relational?
  2. Do my data access patterns lend themselves to denormalization?
  3. Do I expect a lot of schema change?
  4. Can I drop ACID?
  5. Do I want to support a new piece of infrastructure? (note complexity is a critical dimension that you have to consider)