January 15, 2013 by MongoDB Comments
There are a variety of reasons for moving from a relational database (RDBMS) to MongoDB. Perhaps, like FamilySearch, the family history division of The Church of Jesus Christ of Latter-day Saints, a company wants to improve response times from 3 seconds (RDBMS) to under 15 milliseconds (MongoDB). Or perhaps, like Apollo Group (PDF), the private education giant behind University of Phoenix, an enterprise is hoping to store unstructured data and scale to support anticipated growth in the number of users and volume of your content.
Whatever the reason for moving off a relational database for MongoDB, it’s important to plan appropriately.
In my role I get to work directly with MongoDB users like Telefonica, nearly all of which come from a relational database background. Sometimes when people are fed up with using SQL, or they see MongoDB as a way to scale, they decide to migrate an application designed for a relational database directly to MongoDB…without rethinking the data model and architecture of their application. There are good ways to map SQL executables to MongoDB, but this isn’t one of them.
Another error-prone migration “strategy” is driven by the blind usage of Object Document Mappers (ODM) and Object Relational Mappers (ORM) that shield a lot of the complexity of manipulating a database, but can also contribute to poor data model design.
So when considering a direct migration from RDBMS to MongoDB, it’s important to be attentive to some issues:
The first question to ask, then, when moving from a relational database to MongoDB is, ‘How will this data be accessed?’ Other important questions include:
These should be the first questions people ask themselves before migrating data from an RDBMS into MongoDB. Indeed, these should be the main questions someone should be asking before using any persistence layer. As stated, there are a lot of great reasons to use MongoDB instead of a relational database, but careful planning is required to pull off a successful migration.
Posted by Norberto Leite, Senior Solutions Architect for EMEA, 10gen.