Peter Mattis 谈分布式数据库与 AI 编程

Peter Mattis 把自己对计算机的兴趣追溯到游戏和家里的电脑。他曾照着书输入程序，大学起初学习机械工程，后来发现计算机课程更得心应手，于是转学计算机科学。

大学期间，Mattis 和室友开发了图像编辑器 GIMP 及其图形工具包。他们边尝试边查阅论文；他认为，尚不了解项目全部难度时的一点天真，帮助他们迈出了第一步。

GIMP 发布前不久，有人宣布正在开发功能甚至更多的类似程序。他们仍继续开发。Mattis 认为，听说别人有同样的想法，不应自动成为团队放弃开发和发布的理由。

大学毕业后，他从图形转向存储，并结识了 Google 创始人 Larry Page 和 Sergey Brin。他回忆，自己曾因从旧金山通勤太远而拒绝早期 Google 邀请，另一家创业公司发展不顺后才加入。

在 Google，Mattis 参与了后来成为 Gmail 的邮件项目后端，包括邮件会话、存储和索引。他回忆，推出时免费容量远高于当时的竞争服务，令人震惊。

Gmail 建立在 Google 分布式文件系统与搜索经验之上，但原型的检索系统后来被重写。邮件会话需要查找和索引；Mattis 记得 B 树用于管理未读数等相关数据。

他回忆 Paul Buchheit 将广告引入 Gmail，而团队在容量有限时通过邀请控制推出节奏。这些是他对早期产品和基础设施决策的回忆，并非该服务的完整历史。

话题转向 Google 的共享基础设施，包括单体代码库和构建工具。Mattis 后来加入 Colossus 团队，开发接替 Google File System 的分布式存储系统。

Colossus 将数据存储在多台机器组成的集群中。Mattis 介绍了纠删码：它能容忍故障，而存储开销可以低于为每一次可容忍故障保留一个完整副本。

在他举的九块方案中，任意五块可重建数据，因此可以丢失四块。具体编码及部署方式很重要；要点是冗余不一定意味着将整个文件复制多次。

Mattis 说，早期 GFS 的主节点在元数据方面成为扩展瓶颈。Colossus 使用 Bigtable 存放文件名、分块列表等元数据，而普通 Bigtable 自身也需要存储。

团队用一个不依赖 Colossus 的基础 Bigtable 解决启动时的循环依赖，再在其上运行 Colossus 和普通 Bigtable。他称这是当时务实的启动方案，后来被替换。

高吞吐、高可用和低延迟是不同目标。Mattis 指出，磁盘存储可能支持很高的吞吐量，但单次读取仍有明显延迟；更快的 SSD 和网络会改变工程权衡。

他鼓励工程师从硬件限制出发思考，而非只考虑人能感知的延迟。网络距离、处理器缓存、同步和数据局部性都会影响性能；避免不必要的协调可能很重要。

在 Google，一位同事发现被广泛使用的 C++ map 有明显的内存与缓存开销。Mattis 构建了基于 B 树的替代方案，让一个节点容纳更多项，从而在适用场景改善局部性。

有序数组适合保存少量键。B 树通过拆分已满节点并用父节点索引，将这一思路扩展到更大数据量。Mattis 指出一个权衡：移动条目可能失去原 map 提供的指针稳定性。

这一优化源于对实际性能剖析结果的观察，而非假定标准库对所有工作负载都已最优。在那个场景中，更少的指针和更好的空间局部性让 B 树更省内存、运行更快。

他也关注 Swiss table 哈希映射，并尝试用 Go 实现。哈希表将键映射到桶；不同设计在冲突处理以及如何排列元数据以提高访问效率上有所区别。

一次长途飞行中，他让部分基准测试变快，随后结合他人的想法构建出公司可用的版本。Go 团队后来进一步推进运行时实现；Mattis 将成果归功于更广泛的协作，而非一人独立完成。 [Go 团队的技术说明](https://go.dev/blog/swisstable)介绍了最终的 map 设计。

在 Google 完成 Colossus 等工作后，Mattis 联合创立移动照片分享公司 Viewfinder。他说团队难以找到合适的获客方式，最终 Square 收购它主要是为了团队人才。

他区分了 Colossus 这类围绕大型追加式文件设计的分布式文件系统，与 Spanner 这类在存储之上支持结构化记录和事务访问的数据库。

日志结构合并树是利用不可变文件构建可变数据库的一种方法。Mattis 提到他为 Cockroach Labs 实现的 LSM 存储引擎 Pebble，作为这一工程脉络的一部分。

建设 Viewfinder 时，创始人曾讨论过类似 Google 内部系统的数据库，但暂时搁置。在 Square，他们看到类似存储问题，于是继续探索，最终将项目独立为 Cockroach Labs。

客户常在遭遇故障，或单节点系统难以扩展后寻找分布式数据库。Mattis 讨论手动分片的代价：需求增长时，应用团队必须跟踪数据位置并重新平衡。

简单的分片方案可将每个用户哈希到固定数量的分片之一。分片满时，迁移数据和重新映射可能很繁重；自动拆分范围和放置数据试图让数据库承担这部分运维工作。

索引将键范围映射到其位置。Mattis 认为它与 B 树有相似之处，而 B 树也出现在数据库的有序索引中。具体实现仍取决于数据库和工作负载。

事务将多项修改组合起来，使其一起成功或失败。隔离性关乎并发事务如何相互影响；可串行化使结果等价于某种串行顺序，有助于推理应用中的某些约束。

在最终一致性下，写入后某个副本可能暂时返回旧值。应用可以适应这一情况，但必须对此做处理。更强的保证可以简化应用推理，同时引入协调成本。

Mattis 将 Raft 介绍为协调副本的共识协议。复制能在故障时保护数据，但可用性、持久性和延迟取决于法定人数规则与部署配置。 [Raft 论文](https://raft.github.io/raft.pdf)介绍了复制日志、多数派共识和安全性。

他说 CockroachDB 常用三个副本，也支持其他配置。跨区域放置可以提高抵御区域故障的能力，但地理往返会增加延迟；顺序读写会让延迟累积。

对 Mattis 来说，关键任务系统是银行、交易或购物车等企业核心服务。故障损害的不只是收入，也可能影响客户和声誉，因此可靠性需要持续投入。

Mattis 回忆，在 AI 出现前产出最高的年份，自己一年写过约十万行代码。这是个人估计，并非受控的生产力或质量测量；代码行数本身也不适合直接比较不同项目。

随着管理职责增加，他写代码的时间减少。后来他重新参与一线工作，部分原因是希望理解并指导公司使用编程智能体；他发现这些工具改变了自己探索问题的速度。

他把模型当作技术想法的讨论伙伴：它能快速提出可能性，但回答可能错误或过度迎合。仍需要领域知识来质疑和验证它提出的方案。

Mattis 将指导智能体比作亲自参与的技术领导：多个任务并行时确定架构并纠正工作。主持人 Gergely Orosz 指出，人员管理还包括这类比喻没有涵盖的人际关系与责任。

他预测 AI 将编写越来越多的软件，并介绍公司内部让非工程师制作小应用的平台。这一预测是对未来的观点，并不能证明所有软件都会沿此路径发展。

他的工作流使用多个编程会话；遇到关键工作时，他也会让另一个模型挑战设计。他说自己通常并行处理约五到十个会话，具体使用多少子智能体则取决于任务。

他从 Emacs 转向 VS Code，近期又使用桌面界面，以便更容易追踪多个智能体会话。这是适合他个人的工作方式，也可能随工具演进而变化。

Orosz 询问更快的产出是否会带来更多回归问题。Mattis 认为必须明确要求智能体充分测试；他提到可在适当场景使用属性测试、变形测试和确定性模拟。

他还建议使用智能体进行对抗式安全和性能审查。这些是扩大审查范围的建议，并不能证明自动审查能发现所有缺陷或替代专家判断。

谈到代码审查，Mattis 说自己仍会查看智能体生成的大部分代码，但预计逐行审查的程度会变化。他强调，测试不完整、安全细节和性能敏感路径仍需关注。

针对一项性能敏感的修改，他让智能体建立生成汇编代码的检查，以便未来改动时发现不必要的开销。这是一个具体护栏；它是否有效取决于检查实际测量了什么。

他把自己的工作节奏描述为并行运行多项实验、检查进展、纠正看起来不对的方向，并放弃失败的想法。更高的并行度也增加了他需要同时跟踪的事情。

他把学习智能体编程比作学习驾驶：熟悉操作和了解失败模式都很重要。他谈到工程师能力被大幅放大时，使用的是类比和观察，而非经过测量的普遍倍数。

Mattis 认为领域知识有助于提出更好的问题并评估模型产出。他提醒，若不理解存储与网络需求，生成的数据库即使表面看似可信，也可能缺乏实质。

他建议研究优秀工程师的代码，并用 AI 从不同层次解释不熟悉的部分。这类解释可以作为学习起点，但应结合代码和其他资料核验。

他说，好奇心应超出眼前任务：学习相邻系统和业务领域，可以让人从理解现有设计走向提出改进。他也承认，目前的节奏既令人兴奋，也让人疲惫。