Transactions Come to MongoDB

ACID transactions were originally a breakthrough in database computer science. Jim Gray defined the most widely accepted transaction model in the late 1970s. As he put it, “A transaction is a transformation of state which has the properties of atomicity (all or nothing), durability (effects survive failures), and consistency (a correct transformation).” This soon became popularized as ACID transactions: Atomic, Consistent, Independent, and Durable.

By the mid-1990s the idea that you might want a database that did not support ACID transactions seemed ludicrous. However, as the Web 2.0 revolution got underway, restrictions implicit in the ACID model became apparent. Websites dedicated to online ecommerce—Amazon for example—had a need for a transactional processing capability that could operate at massive scale. Early social networking sites such as Myspace and eventually Facebook faced similar challenges scaling their infrastructure from thousands to millions of users. Most importantly, these web companies aspired to global scale.

When operating at global scale, it turns out you can’t have it all: It’s impossible to have global scalability, ACID consistency, and high availability. If you’re Amazon, and the network between the U.S. and the U.K. is interrupted, you must either shut down one of those locations or allow the two locations to see inconsistent versions of the database. This dilemma was formalized in Brewer’s now infamous CAP theorem. For companies such as Amazon, availability and scalability trumped consistency, and they therefore turned away from ACID relational databases.

As distributed systems became more widespread, the stranglehold the relational database had previously enjoyed was broken. New databases emerged, most of which did not enforce ACID transactions.

MongoDB was one of these “next-generation” databases. MongoDB enforces strict consistency within a single document update, but it has not been possible to create a transaction that spans multiple documents. This relaxed transactional consistency allows MongoDB to scale more easily, but makes life a little bit more difficult for the application developer.

Obviously, MongoDB has done well enough in gathering the loyalty and affection of modern developers. However, there are a large range of application patterns for which ACID transactions are simply mandatory. For instance, it’s almost impossible to construct a financial system without an ACID-compliant database, and it’s awkward to support order processing without some degree of transactional consistency.

Therefore, it’s not that surprising to find MongoDB announcing support for ACID transactions in its 4.0 release. Details of the implementation are incomplete to date, but it appears that MongoDB will be implementing a paradigm very familiar to those who have used relational ACID databases.

Transactions will be identified by begin transaction statements and terminated by commit or rollback statements. Under the hood, MongoDB will implement a Multi-Version Consistency Control (MVCC) model. In an MVCC system, multiple versions of data items are maintained and are identified by transaction IDs or timestamps. Queries see only the versions of data that are current when the query commenced, preventing queries from seeing uncommitted data and also minimizing locking. This model has worked successfully in most of the relational systems, and there is no reason to think it won’t work well within MongoDB. However, it does introduce a new contention point within applications, since it is necessary for MongoDB to lock documents that are involved in current transactions. Luckily, the WiredTiger engine already supports document-level locking so this contention is relatively contained.

It may seem strange to see MongoDB expanding the very features of the relational databases that it originally rejected. In the last few releases, we’ve seen implementation of joins, strict schemas, and now ACID transactions. However, what this indicates is that MongoDB is increasingly contending for serious enterprise database workloads: MongoDB is expanding the scope of its ambitions.