I am not a database expert and have no formal computer science background, so bear with me. I want to know the kinds of real world negative things that can happen if you use an old MongoDB version prior to v4, which were not ACID compliant. This applies to any ACID noncompliant database.
I understand that MongoDB can perform Atomic Operations, but that they don’t “support traditional locking and complex transactions”, mostly for performance reasons. I also understand the importance of database transactions, and the example of when your database is for a bank, and you’re updating several records that all need to be in sync, you want the transaction to revert back to the initial state if there’s a power outage so credit equals purchase, etc.
But when I get into conversations about MongoDB, those of us that don’t know the technical details of how databases are actually implemented start throwing around statements like:
MongoDB is way faster than MySQL and Postgres, but there’s a tiny chance, like 1 in a million, that it “won’t save correctly”.
That “won’t save correctly” part is referring to this understanding: If there’s a power outage right at the instant you’re writing to MongoDB, there’s a chance for a particular record (say you’re tracking pageviews in documents with 10 attributes each), that one of the documents only saved 5 of the attributes… which means over time your pageview counters are going to be “slightly” off. You’ll never know by how much, you know they’ll be 99.999% correct, but not 100%. This is because, unless you specifically made this a mongodb atomic operation, the operation is not guaranteed to have been atomic.
So my question is, what is the correct interpretation of when and why MongoDB may not “save correctly”? What parts of ACID does it not satisfy, and under what circumstances, and how do you know when that 0.001% of your data is off? Can’t this be fixed somehow? If not, this seems to mean that you shouldn’t store things like your users table in MongoDB, because a record might not save. But then again, that 1/1,000,000 user might just need to “try signing up again”, no?
I am just looking for maybe a list of when/why negative things happen with an ACID noncompliant database like MongoDB, and ideally if there’s a standard workaround (like run a background job to cleanup data, or only use SQL for this, etc.).
One thing you lose with MongoDB is multi-collection (table) transactions. Atomic modifiers in MongoDB can only work against a single document.
If you need to remove an item from inventory and add it to someone’s order at the same time – you can’t. Unless those two things – inventory and orders – exist in the same document (which they probably do not).
I encountered this very same issue in an application I am working on and had two possible solutions to choose from:
1) Structure your documents as best you can and use atomic modifiers as best you can and for the remaining bit, use a background process to cleanup records that may be out of sync. For example, I remove items from inventory and add them to a reservedInventory array of the same document using atomic modifiers.
This lets me always know that items are NOT available in the inventory (because they are reserved by a customer). When the customer check’s out, I then remove the items from the reservedInventory. Its not a standard transaction and since the customer could abandon the cart, I need some background process to go through and find abandoned carts and move the reserved inventory back into the available inventory pool.
This is obviously less than ideal, but its the only part of a large application where mongodb does not fit the need perfectly. Plus, it works flawlessly thus far. This may not be possible for many scenarios, but because of the document structure I am using, it fits well.
2) Use a transactional database in conjunction with MongoDB. It is common to use MySQL to provide transactions for the things that absolutely need them while letting MongoDB (or any other NoSQL) do what it does best.
If my solution from #1 does not work in the long run, I will investigate further into combining MongoDB with MySQL but for now #1 suits my needs well.