分布式数据库与 Peter Mattis：从 GIMP、Gmail 到 Cockroach Labs

流媒体播放最新一集

现在就在 YouTube、Apple 和 Spotify 上收听和观看。本页顶部可查看本集文字稿，底部可查看本集时间戳。

本节目由以下赞助商支持

• turbopuffer – turbopuffer 工程团队正在做一件非常酷的事：他们正从第一性原理出发彻底重新设计存储架构，让搜索在大规模下更快、更便宜、更可靠。而且他们把整个过程都记录下来了！在 turbopuffer.com/v3 关注他们的重写进展

• Linear – 我们大多数人在“单人模式”下与智能体协作。Linear 的观点是，智能体工作应该是团队协作：你的队友可以跟进智能体的会话，查看它产出的 PR，并加入评审。支持 Codex、Cursor、Linear 自家智能体或自定义智能体。来看看吧

• WorkOS – 你如何处理智能体与权限？WorkOS 构建了 Airlock，这是面向 AI 智能体的授权层。它会根据智能体的意图和你的规则评估每一个请求，然后允许、拒绝，或将其转交给人工审批。支持 Claude Code、Codex 和 MCP 网关。试试看。

本集内容

一位在 AI 出现之前每年都定期将约 10 万行数据库级代码发布到生产环境的软件老将，怎么会觉得自己今天效率更高，而且质量毫无下降？Peter Mattis 是 Cockroach Labs 的联合创始人兼 CTO，也是 GIMP 的原始创作者。他还曾在 Google 参与 Gmail 和分布式存储的工作。

在本集中，Peter 回顾了他从开源到 Google，再到创立数据库公司的历程，我们探讨了如何在大规模下保持系统快速、可靠和正确，从 Gmail 早期的存储挑战到构建分布式数据库的权衡取舍。

Peter 告诉我们，在他的工作转向管理之后，AI 如何让他重新开始写代码，以及为什么他相信 AI 可以提高质量，并成倍放大领域专家的影响力。我们还思考了代码评审的未来，Peter 也就如何提升我们的工程技能给出了一些建议。

与 Peter 对话的要点

1. Peter 最初因为通勤问题拒绝了 Sergey Brin 加入 Google 的邀请。著名的 Google 标志的第一个版本就是在 GIMP 中制作的，这是 Peter 和他的大学室友 Spencer Kimball 创建的自由开源光栅图形和图像编辑软件。

由 GIMP 制作的 Google 标志第一版

2001 年，Sergey 联系了 Peter，邀请他参加面试，随后发出了录用通知。但 Peter 说了“不”，因为他住在旧金山，不喜欢花一小时通勤到山景城。他转而加入了另一家初创公司，但那家公司没什么起色。当 Google 再次联系他时，他抓住了机会。

2. 在得知一个更雄心勃勃的照片编辑器后，Peter 差点没有发布 GIMP。Peter 和 Spencer 为 GIMP 付出了很多努力，但在发布前几周，他们看到另一个程序的公告，声称能做 GIMP 所做的一切——甚至更多！Peter 和 Spencer 感到气馁，但还是发布了——之后的事就成了历史。他们再也没有听到那个更雄心勃勃的项目。Peter 说：“总会有别人在做你的想法。如果他们预先宣布，你不能因此被劝退。给创始人的建议：假设有几十个人和你有同样的想法，但大多数人不会发布它！要知道这是一场竞争；你必须享受这一点——不要害怕它。”

3. 第一版 Gmail 使用了 B 树。Gmail 于 2004 年 4 月 1 日推出，免费提供 1GB 电子邮件存储空间，当时这一优惠被认为慷慨得离谱，大多数人以为这是愚人节玩笑！B 树在 Gmail 的存储层中发挥了作用，用于存储电子邮件会话。在底层，每条收到的邮件都通过搜索索引匹配到一个会话。会话及其未读计数由 B 树跟踪。

4. Colossus 将 Google 的文件存储开销降低了 33%，同时提高了冗余度。在 Colossus 之前，Google 文件系统（GFS）存储三份完整的数据副本。对于成为 GFS 后继者的 Colossus，Peter 和团队在分布式文件系统中率先使用了 Reed–Solomon 纠删码。数据只存储两次，但冗余度却提高了！

5. 在全球范围内发送数据包最快的方式是通过太空！Peter 脑中记着“光速数字”——类似于 turbopuffer 创始人 Simon Eskildsen 所做的“餐巾纸数学”计算。例如，一个区域内的网络往返时间从 Colossus 构建时的毫秒级降到了今天的约 100 微秒（快了 10 倍！）。但有时瓶颈是光速，而光在真空中的速度比任何地方都快，这意味着最快的全球路线是直接上行到 Starlink，通过激光横跨，然后再下行。在《延迟不是选项：太空中的低延迟路由》中了解更多。

6. Peter 两次在性能方面“击败”了标准库数据结构。在 Google，他的一位同事注意到内存分析中出现了 std::map。Peter 仔细查看后发现 std::map 的实现是红黑树，这意味着每个节点有两个指针。Peter 构建了一个语义几乎相同的 B 树，由于空间局部性，它既更快，又因为使用了更少的指针而更小。他们在 Google 内部使用了这种数据结构。Peter 对 Go 的 map 也做了类似的事情：它性能不错，但他构建了一个更快的Swiss Table 实现。该实现后来进入了 Go 库，Go 团队帮助完成了它！

7. 如果你眯起眼睛看，分布式数据库和存储系统中的一切开始看起来都像 B 树。这些 B 树是本集播客中反复出现的主题：Gmail 的后端、std::map 的替代品、CockroachDB 的范围索引等。甚至有一篇关于这种现象的论文，The Ubiquitous B-Tree。

一棵 B 树：一种非常有用的数据结构。来源：Wikipedia

8. 在分布式数据库中，要实现共识，至少需要三个副本。只有一个副本时，崩溃后无法恢复。有主副本和辅助副本时，崩溃后两者都不知道对方是否收到了最后一次写入。因此，CockroachDB 默认使用三个副本——某些系统表最多使用五个——客户可以增加更多副本，但这会导致更高的延迟。

9. CockroachDB 的设计灵感来自 Google 的 Colossus 数据存储系统和 Spanner。Colossus 是仅追加的，意味着你只能向文件添加内容，而不能修改它们。Google 的分布式数据库 Spanner 构建在 Colossus 之上，因此 Spanner 的设计决策源于 Colossus 的仅追加特性。但如果你无法更新文件，只能向其中追加内容，就不可能使用 B 树作为数据库的设计结构，因为 B 树需要文件被更新。对于仅追加文件系统，理想的数据结构是日志结构合并树（LSM 树），其中写入被追加到日志文件以实现持久性：

日志结构合并树。来源：Wikipedia

Google 通过 LevelDB 普及了 LSM，后来 RocksDB 分叉了 LevelDB。RocksDB 是 CockroachDB 早期使用的底层存储引擎。2019 年，Peter 编写并开源了 Pebble，它现在是 CockroachDB 的存储引擎。

10. Peter，Google 前 C++ 可读性审查者，预测我们将停止审查代码：在 Google，每个代码变更都需要由语言可读性审查者签署“可读性”，Peter 多年来一直是 C++ 可读性审查者。但如今，他审查的代码越来越少，并预见这一趋势将持续。正如他所说：“我发现智能体变得越来越好；你需要给予的审查越来越少。我不知道是今年还是明年，[但]我们将实质性地停止以不再看汇编代码的方式来看待代码。”

11. Cockroach Labs 的非工程师在几个月内构建了约 1,000 个内部应用（！！）。今年早些时候，Cockroach Labs 推出了一个供非开发者构建应用的内部平台（可以把它想象成“内部版 Lovable”）。人们纷纷加入；人力资源专业人员构建了他们梦寐以求的新工具，而 CFO 创建了他们一直渴望的仪表板，还有许多其他人也是如此。Peter 和工程团队对这种参与度感到惊讶，但这与 OpenAI 看到其几乎所有非工程师在短短 4 个月内将几乎全部 token 支出从 ChatGPT 转移到 Codex 的情况相吻合。

12. 有了 AI，“心流”还存在吗？我问了 Peter 这个问题，他认为存在，但与“编码心流”状态不同：“感觉确实有点不同。可能强度稍低，但你在认知上管理更多事情。我正在思考那些通常需要我一周才能实验的想法。我想到多个这样的实验，然后同时将它们全部启动。[感觉]就像我是一位大学教授，带着一大群研究助理，他们都在做事情，而且回来得真的很快。”