计算机科学未来或不再是增长型行业数据库领域的图灵奖得主 Mike Stonebraker中文常译作 石破天表示“如果今天重新开始我不确定还会不会建议 18 岁的人去学计算机”。他是 Ingres 和 Postgres 背后的关键创造者也是数据库领域最重要的人物之一在他看来计算机科学未来很可能不再是一个增长型行业。在这期访谈里Stonebraker 把半个数据库行业都点名骂了一遍。他骂 Oracle称 Larry Ellison 当年是在“撒谎”将还没实现的功能卖给客户让第一批客户帮自己 debug骂 Google说 Google 当年推 MapReduce 和最终一致性是“愚蠢”的Hadoop 低效得离谱最终一致性也只适合极少数场景等到 Spanner 出来Google 自己也承认事务、一致性这些数据库老问题绕不过去还骂 AWS认为 Amazon 同时维护大概 15 种数据库而真正需要的可能只有 3 种很多数据库没有足够性能和市场理由继续存在。对 AI 的看法他认为现在所谓的 agentic AI本质上是“大模型 一层系统包装”且大多数还停在“只读”阶段。一旦进入真正的“读写”世界问题就回到数据库的老问题事务、一致性、原子性这不是 AI 问题而是分布式数据库问题。对于大模型写 SQL在公开 benchmark 上模型能做到 80% 的准确率看似只差一步就能上生产。但在真实数据仓库测试里结果是 0%即使加上 RAG、甚至把 join 条件直接喂给模型最多也只能到 35%而一个熟练的人类工程师可以做到 90% 以上。所以他得出结论这项技术至少在可见的未来还不够格进入生产环境。Postgres最好用的起点不是终点主持人询问 Stonebraker 进入数据库领域的经历他表示毕业之后被伯克利录用当时继续博士期间的方向没前途在 Gene Wong 的带领下于 1972 年开始做 Ingres这是他拿 tenure 的关键项目他在 1976 年拿到了终身教职。伯克利版本的 Ingres 很受欢迎有 100 所大学开始使用但在 Arizona State University 的项目中失败因为 Unix 上没有 COBOL。唯一的出路是创业1980 年他们成立了 Ingres 公司把系统迁移到 VMS 这样的“真正操作系统”上并提供商业支持。主持人提到 Ingres 与 Oracle Corporation 竞争技术上 Ingres 更好但 Oracle 赢了。Stonebraker 认为 Larry Ellison 是厉害的销售会对客户撒谎把不能用的功能卖出去让客户 debug。例如“引用完整性”功能Ingres 实现了而 Oracle 在手册里解释但标注“尚未实现”。从 Ingres 到 Postgres最大的变化是 Postgres 被设计成可扩展类型系统能定义任意数据类型且运行效率高。因为 Ingres 无法高效支持 GIS且日期计算逻辑写死不能自定义减法。此外Postgres 还支持继承和“时间旅行”不过“时间旅行”实现得糟糕后来被移除。主持人询问 Stonebraker 如何识别优秀工程师他表示一眼就能看出若学生完成的工作量是合理水平的三倍就是非常优秀。对于判断一个人不够聪明跟他聊技术细节就能知道。Stonebraker 提出“One size fits none”观点认为通用型数据库系统不是最优解真正需要的是针对具体需求定制的数据库方案。像 ClickHouse 是列存Pinecone 在基于文本的向量处理上比用用户自定义类型硬塞的方案更快。Postgres 适合低端场景在高端场景缺乏竞争力。索引一出现GPU 就很难发挥作用主持人询问 GPU 会不会给数据库优化带来新机会Stonebraker 认为最大挑战在于 GPU 本质是 SIMD与索引相冲突只要索引是正确答案GPU 大概率不是好答案。还得确保从存储到计算的带宽不会成为瓶颈否则 CPU 和 GPU 之间的总线会成为瓶颈。主持人询问在 SIMD 模式下索引效果变差的原因Stonebraker 以查询 Ryan 的工资为例说明索引过程很难并行化。Ingres 最早版本全部从零写最难实现的部分是查询优化器因为它在算法层面很复杂至今资深数据库程序员仍认为优化器是系统里最难的部分。Google 是选错了方向Amazon 是选太多方向MapReduce 出来后席卷数据领域很多人认为 Google 很懂但 Stonebraker 强烈反对。他认为很多人盲目跟从 GoogleHadoop 效率低得离谱他们 2011 年的论文证明用分布式数据库系统可以把 Hadoop 打得很惨。Google 还认为最终一致性是正确的并发控制方式但这只解决特定问题在真实世界少见。例如东海岸和西海岸数据库副本保持一致的问题最终一致性可能导致库存超卖。后来 Google 的 Jeff Dean 意识到问题Spanner 用的是传统事务系统Google 放弃了最终一致性和 MapReduce。这本质上是性能和数据完整性之间的权衡。Stonebraker 在 2011 年论文前找 Google 团队交流合作被拒绝。对于 Amazon他认为 Amazon 支持大概 15 种数据库系统多了大概 12 种很多数据库有别的数据库能做得更好那些性能不够好、市场规模不足以支撑维护成本的数据库应被淘汰。主持人询问 Stonebraker 为何不直接去工业界工作他表示去工业界会受公司规则束缚且他喜欢待在创业公司在 Informix 兼职时感觉不到自己能带来变化不适合大公司环境。把 Linux 上半部分换成数据库Deboss 学术项目大概在 2019 年、2020 年左右开始与 Matei Zaharia 有关。Databricks 在云上跑用户的 Spark 作业调度上百万个 Spark 任务最后把调度数据放进 Postgres 数据库由 Postgres 应用做调度。这启发他们把 Linux 至少上半部分用数据库系统替换和伯克利、斯坦福一起做这件事很成功。斯坦福给 JavaScript 做了扩展把所有状态放进数据库形成新的编程语言模型和操作系统模型。后来找风投融资风投认为替代 Linux 是做梦但编程语言部分有意思。2023 年成立了 Deboss 公司提供 TypeScript、Java、Go 和 Python支持工作流系统工作流有很多好性质速度比现有竞品快用起来容易。目前大概三分之二的 Deboss 客户在做 agentic AI大多数 agentic AI 还是只读型未来会转向可读可写应用这类系统会变得“数据库化”Deboss 擅长处理。主持人询问最初研究项目把操作系统内部核心状态替换成数据库有无代价Stonebraker 表示基本没缺点构建在 DBMS 之上的文件系统更快调度引擎性能能打平还能具备 failover 能力。理论上 Linux 应把部分替换成数据库式实现但跟 Linux 圈子的人提他们有威胁感。Java 花了 10 年才被广泛接受这种事情时间常数大。在真实数据仓库里LLM 写 SQL 的准确率是 0%Stonebraker 表示三年前开始研究大语言模型在真实世界数据库上的应用尤其在真实数据仓库上测试 text - to - SQL 技术。他们有四套 benchmark每套包含文本和 SQL。公开 benchmark 里大语言模型准确率能到 80% 甚至更高但在他们的 benchmark 上是 0%添加增强技巧后最高到 35%所以这项技术短期内无法上生产。差别在于数据仓库里的数据不在大模型训练语料里查询复杂度高schema 不直观还有大量特殊数据。他们把自己的 benchmark 发出来叫 Beaver认为合理做法是把检索系统输入变成含 from 子句和 join 条件的简单片段与不同结构化数据库打交道时用 SQL 做 join 更靠谱。他们和德国慕尼黑市交通部门合作把各类数据转成 SQL 或表用接近查询优化器的方式做 join。主持人询问人类在 benchmark 上的准确率Stonebraker 表示熟悉 SQL、看懂 schema 的程序员准确率能到 90% 以上。计算机科学可能不再是增长型行业主持人询问系统学习数据库的推荐资料Stonebraker 推荐他和 Joe Hellerstein 出的“红皮书” Readings in Database Systems还建议看后来重要、流行的论文。他认为如果回到刚毕业要跳出框框去想敢想疯狂念头并去做。但现在更值得问的是如果今天才刚开始会选什么专业他不确定是否还会建议 18 岁的人学计算机医疗保健和建筑、维修等工种相对安全。如果快拿到 PhD应找有声望的工作挑不随大流的方向。他不相信“去追随你的热情钱总会自己解决”这句话但还是会跟孩子和孙子这么说因为他太太就是因为父母的建议放弃做老师一直有遗憾他认为应找有热情的事这样会过得更开心。