The relational database has been the foundation of enterprise applications for decades, and MySQL has been one of the most popular and inexpensive options available. But with the explosion of unstructured data, new non-relational databases like MongoDB have emerged to address the requirements that modern applications demand. You need a new kind of database in order to manage, process, and analyze data that doesn't fit into the neat rows and columns of a relational table.
Choice is a good thing, but it can add complication, especially when there are now so many different database technologies to choose from. Yet it doesn't have to be either / or. In the case of existing MySQL-based applications, there are plenty of users who have added MongoDB in a hybrid deployment environment to deliver specific functionality and modernization. Here are three examples of companies that are using MongoDB and MySQL:
1. Next Generation Apps: Sage Group
New business requirements push organizations to adopt MongoDB for the next-generation components of their applications. For example, Sage Group, one of the world’s leading suppliers of business management software and services, integrated MongoDB into its popular Enterprise Resource Planning (ERP) solution for midsize companies. Sage customers now enjoy a higher degree of functionality and personalization as a result of the integration. While many Sage products were originally built on and continue to run on MySQL, the latest user experience functionality centers around MongoDB.
2. Right Tool for the Job: E-commerce at OpenSky
Many retail applications benefit from a combination of MongoDB and MySQL. For example, New York City based e-commerce startup OpenSky needed to model a cross-industry product catalogue. Modeling different products with different attributes in a relational database became overly complex and cumbersome. In contrast, MongoDB's flexible, document-based data model was a perfect fit for this type of data. In moving the product catalog to MongoDB, the codebase simplified and performance improved dramatically.
Yet there was a key component of the OpenSky application that didn’t get migrated to MongoDB: the order management system. Because order management requires complex transactions, it remained on MySQL.
3. Solving MySQL Schema Migration Pain: Craigslist
For much of the history of Craigslist, MySQL was the only option for data storage, including its massive archive of classified posts. These posts are retained for years after they were initially posted for access by users (e.g., reposting an old job listing). The original Craigslist archive application simply copied the existing live database. If the live database schema changed, those changes needed to be propagated to the archive system.
This result was a hodgepodge schema and lengthy delays in making simple changes. For example, each ALTER TABLE statement took months to complete on the MySQL archive. When making changes to billions of rows in their MySQL cluster, Craigslist could not move data to the archive. Archive-ready data would pile up in the production database. During these periods, performance on the live database deteriorated.
Craigslist migrated their archive to MongoDB, keeping the live listings on MySQL. MongoDB's flexible data model could easily accommodate changes to the schema, without affecting the performance of the live site.
Want to Learn More? Get the RDBMS to MongoDB Migration Guide
Is there part of your application that would be better suited to a non-relational database? Companies like Salesforce.com, MTV, eHarmony and Cisco have migrated successfully from relational databases to MongoDB. In this whitepaper, you'll learn:
- Step by step how to migrate from a relational database to MongoDB.
- The relevant technical considerations, such as differences between the relational and document data models and the implications for schema design.
- Indexing, queries, application integration and data migration.