计算机不再是朝阳产业？
编译 | 王启隆
出品丨AI 科技大本营（ID：rgznai100）
过去这些年，数据库世界里最流行的几套说法，几乎都能在迈克·斯通布雷克这里撞上一堵墙。
你跟他说大模型正在重写一切，他会告诉你，他们拿四个真实生产级数据仓库测过，今天最热的 Text-to-SQL 在自己的基准上得分是 0。你跟他说 Hadoop 和 MapReduce 曾经开启了一个新时代，他会很不客气地说，那不过是谷歌干过的一件蠢事。你如果再把他当年开发的 Postgres讲成一套可以吞掉所有场景的终极答案，他也不会顺着这个行业共识往下说。
这不是一场温和的数据库怀旧访谈。
这是 Ryan Peterman 播客和图灵奖得主、Postgres 奠基者 Mike Stonebraker的一场长谈。两个人一路从 Ingres 怎么在 1970 年代起步，聊到 Oracle 当年怎么卖货，聊到 Postgres 为什么要把类型系统做成可扩展，聊到为什么查询优化器直到今天仍然是数据库里最难啃的骨头，也聊到他现在最关心的两件事：
大模型到底能不能真的把自然语言变成生产环境里的 SQL？
Agent 真开始读写世界之后，数据库系统会不会重新回到舞台中央？
这位八十多岁的数据库老兵，他骂的很多东西，今天恰好又以新面貌回来了。大家重新迷上通用平台，迷上一个系统吃掉一切，迷上只要模型够强就能抹平结构化世界的复杂度，迷上把正确性往后放、先把速度和规模做出来。Stonebraker 基本是在把这些流行信念一条条掀开，说数据库世界从来不是这样运转的。
要点速览
MapReduce 是谷歌干过的蠢事之一。谷歌后来连 eventual consistency 这条路也走错了，最后还是回到了 Spanner 这种传统事务系统。
Postgres 是今天最好的默认答案，但只是默认答案。社区大、免费、好招人、通用能力强，这些都是真的。可一旦进入百万级事务、PB 级仓库、多节点和列存这些高端场景，通用系统就不再够用了。
Postgres 从 Ingres 走出来，核心不是再造一个关系型数据库，而是要做一个可扩展的类型系统，让数据库能真正处理 GIS、金融债券时间这类标准类型之外的世界。
数据库最难的部分还是查询优化器。几十年过去，最难的地方没变。
对聪明工程师和普通工程师的区分方式：不看套路，不看包装，直接追问你到底做了什么、错误怎么处理、为什么这样实现，深问几轮，水平就藏不住了。
把应用状态更深地放回数据库，让工作流天然拥有持久化、事务、故障转移这些特性。因为未来大量读写型 Agent，最后都会重新撞上数据库问题。
如果今天重新开始，他都不确定还会不会建议 18 岁的人主修计算机科学。
“甲骨文靠对客户撒谎赢了市场”
主持人：今天我们请到的是迈克·斯通布雷克（Mike Stonebraker）。他是图灵奖得主，因对 Postgres 等数据库系统做出的开创性贡献而闻名。首先我想聊聊 Postgres 是如何起步的。为此，我想从最开始讲起。你是如何进入数据库系统构建这个领域的？
Mike Stonebraker：毕业那年，我有幸被伯克利大学聘用。当时很明显的一点是，我必须寻找新的研究方向——我读博期间做的那些东西，在当时和现在看来都没什么前途。如果能被一位深谙门道的导师收于麾下，你就能赢在起跑线上。所以，目前依然健在且精神矍铄的尤金·王（Gene Wong）把我带到了他的门下，他说：“咱们一起搞点什么吧。”
那是 1971 年，也就是泰德·科德（Ted Codd）在《美国计算机学会通讯》（CACM）上发表那篇开创性论文的第二年。尤金·王说：“咱们来看看数据库这块的东西吧。” 当时市面上的竞争者是一个叫CODASYL的提案，你可能太年轻都没听说过。那是一个底层的、像意大利面一样纠缠不清的网络模型，你需要通过顺藤摸瓜找指针来执行查询。另一个替代方案是 IBM 提出的名为IMS的层次化模型，这东西现在还有。它是层次化数据，也就是把数据组织成树状结构。
即使在当时，IBM 也意识到树状结构不够通用，无法解决很多人的问题。所以他们东拼西凑，硬是把它改造成了一个受限的网络结构。明眼人一看就知道那是个粗劣的补丁。
而 CODASYL 提案也有各种致命缺陷。除了过于底层且极难调试之外，它还有一个毛病：一旦你现在的所谓“数据模式（Schema）”发生任何变化，你基本上就得把所有东西推倒重来，因为它完全被焊死在了物理层面上。相比之下，泰德·科德的理论简直无懈可击。
所以尤金说：“咱们也造一个这样的系统吧。这显然是下一步该尝试的方向。”于是，1972 年，当我还是一名伯克利助理教授的时候，我们开始构建 Ingres。如你所知，作为助理教授，你有五年的时间来证明自己的实力，要么被解雇，要么拿到终身教职。所以，Ingres 就是我拿到终身教职的敲门砖，这在 1976 年如愿以偿。这就是一切的起点。
接下来的发展又是机缘巧合。在当时，很多人做出来的原型系统都充满了“学生气”，意思是代码虽然能跑，但如果交给别人，别人根本跑不起来。所以我们花了前一半的精力做出了一个能跑的雏形，然后不知怎么地，我们又投入了另一半的精力把它打磨到真正稳定运转的程度。所以加州大学版本的 Ingres 是真正能用的。在接下来的几年里，大约有一百多所大学开始运行它，因为Unix当时正在崛起，而这是一个能在 Unix 上运行的免费数据库系统。它在学术界非常受欢迎。
我们开始在伯克利接待大量的访客，他们会说：“哇，这玩意儿看起来真酷。你们运行过的最大的 Ingres 应用程序是什么？” 我们不得不尴尬地回答：“没多大。” 这一点在亚利桑那州立大学考虑用 Ingres 来管理他们全部 4 万名学生的学籍数据时，被展现得淋漓尽致。他们可以克服从贝尔实验室获取不受支持的操作系统的困难，也可以克服运行我们这帮伯克利家伙搞出来的不受支持的数据库系统的困难。但是，当他们发现 Unix 上没有 COBOL 语言支持时，这个项目彻底泡汤了，因为他们完全是一个依赖 COBOL 的团队。所以，不受支持的操作系统、不受支持的数据库系统，再加上没有 COBOL，注定了我们要被边缘化。
很显然，摆脱这种困境的唯一出路就是创办一家公司。所以 1980 年，我们拿到了当时那种形式的风险投资，创立了 Ingres 公司，把 Ingres 移植到了DEC 的 VMS上——那是一个真正的操作系统。我们拥有了一家能为 Ingres 提供支持的真正公司，这也是我们商业之旅的开端。
主持人：我看到 Ingres 当时在和拉里·埃里森（Larry Ellison）的 Oracle 竞争。我也看到 Ingres 显然比他们提供的产品更好，但你们依然在某种程度上处于竞争状态。他们是怎么竞争的？
Mike Stonebraker：拉里·埃里森是个绝佳的推销员。在当时，他能把“现在时”和“将来时”混为一谈，说白了就是对客户撒谎。他会把根本不能用的东西发货，然后让第一批客户帮他调试。我认为他使用了一些极其见不得光的商业手段。对客户撒谎，我认为是违背良知的。
举个例子，数据库里有个东西叫“参照完整性（referential integrity）”，意思是如果你解雇了一名员工，而他是某个部门的最后一个人，你是想把这个部门一起删掉，还是让它变成一个幽灵部门？就是这类问题。Ingres 公司实现了参照完整性。而Oracle 公司只是写了两页手册，上面印着大家都认可的“参照完整性定义”，然后在最底下用小字写着：“尚未实现”。
主持人：很有意思。我曾采访过一位在太阳微系统（Sun Microsystems）工作过的人，他对拉里·埃里森也有类似的评价，觉得他有点不太光彩。看来这是个共识。我也在其他地方看到过你的说法，当 Oracle 收购 MySQL 时，大家都感到恐慌，纷纷转向了 Postgres。这也是 Postgres 取代 MySQL 成为首选开源关系型数据库的契机。
你创造了 Ingres，里面包含了很多技术创新，使它优于当时的现有产品，但最终它还是退出了历史舞台，你又开发了 Postgres。Ingres 有什么是做不到的，而 Postgres 做到了？
Mike Stonebraker：在最开始指导我们的大方向，其实源于学术版 Ingres 的初衷：我们要为隔壁的 Pravin Varaiya 教授想要的一个地理信息系统（GIS）提供支持。为了支持 GIS 系统，你需要点、线、多边形、线组这类数据。很显然 Ingres 做不到，因为我们在 Ingres 里放入的数据类型都是标准的：整数、浮点数、文本、字符串。你无法在这些基础之上高效地支持 GIS 数据类型。所以，作为 GIS 系统的底层，学术版的 Ingres 是一个彻底的失败。这件事一直留在我们脑海里。
另外发生的一件事，虽然在时间顺序上有点错位，但能很好地说明问题。大概在 1985 年，ANSI 刚刚提出了关系型数据库的日期和时间标准。商业版 Ingres 使用标准的公历实现了日期和时间。当时我既参与商业版 Ingres 的工作，同时也是加州大学的教授。我接到一个 Ingres 客户的电话，他说：“你们把日期和时间实现错了。” 我一头雾水：“啊？我们实现了公历，你可以做减法。除了二月和闰年，每个月有 30 或 31 天。所以日期的减法运算完全符合你的预期啊。”
但他告诉我，在他的特定领域里，他要的根本不是这个。他在处理债券金融工具，无论一个月有多长，他的金融债券在每个月产生的利息都是一样的。他有买入债券的日期和卖出债券的日期。他想做一个减法，乘以票面利率，然后说：“这就是我们付给你的利息。”但当然，在他那里的减法定义是：3 月 15 日减 2 月 15 日等于 30 天，因为这就是他那个日历的定义。
所以他不得不把两个日期提取到用户代码中，在代码里做减法，然后再把结果放回去，这让他的效率降低了两到三倍。他问：“为什么我不能直接用我想要的逻辑，重载你们的减法定义呢？” 当然，在 Ingres 里，这都是写死在底层代码里的。
问题在于，这是一个你需要“债券时间”的场景，就像你需要点、线和多边形一样。Postgres 在架构之初就设计了一个可扩展的类型系统。你可以拥有任何你想要的数据类型，而且效率极高。这就是 Postgres 的核心要义：它具备极高的灵活性。在商业数据处理中，大多数人对标准数据类型很满意，但关系型数据库开始渗透到各种其他领域。所谓的抽象数据类型或存储过程具有极大的适用性，所以这成了 Postgres 最大的杀手锏。
我们还支持了当时人工智能领域的家伙们想要的“继承”功能。我们甚至支持了“时间旅行（历史数据查询）”。不过那部分的实现简直烂透了，后来就被移除了。总之，Postgres 里有大量非常巧妙的设计。
“我受不了不够聪明的人”
主持人：你提到你想招募非凡的软件工程师，而且我记得你以前说过，你找这样的人毫不费力。在招聘时，你是如何辨别出他们就是那些非凡之才的？
Mike Stonebraker：通常这很明显。我对事情的难度有很好的直觉。如果他们在学校里完成的工作量，是我认为合理预期工作量的三倍，那他们就是不可思议的天才。
主持人：反过来说，你有一句很有意思的话，我把它记下来了。你说：“我受不了那些不够聪明的人。和他们交流太费劲了。” 你是如何辨别那些不够聪明的人的？
Mike Stonebraker：这其实非常简单。你和他们聊一聊，很快就能试探出他们到底聪不聪明。“你的硕士论文写的是什么？你具体做了什么？它是怎么运作的？你是如何处理错误情况的？你开了多少个进程？你为什么不用线程？”你只需要问他们深度的技术问题。
主持人：你做过一次演讲，好像背后还有一篇论文，提出了这样一个观点：万金油式（one-size-fits-all）的数据库系统并不是最优解，试图适应一切的系统实际上什么都适应不好。你真正需要的是针对特定需求量身定制的数据库解决方案。你认为当今市面上有哪些数据库产品是这种“万金油”？
Mike Stonebraker：在 2004 年我写那篇论文的时候，我们有一个学术项目，后来演变成了Streambase。一个流处理引擎看起来和关系型数据库毫无相似之处。我们还有了用于数据仓库的列式存储的初步构想，后来被Vertica发扬光大，它看起来和行式存储也完全不同。所以这里有三个截然不同的实现，它们彼此毫无相似之处，而且在各自的领域，它们都比其他系统快上一个数量级。很明显，通过这三个例子可以看出，当你运行一个并非为你特定场景架构的数据库系统时，你就要牺牲一个数量级的性能。
我认为这在今天依然成立。ClickHouse是一个列存数据库。Pinecone在基于文本的向量处理上，比用户自定义类型要快得多。我认为情况依然如此，而且在多个底层实现之上套用一个通用的解析器，并没有什么难度。只是 Postgres 至今选择不这么做。他们没有实现列式存储，所以我认为他们在大型数据仓库领域缺乏竞争力。他们也没有多节点支持。同样，对于拥有大型数据仓库的人来说，这是入场券。所以我认为这个观点今天依然像过去一样正确。
不过有一点也是事实：如果你想快速起步，你遇到了一个数据库问题，答案就是选择 Postgres。它有庞大的编程社区，各种数据类型的实现，它是免费的，而且你很容易招到懂 Postgres 的人来推进工作。作为满足最低通用需求的选项，它是极好的。只要你不是想实现每秒一百万次的事务，它就完全没问题。只要你不是想支撑一个 PB 级的数据仓库，它就能运转良好。在低端场景，它绝对是正确的“万金油”。但在高端场景，这套就行不通了。
主持人：GPU 会为优化数据库提供一些新的机会吗？
Mike Stonebraker：也许会，但我认为巨大的挑战在于 GPU 是 SIMD（单指令多数据流）架构，而这简直是索引的死穴。只要索引是正确的解决方案，GPU 可能就不是个好主意。此外，你必须在架构上确保来自存储的带宽不会成为瓶颈。如果 GPU 只是 CPU 的一个附加组件，那么连接 GPU 和 CPU 的总线往往就会成为瓶颈。
主持人：你能解释一下为什么在使用 SIMD 时，索引的效果会大打折扣吗？
Mike Stonebraker：假设我在查找瑞恩的薪水，而且我有一个 B 树索引。你走到 B 树的根节点，找到包含瑞恩所在区间的分割点。你顺着指针往下走。这绝对是一次内存访问。然后你再重复这个过程，大概要重复三四次。这个过程是无法很好地并行化的。所以答案就是：索引无法很好地并行化。
“谷歌当年干的蠢事，不止 MapReduce 一件”
主持人：你提到了 B 树。当你们最初实现第一版 Ingres 时，所有这些都是你们手写的吗？因为我想象当时大概没有什么现成的 B 树代码库之类的东西。
Mike Stonebraker：是的，最初版本的 Ingres 全都是从零开始手写的。
主持人：那个实现过程中最难的部分是什么？
Mike Stonebraker：查询优化器。
主持人：为什么它那么难？
Mike Stonebraker：它非常棘手。它在算法上实在太难了。如果你去问任何一位资深的数据库程序员最难的部分是什么，他们至今依然会说是优化器。
主持人：MapReduce 大概在 2000 年代初问世，它席卷了整个数据领域。人们对它印象深刻，觉得谷歌真的知道自己在干什么，这是有史以来最棒的发明。但当我查阅文献以及你当时的看法时，似乎你非常不认同。你为什么如此不看好 MapReduce？
Mike Stonebraker：我认为当时有很多不太懂行的人说：“谷歌真的很聪明。他们肯定知道自己在干什么，所以他们说什么我们就做什么。”
于是他们开始搞Hadoop。但是 Hadoop 的效率低得令人发指。当时，大卫·德威特（David DeWitt）和其他参与了我们 2011 年论文的人，我们非常了解分布式数据库，并且明白用一个分布式数据库系统就能把 Hadoop 打得落花流水，这基本上就是那篇 2011 年论文的核心观点。当然，事实也确实如此。
但谷歌干的蠢事可不止这一件。谷歌当时还认为，“最终一致性（eventual consistency）”是处理并发控制的正确方式。在那个时期，这是谷歌高层定下的基调。而所有的数据库专家都说：“你们简直疯了。” 因为它只能解决一种非常特定类型的问题，而那种问题在实际应用中极少出现。
主持人：他们为什么要追求最终一致性？
Mike Stonebraker：他们的设想是，你在东海岸有一个数据库，在西海岸也有一个数据库，它们互为副本。你希望它们保持一致。如果你说：“我要执行一个事务，我要把西海岸仓库里的小商品数量减一”，那么在提交这个事务之前，你需要去更新东海岸的仓库。这需要花费一次消息往返的代价来更新它。然后为了确保万无一失，还需要另一次往返消息来确认两边都正确地提交了。执行分布式提交是非常昂贵的，现在依然如此。
所以他们的想法是，你在西海岸执行更新，把小商品减一，然后你只是异步发送一条消息，且不放在事务里，这样“最终”东海岸的仓库也会减一。与此同时，如果你在东海岸，你把食品减一。你发送一条异步消息。最终，西海岸会收到它，最终一切都会尘埃落定。
如果你的系统允许库存出现负数，那么当东海岸和西海岸的人同时卖出最后一件商品时，最终仓库的状态就会变成负一，然后就会有人收不到他们的商品。如果你像亚马逊那样，允许标明“通常在 24 小时内发货”，那也许你可以超卖，但大多数企业做不到这一点。所以最终一致性根本行不通。
我们刚才花了很长时间聊参照完整性。在销售系统中，参照完整性就是一个完整性约束：库存必须大于负一。而最终一致性在这里就行不通了。谷歌的杰夫·迪恩（Jeff Dean）最终想明白了这一点，所以当他们开发 Spanner 时，Spanner 用回了传统的事务系统，谷歌也彻底放弃了最终一致性，彻底放弃了 MapReduce。
主持人：所以这本质上是用正确性来换取性能。也就是性能与数据完整性之间的权衡。如果你不在乎你的数据，那你才愿意承受糟糕的结果。在谷歌做这些你认为错得离谱的事情时，你和他们的团队交流过吗？
Mike Stonebraker：在 2011 年那篇论文发表之前，我们和他们谈过，提议说：“我们为什么不合作搞点东西呢？” 但他们不感兴趣。所以他们拒绝了。
主持人：你有没有看到其他大型科技公司的数据库或数据库解决方案中，也有你强烈不认同的例子？比如亚马逊或 Facebook。
Mike Stonebraker：大概三年前我在亚马逊做过一次演讲，我告诉了他们所有我认为他们做错的地方。我认为亚马逊的问题在于他们同时在支持 15 种不同的数据库系统，这大概多出了 12 种。他们有自己的企业文化，我说：“你们支持的数据库系统太多了。”但到目前为止，他们还没有选择淘汰其中的任何一个。
主持人：为什么你觉得 15 种应该缩减到 3 种？
Mike Stonebraker：他们在支持一个基于图的数据库系统，而业界早就达成共识，图数据库系统几乎从来都不是性能最优的选择。如果你喜欢那种处理节点和边缘的用户界面，没问题。你可以在关系型数据库系统之上加一层，给你提供那种用户模型。
他们的大多数数据库系统，总能找到另一个在特定领域做得比它更好的系统。我的答案是，如果一个数据库系统在一个足够大的市场里没有性能优势，无法证明其维护成本的合理性，你就应该把它淘汰掉。
主持人：你从学术界对工业界产生了深远的影响，我有一个想法：为什么不直接在工业界工作呢？为什么你更倾向于留在学术界，以你现在的方式施加影响，而不是直接去 AWS 之类的公司谋个差事，做个极其杰出的工程师？
Mike Stonebraker：因为那意味着你会有个老板。会有公司规章制度，限制你发表论文，限制你去参加会议发表演讲，限制你去刺探竞争对手那些他们不愿向同行透露的底牌。但最主要的是，我真的非常喜欢置身于初创公司中。在商业版的 Postgres 被 Informix 收购后，我曾在 Informix 兼职工作过，那是一家有 2000 人的公司，我感觉自己根本发挥不了什么作用，因为那里官僚主义严重，总裁想要什么，他就能得到什么。我觉得我天生不适合搞办公室政治。我做不好那个，而且我很难跟那些我认为愚蠢的人打交道。所以在大公司里，我会遇到很多麻烦。
对刚 Linux 的 DBOS
主持人：我想聊聊 DBOS。我觉得这是一个非常有趣的技术模型。你能解释一下 DBOS 是什么吗？
Mike Stonebraker：我们大概在 2019 年、2020 年左右启动了这个学术项目。当时的核心背景是，斯坦福大学的教职员工、也是Databricks的创始人之一，同时也是 Spark 最初创造者的马泰·扎哈里亚（Matei Zaharia）提出了一些痛点。他说，当时 Databricks 基本上是在云端运行人们的 Spark 任务。他说在任何给定时间，他们可能要调度一百万个 Spark 任务。所以必须编写一个调度器，来决定接下来运行谁，而且要达到百万级的规模。他说他们尝试了操作系统专家编写的所有调度器，但都无法支撑这种规模。
于是，我们把所有的调度数据都放进了一个 Postgres 数据库里，基本上就是用一个 Postgres 应用程序来做调度。然后我们突然恍然大悟：操作系统里绝大多数的工作，本质上都是在大规模地管理数据，而你本就应该用数据库技术来做这件事。那么，我们为什么不干脆用一个数据库系统来替换掉 Linux 至少上半部分的功能呢？
这就是那个学术项目的核心思想。我们在 2020 年代初在伯克利和斯坦福研究了这个项目，而且非常成功。它显然是行得通的。在这个过程中，斯坦福的团队为JavaScript编写了一个扩展程序，因为你需要一个编程环境来与你的底层实现进行交互。如果你在做一种编程语言，并且运行在一个本质上是数据库的操作系统之上，那么最显而易见的做法，就是把所有的状态都存在数据库里。他们正是这么做的。所以我们拥有了创新的编程语言模型，以及创新的操作系统模型。
当然，接下来的想法就是，我们能创办一家公司吗？我们去和风险投资人谈，他们异口同声地说：“想取代 Linux，你是在做梦。不过，你们那个编程语言的东西倒是很巧妙。” 我们拥有的，相当于 JavaScript 的扩展，它能让任何程序都具备数据库系统的所有优秀特性。数据是持久化的。你可以使用事务。如果系统崩溃了，它会自动故障转移。全都是这些绝妙的特性。
所以我们在 2023 年拿到了融资，成立了公司，这就是DBOS 公司。我们决定用这个名字，因为它一直都是这个项目的名字，但我们实际上做的是编程语言的生意。目前，DBOS 拥有 TypeScript 版本、Java 版本、Go 版本和 Python 版本，它们几乎是无缝对接的。它跑起来就像是普通的程序一样。
在云端世界里，把你的应用程序构建成工作流是绝对的大势所趋。所以我们决定，我们要支持一个工作流系统，就这么简单。DBOS 在这四种语言中支持的工作流，其各个步骤、各个微应用（不管你怎么称呼它们），都是具备事务性的。工作流是持久化的，所以一旦你完成了一个步骤，它就不会被遗忘。很明显，如果有市场需求，我们可以让工作流具备原子性，这意味着整个工作流要么全部完成，要么就像从未发生过一样。它拥有非常棒的特性，而且比竞争对手快得多，也容易使用得多。
公司目前正在这个领域进行销售和创新。核心理念是，当你把应用程序的状态放入数据库时，你想让它持久化，然后你再想办法让它跑得快。正像我们之前聊到的，他们的商业模式非常明确，就是去吸引基层程序员的兴趣。所以我们的策略一直是：“告诉我们，基层程序员们，你们需要什么我们还没有的东西，快速把它做出来，然后说服人们去尝试。” 我们在吸引那些想要选择最佳方案的其他初创公司方面非常成功，而且我们也开始在大型企业中取得突破。
这是一个非常有趣的市场，我认为目前最关键的一点是，大概有三分之二的客户在做智能体 AI（agentic AI），这意味着他们有一个大语言模型，周围环绕着一堆提供更多信号的组件。到目前为止，绝大多数的智能体 AI 都是只读的，意思是你想预测一下瑞恩会不会成为一个好客户。它只是运行一些数据，然后生成一个新结果交给某人。基本上是只读的，这意味着你并没有真正去更新瑞恩的信用评分。
我认为这个领域很快就会演变为：使用智能体来执行读写应用程序，而这将使它们变得非常“数据库化”。DBOS 非常擅长处理这类事情。举个例子，如果你想写一个智能体，或者两个智能体，把 100 美元从我的账户转到你的账户。你需要从我的账户扣款，在你的账户加钱，这两个智能体必须同意提交，否则你就得把一切回滚。也就是说，工作流需要具备我所说的原子性，要么全部发生，要么就像从未发生过。我认为这个市场的需求会随着人们对读写操作的渴望而不断攀升。我认为这对市场是个好兆头，对 DBOS 也是个好兆头。
主持人：所以现在市场上提供给应用程序开发者的东西，和最初那个把操作系统内核替换成数据库的研究项目是不一样的。我明白了。这真的很酷。我从未想象过用一个数据库来替换操作系统的所有状态。这其中的权衡是什么？
Mike Stonebraker：写在数据库管理系统（DBMS）之上的文件系统，比 Linux 文件系统还要快。调度引擎与其他调度引擎相比也毫不逊色。你可以让一切都具备故障转移能力，所以你不需要做任何额外的工作就能获得高可用性。答案是，真的没有任何缺点。
主持人：那为什么 Linux 不吸收这项技术，用它来升级自己呢？
Mike Stonebraker：你当然希望他们会这么做。换句话说，你应该把所有那些设备驱动之类的杂七杂八的东西留在最底层，因为这类东西很多，也没人愿意去碰它们，然后用数据库实现来替换掉其他所有的东西。
主持人：你向 Linux 社区的人提过这件事吗？他们通常是什么反应？
Mike Stonebraker：当年做学术项目的时候，如果我向操作系统专家提到这个，他们会感到极大的威胁，他们的反应是：“这是搞数据库的家伙想来抢地盘。” 我觉得编程语言领域的人也是一样的反应：“实现编程环境运行时的最佳方式，竟然是使用数据库。”
主持人：这很有意思。我是说，如果它客观上是正确的，那它也许终将接管一切。
Mike Stonebraker：毕竟，Java 也花了 10 年时间才被广泛接受。我认为这需要一个漫长的时间周期。
大模型得分 0%？
主持人：我们聊了很多数据库的过去，我很好奇你对数据库领域未解之谜的看法，以及你认为未来会是什么样。
Mike Stonebraker：好的。我想谈两件不同的事情。第一件事是，和所有人一样，三年前我们开始研究大语言模型到底能干什么。我们一直试图让现在所谓的 Text-to-SQL（自然语言转 SQL）在真实的数据库中发挥作用，特别是在真实的生产级数据仓库中。
我们在四个不同的生产级数据仓库上测试了这项技术，我们获取了实际用户在系统中运行的真实工作负载，并让他们逆向工程出与该查询序列对应的自然语言文本。所以我们拥有了四个基准测试的文本和 SQL 对照数据。
主持人：当你说 Text-to-SQL 时，是指像人类用英语向模型发出提示词那样吗？
Mike Stonebraker：那些文本可能是：“告诉我麻省理工学院所有年龄超过四岁且获得过图灵奖的教授。” 大语言模型据说很擅长这个。现有的 Text-to-SQL 基准测试，有一个叫 Spider，另一个叫 BIRD，最顶尖的 LLM 系统在这些基准测试上表现相当不错。准确率能达到 80% 甚至更高。虽然还没达到超人类的水平，但也相当不错了。你是会考虑使用它们的。目前的排行榜上大概有 85% 的准确率，已经很接近实用了。
主持人：你说它也许还没完全准备好投入实际应用，但看起来确实相当不错了。
Mike Stonebraker：然而，在我们的基准测试里，大语言模型的得分是 0%。如果你用 RAG（检索增强生成）和各种技巧来强化它们，准确率能提升到10%。如果你在提示词中直接给出 FROM 子句——换句话说，告诉它所有需要访问的实际表名，以及所有需要连接的 JOIN 条件——准确率能上升到大概35%。所以，这项技术的现状就是，它根本没有准备好投入实际应用，而且在很长一段时间内都不会，甚至可能永远都不会。
主持人：区别到底在哪儿？
Mike Stonebraker：第一，LLM 是在公共语料库（the pile）上训练出来的。而数据仓库的数据并不在那个语料库里。有一句老话：如果你以前没有见过这些数据几次，你根本不可能把它吐出来。这是第一点。
第二，Spider 和 BIRD 测试里的查询复杂度，大概也就是 10 到 20 行 SQL 代码。但在真实世界的数据仓库里，那是 100 行 SQL 代码。复杂度完全不在一个量级。
第三，Spider 和 BIRD 里的数据模式（Schema）非常干净。表名是见名知意的。列名是见名知意的，而且没有重复。但在数据仓库里，人们到处都在用物化视图。这意味着存在数据冗余，而且列名经常是下划线、Z、大写字母等等乱七八糟的东西。它们根本不能见名知意。这让难度大大增加。
最后，他们还有各种极其特殊的数据。比如“J-term”在麻省理工学院是个很常见的词。它是指一月份的一个为期一个月的学期。这并非麻省理工独有，但也不是很普及。所以，它不在训练语料库里，包含极其特殊的数据，查询并不简单，而且数据模式一团糟。这些因素加在一起，让它根本无法工作。而我所知道的每一个数据仓库都是这副德行。我认为这项技术目前根本行不通，而且在短期内也别指望它能行得通。
主持人：那你该怎么办？
Mike Stonebraker：首先，我们发布了我们的基准测试。它叫Beaver，是这四个真实数据仓库的匿名化和抽象化版本。如果你觉得自己做 Text-to-SQL 真的很牛，那就来试试真实的基准测试，别玩那些假的。
第二，借用我刚才说的，如果你没有所有的 JOIN 条件，没有 FROM 子句，你就彻底完蛋了。更重要的是，如果你不把查询拆解成更简单的部分，你也会完蛋。这对我来说意味着，你需要给你的检索系统提供更简单的组件，其中包括 FROM 子句和 JOIN 条件。这是第一点。
第二，一旦你想同时与两个不同的结构化数据库对话，比如你的数据仓库和你的 CRM 系统，那在我看来，用 LLM 来做结构化数据的 JOIN 绝对是个馊主意。你最好还是让它们保持表的形式，然后在 SQL 里做 JOIN。
我们的观点是，我们正在尝试把一切都变成表。我们正在和德国慕尼黑市的交通部合作，他们有六个全职人员专门回答市民的投诉和质询，问题大概是这种：“为什么我家旁边的十字路口，绿灯时间短得不够我走过去？” 各种各样的问题。“为什么电车停靠的时间不够我上车？” “为什么电车一小时才来一趟？”
他们的数据库里，电车时刻表是 SQL。红绿灯时序是 SQL。十字路口的地图是 CAD。德国联邦关于这些东西的法规是文本。慕尼黑市的法规也是文本。所以你得把 SQL、SQL、CAD、文本和文本连接（JOIN）在一起。我们的观点是，把它们全都转换成 SQL，全变成表，然后用一个类似查询优化器的东西来做 JOIN。这就是我们正在研究的方向。我想其他人会有其他的思路，但我认为这是一个极其肥沃的领域，因为人们真的非常需要解决这个问题。这是第一件事。
第二件事，我们之前聊到了智能体 AI（agentic AI）。一旦它涉及到读写操作，它就变成了一个分布式数据库问题，你会需要原子性、一致性等等所有这些特性。我认为这是一个非常有趣的领域。所以这基本上就是我现在正在研究的东西。
主持人：在那个目前得分是 0% 的基准测试上，人类能拿多少分？比如你找一个真正懂 SQL 的人，普通人类能得多少分？
Mike Stonebraker：一旦你消除了文本中的歧义，一个熟悉数据模式的资深 SQL 程序员能达到极高的准确率。
主持人：好的。大概至少能到 90% 之类的。哇，我真惊讶 LLM 在这种基准测试上得分这么低。也许这期节目播出去之后，某个在 Anthropic 工作的人会联系你，说：“咱们来试试……”
Mike Stonebraker：我很乐意看看结果，因为如果成了，那将是一个了不起的成功故事。
大模型得分 0%？
主持人：对于那些想要深入理解数据库，并且正在寻找学习资料的人来说，有没有哪本书是你推荐的顶尖技术书籍，或者是文献中的经典论文？
Mike Stonebraker：乔·海勒斯坦（Joe Hellerstein）和我出版过一本被称为“红皮书”的书，叫《数据库系统读本》（Readings in Database Systems）。它现在已经出版八年了。我觉得它作为八年前的阅读材料是非常棒的，除此之外，可以去读读文献中那些广受欢迎的论文。
主持人：如果你能回到刚毕业的时候，带着你今天所知道的一切，你会给自己什么建议？
Mike Stonebraker：当年我刚在伯克利接下那份工作时，我们连想都没怎么想，就说：“咱们写个数据库系统吧。” 我们对数据库一无所知，对底层实现一窍不通。我们也不像比尔·乔伊（Bill Joy，Sun的联合创始人）那样是编程高手。所以，一开始就去做那么疯狂的事情，真的是挺疯狂的。但你投入了精力，你让东西运转起来，你在这个过程中不断学习。所以答案是：跳出框架思考。敢于有疯狂的想法，并努力去实现它们。
对我来说，这根本不是什么显而易见的事。更好的问题是，如果你今天才刚起步，你会选择什么专业？因为我认为计算机科学在未来可能不再是一个朝阳产业了。我不太确定我还会不会建议 18 岁的年轻人们去主修计算机科学。我认为医疗保健和建筑行业是安稳的选择，而其他一切看起来风险都要大得多。
如果你即将拿到博士学位，正在犹豫该做什么，我觉得事情很简单。接受你能拿到的最有名望的工作，找一位愿意帮你的导师，然后选一个不随波逐流的领域。就像我们做的那个叫 Rubicon 的项目，绝对是不随波逐流的。选一个逆流而上的方向，然后努力让它大放异彩。
我和我妻子都曾说过：“追随你的热情。钱的问题总会迎刃而解的。”其实我骨子里根本不相信这句话，但我觉得你必须这么告诉你的孩子和孙子们。
主持人：如果你不相信这句话，那你为什么还要这么告诉他们？
Mike Stonebraker：我妻子就是个很好的例子。她有计算机科学的本科学位和硕士学位，但她真正想做的是一名中小学教师。她的父母说：“你不能去教书，那赚不到足够的钱。” 我觉得从那以后，她一直都在后悔那个决定。她对搞计算机科学并没有什么热情；那对她来说只是个谋生的手艺。
所以我认为，找到你热爱的事业，你大概率不会饿死——你可能赚不到大钱，但我认为你会有很大的机会，比做一份你不热爱的工作要快乐得多。因为我认识的很多人，他们仅仅把工作看作是一份工作，认为真正的生活是下午 5 点下班后到第二天早上 8 点上班前的那段时间。我完全不这么想。我真的热爱我所做的一切。无论我赚不赚钱，这都无所谓。
（投稿或寻求报道：zhanghy@csdn.net）
热门跟贴