Mike Stonebraker 是 2014 年图灵奖得主，他对数据库系统的奠基性贡献几乎写进了所有相关教科书。从 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一个都是真正成就了诸多商业公司的工程系统。 最近他做客 Meta 资深工程师 Ryan Peterman 的播客，与其进行了一个小时的对话。他说话直接，不太客气。聊到 Larry Ellison 时，他说那人“把现在时和将来时混为一谈，本质上是在对客户撒谎”；聊到 Google 当年力推的 MapReduce 和最终一致性，他说“那不是 Google 唯一一件愚蠢的事”；聊到亚马逊同时维护着十五个数据库系统，他说“多了十二个”； 他也表达了对如今 AI 的看法。在他看来，现在多数 agentic AI 还停在“只读”，给一个客户算个分、出个预测，并不真的去改数据库里的字段。一旦 agent 开始做读写，比如两个 agent 协作完成一笔转账，问题就立刻落回数据库的老地盘：事务、一致性、原子性。 说到大模型写 SQL，他甩出来几个数字。在 Spider、Bird 这些公开 text－to－SQL 基准上，最好的模型已经能拿到 85％ 准确率，看起来差一步就能上生产。但 Stonebraker 团队用四个真实生产数据仓库做了一个新基准 Beaver，在这个基准上，大模型的准确率是 0；加上 RAG 也只到 10％；把 join 条件直接喂给模型，最多到 35％。同样的任务，一个懂 schema 的 SQL 工程师能做到 90％ 以上。所以他的结论是：这项技术，至少在可见的未来，还不够格进生产。 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）的雏形，那时候我刚到伯克利当助理教授。 那个年代很多人写的原型都是“实验室风”，自己机器上能跑，拿给别人就跑不动了。Ingres 我们先投入了第一个 90％ 让它能跑起来，然后不知道为什么，又投入了下一个 90％ 让它真正好用。所以伯克利版的 Ingres 是真能用的。接下来几年大概有一百所大学开始跑它，因为 Unix 起来了，而 Ingres 是一套免费的、跑在 Unix 上的数据库。它在学术圈相当流行。 当亚利桑那州立大学考虑用 Ingres 跑他们四万学生的学籍数据时，这个问题得到了充分的印证。他们要装一个不被支持的操作系统（贝尔实验室的 Unix），要跑一个不被支持的数据库（伯克利这帮人搞的 Ingres），这两条他们都能接受。但项目最后死在第三条上：Unix 上没有 COBOL（一种主要用于商业数据处理的老牌编程语言），而他们是个 COBOL 的店。不被支持的操作系统、不被支持的数据库，再加上没 COBOL，我们就被判了死刑。 唯一的出路是开公司。1980 年我们拿到了那个年代意义上的风险投资，成立了 Ingres 公司，把 Ingres 移植到 DEC 公司（数字设备公司，当年的小型机巨头）的 VMS 上，一个真正的操作系统、一家真正能支持产品的公司。这就是商业化旅程的起点。 Stonebraker：Larry Ellison 是个一流的销售。他当时基本上把现在时和将来时混为一谈，说白了就是对客户撒谎。他会发不能用的东西，让早期客户帮他 debug。我觉得他做的是非常不光彩的生意，对客户撒谎在我看来是不可原谅的。 举个例子，有一个东西叫“参照完整性”（Referential Integrity，关系数据库里的一种约束：一张表里对另一张表的引用必须真实有效，不能指向不存在的记录）。比方说你解雇了一个员工，而他正好是某个部门的最后一个人，那你是要把这个部门删掉，还是留一个空壳部门？诸如此类。Ingres 公司把参照完整性实现了。Oracle 公司写了两页手册，先把参照完整性的定义写出来，这部分大家都同意，然后在底下加了一行：尚未实现。 Peterman：有意思。我之前采访过一个在 Sun Microsystems 干过的人，他对 Larry Ellison 的看法也差不多，觉得这人有点不光彩。看来是个共识。我还在某处看到你说过，Oracle 收购 MySQL 的时候，所有人都怕了，转去用 Postgres。 Stonebraker：一开始就有一件事埋在我们脑子里。学术版 Ingres 最早的目标是要支持隔壁那位 Praveen Varah 教授要做的地理信息系统（GIS）。要支持 GIS，你得有点、线、多边形、线组这些数据类型。但 Ingres 显然搞不定，我们放进 Ingres 的数据类型是标准那几样：整数、浮点、文本字符串。在这之上你不可能高效地支持 GIS 类型。所以作为一个 GIS，学术版 Ingres 是个彻头彻尾的失败。这件事一直放在我们脑子后面。 另一件事时间上稍微往后跳一下，但能把这个点说透。大概 1985 年，ANSI（美国国家标准协会）刚提了一个关系数据库的日期时间标准。商业版 Ingres 把日期时间实现了，用的是标准的格里高利历。我那时候跟商业版那边也有联系，同时还在伯克利当教授。 我接到一个 Ingres 客户的电话。他说，你们日期时间实现错了。我说，我们实现的就是格里高利历啊，你能做减法，月份有 30 天或者 31 天，二月除外、闰年除外，日期减法就是按你期望的方式工作的。 他说不对，那不是我要的。他做的是债券金融工具。出于某种原因，他的债券每个月付的利息一样，不管这个月有几天。他有买债券的日期、卖债券的日期，他想直接做减法，乘以票息率，得到付给客户的利息。但他要的减法是：3 月 15 日减 2 月 15 日等于 30 天，因为他那套日历就是这么定义的。结果他不得不把两个日期取出来，在用户代码里做减法，再把答案塞回数据库，效率掉了两到三倍。 但他要的东西，本质上跟前面那个“点、线、多边形”是一回事。他要的是债券时间。Postgres 的设计目标就是有一个可扩展的类型系统，你想要什么数据类型都行，而且都是高效的。这就是 Postgres 的核心，它有这种灵活性。 业务数据处理多数时候用标准类型就够了，但关系数据库开始扩散到各种地方，人们想要的是抽象数据类型，或者叫存储过程，叫法很多。这种可扩展性给了Postgres 巨大的适用面，这是 Postgres 最大的事情。 Postgres 也支持了当时 AI 那帮人想要的继承机制。我们还做过时间旅行（time travel，让数据库能查询历史时点状态），但实现烂得一塌糊涂，过了一阵就被拿掉了。但不管怎么说，Postgres 确实包含很多有意思的东西。 Stonebraker：通常很明显。我对什么事大概有多难，心里有数。如果他们在bwin必赢体育 学院里干完的量是我觉得合理水平的三倍，那他们就是非常出色的人。 Stonebraker：这事很容易，你跟他聊几句，很快就能看出来。你的硕士论文做的是什么？具体怎么工作的？错误条件你怎么处理的？用了多少进程？为什么不用线程？就是问深度的技术问题。 Peterman：你做过一个演讲，后面也有篇论文，讲的是“一种数据库通吃所有场景”是错的，你想要的是针对具体需求的数据库方案。今天市面上你看到哪些数据库还在试图通吃？ Stonebraker：我写那篇论文是 2004 年。我们当时有一个学术项目，后来变成了 StreamBase（流处理数据库），流处理引擎跟关系数据库长得一点都不像。我们还有一个列存（按列存储数据，更适合分析型查询）的雏形，做数据仓库用的，后来 Vertica（基于列存的分析型数据库）把它推开了，列存跟行存也长得一点都不像。三种完全不同的实现，互相没有任何相似，每一种都比对手快一个数量级。所以很清楚，你跑一个不是为你这类工作负载设计的数据库，你就要付一个数量级的代价。 我觉得今天还是这样。ClickHouse（开源列式分析数据库）是个列存，Pinecone（向量数据库）做文本向量处理比“用户自定义类型”那条路要快。所以这个判断基本没变。 技术上没什么难度把一个统一的解析器架在多种实现之上。Postgres 到现在为止选择不这么做。它没有列存实现，所以在大型数据仓库上它不具备竞争力。它也没有多节点支持，对大数据仓库来说这是入场券。所以这个观点今天和当年一样成立。 不过另一个角度也对：如果你想快点干起来，有数据库需求，选 Postgres。社区巨大，各种数据类型实现都有，免费，你能找到 Postgres 直接用。在你撑到每秒百万级事务之前，它都用得挺好。在你支撑 PB 级数据仓库之前，它就是那个最优解。低端，Postgres 就是绝对的“一种通吃”。高端，这话就不成立了。 Stonebraker：可能。但我觉得最大的挑战在于，GPU 是 SIMD（Single Instruction Multiple Data，单指令多数据），这跟索引正好是反着来的。所以只要“索引”是正确答案的地方，GPU 大概就不是好主意。另外架构上你得让从存储到 GPU 的带宽不成为瓶颈。如果 GPU 是 CPU 的附加件，那 CPU 到 GPU 的总线很多时候就是瓶颈。 Stonebraker：比方说我要找 Ryan 的工资，我有一棵 B 树（一种平衡树索引结构）。你先到根节点，找到 Ryan 落在哪一边的分隔符，顺着指针走，那是一次内存访问；然后再来一遍，这样跑三四层。这种过程没法很好地并行。所以答案是：索引并行不起来。 Peterman：MapReduce 在 2000 年代初出来，在数据世界掀起了风暴，大家觉得 Google 真懂行，这是面包发明以来最好的东西。但我看你当时和你后来的论文，你强烈不同意。为什么？ Stonebraker：那时候有一大批不太开窍的人，他们说 Google 这么聪明，他们做的肯定是对的，Google 怎么说我们就怎么做。于是一窝蜂上 Hadoop（MapReduce 的开源实现）。但 Hadoop 的效率低得离谱。当时 Dave DeWitt（数据库领域元老，威斯康星大学教授）和我们 2011 年那篇论文的几个作者都懂分布式数据库，我们清楚分布式数据库系统能把 Hadoop 按在地上摩擦，那篇论文基本就是这么写的。事实证明也是如此。 而那不是 Google 唯一一件愚蠢的事。同一时期 Google 还在大力鼓吹“最终一致性”是做并发控制的正确方式，这是他们居高临下发布的。但所有数据库圈的人都说，你们脑子坏了，它只解决一小类特殊问题，而那类问题在实际中很少出现。 如果你说，我做一个事务把西海岸仓库的小部件数量减一，提交这个事务之前，我要先把消息发到东海岸更新它，再发回来确认，然后还要再来一轮消息确保两边都正确提交，那做一个分布式提交是很贵的，今天也还是这样。 所以那个想法是：你在西海岸做更新、把库存减一，只是异步发个消息出去、不放进事务里，东海岸最终会被减一。同时如果你在东海岸把另一种货品减一，你也异步发消息，西海岸最终也会收到，最后一切收敛。 但如果允许库存跌破零，会发生这种事：东海岸和西海岸的人同时卖掉了最后一个小部件，最后仓库状态变成负一，有人拿不到他的货。 如果你像亚马逊那样说“通常 24 小时内发货”，那也许还能允许超卖。但大多数企业做不到。所以最终一致性就是不工作。我们前面提到过参照完整性，在销售系统里，参照完整性的约束就是“库存大于负一”，这个约束在最终一致性下崩了。Google 的 Jeff Dean（Google 首席科学家，MapReduce 和 Spanner 的主要作者之一）后来想清楚了这件事。他们做 Spanner（Google 的全球分布式数据库）的时候，Spanner 是一个传统的事务系统，Google 完全放弃了最终一致性，完全放弃了 MapReduce。 Stonebraker：大概三年前我在亚马逊做过一次演讲，把所有我觉得他们做错的事都讲了。亚马逊的问题是他们在维护十五个不同的数据库系统，大概多出了十二个。他们有自己的文化，我说你们维护的数据库系统太多了。到现在为止他们一个也没退役。 Stonebraker：比方说他们在维护一个图数据库。但大家都清楚，图数据库在性能上几乎从来不是首选。如果你喜欢“节点和边”那种用户接口，没问题，在关系数据库之上做一层壳，把这个用户模型给你就行。他们大多数数据库系统，都有另一个数据库系统在该做的事上做得更好。所以答案是：任何在足够大的市场里不具备性能竞争力的数据库系统，你都该退役它，因为维护要钱。 Peterman：你从学术界深刻地影响了产业。我有个问题：为什么不直接去工业界？为什么你更愿意留在学术界用这种方式产生影响，而不是去 AWS 之类的地方做个杰出工程师？ Stonebraker：因为那样你头上就有个老板，有公司规章，限制你发表论文的自由，限制你去会议讲东西的自由，限制你去探查竞争对手在做什么的自由。但更主要的是，我喜欢做创业。 商业版 Postgres 后来被 Informix（1980－1990 年代的关系数据库巨头之一）收购，我那时在 Informix 兼职。那是一家两千人的公司，我感觉做不出什么改变，它官僚，总裁要什么就是什么。我天生不适合搞政治，搞不来。我跟我觉得笨的人打交道有困难。所以我跟大公司有点麻烦。 Stonebraker：我们 2019、2020 年左右开始这个学术项目。当时 Matei Zaharia（Spark 的创造者，Databricks 联合创始人）在斯坦福任教。他说，Databricks 那时候基本上就是在云上跑用户的 Spark（一种主流的分布式数据处理引擎）任务，任意时刻可能有上百万个 Spark 任务在调度，得写一个能在百万级别工作的调度器。 他说他们试过所有 OS 圈那些人写的调度器，都不行，扛不住。所以最后他们把所有调度数据放进了一个 Postgres 数据库，基本就是用一个 Postgres 应用来做调度。 然后我们就意识到：你在操作系统里大部分时间做的事，就是在管理大规模数据。你应该用数据库技术来做这件事。那干脆把 Linux 的上半部分换成数据库系统好了。 那就是这个学术项目的主旨。我们在 20 年代初在伯克利和斯坦福做这个，做得相当成功，确实能跑通。过程中斯坦福那边给 JavaScript 写了一个扩展，因为你需要某种编程入口跟你的实现对话。 如果你做的是一个跑在数据库之上的“操作系统”，而你又有一个编程语言运行时，那很自然就是把所有状态都放到数据库里，他们就是这么做的。所以我们既有一个创新的编程语言模型，也有一个创新的操作系统模型。 接下来当然是想，能不能做公司？我们跟风投聊，没有一个人不说“你想取代 Linux 那是做梦”，但他们都说，你这个编程语言部分很有意思。我们的 JavaScript 扩展能让任何程序都拥有数据库系统的那些好性质：状态是持久的，你可以有事务，失败时可以故障转移，这些好东西。 2023 年我们拿到融资成立了 DBOS（Database Operating System）公司，这一直是项目的名字。但我们做的实际上是编程语言生意。今天 DBOS 有 TypeScript 版本、Java 版本、Go 版本、Python 版本，都是无缝的，看起来就是普通程序，但跑在云的世界里。 Stonebraker：现在每个人都有动机把应用结构组织成“工作流”。所以我们决定就支持工作流系统。DBOS 在那四种语言下支持的工作流，里面的每一步，叫微操作也好叫别的也好，都是事务性的。工作流是持久的，一步走完不会被忘记。如果有人有市场需求，我们可以做到工作流是原子的：整个工作流要么完成，要么看上去从未发生过。它的性质非常好，比竞争对手快很多、用起来也容易很多。公司在这块卖得很好，也在持续创新。 整个想法是，把应用的状态放到数据库里让它持久化，然后想办法跑得快。商业模式是先抓底层程序员，跟他们说，你需要什么我们没有，告诉我们，我们尽快加上，把人拉过来试。 Stonebraker：我们在很多创业公司里很成功，他们想选最好的东西。我们也开始打进大客户。今天大概三分之二的客户在做 agentic AI，一个大语言模型，周围加一堆增强信号的东西。目前为止 agentic AI 大多是只读的，比如你要给“Ryan 是不是好客户”产出一个预测，跑一堆东西出一个新结果给某个人。本质上是只读的，你没真的去改 Ryan 的信用评级。 我估计很快整个世界就会用 agent 做读写应用，那它就会变得非常“数据库”，而 DBOS 在这块做得特别好。比方说你写两个 agent，把我账户里的 100 美元转到你账户：一个 agent 把我账户减 100，另一个把你账户加 100，这两个 agent 必须要么都提交、要么全部回滚，也就是说工作流必须是我说的“原子的”，要么发生，要么看起来没发生过。我觉得这个市场对原子性的需求会越来越高，这对 DBOS 是好事。 Peterman：那今天向应用开发者交付的 DBOS，跟最初那个“把操作系统内核换成数据库”的研究版本不一样了。这其实挺酷的，我以前没想过把操作系统所有状态都放进数据库。这里一定有什么权衡吧？ Stonebraker：在 DBMS（Database Management System，数据库管理系统）之上写的文件系统比 Linux 文件系统更快。调度引擎跟其他调度引擎相比也有竞争力。所有东西都能故障转移，你不用做任何额外的事就拿到了高可用。答案是没什么坏处。 Stonebraker：学术项目阶段，我跟操作系统那帮人提的时候，他们会觉得很被冒犯，觉得这是数据库圈的人在抢他们的地盘。编程语言的人也一样，他们觉得编程环境的运行时该是他们的，我们说运行时该用数据库做，他们也不爽。 Stonebraker：有两件事我想说。第一件，跟所有人一样，三年前我们开始看大语言模型能干什么。我们一直在做 text－to－SQL（让模型把自然语言问题翻译成 SQL 查询）。我们想让它在真实世界的数据库上工作，尤其是真实世界的数据仓库。我们在四个生产级的数据仓库上试，拿到了真实的用户工作负载、真实运行的查询，让真实用户回过头给我们提供这些 SQL 对应的自然语言文本。所以我们有四个真实的 text－to－SQL 基准。 Stonebraker：比方说“告诉我所有在 MIT 拿过图灵奖的教授”。LLM 应该擅长这件事。Text－to－SQL 已经有公开基准，一个叫 Spider，一个叫 Bird（两个学术界主流的 text－to－SQL 基准数据集）。最好的 LLM 系统在这些基准上挺不错，80％ 准确率以上，当前榜首大概 85％，你会考虑用它，虽然还不到生产级。 但在我们的基准上，大语言模型的准确率是 0％。如果你给它加上 RAG（检索增强生成）和所有那些花招，能到 10％。如果你在 prompt 里直接告诉它 from 子句，也就是把所有要访问的表、所有要做的连接条件都喂给它，准确率到 35％ 左右。这东西离生产级很远，而且短期内大概也到不了，如果它真的能到的话。 第一，数据。LLM 是在 The Pile（Eleuther AI 制作的开源大模型训练语料库，800GB 文本）上训练的，数据仓库里的数据不在 The Pile 里。有句老话，如果你之前没见过这数据几次，你没机会把它复述出来。这是第一。 第三，schema。Spider 和 Bird 里的 schema 是干净的，表名是助记的，列名是助记的，没有重复。但真实数据仓库里，人们到处建物化视图（materialized view，预先计算好的查询结果，加速分析），意味着到处有冗余；列名经常是 underscore＿z＿uppers＿andre＿blah 这种，毫无助记性，很难。还有他们有特异数据，比方说 J－term（MIT 等美国大学一月份的一个迷你学期）在 MIT 是个流行词，一月份的一个一个月学期，这个词不只 MIT 有，但也不普及，不在 The Pile 里。特异数据、查询复杂、schema 一团糟，这三件事在我知道的每个数据仓库里都成立。所以这技术就是不工作，短期内也不会工作。 Stonebraker：第一，我们把基准发表了，叫 Beaver，是这四个数据仓库的脱敏抽象版本。如果你觉得自己 text－to－SQL 做得很好，来真基准上试，别老在假的上跑。 第二，接着我刚才说的，如果你拿不到 from 子句、拿不到所有连接条件，你就完蛋；如果你不把查询拆成更简单的小块，你也完蛋。这告诉我什么呢？你想给检索系统更简单的小块，小块里要包含 from 子句、要包含连接条件。这是一。 第二，你一旦想跨两个不同的结构化数据库聊，比如你的数据仓库和你的 CRM 系统，那很显然，用 LLM 做结构化数据连接是个坏主意。你最好把它们留在表里，做 SQL 连接。所以我们的视角是，把所有东西都变成表。 我们在跟德国慕尼黑交通部合作。他们有六个全职的人在回答市民投诉性的查询，比方说“为什么我家旁边的路口绿灯时间不够我过马路”、“为什么电车停的时间不够我上车”、“为什么电车一小时才来一班”。他们的数据库里有什么？电车时刻表是 SQL，信号灯时序是 SQL，路口图是 CAD（计算机辅助设计文件），德国联邦的相关法规是文本，慕尼黑市的相关法规也是文本。所以你要做的是 SQL × SQL × CAD × 文本 × 文本的连接。 我们的视角是把它们全部变成 SQL、变成表，然后用一个相当于查询优化器的东西做连接。这就是我们现在在做的事。我觉得别人会有别的想法，但这是个非常肥沃的领域，因为人们真的想做这件事。这是一。 第二，前面说的 agentic AI，一旦它变成读写，它就是个分布式数据库问题，你要原子性、要一致性、要那一整套东西。我觉得这是非常有意思的领域。这就是我现在在做的。 Stonebraker：文献里的论文。我和 Joe Hellerstein（伯克利数据库教授，与 Stonebraker 长期合作）出过一本叫《Readings in Database Systems》的“红皮书”，但已经八年了。作为八年前的读物我觉得它很好。除此之外就是文献里有名的论文。 Stonebraker：我刚到伯克利接那份工作的时候，没怎么思考过就说，我们来写一个数据库系统吧。当时我们对数据库一无所知，对实现也一无所知，我们也不是 Bill Joy（BSD Unix 主要作者，Sun Microsystems 联合创始人）那种水平的程序员。开局做这种事，真的相当疯狂。但你硬着头皮干，让它能跑起来，一路上学。所以答案是：跳出框架，想些疯狂的事，去做。 更好的问题是：如果你今天刚开始，会主修什么？因为我觉得计算机科学未来不一定是一个增长行业。我现在不太确定我会推荐 18 岁的小孩去主修计算机科学。 我觉得医疗和建筑这些行业是稳妥的赌注，其他都看起来风险大不少。如果你即将拿到博士学位、要决定接下来做什么，那其实容易：挑你能拿到的最有声望的工作，找一个愿意帮你的导师，选一个不随大流的方向。比方说我们的项目 Rubicon，就是不随大流的。 我和我太太总跟人说，跟随你的热情，钱总会有的。但说实话我一秒钟都不信这话，我觉得这只是你必须告诉孩子和孙子的话。 Stonebraker：我太太就是个例子。她有计算机科学的硕士和本科学位，但她想做 K－12 老师。她父母说，你不能这么做，赚不到钱。我觉得从那以后她一直后悔这个决定。她对计算机科学没什么热情，只是把它当个手艺干。所以答案是：找你有热情的事做，你不会饿死，可能赚不到大钱，但你大概率会比做你没热情的事更快乐。 我认识很多人把工作仅仅当工作，生活是发生在下午五点到早上八点之间的事。我完全不是这样，我真的喜欢我做的事，赚多少钱不重要。
京公网安备11010202000001号
