Modernizing RDBMS Schemas With a MongoDB Document Model
Rate this tutorial
Welcome to the exciting journey of transitioning from the traditional realm of relational databases to the dynamic world of MongoDB! This is the first entry in a series of tutorials helping you migrate from relational databases to MongoDB. Buckle up as we embark on a thrilling adventure filled with schema design, data modeling, and the wonders of the document model. Say goodbye to the rigid confines of tables and rows, and hello to the boundless possibilities of collections and documents. In this tutorial, we'll unravel the mysteries of MongoDB's schema design, exploring how to harness its flexibility to optimize your data storage like never before, using the Relational Migrator tool!
The migration from a relational database to MongoDB involves several stages. Once you've determined your database and application requirements, the initial step is schema design. This process involves multiple steps, all centered around how you intend to access your data. In MongoDB, data accessed together should be stored together. Let's delve into the schema design process.
The most fundamental difference between the world of relational databases and MongoDB is how your data is modeled. There are some terminology changes to keep in mind when moving from relational databases to MongoDB:
| RDBMS | MongoDB |
|---|---|
| Database | Database |
| Table | Collection |
| Row | Document |
| Column | Field |
| Index | Index |
| JOIN | Embedded document, document references, or $lookup to combine data from different collections |
Transitioning from a relational database to MongoDB offers several advantages due to the flexibility of JSON (JavaScript Object Notation) documents. MongoDB's BSON (Binary JSON) encoding extends JSON's capabilities by including additional data types like int, decimal, dates, and more, making it more efficient for representing complex data structures.
Documents in MongoDB, with features such as sub-documents (embedded documents) and arrays, align well with the structure of application-level objects. This alignment simplifies data mapping for developers, as opposed to the complexities of mapping object representations to tabular structures in relational databases, which can slow down development, especially when using Object Relational Mappers (ORMs).
When designing schemas for MongoDB, it's crucial to consider the application's requirements and leverage the document model's flexibility. While mirroring a relational database's flat schema in MongoDB might seem straightforward, it undermines the benefits of MongoDB's embedded data structures. For instance, MongoDB allows collapsing (embedding) data belonging to a parent-child relationship in relational databases into a single document, enhancing efficiency and performance. It's time to introduce a powerful tool that will streamline your transition from relational databases to MongoDB: the Relational Migrator.
The transition from a relational database to MongoDB is made significantly smoother with the help of the Relational Migrator. The first step in this process is a comprehensive analysis of your existing relational schema. The Relational Migrator examines your database, identifying tables, relationships, keys, and other elements that define the structure and integrity of your data. You can connect to a live database or load a .SQL file containing Data Defining Language (DDL) statements. For this tutorial, I’m just going to use the sample schema available when you click create new project.
The first screen you’ll see is a diagram of your relational database relationships. This lays the groundwork by providing a clear picture of your current data model, which is instrumental in devising an effective migration strategy. By understanding the intricacies of your relational schema, the Relational Migrator can make informed suggestions on how to best transition this structure into MongoDB's document model.
Once your relational schema is analyzed, the Relational Migrator begins the task of suggesting MongoDB schemas. It offers suggestions for MongoDB schemas, translating relational concepts into document models. This isn't just about moving data around; it's about rethinking how that data can be structured to best utilize MongoDB's capabilities, such as its flexible document model and powerful query language.
Review the proposed document models, focusing on MongoDB's ability to handle embedded documents and references. Assess how these models align with your application's data access patterns and performance requirements.
You now enter the tuning phase. It's here that you adjust these suggestions to tailor-fit your application. This stage is also about strategizing how best to leverage your data — considering aspects like access patterns, update frequencies, and the potential for data growth. For an in-depth guide on how to model your data in MongoDB, see our data modeling guide.
In MongoDB, data that is accessed together should be stored together. This allows the avoidance of resource-intensive
$lookup operations where not necessary. Evaluate whether to embed or reference data based on how it's accessed and updated. Remember, embedding can significantly speed up read operations but might complicate updates if the embedded data is voluminous or frequently changed. Use the Relational Migrator's suggestions as a starting point but remain flexible. Not every recommendation will be applicable, especially as you project data growth and access patterns into the future.You may be stuck, staring at the daunting representation of your tables, wondering how to reduce this to a manageable number of collections that best meets your needs. Select any collection to see a list of suggestions for how to represent your data using embedded arrays or documents. Relational Migrator will show all the relationships in your database and how you can represent them in MongoDB, but they might not all be appropriate for application. In my example, I have selected the products collection.
Here, you can see I’m presented with a list of suggested mappings in the panel on the right side of the screen. A perfect suggestion for my use case is the categories. That is likely going to be read with the product document and will likely not be updated often, and presenting them together in one document will reduce the need for the
$lookup operation in my application example.An example of a suggestion I may avoid would be orders. To look at this like an e-commerce app, it is reasonable to expect the orders array to grow indefinitely, as more and more people order this product. This unbounded array is considered an anti-pattern and will harm the database performance. Now that I’ve considered this, I can deselect the undesired fields and select Apply.
Even better, if I don’t ever access the supplier collection outside of the product collection, once I’ve embedded it, I can drop this collection, and simplify my database.
If you want to see the relationships between two collections, select the link joining them. Here, you’ll see the Parent/Child relationship, the nature of the relationship (one-to-one/one-to-many/many-to-many), and the keys involved in linking the collections. Understanding the relationships in your data will help inform where you can make improvements in schema design.
Carefully consider the structure of each collection. The way you access and manipulate your data should guide the organization of your documents. The representation of relationships in MongoDB is a critical decision point. Embedding documents offers performance benefits for read-heavy operations, but references might be more suitable for datasets that are large or frequently updated. You can read more about this data concept in the data modeling documentation. Use the migrator’s suggestions to iteratively refine your new schema, and understand the suggestions are useful, but not all will make sense for you.
While the tool provides valuable recommendations, it's crucial to adapt these to your application's specific context. There are limited cases where all your data in one doc will be an optimal decision for your migration. Your migration strategy should not be static. As you begin to work with your new MongoDB schema, it's essential to remain open to changes. Real-world application usage and performance metrics will guide further refinements, ensuring that your database architecture is not only optimized for current needs but also scalable for future demands.
Once you’re happy with your database design, select data migration from the top of the page. Here, just enter your old relational database connection string and your new MongoDB database connection string, and follow the on-screen instructions. If you want to learn more or get stuck in the process, the Relational Migrator documentation contains all the information you need.
It can be difficult to understand how best to store your data in your application, especially if you’re new to MongoDB. MongoDB Atlas offers a variety of data modeling templates that are designed to demonstrate best practices for various use cases. To find them, go to your project overview and you'll see the "Data Toolkit." Under this header, click the "Data Modeling Templates." These templates are there to serve as a good starting point to demonstrate best practices depending on how you plan on interacting with your data.
While you may not encounter an exact replica of your application, these templates serve to showcase optimal schema design practices based on access patterns. For most cases, something applicable or worth considering in your data model design will be presented, enabling you to maximize the effectiveness of the document model.
Whether you're brand new to the MongoDB world or already familiar with the document model, migrating from a relational database to MongoDB requires careful consideration. These tools (such as Relational Migrator) and resources are there to speed up and inform your move to MongoDB and help you get the most out of your data.
In our next tutorial, we will discuss querying, how to translate your SQL queries using Relational Migrator, and how to utilize indexes to minimize your write overhead, reduce your read times, and speed up your application as you move from relational databases to MongoDB.
If you found this tutorial useful, check out our article — How to Model Your Documents for Vector Search — or pop over to our community forums to see what others are doing with MongoDB.
Rate this tutorial