MongoDB不符合ACID的标准是什么意思？
我不是数据库专家，没有正式的计算机科学背景，所以请耐心等待。 我想知道如果使用不符合ACID标准的MongoDB，可能会发生的真实世界的负面情况。 这适用于任何ACID不合规数据库。
据我所知，MongoDB可以执行Atomic Operations，但他们并不“支持传统锁定和复杂事务”，主要是出于性能方面的考虑。 我也了解数据库事务的重要性，以及您的数据库用于银行时的示例，并且您正在更新多个需要同步的记录，如果有一个数据库需要事务恢复到初始状态停电，所以信贷等于购买等。
但是当我进入关于MongoDB的谈话时，我们这些不知道数据库如何实际实现的技术细节的人开始抛出像下面这样的陈述：
MongoDB的速度比MySQL和Postgres快，但是有一个很小的机会，比如百万分之一，它“无法正确保存”。
这个“无法正确保存”的部分是指这样的理解：如果您在写入MongoDB的瞬间有停电的可能，则可能会有特定记录（例如，您要跟踪具有10个属性的文档中的浏览量每个文档），其中一个文档只保存了5个属性......这意味着随着时间的推移，您的浏览量计数器将“略微”关闭。 你永远不会知道多少，你知道他们将99.999％正确，但不是100％。 这是因为，除非你专门做了一个mongodb原子操作，否则操作不能保证是原子操作。
所以我的问题是，什么时候以及为什么MongoDB不能“正确保存”的正确解释？ ACID的哪些部分不能满足要求，以及在什么情况下，您如何知道您的数据的0.001％何时关闭？ 这不能以某种方式解决吗？ 如果没有，这似乎意味着你不应该在MongoDB中存储像users表这样的东西，因为记录可能不会保存。 但是再一次，那1 / 1,000,000用户可能只需要“尝试再次注册”，不是吗？
我只是在寻找一个时间/为什么负面事情发生在一个像MongoDB这样的ACID不兼容的数据库的列表，理想情况下，如果有一个标准的解决方法（比如运行后台作业来清理数据，或者只使用SQL等） 。
MongoDB失去的一件事是多次收集（表）事务。 MongoDB中的原子修饰符只能针对单个文档。
如果您需要从库存中删除某件商品并将其添加到某个人的订单中，则无法进行此操作。 除非这两件事情 - 库存和订单 - 存在于同一份文件中（他们可能不这样做）。
我在一个正在处理的应用程序中遇到了这个问题，并且存在两种可能的解决方案：
1）尽你最大可能地构建您的文档，并尽可能使用原子修饰符，因为他仍然可以使用后台进程来清理可能不同步的记录。 例如，我从库存中删除项目，并使用原子修饰符将它们添加到同一文档的reservedInventory数组中。
这让我总是知道物品在库存中不可用（因为它们是由客户保留的）。 当客户检查结束时，我从reservedInventory中删除这些项目。 它不是一项标准交易，因为客户可能会放弃购物车，所以我需要一些后台流程才能查找并找到废弃的购物车，并将预留的库存移回可用库存池。
这显然不太理想，但它是大型应用程序中mongodb不能完美满足需求的唯一部分。 此外，它迄今为止完美无瑕。 对于许多情况来说这可能是不可能的，但由于我使用的文档结构，它很适合。
2）将事务数据库与MongoDB结合使用。 使用MySQL为绝对需要的事务提供事务处理是很常见的，同时让MongoDB（或任何其他NoSQL）尽其所能。
如果我的解决方案从长远来看不起作用，我会进一步调查MongoDB与MySQL的结合，但现在＃1很适合我的需求。
实际上MongoDB不符合ACID标准是不正确的。 相反，MongoDB 在文档级是ACID编译器。
对单个文档的任何更新都是
MongoDB没有的事务是事务 - 也就是说，多文档更新可以回滚并且符合ACID标准。
请注意，通过使用两阶段提交，您可以在符合ACID的更新之上将事务构建到单个文档。
“星巴克不使用两阶段提交”中有一个很好的解释。
这不是关于NoSQL数据库，但它确实说明了有时您可以承受失去一笔交易或使您的数据库暂时处于不一致状态。
我不认为这是需要“固定”的东西。 解决方法是使用符合ACID标准的关系数据库。 当您的行为符合您的应用程序要求时，您可以选择NoSQL备选方案
链接地址: http://www.djcxy.com/p/86369.html上一篇: What does MongoDB not being ACID compliant really mean?