图灵奖得主：劝年轻人别学计算机DeepTech深科技

Mike Stonebraker 是 2014 年图灵奖得主，他对数据库系统的奠基性贡献几乎写进了所有相关教科书。从 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一个都是真正成就了诸多商业公司的工程系统。

最近他做客 Meta 资深工程师 Ryan Peterman 的播客，与其进行了一个小时的对话。他说话直接，不太客气。聊到 Larry Ellison 时，他说那人“把现在时和将来时混为一谈，本质上是在对客户撒谎”；聊到 Google 当年力推的 MapReduce 和最终一致性，他说“那不是 Google 唯一一件愚蠢的事”；聊到亚马逊同时维护着十五个数据库系统，他说“多了十二个”；

（来源：Youtube）

他也表达了对如今 AI 的看法。在他看来，现在多数 agentic AI 还停在“只读”，给一个客户算个分、出个预测，并不真的去改数据库里的字段。一旦 agent 开始做读写，比如两个 agent 协作完成一笔转账，问题就立刻落回数据库的老地盘：事务、一致性、原子性。

说到大模型写 SQL，他甩出来几个数字。在 Spider、Bird 这些公开 text－to－SQL 基准上，最好的模型已经能拿到 85％ 准确率，看起来差一步就能上生产。但 Stonebraker 团队用四个真实生产数据仓库做了一个新基准 Beaver，在这个基准上，大模型的准确率是 0；加上 RAG 也只到 10％；把 join 条件直接喂给模型，最多到 35％。同样的任务，一个懂 schema 的 SQL 工程师能做到 90％ 以上。所以他的结论是：这项技术，至少在可见的未来，还不够格进生产。

谈及对年轻人的建议，他说如今已不太确定是否要推荐十八岁的小孩去主修计算机科学，“医疗和建筑业是稳妥的选择”。

下面是这次对话的完整内容：

在伯克利，被一个懂门道的人带进门

Peterman：我第一件想聊的事是 Postgres 是怎么起步的。我想从更早的地方开始，你最初是怎么进入数据库这个领域的？

Stonebraker：我毕业之后很幸运被伯克利招了进去，但我心里清楚一件事：把博士时候做的东西继续往下做，不会有什么前途。那时候和今天一样，能找到一个懂门道的导师把你带进门，你就比别人快一截。Gene Wong 把我收到他翼下，他现在还在干活。他说，咱俩一起搞点事情吧。

那是 1971 年，Ted Codd（关系数据库理论奠基人）那篇开创性的论文发表在 CACM（《Communications of the ACM》，计算机领域的顶级刊物）上是 1970 年。Gene Wong 说，我们去研究下数据库这块。当时关系模型有两个对手。一个叫 CODASYL 提案（1960 年代提出的网状数据库标准，把数据按“指针网”组织），你大概太年轻没听说过。它是个底层的、像意大利面一样缠绕的网状结构，要查一条数据得一路追指针。另一个是 IBM 的 IMS（Information Management System，IBM 的层次数据库系统，今天还在卖），数据是树形组织的。但 IBM 自己当时就承认树不够通用，解决不了很多人的问题，于是又加了一层补丁，把它变成一个受限的网状结构，一看就是个糟糕的补丁。

CODASYL 那套问题一堆。层级太低，调试起来要命。它还有个性质：一旦你的 schema（数据结构定义）有任何变化，基本就得把所有东西扔了重来，因为它整个根扎在物理层面。而 Codd 那套东西完全说得通。所以 Gene 说，咱们就来造一个这样的玩意儿吧，下一步显然该试这个方向。1972 年他开始造 Ingres（INteractive GRaphics REtrieval System）的雏形，那时候我刚到伯克利当助理教授。

Peterman：Ingres 是怎么从一个原型走到真的能用的？

Stonebraker：美国大学里的助理教授一般有五年的考核期，要么熬到终身教职，要么走人。Ingres 就是我拿到终身教职的敲门砖，1976 年我拿到了。

那个年代很多人写的原型都是“实验室风”，自己机器上能跑，拿给别人就跑不动了。Ingres 我们先投入了第一个 90％ 让它能跑起来，然后不知道为什么，又投入了下一个 90％ 让它真正好用。所以伯克利版的 Ingres 是真能用的。接下来几年大概有一百所大学开始跑它，因为 Unix 起来了，而 Ingres 是一套免费的、跑在 Unix 上的数据库。它在学术圈相当流行。

我们在伯克利开始接待大量访客，他们会说，这东西看起来真不错，你们最大的 Ingres 应用是什么？我们只能说，其实不太大。

当亚利桑那州立大学考虑用 Ingres 跑他们四万学生的学籍数据时，这个问题得到了充分的印证。他们要装一个不被支持的操作系统（贝尔实验室的 Unix），要跑一个不被支持的数据库（伯克利这帮人搞的 Ingres），这两条他们都能接受。但项目最后死在第三条上：Unix 上没有 COBOL（一种主要用于商业数据处理的老牌编程语言），而他们是个 COBOL 的店。不被支持的操作系统、不被支持的数据库，再加上没 COBOL，我们就被判了死刑。

唯一的出路是开公司。1980 年我们拿到了那个年代意义上的风险投资，成立了 Ingres 公司，把 Ingres 移植到 DEC 公司（数字设备公司，当年的小型机巨头）的 VMS 上，一个真正的操作系统、一家真正能支持产品的公司。这就是商业化旅程的起点。

Larry Ellison 把现在时和将来时混为一谈

Peterman：我看到 Ingres 当时是和 Larry Ellison 的 Oracle 在竞争。从能力上看 Ingres 明显更好，他们怎么还能跟你们争？

Stonebraker：Larry Ellison 是个一流的销售。他当时基本上把现在时和将来时混为一谈，说白了就是对客户撒谎。他会发不能用的东西，让早期客户帮他 debug。我觉得他做的是非常不光彩的生意，对客户撒谎在我看来是不可原谅的。

举个例子，有一个东西叫“参照完整性”（Referential Integrity，关系数据库里的一种约束：一张表里对另一张表的引用必须真实有效，不能指向不存在的记录）。比方说你解雇了一个员工，而他正好是某个部门的最后一个人，那你是要把这个部门删掉，还是留一个空壳部门？诸如此类。Ingres 公司把参照完整性实现了。Oracle 公司写了两页手册，先把参照完整性的定义写出来，这部分大家都同意，然后在底下加了一行：尚未实现。

Peterman：有意思。我之前采访过一个在 Sun Microsystems 干过的人，他对 Larry Ellison 的看法也差不多，觉得这人有点不光彩。看来是个共识。我还在某处看到你说过，Oracle 收购 MySQL 的时候，所有人都怕了，转去用 Postgres。

Stonebraker：那就是 Postgres 取代 MySQL、成为首选开源关系型数据库的起点。

一个债券交易员的电话，催生了 Postgres

Peterman：你造了 Ingres，里面有大量技术创新，让它比对手强。但最后它还是没了，你做了 Postgres。Ingres 没做、而 Postgres 做了的那件关键的事是什么？

Stonebraker：一开始就有一件事埋在我们脑子里。学术版 Ingres 最早的目标是要支持隔壁那位 Praveen Varah 教授要做的地理信息系统（GIS）。要支持 GIS，你得有点、线、多边形、线组这些数据类型。但 Ingres 显然搞不定，我们放进 Ingres 的数据类型是标准那几样：整数、浮点、文本字符串。在这之上你不可能高效地支持 GIS 类型。所以作为一个 GIS，学术版 Ingres 是个彻头彻尾的失败。这件事一直放在我们脑子后面。

另一件事时间上稍微往后跳一下，但能把这个点说透。大概 1985 年，ANSI（美国国家标准协会）刚提了一个关系数据库的日期时间标准。商业版 Ingres 把日期时间实现了，用的是标准的格里高利历。我那时候跟商业版那边也有联系，同时还在伯克利当教授。

我接到一个 Ingres 客户的电话。他说，你们日期时间实现错了。我说，我们实现的就是格里高利历啊，你能做减法，月份有 30 天或者 31 天，二月除外、闰年除外，日期减法就是按你期望的方式工作的。

他说不对，那不是我要的。他做的是债券金融工具。出于某种原因，他的债券每个月付的利息一样，不管这个月有几天。他有买债券的日期、卖债券的日期，他想直接做减法，乘以票息率，得到付给客户的利息。但他要的减法是：3 月 15 日减 2 月 15 日等于 30 天，因为他那套日历就是这么定义的。结果他不得不把两个日期取出来，在用户代码里做减法，再把答案塞回数据库，效率掉了两到三倍。

他说，我为什么不能直接重载你定义的减法，换成我要的版本？当然，Ingres 是写死的。

但他要的东西，本质上跟前面那个“点、线、多边形”是一回事。他要的是债券时间。Postgres 的设计目标就是有一个可扩展的类型系统，你想要什么数据类型都行，而且都是高效的。这就是 Postgres 的核心，它有这种灵活性。

业务数据处理多数时候用标准类型就够了，但关系数据库开始扩散到各种地方，人们想要的是抽象数据类型，或者叫存储过程，叫法很多。这种可扩展性给了Postgres 巨大的适用面，这是 Postgres 最大的事情。

Postgres 也支持了当时 AI 那帮人想要的继承机制。我们还做过时间旅行（time travel，让数据库能查询历史时点状态），但实现烂得一塌糊涂，过了一阵就被拿掉了。但不管怎么说，Postgres 确实包含很多有意思的东西。

Peterman：你想招的是非常出色的软件工程师。你之前说过，你找这种人没什么困难。你怎么识别那种“非凡”的工程师？

Stonebraker：通常很明显。我对什么事大概有多难，心里有数。如果他们在学校里干完的量是我觉得合理水平的三倍，那他们就是非常出色的人。

Peterman：反过来，你说过一句很有意思的话：“我受不了不那么聪明的人，跟他们说话很费劲。”你又是怎么识别一个人不聪明的？

Stonebraker：这事很容易，你跟他聊几句，很快就能看出来。你的硕士论文做的是什么？具体怎么工作的？错误条件你怎么处理的？用了多少进程？为什么不用线程？就是问深度的技术问题。

一种数据库不可能解决所有问题

Peterman：你做过一个演讲，后面也有篇论文，讲的是“一种数据库通吃所有场景”是错的，你想要的是针对具体需求的数据库方案。今天市面上你看到哪些数据库还在试图通吃？

Stonebraker：我写那篇论文是 2004 年。我们当时有一个学术项目，后来变成了 StreamBase（流处理数据库），流处理引擎跟关系数据库长得一点都不像。我们还有一个列存（按列存储数据，更适合分析型查询）的雏形，做数据仓库用的，后来 Vertica（基于列存的分析型数据库）把它推开了，列存跟行存也长得一点都不像。三种完全不同的实现，互相没有任何相似，每一种都比对手快一个数量级。所以很清楚，你跑一个不是为你这类工作负载设计的数据库，你就要付一个数量级的代价。

我觉得今天还是这样。ClickHouse（开源列式分析数据库）是个列存，Pinecone（向量数据库）做文本向量处理比“用户自定义类型”那条路要快。所以这个判断基本没变。

技术上没什么难度把一个统一的解析器架在多种实现之上。Postgres 到现在为止选择不这么做。它没有列存实现，所以在大型数据仓库上它不具备竞争力。它也没有多节点支持，对大数据仓库来说这是入场券。所以这个观点今天和当年一样成立。