MongoDB 文档和博客这样描述它的事务能力。
MongoDB 写入操作在文档级别符合 ACID - 包括 >自动更新嵌入式数组和子文档的能力。
现在我想知道这种“文档级事务支持”是否足够？ 我的意思是说它可以和老式 RDBMS 中的事务支持一样好吗？
关于可能的重复，我想到的是一个普遍的问题，即“这足够了吗？”对于开发人员？与否。
【问题讨论】：
标签： mongodb transactions nosql
我会同意 Joshua 的观点，并加上我的两分钱。在 RDBMS 世界中，事务非常频繁地更新多个规范化的数据承载结构。需要强大的原子性级别来确保将更改作为一个单元提交给所有这些结构，或者作为一个单元回滚。在 MongoDB 中，理想情况下，您将设计您的模式以将逻辑上属于一起的数据一起存放在同一个文档中。这使得文档级别的原子性完全满足您的典型文档架构。
我也同意，RDBMS 和 MongoDB 事务处理都不应该是您防止错误和数据损坏的唯一防线。对于必须是原子的关键数据更改，您应该始终在更新后的代码级别检查一致性。
最后一个想法：在大多数 RDBMS 系统中，事务处理并不总是一对一地映射到并发。通常，大型事务可以锁定整个表或表并导致积压响应。在 MongoDB 中，事务处理中的文档级 ACID 合规性与使用 WiredTiger 存储引擎的人可用的文档级并发性非常吻合。如果在设计时兼顾这两个方面，您的应用程序可以在文档级别实现高度并发和完全符合 ACID，从而为事务性工作负载提供高水平的性能和吞吐量。
干杯，
比尔·芬奇
【讨论】：
回答这个问题需要了解 NoSQL 世界中的模式设计。如果您像在 RDBMS 中那样处理架构设计，那么您将遇到非常糟糕的情况，而不仅仅是因为事务。
但是，如果您正确设计文档，则文档级别的 ACID 合规性应该适用于 99% 的用例。我什至会争辩说，在这 99% 和 1% 的用例之外，您不应该依赖数据库进行交易。这将是一个非常复杂的情况，您要并行更改两个完全独立的事物。即使在 RDBMS 中，如果您这样做，您总是会在代码中编写验证。
一个示例可能是银行客户的批量更新，其中涉及他们更改姓名并同时更改地址。在 RDBMS 中，这些可能是单独的表。在 MongoDB 中，它们都在同一个文档中。所以这符合 99%。
借记一个帐户并贷记另一个帐户就是适合 1% 的示例。您可以将其包装在 SQL 中的事务中，但如果您之后不编写代码来验证写入，您将失去工作。你永远不会依赖数据库。与 MongoDB 相同，这将是两个不同的文档。
【讨论】：
文档级事务很好，但对于实际应用程序来说还不够。通常，您必须像在 RDBMS 世界中那样思考一些不同的想法，并使用“子文档”，并且您可以在没有集合范围事务的情况下解决许多情况，但是有足够的用例，您肯定需要集合-广泛的交易。 帐户系统的借方/贷方情况就是一个例子……或者如果您实施一场战斗游戏，其中两个玩家互相对抗，一个（获胜者）从另一个（更宽松的）那里获得“资源”。 ..如果出现故障，您必须并行更新两个玩家的资源状态，或者两者都必须回滚。这不像在 RDBM 系统中那样由 MongoDB 事务处理。
再一次，正如其他人已经说过的那样：您必须考虑对象/文档结构，在那里您可以处理许多情况，其中文档级事务已经足够......
但是集合范围的事务在 MongoDB 的路线图上；-)
【讨论】：
如果您能够将所有逻辑数据包含在一个文档中，那么 MongoDB 将比关系数据库更快、性能更高。您必须确保将同时写入或不写入所有数据（在文档级别符合 ACID）。
如果您不着急，MongoDB 正在努力获取跨集合的事务！
问候， 娟
【讨论】：
从 4.0 版开始，MongoDB 将添加对多文档事务的支持。因此，您将拥有 MongoDB 中具有 ACID 保证的文档模型的强大功能。
详情请访问此链接：https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb?jmp=community
【讨论】：