分布式数据库怎样兼顾速度、可靠和正确？｜The Pragmatic Engineer × Peter Mattis

分布式数据库不能只追求快：数据要能在机器故障后恢复，也要让不同副本对写入顺序达成一致。Cockroach Labs 联合创办人 Peter Mattis 从 Gmail、Google 的存储系统和 CockroachDB 讲这些设计如何相互影响，也谈到 AI 正在改变工程师的工作方式。贯穿他的经验的一点是，性能、可靠性和正确性往往取决于底层结构，而不是简单增加机器。

原始来源：Distributed databases with Peter Mattis。中文深度整理，非逐字翻译。本文依据发布方 The Pragmatic Engineer 的节目整理与技术要点，不是 YouTube 字幕。

Gmail 用树结构把邮件归进对话

Peter Mattis 早年参与 Gmail 存储系统时，邮件不是彼此孤立地保存：系统需要把新邮件匹配到已有对话，并维护线程和未读数。发布方的节目整理介绍，Gmail 使用 B 树跟踪邮件线程及其未读状态。B 树是一种把大量键值组织成有序索引的数据结构，适合在磁盘或存储系统里查找和更新记录。

这类数据结构也影响工程师后来怎样设计数据库。Peter 在 Google 观察到，C++ 的 std::map 使用红黑树，每个节点都要保存指针；他做的 B 树在相近接口下能利用数据局部性，减少指针占用，并在 Google 内部应用。后来他也为 Go 的 map 做过 Swiss Table 实现，最终由 Go 团队协作完善并进入标准库。这里的例子说明，性能改进不一定来自换更大的服务器，有时来自重新安排数据在内存中的布局。

存储系统的约束会传到数据库里

Google 的 Colossus 用纠删码减少存储开销：在保留冗余能力的同时，把完整副本从三份减少为两份。节目整理称，这让文件存储的冗余开销降低约三分之一。Colossus 的设计也影响了 Spanner。因为 Colossus 是追加写入式系统，数据文件不能随意原地修改，后来构建在它之上的系统更适合采用 LSM 树。

LSM 树把新写入先追加到日志，再逐步合并数据；它符合追加写入存储的特点，但读写性能与传统 B 树不同。CockroachDB 早期使用 RocksDB，后来 Mattis 编写并开源 Pebble，成为 CockroachDB 的存储引擎。这个演进说明，数据库选型不是寻找一棵“最好的树”，而是先看底层存储允许怎样写，再选择与这些限制相匹配的数据结构。

三个副本不是免费保险

分布式系统要考虑机器之间的信息传递有延迟、服务可能离线、CPU 或网络等资源会耗尽。Mattis 的经验是，很多故障最终来自资源池被用光，而不是抽象的算法错误。比如，数据库默认把数据放在三个副本上：只有一个副本时，机器坏了就无法恢复；两个副本则可能在一方崩溃后无法确认最后一笔写入是否已被另一方收到。三个副本能让系统通过多数派判断达成一致。

但副本越多，写入需要等待的节点也可能越多，因而影响延迟和成本。节目还提到，CockroachDB 的部分系统表会用五个副本；客户也能增加副本，只是系统要付出更高延迟。工程师需要按数据的重要性、故障恢复要求和用户可接受的等待时间来定，而不能把“副本越多”当成无条件更可靠。

AI 让工程师更像同时带着几组实验

Peter 过去每年能把约十万行数据库级代码交付到生产环境。节目整理记录，他现在觉得自己借助 AI 更高效，且没有明显牺牲质量。他会同时启动多个实验，让不同的代理并行处理，再比较回来的结果；这种工作状态不像专注敲一段代码，更像同时带着一群研究助理推进问题。

他也观察到，Cockroach Labs 的非工程员工曾在几个月内用内部工具做出约一千个小应用，包括 HR 工具和财务仪表盘。这显示 AI 编程工具能让更多人把需求变成可用的软件，但这些工具是否适合长期维护、会不会增加系统的隐性复杂度，节目整理没有提供独立评估。

Mattis 还预测，随着代理写代码的能力提升，工程师可能逐渐减少逐行检查代码的时间。他把这看作趋势判断，而不是已经普遍发生的事实。对数据库这样的系统，最终仍要验证写入顺序、故障恢复、数据一致性和资源上限；AI 加快了试验速度，但没有替团队取消这些正确性要求。