Postgres vs MongoDB for Transactional B2B Apps at 1M+ Records
您的 B2B 产品在去年达到了产品市场契合点。今天，您的主数据库中有 120 万条记录，响应时间在高峰时段悄然突破 400 毫秒，而您的基础设施账单刚刚翻了一番。在您花费另一个季度去调优错误的引擎之前，值得问一问：您当初是否选对了数据库，或者现在切换是否比再忍受一年的变通方案更划算。
"随便选一个"在何处悄然崩溃
Postgres 与 MongoDB 之争由来已久，但大多数团队仍然凭感觉做出选择。团队里有人熟悉 Postgres，或者教程使用了 MongoDB，于是这就成了默认选项。在前十万条记录时，这个选择是无形的。一旦超过百万行和几千个并发用户，错误选型的代价就开始以缓慢的仪表板、周末救火以及工程负责人昂贵的重构提案的形式浮现出来。
两款引擎都非常出色。两者都支撑着庞大的生产工作负载。但它们针对不同的数据形态和不同的保证进行了优化，而 B2B 事务型应用恰恰在这两者分歧的维度上施加压力。对这类应用最重要的四个权衡是：一致性、大规模下的查询延迟、拥有成本，以及变更成本。
一致性是业务风险，不是偏好
对于事务型 B2B 系统（发票、订单、合同、库存、薪资），数据库的默认一致性模型不是口味问题。它是一种业务风险，当它失效时会体现在您的损益表上。
Postgres 是一款成熟的关系型引擎，具有强大的 ACID 保证、真正的外键，以及开箱即用的可串行化隔离级别。当您的计费服务提交一张发票时，您可以保证相应的行项目存在，客户额度被原子性地扣减，并且并发读取不会看到未完成的写入。对于涉及财务的工作流，这种正确性值得付费。
MongoDB 已经缩小了很多差距。多文档 ACID 事务自 4.0 起已具备生产可用性，单文档写入始终是原子的。但默认配置仍然偏向可用性和灵活的模式，而非严格的正确性。多文档事务带有可测量的性能成本，索引必须刻意维护，而模式漂移可能一直隐藏，直到一份错误的报告在客户面前将其暴露。
工程上的权衡直接映射到业务风险。如果一份面向客户的报告中的错误数字会让您失去一个客户，那么请优先选择默认强制正确性的数据库。如果您的工作负载主要是仅追加的遥测数据或最终一致性可以接受的用户生成内容，这个约束的影响就没那么大。
100 万条以上记录时的延迟
两款引擎都能扩展到远超百万条记录。真正的区别在于您需要做多少工作才能让它们保持快速。
Postgres 在"无聊"的读取模式上胜出：有界结果集、带索引的连接、带有可预测过滤条件的良好查询。一张正确建立索引的 Postgres 表可以在数亿行的量级上以个位数毫秒的速度提供点查找服务，并且查询规划器通常能从写得不好的查询中恢复。Postgres 吃力的地方是无界文档读取、深度嵌套的反范式结构，以及模式变化剧烈的工作负载。
MongoDB 在您的访问模式确实是文档形态时胜出：一次查询返回一个嵌套对象，该对象干净地映射到 API 响应，热路径上没有连接。这消除了网络往返和序列化开销。但陷阱是，只有当您在第一天就正确设计了文档边界时，这才成立。当这些边界是错误的（而且它们通常是错的，因为早期的产品决策是猜测）时，您最终会得到跨集合查找，而 MongoDB 从未针对这一点进行优化，延迟退化的速度比同等的 Postgres 连接更快。
对于带有仪表板、可过滤列表和叠加在事务数据之上的分析报告的 B2B 应用，在 100 万条以上记录时，Postgres 几乎总是赢得中位延迟的较量。
真实的成本图景
云服务的定价页面让 Postgres 和 MongoDB 看起来相似。真实的拥有成本并非如此。
Postgres 是一种大宗商品。每家主要的云厂商都提供托管服务，很多工程师知道如何调优它，而开源 Postgres 在生产环境中的运行方式与在笔记本电脑上一致。当凌晨 2 点出问题时，您可以找到答案。
托管的 MongoDB 很方便，但一旦进入带有备份、VPC 对等连接和审计日志的专用集群，其价格就是溢价的。自托管 MongoDB 是可行的，但需要在当前市场上比 Postgres 运维技能更稀缺、更昂贵的运维能力。
更大的成本是二阶成本：每年有多少工程师小时用于模式迁移、索引调优和救火？我们合作的团队通常低估这一点三到五倍。一个每季度为您的团队节省两个工程周的数据库，无论账单上的标价如何，其回报都远超其成本。
每款引擎实际胜出的场景
在以下情况下选择 Postgres：您的数据本质上是关系型的（客户、订单、发票、行项目）；您需要强一致性和真正的引用完整性；您的团队规模小，无法负担一位数据库专家；或者分析读取和仪表板与写入位于同一系统中。
在以下情况下选择 MongoDB：您的文档确实是嵌套的且很少连接（产品目录、CMS 内容、高流量事件负载）；您需要跨区域的水平写入扩展并能接受最终一致性；您的模式演进迅速，您重视灵活性胜过强制约束；或者您已经具备了良好运行它的运维专长。
对于大多数 B2B 事务型应用，诚实的自我评估会落到 Postgres 上。这并不意味着 MongoDB 是错的。这意味着默认选项必须由工作负载的形态来赢得，而不是由团队的熟悉程度来赢得。
如果您已在生产中，务实的路径
如果您已经在错误的引擎上进入了生产，不要恐慌迁移。重写是解决数据库问题最昂贵的方式。先从测量开始：分析您最慢的十个查询，计算您正在吸收的运维开销的年成本，并将两三个最热工作负载的定向迁移成本与维持现状的成本进行比较。
有时正确的答案是混合方案。让当前系统继续做它擅长的事情，仅针对另一款引擎确实更适合的工作负载在旁边引入 Postgres 或 MongoDB。这是一个比完全重写更小、更可测试的赌注，让您在把整个产品都押上之前验证假设。
您在 1 万条记录时选择的数据库，在 1000 万条时很少还是正确的数据库。避免痛苦的重新平台化的团队，是那些按计划而不是按火情重新审视选择的团队。如果您的产品正在接近这个规模，并且您希望在下一份扩容账单到来之前，就架构问题获得一位有经验的第二意见，MerkTechs 工程团队很乐意与您的 CTO 坐下来，针对您实际的工作负载走一遍这些权衡。