If you've used MongoDB or been a part of users' conversations about MongoDB, you'll be aware that, while it's one of the most successful NoSQL databases available, it has faced a lot of criticism for not supporting multi-document transactions. Now, that's about to change.
Background on SQL Databases, NoSQL Databases, and MongoDB
Original SQL databases were built to manage data and stream processing in a relational database. In the late 2000s, the first NoSQL databases were developed to deal with some limitations of SQL relational databases related to multi-structured data, horizontal scalability, and quickly evolving schemas.
In this context, 10gen software company began developing MongoDB in 2007 as a service product, and then in 2009, the company shifted to an open source development model that offered commercial support and other services. In 2013, 10gen changed its name to MongoDB Inc. Now, MongoDB is one of the most successful NoSQL databases out there.
The Challenges of Working with MongoDB
Despite the fact that MongoDB is a very successful example of an NoSQL database, one the biggest criticisms it faces is that it does not allow ACID (atomicity, consistency, isolation, durability) transactions when it comes to multi-document transactions, though it does support ACID transactions at the document level. It is important to note here that most NoSQL databases, not just MongoDB, lack true ACID transactions, which were more a function of SQL databases.
Some users think that transactions have a great impact on their applications and thus choose to continue using SQL databases rather than NoSQL databases. From my own experience of working with MongoDB, modeling data appropriately will, in many scenarios, minimize the need for multi-document transactions, and the denormalized data model will continue to be optimal for data and use cases.
But as many NoSQL database users continue to maintain, there are certain scenarios where multi-document transactions can make your application less complex and more reliable. These users will be happy to hear that MongoDB supports multi-document transactions in MongoDB v4.0. This development has been in progress for a long time. Let's take a look at what lead to this development.
WiredTiger vs. MMAPv1
Due to the original proposal of MongoDB, their first DB engine, MMAPv1, wasn’t built to support transactions. In December of 2014, however, MongoDB acquired WiredTiger, which was their first step toward including transactions. This acquisition meant that MMAPv1 was replaced by WiredTiger as the default DB engine in MongoDB v3.0. As shown below, WiredTiger performs well in the following categories in most use-cases, whereas MMAPv1’s design makes it suitable for specific, specialized cases.
- Scalability.
- - WiredTiger performs better on multi-core systems.
- - MMAPv1 is not designed to scale with multiple cores; adding CPU cores does not significantly improve performance.
- Concurrency.
- - WiredTiger performs its locking on the document level, whereas MMAPv1 performs it on the collection level, resulting in superior concurrency for WiredTiger.
- Compression.
- - WiredTiger supports gzip and snappy (default) compression for indexes and collections; MMAPv1 does not support compression.
- - The size of WiredTiger collections is smaller than MMAPv1, with or without compression enabled.
- - WiredTiger supports index-prefix compression, reducing the size of indexes both on disk and loaded in memory.
Most importantly, WiredTiger also enabled MongoDB to begin building support for multi-document transactions. This didn't happen immediately since it was impossible for MongoDB to implement all the changes they planned at once. After 3 years, however, MongoDB will soon release v4.2, which will support transactions in a sharded deployment.
Summary
When a developer faces a new paradigm, like a shift from SQL to NoSQL databases, he can use it to help his work processes or he can have one of two negative responses: either the developer resists new challenges (a defensive reaction to change) and thinks that the new paradigm does not work for his case, or else he uses the new paradigm in the wrong way. I have seen some cases where a developer was using MongoDB as a database for an application where the data was too related to be used in a non-relationship database, which meant he had to increase his code's complexity to ensure the consistency of the relationships.
In another case, the developer was trying to create his data model, using an NoSQL document-oriented database, by thinking about it in terms of an SQL relationship database. In some cases, this approach can work, but the best approach is to have a whole new perspective about the application and understand how it makes the most sense to build the model relationships, when necessary, using inner documents or soft constraints (identifiers). In this case also, if the developer used the new paradigm in the way it was intended to be used, his experience would have been much more positive.
This is what happened to some developers who tried to use MongoDB: the first MongoDB version releases faced many critiques because they didn't have certain features that developers were used to having with SQL databases, such as join operations and transactions; there were also complaints about its Map/Reduce performance. Some users didn't like the new paradigm of the NoSQL document-oriented database in general.
It's important for developers to realize that 1) sometimes adapting to a new model can bring positive change and 2) MongoDB has listened to user critiques and has worked hard to resolve them. MongoDB has evolved a lot in the last years for the better. Not only will it support multi-document transactions, but it also has other features, such as the Aggregate pipeline, which allows users to aggregate data in a flexible way that performs better than Map/Reduce. While MongoDB can still improve, it's certainly headed in the right direction, and many developers can benefit from using it.
I believe that transactions will make MongoDB the best choice of a wide range of new applications -- apps that require “all-or-nothing” execution. MongoDB's new version release will allow developers to evolve their current applications to the transactional paradigm, or at least give them the option to choose whether or not they want to use transactions.
