I’ve recently been building a web app with Node and Express and decided to go full MERN stack and integrate MongoDB—or more accurately, I’m working with mongoose, the object modeling tool for MongoDB. I’ve spent most of my time working with SQL databases (PostgreSQL especially) and there are a lot of great posts out in the world that chart the difference between SQL and NoSQL databases.
One of the processes I had taken for granted in a SQL context is transactions. In the most basic context, a transaction involves the propagation of one or more changes to a database. Order matters in transactions. Consider an event where you have a value A, value B, and value C. Value A needs to deduct something from value B so that value C can deduct something from value A. Assume value A is 10, value B is 20, and value C is 100, and the value deducted is 15. If C deducts from A before A can deduct from B, that means A will have a negative value at some point. In this benign hypothetical, this is fine. But imagine we are dealing with a bank: A could incur overdraft penalties. In the real world, this could get sticky. If we were dealing with inventories in eCommerce, people could be buying things they thing are available but actually are not. Order matters!
TutorialsPoint has a helpful breakdown of the properties of transactions, which can be remembered through the acronym ACID.
• Atomicity − ensures that all operations within the work unit are > completed successfully. Otherwise, the transaction is aborted at
the point of failure and all the previous operations are rolled > back to their former state.
• Consistency − ensures that the database properly changes states
upon a successfully committed transaction.
• Isolation − enables transactions to operate independently of and transparent to each other.
• Durability − ensures that the result or effect of a committed
transaction persists in case of a system failure.
Historically, ACID transactions were not a part of MongoDB. This had to do with the the way NoSQL databases were used, but their growing popularity changed that. See Laura Schaefer’s blog post from January 2019 on the subject:
They explained how, for non-relational databases like MongoDB,
multi-document ACID transactions have historically been a bit of
an odd case. With a document data model, you naturally prefer to
keep changes localized to the document you are working on, so the
single operation ACID compliance was often enough.
With MongoDB 4.0, it became possible to execute ACID transactions, but that did not mean it was impossible before. The package Fawn made it possible to execute ACID transactions in MongoDb.
The development of ACID transactions in MongoDB was motivated, in part, by the long shadow relational databases with table models have cast over the history of databases. As Mat Keet and Alyson Cabral wrote in June of this year:
With subdocuments and arrays, documents allow related data to be
modeled in a single, rich and natural data structure, rather than > spread across separate, related tables composed of flat rows and > columns. As a result, MongoDB’s existing single document atomicity > guarantees can meet the data integrity needs of most applications. > In fact, when leveraging the richness and power of the document > > model, we estimate 80%-90% of applications don’t need multi- document transactions at all.
However, some developers and DBAs have been conditioned by 40
years of relational data modeling to assume multi-document
transactions are a requirement for any database, irrespective of
the data model they are built upon. Some are concerned that while
multi-document transactions aren’t needed by their apps today, they > might be in the future. And for some workloads, support for ACID > transactions across multiple documents is required.
As a result, the addition of multi-document transactions makes it > easier than ever for developers to address a complete range of use > cases on MongoDB. For some, simply knowing that they are available > will assure them that they can evolve their application as needed, > and the database will support them.
In Node, ACID transactions require the creation of helper functions that rely on async/await patterns in JavaScript to ensure that not only are transactions completely successfully but are completed in the correct order. For more on the topic, I recommend this post on MongoDB's blog.
Top comments (2)
Is there something missing on this part: "Consider a financial transfer, where X needs to send a (????)
TutorialsPoint has a helpful breakdown of the properties of transactions, which can be remembered through the acronym ACID. "
Thanks for catching this! I've revised it above.