MongoDB 在 v4 之前不符合 ACID 的真正含义是什么? [英] What did MongoDB not being ACID compliant before v4 really mean?

问题描述

我不是数据库专家，也没有正式的计算机科学背景，所以请多多包涵.我想知道如果您使用旧的 MongoDB 会发生哪些现实世界负面的事情v4 之前的版本，不符合 ACID.这适用于任何不符合 ACID 的数据库.

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.

我了解 MongoDB 可以执行 原子操作，但他们不能t 支持传统锁定和复杂事务"，主要是出于性能原因.我也了解数据库事务的重要性，以及当您的数据库用于银行的示例，并且您正在更新几条都需要同步的记录时，您希望事务恢复到初始状态，如果有停电所以信用等于购买等.

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.

但是，当我开始谈论 MongoDB 时，我们这些不了解数据库实际实现方式的技术细节的人开始抛出如下语句:

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 比 MySQL 和 Postgres 快得多，但它无法正确保存"的可能性很小，例如百万分之一.

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".

不会正确保存"部分指的是这种理解:如果在您向 MongoDB 写入的那一刻发生停电，则有可能获得特定记录(例如，您正在跟踪文档中的页面浏览量)每个有 10 个属性)，其中一个文档只保存了 5 个属性……这意味着随着时间的推移，您的浏览量计数器将略微"关闭.你永远不会知道多少，你知道他们会 99.999% 正确，但不是 100%.这是因为，除非您专门将其设为 mongodb 原子操作，否则该操作是不保证是原子的.

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.

所以我的问题是，什么时候以及为什么 MongoDB 不能正确保存"的正确解释是什么?它不满足 ACID 的哪些部分，在什么情况下，以及您如何知道 0.001% 的数据何时关闭?这不能以某种方式解决吗?如果不是，这似乎意味着您不应该将 users 表之类的内容存储在 MongoDB 中，因为可能无法保存记录.但话说回来，这 1/1,000,000 的用户可能只需要尝试再次注册"，不是吗?

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?

我只是在寻找一个关于何时/为什么会在 MongoDB 等不符合 ACID 的数据库上发生负面事情的列表，理想情况下，如果有一个标准的解决方法(比如运行后台作业来清理数据，或者只为此使用 SQL，等等).

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.).

推荐答案

你在 MongoDB 中失去的一件事是多集合(表)事务.MongoDB 中的原子修饰符只能作用于单个文档.

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) 尽可能构建文档并尽可能使用原子修饰符，对于剩余部分，使用后台进程清理可能不同步的记录.例如，我从库存中删除项目并使用原子修饰符将它们添加到同一文档的 reservedInventory 数组中.

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.

这让我始终知道库存中没有物品(因为它们是由客户保留的).当客户结账时，我会从 reservedInventory 中删除这些项目.这不是标准交易，由于客户可能会放弃购物车，因此我需要一些后台进程来查找废弃的购物车并将保留的库存移回可用库存池.

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.

这显然不太理想，但它是大型应用程序中唯一 mongodb 不能完美满足需求的部分.另外，到目前为止它完美无缺.这在许多情况下可能是不可能的，但由于我使用的文档结构，它很适合.

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) 将事务数据库与 MongoDB 结合使用.通常使用 MySQL 为绝对需要它们的事物提供事务，同时让 MongoDB(或任何其他 NoSQL)做它最擅长的事情.

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.

如果我的 #1 解决方案从长远来看不起作用，我将进一步研究将 MongoDB 与 MySQL 结合，但现在 #1 很适合我的需求.

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.

这篇关于MongoDB 在 v4 之前不符合 ACID 的真正含义是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！