我不是数据库专家，也没有正式的计算机科学背景，所以请多多包涵。我想知道如果您使用旧的 MongoDB version prior to v4 会发生哪些现实世界负面的事情, 不是 ACID合规。这适用于任何不符合 ACID 的数据库。
我了解 MongoDB 可以执行 Atomic Operations ，但它们不“支持传统的锁定和复杂事务”，主要是出于性能原因。我也了解数据库事务的重要性，以及当您的数据库用于银行的示例，并且您正在更新几条都需要同步的记录时，您希望事务恢复到初始状态，如果有停电所以信用等于购买等。
但是，当我开始谈论 MongoDB 时，我们这些不了解数据库实际实现方式的技术细节的人开始抛出如下语句:
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 atomic operation , 不保证操作是原子的。
所以我的问题是，什么时候以及为什么 MongoDB 不能“正确保存”的正确解释是什么？它不满足 ACID 的哪些部分，在什么情况下，以及您如何知道 0.001% 的数据何时关闭？这不能以某种方式解决吗？如果不是，这似乎意味着您不应该将 users 表之类的内容存储在 MongoDB 中，因为可能无法保存记录。但话说回来，这 1/1,000,000 的用户可能只需要“尝试再次注册”，不是吗？
我只是在寻找一个关于何时/为什么会在 MongoDB 等不符合 ACID 的数据库上发生负面事情的列表，理想情况下，如果有一个标准的解决方法(比如运行后台作业来清理数据，或者只为此使用 SQL，等等)。
最佳答案
MongoDB 不符合 ACID 实际上是不正确的。相反，MongoDB 在文档级别 是 ACID 兼容的。
对单个文档的任何更新都是
- 原子:要么完全完成，要么不完成
- 一致:没有读者会看到“部分应用”的更新
- 孤立:同样，没有读者会看到“脏”读
- 耐用:(带有适当的写入问题)
MongoDB 没有的是 事务 - 即可以回滚且符合 ACID 的多文档更新。
请注意，您可以通过 using two-phase commit 在单个文档的符合 ACID 的更新之上构建事务。 .
关于sql - MongoDB 在 v4 之前不符合 ACID 的真正含义是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7149890/