在v4之前，MongoDB不符合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?

我只是在寻找与ACID不兼容的数据库(例如MongoDB)何时/为什么出现负面事件的列表，理想情况下，如果有标准的解决方法(例如运行后台作业以清理数据，或者仅使用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.

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