支持ACID的MongoDB与RDBMS对比：适用性及性能分析

一、带事务的性能对比 #

MongoDB 4.0+支持ACID事务后，和RDBMS的性能差异主要体现在事务复杂度与部署架构上：

• 单文档事务：MongoDB的文档级锁机制天然适配单文档操作，性能接近甚至超过RDBMS。无需跨表关联，事务仅锁定目标文档，并发冲突概率更低——比如单实例下，1000次单文档更新事务，MongoDB耗时通常比MySQL少10%-20%。
• 多文档/多集合事务（单实例）：依赖两阶段提交（2PC）实现，性能略逊于RDBMS的本地事务。相同复杂度的多集合事务，MongoDB耗时约为MySQL的1.2-1.5倍，差异主要来自事务协调的额外开销。
• 跨分片分布式事务：性能差距进一步拉大，耗时通常是单实例RDBMS的2-3倍。需要协调多个分片节点的锁、日志同步，网络延迟和节点协调成本显著增加。

二、能否在多数场景下替代RDBMS？ #

适合替代的场景 #

• 半结构化/非结构化数据存储：比如用户行为日志、社交动态、IoT设备数据，MongoDB的无schema文档模型无需预定义表结构，可灵活适配数据结构变化。
• 高并发单文档OLTP场景：比如电商商品详情、用户信息管理，单文档事务性能优异，且MongoDB的水平分片扩展能力比RDBMS更便捷，能更好应对流量突增。
• 快速迭代的业务：无需频繁执行ALTER TABLE修改结构，降低运维成本，加快业务上线速度。

不适合替代的场景 #

• 复杂多表关联查询：比如财务多维度报表、供应链跨节点统计，RDBMS的JOIN查询效率远高于MongoDB的$lookup，后者在关联数据量较大时性能会急剧下降。
• 复杂事务场景：这是MongoDB的核心短板，下面结合具体场景说明。

三、为何MongoDB不适合复杂事务应用？ #

所谓“复杂事务”，通常指涉及多实体、多步骤、强关联的原子性操作，以下是典型场景对比：

1. 银行转账+多维度账务联动场景 #

业务逻辑：用户A转账给用户B，需同时完成：更新A/B账户余额、记录转账流水、给A增加积分、更新积分流水、同步账户风险评级，涉及5个独立集合。

• RDBMS：可在一个本地事务中通过多表操作完成，锁机制成熟，事务回滚原子性强，并发高时仍能保持稳定性能，数据库优化器会自动生成最优执行计划。
• MongoDB：即使支持多集合事务，也需手动编写多集合读写逻辑，事务执行时需锁定多个文档/集合，并发冲突概率大幅上升；若为分片集群，跨分片事务的协调成本会导致延迟飙升，且默认事务超时时间（60秒）无法适配长耗时的复杂事务，容易出现执行失败或数据不一致。

2. 电商订单全链路库存扣减场景 #

业务逻辑：用户下单后，需扣减商品SKU库存、扣减仓库总库存、更新订单状态、记录库存变动日志、更新商品销量统计，涉及多个关联实体（部分数据需跨集合共享）。

• RDBMS：通过外键约束和多表事务，可确保所有操作原子性完成，库存扣减的行级锁能有效平衡并发和一致性。
• MongoDB：若将库存与订单嵌入同一文档，会导致库存数据无法被多个订单共享；若拆分独立集合，多集合事务的开销会随着事务步骤增加而指数级上升，且无法像RDBMS一样通过外键约束保证数据关联的合法性，需在业务层额外校验，增加开发复杂度。

3. 财务复式记账场景 #

业务逻辑：每一笔账务操作必须同时更新借方和贷方账户，还要关联科目、部门、项目等维度的统计数据，要求100%的一致性，事务涉及多表关联和多步骤计算。

• RDBMS：原生支持复式记账的事务逻辑，通过ACID特性保证账务平衡，且优化器能高效处理多表关联的事务执行，性能稳定。
• MongoDB：虽然能通过事务实现原子性，但复杂的多关联事务会导致代码逻辑极度繁琐，且事务执行过程中需要多次跨集合读写，性能远低于RDBMS，一旦出现事务失败，回滚逻辑的复杂度也远高于RDBMS。

内容的提问来源于stack exchange，提问作者sabu