␡
- What Is NoSQL?
- Choosing RDBMS, NoSQL, or Both
- Understanding MongoDB
- MongoDB Data Types
- Planning Your Data Model
- Summary
- Q&A
- Workshop
This chapter is from the book
Choosing RDBMS, NoSQL, or Both
When investigating NoSQL databases, keep an open mind regarding which database to use and how to apply it. This is especially true with high-performance systems.
You might need to implement a strategy based on only RDBMS or NoSQL—or you might find that a combination of the two offers the best solution in the end.
With all high-performance databases, you will find yourself trying to balance speed, accuracy, and reliability. The following is a list of just some considerations when choosing a database:
- What does my data look like? Your data might favor a table/row structure of RDBMS, a document structure, or a simple key-value pair structure.
- How is the current data stored? If your data is stored in an RDBMS database, you must evaluate what it would take to migrate all or part to NoSQL. Also consider whether it is possible to keep the legacy data as is and move forward with new data in a NoSQL database.
- How important is the guaranteed accuracy of database transactions? A downside of NoSQL is that most solutions are not as strong in ACID (Atomic, Consistency, Isolation, Durability) as in the more well-established RDBMS systems.
- How important is the speed of the database? If speed is the most critical factor for your database, NoSQL might fit your data well and can provide a huge performance boost.
- What happens when the data is not available? Consider how critical it is for customers when data is not available. Keep in mind that customers view situations in which your database is too slow to respond as unavailability. Many NoSQL solutions, including MongoDB, provide a good high availability plan using replication and sharding.
- How is the database being used? Specifically, consider whether most operations on the database are writes to store data or whether they are reads. You can also use this exercise as an opportunity to define the boundaries of how to split up data, enabling you to gear some data toward writes and other data toward reads.
- Should I split up the data to leverage the advantages of both RDBMS and NoSQL? After you have looked at the previous questions, you might want to consider putting some of the data, such as critical transactions, in an RDBMS while putting other data, such as blog posts, in a NoSQL database.