Andy Pavlo：当数十亿AI智能体冲击数据库
点播放，字幕跟着声音走
Subtitles follow the audio
逐句文字稿
点任意一句，从那里开始听
正在加载字幕…
-
文件系统是什么？它就是个数据库，对吧？什么都是数据库。
-
每个月都有这样的故事：有人因为智能体删了东西，把生产数据库弄丢了。
-
对于不了解数据库历史的人来说，这简直就是蛮荒西部。
-
这就像抓来一只猎豹，给它喂一堆可卡因，然后把它塞进法拉利。
-
人们开发这些东西的速度简直快得离谱。
-
这就是 Andy Pavlo。
-
在数据库的世界里，Andy 差不多就是最接近神的人了。
-
这位卡内基梅隆大学教授，他的课程教了一整代工程师数据库知识，而且事实证明，也教了 AI 模型。
-
Andy 最近加入了 ClickHouse，创办了 ClickHouse Labs，引起了不小的轰动。
-
不久前，AI 里的数据库还意味着向量搜索和 RAG。
-
但如今，智能体会创建数据库、往里面写数据，有时甚至会把它们删掉。
-
欢迎来到《智能体时代的数据库》。
-
我是 Matt Turk，这里是 The MAD Podcast。
-
哦，我们从来没想过会在节目里这么干。我们非得聊 Larry Ellison 吗？
-
我是说，这才刚开场，聊这个有点早吧。
-
不过他确实挺搞笑的，因为他就像数据库界的超级反派。
-
就像他拥有一座夏威夷的岛一样。
-
嗯，这对他来说好像还挺顺利的。
-
好吧，那我们可以等对话后面再进阶到聊 Larry Ellison。
-
我要说一句，我跟 ClickHouse 的合同确实允许我聊 Larry Ellison。我确保这一条是白纸黑字写下来的。好吧，太棒了。
-
我想从头讲起。
-
所以两年前，数据库和AI这个话题就冒出来了。
-
当时有一整个向量数据库的时代，大家都在说你需要把 RAG 跟聊天机器人搜索结合起来。那差不多是两年前的事了。
-
我觉得很多人对数据库和AI这个交叉点的认知，差不多就停在那儿了。
-
显然我们现在进入了智能体的时代。这有什么不一样？会带来什么变化？
-
我是说，向量数据库——你说得没错，从AI和数据库的时代潮流来看，大概两年前是 RAG、向量数据库开始登场的时候，但向量数据库本身，很多从2016年起就已经存在了。
-
只是到了现在，它们的用途才变得明显，因为你可以用它们来增强和改进智能体做事的方式。
-
所以我觉得向量数据库这个市场挺有意思，因为他们很早就进入这个领域了，但他们当时一直在推一个理念：你要在向量或 embedding 上做近似相似度搜索。
-
而不是像传统数据系统那样做精确搜索。
-
而且这在处理自然语言时也很有用，因为你想找、想查询的东西，它的语义你没法精确定义。
-
比如，帮我找出所有来自纽约市、歌里谈到做某种活动的艺人的专辑，对吧？
-
你很难精确说清那到底是什么，而近似最近邻搜索，或者向量数据库里这些向量 embedding 搜索的魔力就在于，你可以根据你要找的东西的语义去查，然后差不多就这样，它就能奏效。
-
因为你并不是在做精确的关键词搜索。
-
所以，你知道，当 ChatDB 在2023年、2024年爆火的时候，还有当大家都意识到现在有这样一种技术存在的时候，向量数据库正好处在正确的位置、正确的时间，因为它们可以增强和改进这些聊天机器人。
-
但要说护城河的话，其实没那么大，因为归根结底，它只是一个索引。
-
而不到一年，几乎每一家数据库厂商都有了自家的向量索引。
-
而现在这已经成了一种标配、基本门槛。
-
我们现在用的每一个数据系统，都有自己的向量索引。
-
当然，这并不是说向量数据库不能在某些事情上比传统数据系统做得更好。
-
只是现在大家都有了这个基础能力。
-
所以我觉得，现在你还是会用向量搜索来增强和改进聊天机器人或者智能体。
-
只是说，你不需要有一个专门只做这件事的数据系统。
-
而且现在智能体会创建数据库、使用数据库，还能修改数据库。
-
可能一年前 Databricks 收购 Neon 的时候，有一个数据说，我记得是说创建 Neon 数据库的智能体数量或比例从 30% 涨到了 80%。
-
由智能体创建的数据库比其它任何来源都多。你给我们展开讲讲，这意味着什么？
-
一个智能体创建一个数据库？
-
可智能体一开始为什么需要创建数据库呢？
-
有创建数据库，还有对现有数据库做分支，那么分支到底是什么意思？
-
分支就是，你有一个数据库，你想给它做一份拷贝、或者说写一个快照，让它看起来像两个各自独立的数据库。
-
你这么做的原因是，你可能有一个生产数据库，它在支撑你的业务、你的应用，是记录系统，所有变更都写进它里面。
-
但接着你又希望，不管是人类开发者还是智能体，都能开始尝试新东西、修改应用，而且你希望他们是在真实数据库上操作。
-
因为很多时候，按传统做法，你会复制数据库，或者弄一个更小版本的数据库，比如一个样本，已经放在那里，因为到处复制这些东西实在太贵了。
-
所以你会有一个类似预发布或者开发用的数据库，然后你希望再把这些改动应用到生产数据库上，而且有些东西是等你上到更大规模之后，一切就能跑通。
-
所以分支让你能做的，就是给真实数据库做一个快照，让你做的所有改动都写到这个快照上，而不影响生产数据库。
-
而一旦你对你所做的改动满意了，可能不一定是数据上的改动，通常是指数据库模式或者应用代码上的改动。
-
一旦你确认已经在快照上验证过，就可以把它上线到生产数据库里了。
-
所以现在有了这些智能体，人们会启动这些编程智能体，让它们写新功能、写应用里的新模块。
-
这已经不是人类在做的事情了。
-
而现在你希望这些智能体能在数据库的副本上验证它们的改动，所以你可以给这些东西创建分支。
-
这通常也会在你跑测试的时候出现。
-
很多时候，这些分支是 GitHub Actions 里跑的 PR，或者类似的测试流程创建出来的。
-
所以你想在数据库的副本上跑测试代码，而不是在线上库上跑。
-
所以这个分支能力主要还是用在开发上。
-
所以现在，人们用智能体来写很多新代码。
-
所以你想让它们在各自的沙箱里跑，而且你可以给数据库做个快照。
-
所以分支能力在这件事上特别有用。
-
对，再往更基础的层面说。
-
智能体需要创建数据库，因为智能体会在现实世界里采取行动。
-
而且如果你让智能体创建一个应用，一个应用说到底还是个数据库。
-
是啊，所以如果你说这是从零开始建的，那当然，你的编程智能体，你给它一个提示，说一个空白应用要做这个，它马上就会创建一个数据库。
-
但大多数创建出来的分支，或者你要叫它们新数据库也行，都是为了这种开发。
-
但没错，现在智能体可以创建数据库了。
-
不管是好是坏，你可以让它们把数据库删掉。
-
人们经常因为这个惹上麻烦，因为它会做那些不该做的事。
-
是啊，去年也有。
-
哦，所以每年都有点故事。
-
有一次事件特别有意思。
-
这事在 X 上被传得挺广，最糟的时候就是这样。
-
所以有个叫 Jism Lenkin 的人，当时想做个东西。
-
就是 Replit，我觉得是 Replit 的智能体跑到数据库里，删了一大堆文件，后来 Replit 也做了正确的调整。
-
显然，这一切现在都还是蛮荒西部，大家都在边做边学，错误肯定免不了。
-
但对于那些不了解数据库发展史的人来说，这就是蛮荒西部。
-
多年来，我们一直都有能力防止人们干蠢事，比如删掉一张数据表，或者删掉一大堆记录。
-
这些控制手段是存在的。
-
只是每个人都想重新发明轮子，结果只能通过惨痛的教训，去重新学会那些过去早就已经做过的事。我们来展开讲讲这一点。
-
那这意味着什么呢？
-
在这个庞大的数据库世界里，现在缺了什么、必须补上什么？是护栏，对吧？
-
这就好比，你刚有了一个孩子，一个刚会走路的小娃，你总不会不装护栏，任由他从楼梯上摔下去，或者把手指插进插座里吧？
-
对这些智能体来说，也是一样的道理。
-
你就把它们当成刚会走路的小孩。
-
它们可能比小孩要稍微高级一点，但也不能就让它们在数据库上撒野，想干什么就干什么。
-
当然，你可以坐在那儿一直盯着它，不停地点“批准、批准、批准”，就像在 Cloud Code 或者其他什么工具里那样。
-
但当然了，这样一来你就没法扩展，也没法让几百个智能体同时干活。
-
所以你需要设置好正确的权限和控制，让它们没法进入生产数据库，去删掉本不该删的表。
-
同样，你也不该让它们去读那些本来就不该读的东西。
-
如果你通过分支或者其他方式设置好正确的护栏，建起这些沙箱，你就能避免那种灾难——每个月都有类似的故事，某个人的生产数据库因为智能体删了东西，或者干了不该干的事，结果整个丢了。
-
只要护栏到位，你就能确保这些事情不会发生。人会偷懒。
-
整个公司、整个组织都用同一个密码，然后又把同一个密码交给智能体。
-
然后我还纳闷，为什么这个智能体开始干一些不该干的事。
-
这些护栏应该跟目前已有的护栏一样吗？
-
对，所以也许更大的问题是，智能体现在至少表现得跟人类不一样了吗？
-
除了能 24/7 全天候运行之外，我还没看到任何东西能表明，他们不是用和人类一样的方式开发、用和人类一样的方式做软件、用和人类一样的方式跟数据交互，对吧？
-
说到底，数据系统能暴露出来的不同能力也就那么多。
-
而那正是暴露给你的 API。
-
所以只要你能为使用这些 API 的人类限制住这些东西，你也能对智能体做同样的事。
-
但这些护栏能有多精细，不只是“别在表上运行、删除或更新”那种程度，这种精细程度其实取决于你在用什么产品。
-
我得说，这方面我喜欢开源数据库，但如果你愿意这么说，企业级商业传统数据库过去已经为人类做过所有这些了。
-
所以它们有很多你想要的那种保护机制，只要把这些也暴露给智能体就行了。明白了。
-
跟人类相比，有什么根本性的不同吗？
-
我想你提到过数据量和可扩展性。
-
有可能会是数十亿个智能体在采取行动，这个事实会改变一切吗？
-
以及它们如何跟数据库交互。
-
老实说，我不知道答案，对吧？
-
就像现在说这个还为时过早，而且我明白，我是说，数据量当然算一个因素，对吧？
-
因为智能体在以人类做不到的方式全天候 24/7 运行。
-
但我们以前在数据库里也见过类似的模式，就是数据量的增长。
-
我就这么说吧，已经有过三个时代，而我们现在身处第四个时代。
-
比如第一个时代，差不多就是刚刚有数据库这东西的初期，你现在可以开始录入信息、运行事务、为你的组织存储东西，而以前全是纸笔的时候你根本做不到。
-
所以大概在七十年代、八十年代，数据库需要处理的流量一直在增长。
-
但在那个时代，主要还是人类在跟数据库交互，不过是在工作时，因为没人会回家还用，而且在 80 年代也不是人人都有电脑，肯定没有我们现在这种水平。
-
所以可以说，那算是一个时代吧，我们经历了流量的增长。
-
然后到了九十年代、两千年初，互联网来了，现在每个人都能通过网站、通过家里的互联网跟数据库交互。
-
所以你就看到流量在那个层级上猛增了一次。
-
然后下一个时代就是手机，现在每个人无论什么时候都有各种应用在跑，他们可以跟网站交互，然后把东西写进数据库、再从数据库里读出来。所以我会说，那就是第三个时代。
-
所以现在智能体，我觉得，就是这个故事的下一个篇章：现在每个人不光有一部手机，还可能有几百个智能体在替他们交互，然后这些智能体再去交互，你知道，就是读取、写入数据库里的数据。
-
说到底，你只要有一个应用，它背后总得有一个数据库撑着。
-
所以这就会让应用去读取和写入信息，读取和写入数据。
-
所以我觉得我们还没到那一步，因为显然不是每个人都已经有几百个智能体在 24 小时全天候运行。
-
但可能发生的事里，有意思的地方在于，你想想，人类用手机或笔记本电脑跟网站或应用交互时，其实基本上只在醒着的时候才会这么做，对吧？
-
你一次只能做一件事，比如我没法一只手拿着手机、另一只手用着笔记本，同时干两件事。
-
这其实一直限制着人类实际能做的事情。
-
但你可以想象这样一个世界：这些智能体就是全天候一直运行，表现得就像人类在跟各种东西交互一样。
-
那流量就会大幅增长。
-
然后，再者，跟 Web 应用不一样，它们通常会——你可以说，这个时代到底跟现在的物联网设备或手机有什么真正的不同呢？
-
物联网设备只是流式插入，就是“这是我测到的数值”。
-
用手机应用的时候，你通常是在读数据。
-
但你可以想象，这些智能体做的是更复杂的操作，是读和写的结合。
-
这样一来，流量就变得更有意思了。
-
所以我觉得，将来打到数据库上的查询数量，可能会增长 10 倍到 100 倍。
-
而且我不觉得我们已经到了那个量级，但我确实从行业里的朋友那儿听说，他们已经看到这类情况了。
-
我们在 ClickHouse 也看到了同样的情况。
-
不过，我还不知道的是，这些交互的复杂程度到底是比人类现在能做到的更高，还是更低。
-
我见过一些人说，智能体生成的那种查询，或者说智能体生成的 SQL 查询，其实更浅，因为它可能一次只试着读一两张表，弄清楚里面有什么；而如果有人用仪表盘或者 BI 工具，
-
比如 Tableau 或 MicroStrategy，它可能会在不同的表之间做非常复杂的关联。
-
我还不知道智能体是不是已经达到那个水平，还是说它们只是就那么直接去做。
-
用更简单的方式从数据库里读数据。
-
所以你的问题是，智能体会不会改变现状？我觉得会。
-
眼下，肯定是在查询量上。
-
而且我觉得这个量还会进一步增加。
-
当然，现在智能体运行的时候，它们会生成自己的遥测数据。
-
所以你得把它存起来，还得把它弄明白。这又是另一个挑战。
-
但至于它们实际做事的模式目前到底有多大不同，这还有待观察。
-
这也是我正在研究的事情。
-
是啊，里面有些非常棒的内容，我一会儿还想再回来聊。
-
但智能体记忆这个概念，现在好像有点成了战场，一边是文件系统，另一边是数据库。你怎么看？文件系统是什么？它就是个数据库，对吧？什么都是数据库，对吧？
-
你有一个目录，还有一堆 Excel 文件。
-
那就是个数据库，对吧？
-
你有笔记本、铅笔和纸。那就是个数据库。
-
我女儿三岁的时候，我们就在试着教她数据库有多重要。
-
我会让她写下来，我们会一起做。
-
我们每天会在一个小横线本上记下温度。
-
然后她会把它合上，再去提交，把数据保存下来。
-
那就是个数据库，对吧？
-
说到底，现在关键就在于你想给智能体提供的输入或者上下文到底是什么形式。
-
据我所知，这些全都是人类可读的文本，对吧？
-
所以，不管这些人类可读的文本是来自你目录里的一堆 JSON 文件，还是从某个数据库系统里提取出来、然后再被转换成正确的输入形式，说到底，这都不重要。
-
我觉得，当你用一个能保护数据的数据库系统时，显然能获得优势和安全保证。SQLite 在这方面就很有名。
-
你为什么非要用文件系统，还要自己操心写得对不对、安不安全，能不能做多次修改再提交，而不是直接看它自己能不能做到，对吧？
-
所以说到底，大家都应该把所有东西放进数据库系统里，对吧？
-
就连一些文件系统，比如 WinFS，在底层其实也是数据库系统，对吧？
-
对，之前还有一篇文章也火过一阵，我记得标题好像是《我不小心重新造出了一个数据库》，讲的就是文件系统。
-
好，有意思。
-
那像多智能体、子智能体、智能体集群这样的世界，是不是就更需要一个数据库？
-
意思是说，这听起来在计算上非常复杂，所以另一边有个极其重型的系统，似乎就说得通了？
-
说到底，如果你需要在这些智能体的多台机器或多个实例之间共享状态——不管它们是不是跑在同一台机器上——还是那句话，数据库管理系统能提供这种能力，让多个读取方去读取共享状态。
-
我还没见过有哪种情况是，智能体在做记忆查询的时候，会把过滤条件之类的东西下推到数据库里。
-
通常这些是作为上下文的一部分提供进去的。
-
还是那句话，这就又回到 RAG 或者基于向量的那套东西了。
-
你是根据自己已经在数据库文件或者数据库本身里针对记忆查到的内容，来提供上下文的。
-
所以还是那句话，据我理解，用来输入上下文的 API 就是人类可读的文本。
-
而不管这些东西是来自文件系统还是数据库系统，其实都无所谓。
-
但数据库系统能提供某些保证，还有一些可以说是奢侈的东西，而文件系统给不了这些。
-
而在多个智能体之间共享状态，就是其中之一。
-
你有没有看到智能体这个圈子在往某一种特定的数据库上收敛？
-
我的意思是，是指把它当记忆来用，还是说智能体在构建应用的时候，会选某一个特定的数据系统而不是另一个？其实两个都算，不过也许更偏后者。
-
后者嘛，很明显，模型是拿人们写的东西喂出来、训练出来的。
-
所以如果我说我要做个新应用，现在它大概率会推荐 Postgres。
-
因为预训练数据集里就是这些。我得说，我不能说是谁。
-
有两家数据库公司问过我，怎么才能让智能体优先推荐他们的数据库，而不是 Postgres。
-
我当时就想，这……首先，这不是我干的事，这不是研究。
-
第二，别来找我。
-
去找那些做模型的人。
-
这显然是能施加影响的地方。这基本上就跟 SEO 一样。
-
你怎么让智能体学会，嘿，我应该用我的数据库 X，而不是 Postgres？
-
我猜你写的东西被搜索引擎高度索引了，所以向你推销，其实就是在向模型推销。
-
这绝对是个第一世界问题，我不是想在这儿谦虚地炫耀，但我的确有个问题，就是我问数据库方面的问题时，它引用的全是我自己，因为我所有的课程材料——这多少应该挺有成就感的吧。
-
呃，不，但问题是，不，因为——比如说我教数据库课的时候，我会说，你给我看看，我想了解那些做这种索引的数据系统，B+ 树什么的。
-
然后我就得说，那我现在得说，我已经知道哪些是这么做的了，你给我看那些不这么做的。
-
然后我还得说，另外，别引用 Andy Pavlo，也别引用任何卡内基梅隆的东西。
-
但问题就是，我们的课程材料……
-
Amado 会不会回你一句，你知道，我知道你是 Andy，对吧？Chachmiede，对。
-
Chachmiede 其实会说，我知道你是谁。
-
我也说过类似的话，但 Perplexity 不会这么做。
-
但问题还在于，我们所有的课程材料都是开源的，所以谁都能直接拿去用。
-
然后它就会说，好吧，你不能引用卡内基梅隆大学。
-
那我就引另一所大学。
-
但那只是我的幻灯片被用在另一门课上。
-
所以我得特别具体地说明，哪些东西不要又被算回我头上。
-
所以我觉得，回答你的问题，对于 OLTP，我有一阵子没试过了，但它通常会回你一句：嘿，你应该用 Postgres。
-
除非你说得非常具体，比如说，哦，我要跑在嵌入式设备上，那它就会说，用 DuckDB，或者 SQLite，之类的；或者我只关心键值，那它就会回来说，用 RocksDB。
-
但说到 OLTP，它几乎总是说，用 Postgres，然后如果你继续聊下去，它可能还会建议，你要不要托管版本。
-
至于 OLAP，要是能看到有没有什么排名，会挺有意思的。其实这主意不坏。
-
也许已经有人做过了，但那个的话，它肯定会回你一个结果。也许你还得再细化一点，比如说，我的工作负载是这样的，我的数据是这样的。
-
然后我觉得它就能给出更细致的答案。
-
我大概有一年没试过这个了。但我以前肯定见过。
-
比如说，它会问，哦，你有钱吗？有。
-
好，那你就可以用 Snowflake 或者 Databricks。你没钱？好，那你就可以用 DuckDB。还是说你想本地部署？
-
那你就可以用 ClickHouse，之类的。
-
那么，你的第二个问题是关于智能体的。
-
那么，它们该推荐哪一个呢？
-
所以这就回答了它们到底推荐哪一个，但……是你本来应该推荐哪一个。
-
对，而且我们聊这个，有一部分就是在说速度这个问题，而这正是 ClickHouse 的强项，后面我们还会再聊 ClickHouse。
-
可能有个概念叫上下文层、本体论，看起来是在把大家往图数据库那边推。
-
那它们，到底有没有意义？
-
我是说，我对图数据库有很强烈的看法。
-
我不觉得你需要一个。
-
我觉得那可以。
-
我还没见过哪个基准测试能显示图数据库，原生的图数据库，比原来的数据库系统表现更好。
-
当那些关系系统在 SQL 或者 API 里有合适的机制，让你能在服务端做图遍历，而不用来回跑。
-
SQL 标准在 2023 年加入了属性图查询的支持。Oracle 支持它。
-
Postgres 本来今年应该支持它的。
-
它快出来了，Postgre 19。
-
但我觉得它被推迟了，或者被撤回了。我不知道为什么。
-
但这都不是重点。
-
不，我觉得上下文层，还是那句话，得看你的需求，你有多少智能体，多个智能体之间是不是共享状态，对很多这类事情来说，Postgres 常常应该成为第一选择。
-
对于 OOTP 来说，如果你是在做分析，那完全是另一回事。
-
我们来聊聊 MCP。好。
-
所以过去一年左右，好像每个人，每家数据库厂商都在自己的产品里加了一个 MCP 服务器。
-
你对此怎么看，比如优点和缺点。
-
而且我是从，你知道，一两年前那种整个从文本到 SQL 的运动过来的，当时每个人都想让 大语言模型s 在数据库之上工作，尤其是为了分析目的，但那玩意儿没怎么成。我们现在到那一步了吗？
-
所以，Text-to-SQL，就是把自然语言转成 SQL 嘛。
-
所以这事儿人们从 70 年代就开始尝试了，对吧？
-
然后每隔一阵子，可能就会出现某种自然语言处理上的突破。
-
人们就说，好吧，现在终于可以成了，对吧？但它一直没成。除了 大语言模型s 以外。
-
我觉得，我一直对学术文献和那些关于各种 Text-to-SQL 框架的研究论文持怀疑态度，因为很多时候他们展示的基准，比如 Spider 和另外几个，这些都是你知道的、模型训练时已经用过的著名基准。
-
所以它当然会把正确答案原样吐出来。
-
我昨天其实跟一个来自一家非常大的银行的人聊过，他说他们现在有一个 Text-to-SQL 接口，但最初实现的时候，他们用的是现成的东西，然后又在内部进一步优化了一点，但准确率大概只有 60%，
-
意思是说，大语言模型 或者那个智能体能生成正确的 SQL 查询，有 60% 的时候能给出正确答案。
-
这大致就是我在其他一些报告里看到过的情况。
-
但他说，通过提供更丰富的语义层、上下文层，花了好几年、好几百万美元才把这东西做起来，他们能把准确率提到 99.5%，这简直离谱。
-
我觉得现在这是可行的，只要你愿意投入时间，建好正确的语义层和你需要的信息上下文。
-
也就是说，模型或者说智能体得有足够的信息，才能从你问的问题里推导出正确的 SQL 查询。
-
我觉得，再说一遍，那是一家有无限资金的大银行，所以他们才能做成这件事。
-
我觉得如果你现在随便下载个东西，一个普通人会发现，这些现有工具根本达不到那种熟练度和准确率。
-
但这并不意味着我们到不了那一步，对吧？
-
那么现在，说到 MCP，也就是 Model Context Protocol，我明白他们为什么这么做了。
-
我觉得这东西是从 Anthropic 出来的，然后大家很快就把它当标准采纳了。
-
然后时不时就会有 Hacker News 上的帖子说 MCP 死了之类的。我不觉得它会消失。
-
它基本上就是一个 REST 接口，一种标准方式，用来规定从智能体发给你手头任何数据系统的请求应该长什么样。
-
然后那个收到 MCP 请求的数据系统，它的工作就是把它转换成正确的 API 调用，去取你需要的数据。
-
放到数据库系统上，就是去写 SQL 查询，把你需要的数据取出来。
-
但通常来说，很多时候它只是把传给你的东西做一个严格的转换，而不是去推导这个 MCP 请求的语义含义，因为 MCP 请求本身必须定义得比较清楚。
-
我对 MCP 没意见。
-
我只是觉得它不是那种能解决世界上所有问题的魔法球。
-
它只是多了一个接口，让你可以把不同的智能体和不同的系统对接起来，去取你需要的数据。
-
所以我完全支持它，因为这样你是在更多地用数据，而不是自己搞一套土办法。所以，是的，非常棒，挺好的。那它能改进吗？
-
我觉得它效率不高，因为你是把人类可读的文本通过网络发过去来取数据。
-
用二进制协议显然有更好的办法。
-
但说到底，它够用了。
-
而且它看起来已经成了大家都在用的标准。
-
那它该不该做你前面提到的那层安全层呢？
-
应该，但这跟传统应用客户端通过 JDBC、ODBC 这些网络协议、或者用终端连到这些不同数据系统发来的 SQL 请求没什么区别。
-
这跟从那边来的请求，和通过 REST 请求、通过 MCP 发来的请求，没什么区别。说到底就是：好，我收到了这些请求，那我得搞清楚是谁在问、想干什么、该不该允许他干。
-
就像我们之前说的那些护栏，不管是 SQL 进来的还是 MCP 进来的，都是一样的。
-
好，那这是对话的一部分，也就是数据库作为智能体的记忆层或者执行层。接下来我们把话题翻过来，聊聊 AI 能为数据库做些什么。
-
显然我们活在一个 AI 几乎什么代码都能写的世界里。
-
数据库也是这样吗？是的。
-
举个例子吧，我在卡内基梅隆大学教数据库系统这门课。
-
一年前，智能体还做不了我们整个项目。
-
我们的项目大概是这样：我们给你一个数据库系统的框架，然后你得去实现索引、查询引擎之类的东西。
-
它能做一部分，但不是全部。
-
我记得是 Opus 4，就是 Anthropic 去年发布的那个。然后局面一下子就打开了。
-
智能体基本上不需要什么提示，就能把我们所有的作业都做完。
-
当然，它有很多训练数据，因为我们所有的项目都是开源的。
-
它们全都在 GitHub 上，不只是卡内基梅隆大学的学生，校外的学生也一样。我们让他们用。
-
所以它们有大量训练数据可以用来实现各种东西。
-
所以我觉得，现在智能体基本上能实现你打造数据库系统所需要的任何东西。
-
当然，你得用正确的方式提示它，手把手带着它，确保你生成正确的设计，然后让它根据你想要的设计来产出实现。
-
说到底，我觉得智能体完全有能力去构建和做这些事情。
-
所以它们能构建出整个数据库。
-
所以，作为风险投资人，我构建数据库的经验是，这是一段长达十年的痛苦旅程，前三年几乎没什么进展，而世界上最聪明的一些人聚在一起，去解决每一次看起来都无法逾越的问题。
-
所以我们现在说，它能把整个东西都造出来。
-
是啊，数据系统领域有句老话：这得要十年，但它是一个系统。
-
你可以在三年里做出前 90%，然后剩下的 10% 要再花七年。
-
所以是啊，我觉得这些智能体非常能干，当然，得有足够的 token，再加上足够的引导，你就能用 vibe coding 搞出一个完整的数据库系统。
-
而且现在肯定有公司在这么做。
-
几乎每一家数据库公司都在用智能体帮忙开发东西。
-
所以我的一个副业项目是“数据库的数据库”，叫 dvdb.io。
-
我们现在做的一件事，就是追踪我知道的每一个数据系统。
-
对于开源的那些，我们每天晚上都会把 GitHub 上最新的提交拉下来，然后追踪哪些提交其实是 Claude 或 Codex 之类工具共同署名的；当然，如果人们把那个功能关掉，你就不知道它到底是不是生成的。
-
智能体，但大多数人不会那么做，而到了现在这个阶段。
-
我觉得超过60%的开源数据库系统都有来自智能体的提交，那么除了写代码，这是不是也适用于运行它们呢？
-
所以说到那个自动驾驶数据库的概念，我记得那大概是你10年前的一个大项目。差不多吧，对。Peloton。
-
对，那请带我们回顾一下这段历程：当年什么还做不到，而今天又变得可能了？
-
嗯，所以当年我刚到卡内基梅隆大学的时候，我做的事情之一，就是在最初几年去拜访公司，看看他们在数据库方面遇到了什么样的挑战。
-
而我反复看到的总体主题就是，光是运行、维护和优化这些系统，就已经是个巨大的难题。
-
而这对我来说并不是什么重大新发现。
-
几十年来，人们一直在尝试这么做。
-
我的意思是，从20世纪70年代关系模型和关系数据库出现以来，人们就一直在尝试对索引、分区键、分片键和调优参数搞自动调优。
-
微软研究院在2000年代初的AutoAdmin项目里做了大量工作，他们有一堆工具，可以管理并自动优化数据系统。
-
补充一下背景，这是因为数据库有成千上万种可能的配置。
-
对，比如说，我的表上该有哪些索引来加快查询？
-
而显然，如果索引太多，写入就会变慢，磁盘空间也会耗尽。
-
还有各种控制系统运行时行为的参数。
-
比如多少内存分配给一个内存池，多少分配给索引，诸如此类，对吧？
-
这已经超出了任何一个人靠推理能搞定的范围。
-
然后你再想想，如果你有成千上万个数据库，那根本不可能——任何人都管不过来这些系统。
-
所以我们花了一些时间研究如何用机器学习来构建自动化工具——放到现在你可能就会叫它AI了——但当时就是用自动化方法、机器学习技术来自动完成这件事。
-
我们大概有两条研究路线。
-
其中一条，是我们把数据库系统看成一种不透明的盒子，我们说，我们不能改它的内部。
-
系统暴露出来的那些API，我们能拿它们做什么？
-
所以基本上就是，怎么自动优化现有的数据库，比如MySQL、Postgres、Oracle这些？
-
然后另一条研究路线是，如果你从零开始构建数据系统，假设它将来会由机器学习工具控制，或者说现在所谓的agent来控制。
-
那你会怎么稍微不一样地设计这个系统？
-
我们从优化MySQL、Postgres里学到的很多东西，最后都放进了我们自己的系统里。
-
所以当时这些自动化工具面临的挑战，就是得有足够的生产数据库训练数据，还得能把你在优化某个部署时学到的东西用到另一个部署上。
-
就像我之前说的，大多数人会有一个预发布或开发环境，然后还有一个生产数据库。
-
所以你显然不会想在生产数据库上乱试，因为在你琢磨怎么调优的时候，那些乱试可能会拖慢速度、让性能变差。
-
所以你会先在预发布数据库上验证，然后再试着应用到生产数据库上。
-
但很多时候，硬件从来不一样，工作负载也从来不一样。
-
所以这是我们一直面临的一大挑战：就是得有足够的训练数据喂给模型，让它们能在生产数据库上做出好的决策。
-
然后大语言模型s出现了。
-
而那真的改变了你解决这个问题的方式，因为它们基本上都是拿网上能找到的博客文章、文档、最佳实践指南训练出来的，那些内容都是讲怎么调优这些数据库的。
-
所以在研究方面，我们发现大语言模型s在某些调优任务上能帮你走到大概85%的程度。
-
当然，总有些奇怪的边角情况，专门的算法可以处理。
-
但就像我们的模型，往往要训练好几个小时，假设你有足够的训练数据来产出最完美的、最优的配置，但大语言模型s只要15分钟就能进来，产出一个差不多够好的结果，而这对大多数人来说就够好了。那我们现在到了那一步吗？
-
我们是不是已经处在一个数据库基本上能自我调优、自我优化的世界里了？
-
我的意思是，答案是肯定的，因为这取决于你实际想要多大的提升。
-
就像我说的，大语言模型s能帮你完成85%。
-
是不是总能再榨出一点性能来？是的。
-
而且总有些人会在意这些细节。
-
因此，我们过去构建的那些自动化方法就会重要得多。
-
但对大多数人来说，其实，让我特别惊讶的一件事是，我们创业那会儿，试着给 Postgres 和 MySQL 做自动调优，结果发现有多少人用的就是亚马逊、谷歌这些云平台的开箱默认配置。
-
他们会说，哦，我们以为亚马逊在帮我们调优呢。结果，人家根本没有。
-
所以有足够多的人可能就在用 DLO 配置，那东西简直烂透了，千万别这么干，而这时候一个 大语言模型 就能来摘点低垂的果实，在短时间内给大家带来一些实实在在的提升。
-
所以在软件世界的其他领域，我们看到开发者的工作性质已经发生了深刻的变化。
-
如果你现在在 CMU 读书，对数据库的世界特别兴奋，那没错，你可以去 ClickHouse 或 Cockroach DB 这类公司工作。
-
但抛开这些，在今天这个世界里，智能体会去调用数据库、管理数据库，然后数据库自己还会自动驾驶，那还有什么工作需要深入的数据库知识呢？
-
所以我会说，我一直跟学生讲，在我的课上，就算你以后不会去当数据库系统工程师，比如去搞 ClickHouse、Cockroach 或者 Postgres 的底层，归根结底，每个人都会跟数据库系统打交道。
-
而如果你了解它们的内部、它们是怎么实现的、对于你给出的查询，数据系统会做什么、不会做什么，那你就能更好地理解这个世界，理解技术栈里发生的事情。
-
那，你需要上我的课才能搞清楚这些吗？
-
不，我要是这么想就太天真了，那些智能体已经把我所有的东西都吸收进去了，所以它们反正能把我教的内容都复述出来。
-
所以，但归根结底，不管你是从传统大学课程学的，还是自学的，或者有校友教你，如果你理解数据系统想做什么，那就能消除迷思和谜团，帮你理解你的应用里正在发生什么，
-
为什么你的查询跑得慢，或者为什么不慢。
-
你就更能理解到底发生了什么。
-
所以，如果你读了计算机科学或工程学位，专注在数据管理系统上，我觉得那种你自己从零开始写系统的时代，我要是觉得它还会继续存在，那就太天真了，但归根结底，
-
数据库公司仍然在招人来做这些事，因为总得有人去理解智能体实际在做什么，并且能搞清楚其中的门道。
-
但要完整回答这个问题，我们正在进入一个数据库的管理和部署方式里完全没有人参与的时代。
-
我会说，我们过去熟悉的传统 DBA 角色，我觉得会被边缘化，很多工作都可以自动化。
-
但这并不一定意味着这些岗位就会消失。
-
他们现在终于能去做更多更高层次的活动了。
-
数据建模始终很重要。而且再说一次，智能体也能做很多这方面的事。
-
但你仍然需要有人来搞明白：这个数据模型有没有真正体现我们组织或业务想在数据库里表达的东西？
-
所有这些事情仍然超级重要。
-
就像，还需要有人去调参数或者给表挑选精确的索引吗？我觉得这意思就很清楚了。智能体可以把这些全做了。太好了。
-
换个话题，数据库圈里的很多人，我猜基本上所有人都很熟悉你的工作。
-
但对不熟悉的人来说，你一直是CMU的终身教授。
-
你开过非常受欢迎的课。
-
我觉得你做的一件很漂亮的事，就是把你当时在CMU教的很多课程免费放到了网上。
-
我刚到卡内基梅隆的时候，是那里唯一一个数据系统方向的教授。
-
那里还有另一位教授，但他做的更多是图挖掘、数据挖掘这类东西。
-
所以2013年我开始的时候，我就想，好吧，我得想办法拿到终身教职。
-
竞争这个词不太准确，但我是在和MIT、斯坦福、伯克利竞争，而我是那里唯一做数据的人。
-
所以我就想，好吧，那就把所有东西免费放到网上，帮助推广我们的研究，以及我们想做的事情。
-
这也有个副作用，就是我会把课准备得更充分，因为我会——倒不是说我本来在家就准备得多好——但我会确保自己把东西都准备好，因为我知道这课会被录下来、被人看，因为我不想说错话。
-
而且我会表现得更专业。
-
我会少说些疯话，大家听我这么说都很震惊。
-
我的课，即使到现在，也被认为是掺了水的。
-
就连对他们来说，这也挺奇怪的。
-
所以是的，就是这样，而且很明显的好处是，不是每个人都能去卡内基梅隆大学。
-
学费可不便宜，那是私立学校。
-
不是所有人都能进得去，但为什么这种教育不能回馈给其他人呢？
-
所以这对我来说不花什么钱，我就把它放到YouTube上，让所有人都能看到。
-
我们在这段对话开头还拿Wu-Tang Clan开玩笑。
-
我好像在哪儿听说过或者看到过，说你上课一开始有个DJ在放Wu-Tang Clan。这是怎么回事？
-
这事儿是从2019年开始的。
-
我当时想，行吧，那咱们就玩点有意思的。
-
你知道，当你为了讲课架摄像机、弄这些东西的时候，显然得花时间去布线、把所有设备接好，对吧？总得花时间。
-
所以，学生们陆陆续续进来，盯着你看，气氛挺尴尬的，什么都没发生，也没人说话。
-
那我就找个DJ坐我旁边，全程在我边上打碟放音乐，对吧？
-
然后你知道，上课的时候你会跟他们聊起来，会发现他们的生活挺有意思的，比如有个人，有一堆前女友想跟他复合。
-
还有个人老把钱借给一些根本不该借的人。
-
所以我们就在课上聊这些。再加上数据库。大家都这样嘛。对，大家都这样。
-
然后我记得有一年，我开了个小玩笑，因为顶尖的数据库会议往往都在学期开始或者学期结束的时候，所以我得出去开会。
-
所以开学第一周，我就得出去参加一个会议。
-
但你不想取消课，因为第一周让学生知道这门课是怎么回事特别重要，他们正琢磨着要选什么课呢，所以我就远程把课录下来。
-
有一年我在洛杉矶开会，然后在那节课最后，因为是录播嘛，我说，哦对了，关于数据库你们最需要知道的东西，然后我就把Wu-Tang Clan第一张专辑的所有成员，再加上当时还在坐牢的Capadonna，一个个念了出来，我说，
-
这才是关于数据库你最需要知道的东西。
-
然后到了学期末，期末考试的第一道题就是：列出Wu-Tang Clan那张《36 Chambers》里的所有成员，再加上当时谁在坐牢。
-
而且拼写必须完全正确。
-
要是他们把那道题答对了，考试就能拿满分了。
-
对，不是killer，是killa。对，没错。所以有人就写错了。
-
他们漏了那个H，本来是该有的。
-
所以其实从来没人答对过。
-
我得说，这招不能再来一遍了，因为学生都等着呢。
-
好，太厉害了。
-
所以这就多多少少把我们引到了ClickHouse和ClickHouse Labs。
-
你最近加入了ClickHouse，要创办ClickHouse Labs。对。
-
那为什么要在一家商业公司办实验室，而不是在学术界做呢？
-
我是说，不深入谈政治的话，现在大学里做研究的处境挺难的。
-
美国的研究经费已经不比从前了。
-
还有一个更大的问题：现在一个智能体都能做很多事情了，那带一个博士生到底意味着什么，对吧？
-
当智能体也能产出东西，还能跟我这个教授一起写论文之类的，你还需要那么多博士生干活吗？
-
所以我还是——我是说，培养学生肯定仍然有价值，我也喜欢做，但我不太清楚的是，我该怎么筹钱，才能招到我想带的那么多学生呢？
-
后来呢，就有一些公司来找我，说，哎，你有没有兴趣离开学校，跟我们一起做点有意思的事？
-
嗯，但每次都有点像是，嘿，你要不要来我们这儿当个工程师，或者，呃，就是把我原本想在研究上做的事打了个折扣。
-
嗯，后来我跟ClickHouse的人聊了聊，那几乎好得让人不敢相信。
-
因为我当时就是，哎，你知道，你知道，他们说，嘿，来跟我们一起做研究吧。
-
我就说，行，但研究就是这么回事，你明白吧？
-
他们说，对对对，你就去干吧。
-
我就说，好吧，你们明白吧，就是事情不一定总能顺利成，因为这是研究，我也说不准。
-
他们说，行啊，太好了，就这么干。
-
这太疯狂了，因为你知道，他们虽然不是早期初创公司，但他们是一家创业公司。他们不是上市公司。
-
一般来说，至少数据库这个圈子里，你只会看到公司已经站稳脚跟之后才去建研究实验室，对吧？
-
而他们愿意冒这种风险，或者说能有这种奢侈，让我这样的人来做研究，这太了不起了，而且他们对此非常认真。
-
所以这个机会几乎好得不像真的，而且到目前为止，你知道，这事我已经干了两个月了，看起来还挺顺利的。
-
我现在算是处在一个观察期，正在过一遍、弄明白他们到目前为止做出来的东西，因为他们其实还没怎么发表或写过他们做了什么。
-
他们有一些博客文章，非常有意思，但他们做了一些很了不起的工作，我觉得这肯定不能算我的功劳。
-
但他们做了一些非常棒的工作，而我现在的任务就是帮他们把这些变成可以传播、可以发布出去给全世界的论文，同时也在启动一些更长远的、探索性的工作。
-
说清楚一点，哪怕我还在大学的时候，在数据库系统这个方向，我的工作也是非常偏应用的。
-
所以我不是在做那种没人懂、全世界只有十个人能看懂的理论工作。
-
而且它跟正在发生的任何事情都没有直接关系。
-
在ClickHouse，我想做的那类事情跟ClickHouse想做的事情是直接相关的。
-
不只是ClickHouse系统本身，而且现在他们也有Postgres的产品了。
-
我们过去在Postgres上做过一大堆东西。
-
现在我们可以开始看真实数据，试着把其中一些东西放进生产负载里，并帮人们把这些东西真正推出去。
-
所以对我来说，这特别让人兴奋，就是能产生直接的影响，而不是我写了论文，然后盼着有人过来把它拿走、采用我们做的东西；我们可以做研究，在真实工作负载、真实生产系统上评估一个想法到底好不好，如果确实有道理，那……
-
我们就能在很短的时间内把它推出去。
-
所以这一点对我来说太有诱惑力了，让我有了这个机会。好，太棒了。
-
既然聊到这儿了，咱们也稍微聊聊ClickHouse。先说明一下，我们FirstMark非常自豪是他们的投资方。
-
我记得在哪儿看到过，说2016年的时候，你担心ClickHouse可能只是个空壳子，因为它好得有点不像是真的。
-
你能给我们展开讲讲吗？
-
对，你知道，就像我刚才说的，嗯，我的数据库……我的工作，我觉得，作为一个研究者，就是要搞清楚外面还有什么别的东西，因为数据库真的是个特别有意思的研究领域，因为不光是我——再说一次，我用的“竞争”这个词很宽泛，没有贬义——但是，
-
你知道，但你其实是在和其他研究者竞争，大家都想把想法拿出来、发表出去，所以不光是我在和别的大学的研究者竞争，你还要和那些大科技公司竞争，微软、谷歌、亚马逊这些巨头，
-
再加上还有一堆创业公司，它们都有自己的数据系统。
-
操作系统创业公司没多少，但数据库系统创业公司一大堆，你作为投资人肯定也知道。
-
所以我的工作就是，每当有新系统发布，就去搞清楚它们和我的研究有什么不同，它们哪里做得更好，我能从它们解决目标问题的方式里学到什么。
-
所以当2016年ClickAlice发布、或者说亮相的时候，我就想，我知道构建一个数据库系统有多难，而这东西凭空冒出来，还带着所有这些能力，比如向量化执行、列式存储那些，
-
压缩方面的东西，还有compaction方面的东西。
-
这几乎让人觉得好得不像真的。
-
要不然，它就是fork了某个已经存在的东西。
-
但当时，2016年那会儿，还没有哪个开源的OLAP引擎能有所有这些能力。
-
所以这把我搞懵了。
-
所以我就直接以为它是假的。
-
结果呢，果不其然，它是真的，显然是真的。它有很多好处。
-
那这些好处都有哪些呢？
-
尤其是，它非常快。
-
而且它非常实时，为什么能做到这样？
-
为什么数据库通常会很吃力，尤其分析型数据库更是如此？
-
而它们又为什么能做到这一点？
-
所以我会说，ClickHouse 的架构，它的核心基础，按 2026 年的标准来看已经不算新了，但放到 2016 年，那肯定是很新的。
-
本质上就是你可以用这种列式布局来存数据，也就是把单个列的所有属性、所有数据连续放在一起，而像行存那样，你会把单条记录所有列的值连续放在一起。
-
像这样存东西，再用向量化指令和 CPU 在一条指令里同时处理多份数据，而不是像以前那样得做 for 循环，跑起来效率低得多。
-
还有内置的压缩机制，他们做日志结构存储的方式，就是先把一堆变更追加进去，因为你想尽可能快地摄入，然后最终在后台再做合并，用更高效的方式存起来。
-
这些核心架构里的很多想法，都来自 Snowflake 做的工作。
-
在 Snowflake 之前，还有一个系统叫 Vectorwise，或者叫 X100。
-
抱歉，应该说它以前是 X100，后来由 CWI 商业化成了 VectorWise，而 CWI 也正是 DuckDB 诞生的同一所学校。
-
所以，人们为这些列存系统、分析系统，还有实时分析系统开发出来的很多想法，其实一直在圈子里流传。
-
但在 2016 年，至少据我所知，没有任何开源的东西能把这些全都做到。
-
所以当 ClickHouse 一出来的时候，就像，嘿，我们把人们之前做的所有这些研究都做成了一整套东西，那真的很厉害，对吧？
-
从那以后，DuckDB 也有了类似的东西，还有阿姆斯特丹那帮人做的 Polars。
-
Firebolt 一开始是 ClickHouse 的一个分支，他们把里面一大堆东西重写了。
-
现在他们都有这些东西了，比如 Databricks 有他们自己的引擎版本。
-
所以每个人都有这种架构，它是基于 Snowflake 和 Vectorwise 所做的工作建立起来的。
-
但现在，还是那句话，2016 年的时候，这还非常新。现在这已经算是基本门槛了。
-
然后我觉得 ClickHouse 这些年来做得特别好的一件事，就是不断提升性能，并且扩展它实际能支持的工作负载。
-
那你看到的 ClickHouse 用例都有哪些？
-
从内部看，你看到客户都在用它做什么？
-
所以我觉得，回到智能体那块，智能体这块看起来也特别有意思，人们用它来观察这些智能体生成的信息、遥测数据，能够实时对它们做出反应，并对它们提问。
-
在金融市场里也有很多应用，比如欺诈检测，任何你想快速摄入数据，然后很快对它提问、问复杂问题，并且能在毫秒级而不是秒级拿到结果的场景。
-
同时做这两件事，让 ClickHouse 处在一个独特的位置。
-
而且 ClickHouse 一路走来，一直在扩展自己的产品组合，对吧？
-
所以它一开始是一个非常强大的 OLAP，后来被称为实时数据库，现在呢，它收购了 Langfuse，用来做 大语言模型 的可观测性，还收购了别的东西。
-
那从内部来看，你怎么理解这种演进？
-
我的意思是，这些全都合到一起吗？
-
我是说，有人问过我，你为什么要加入 ClickHouse？
-
再说，我才做这个两个月，这有点像，怎么说呢，就像你刚结婚，有人问你，你为什么选了你老婆或者老公？我会说，哦，因为他们选了我，对吧？但其实不止这么简单。
-
不，说实话，在我决定加入 ClickHouse 之前，他们在业务层面已经在做一些事情了。
-
就是说，这是 ClickHouse 这家公司，而不是 ClickHouse 这个系统。
-
他们在业务层面做的那些事情，如果我在经营一家数据创业公司，我也会做，而且他们确实在这么做。
-
比如提供 Postgres 服务，而不是只有一个，你知道，特别好的 OLAP 引擎，也不是从 OLTP 这个领域起步。
-
还有监控、可视化、可观测性这一整套东西，不只是面向传统 BI 或传统数据，现在也面向智能体和 大语言模型s，他们正在做各种事情，去扩展建立在自身平台之上的不同垂直领域。
-
对我来说，所有这些都说得通，而且都是沿着不同的轨道在推进。
-
也许可以顺势聊到 2023 年 6 月的数据库市场状况，我们已经零零散散提到过不少了，但还是把这些都串起来吧。
-
所以 ClickHouse 做的一件事，就像你提到的，就是增加了 Postgres 服务，一个托管的 Postgres 服务。
-
这看起来是一个很明显的趋势。
-
所以 Databricks 收购了 Neon，我记得 Snowflake 也做了一笔收购，去年收了 Crunchy。
-
分析型数据库和事务型数据库的这种融合，会是未来吗？
-
这背后是商业和业务上的考量，是为了能向同一个客户卖更多东西吗？
-
还是说，这里面有一种产业层面的产品逻辑？但这里有两件事。
-
就是说，一家数据库公司是不是应该同时提供一套开箱即用的交易型运营数据系统，再加一套 OLAP 系统？
-
或者说，至少它们是不是分开的系统，这可以再讨论；但该不该这么做？该。
-
我是说，回到 agent 能让你做到的事情上，显然维护这些东西仍然是个挑战。
-
但部署一套 Postgres 服务的门槛确实已经降低了。
-
我脑子里还有另一个猜想：对于一家从分析型数据库起步的创业公司来说，是先做分析型、之后再补上 OLTP 产品更好，还是反过来，一家 OLTP 公司之后再补上 OLAP 产品更好？
-
我觉得，再说一次，我知道我这么说有偏见，因为我在 ClickHouse，但你看 Databricks 做了什么，再看 ClickHouse 做了什么，对我来说，那似乎就是做这件事的正确路径。
-
如果你想新开一家数据库创业公司，先做分析，在那里获得增长动力，然后你再补上 OLTP 产品。
-
但我没法证明为什么。
-
因为从商业角度看，这似乎是更聪明的做法。
-
现在的问题是，好吧，你是不是应该有一个单一的 API、一个单一的界面，也就是一个视图、一个单一的逻辑端点，让人们可以在一个被视为单一数据库实例的东西上同时跑事务和分析，
-
还是说，你应该把它们做成某种分开的服务？
-
ClickHouse 现在就是分开的服务。
-
但它有一条快速路径，能把数据从 Postgres 那一边的 OLTP 侧取出来，送进 ClickHouse。
-
Databricks 今年发布的是他们为 LakeBase 推出的 LTAP 引擎，或者说 LTAP 那一套方案，你可以在 Postgres、LakeBase 或 Neon 上跑事务，
-
然后让 OLAP 引擎能够直接读取那些数据，这样你就不用像 ClickHouse 或其他系统那样，把数据存成两份。
-
所以这种思路并不新鲜：有两套引擎，但数据只有一份。
-
2010 年有一家之前的创业公司，叫 Splice Machine，我其实还给他们当过顾问，因为创始人那哥们是 CMU 校友，他请我去给他们做顾问。
-
但他们当时是，因为他们跑的是 HBase 加 Spark SQL，但他们只有一份数据，存在行存里。
-
我是说，从一开始就想要这种 HTAP 系统，或者说这种混合系统的人，挑战一直在于，你怎么，你知道，怎么去协调这样一个事实：有些数据可能还在行存里，而不是列存里。
-
而那些主要的商业厂商，比如 Oracle、SQL Server，他们会存两份，一份放在行存，一份放在列存，这就是所谓的 fraction mirror 方案。
-
而且它们有内部的机制来同步这些东西。
-
但挑战一直都在于，为什么这种混合方案始终没起来，是因为组织或者公司里，这两类不同工作负载的利益相关方，一直都想要属于自己的那个最好的东西。
-
比如 OLTP 团队，跑应用的那些人，运维这一侧，他们不想要一个事务处理还凑合、分析也还凑合的系统，他们想要最好的操作型数据系统。
-
而不管好还是坏，现在这个最好的就是 Postgres，对吧？
-
而“最好”并不总是从性能角度说的，被认为是最好的，可能有各种各样的原因。
-
分析这一边也一样，你不想要一个分析还凑合、事务负载也还凑合的系统。我想要最好的分析系统。
-
所以这一直是这些混合系统在商业上的挑战，在 go-to-market 上的挑战。
-
不过我觉得，Databricks 可能处在一个不错的位置，有潜力把这件事做成，因为他们已经在分析这一侧、机器学习这一侧和数据仓库这一侧有了这样的市场。
-
现在你只是再加上 OLTP 这一侧。
-
所以 ClickHouse 也有可能去走同样的路。
-
这就有点钻进数据系统架构的细节里了。
-
但我觉得大家一直都想要这个。
-
不过挑战往往并不只是纯粹的工程问题。
-
可能有组织上的原因，或者人的原因，让你做不到这件事。特别有意思。
-
那我复述一下，你可以把复杂性对用户隐藏起来，也就是说，你大概可以有一个 NLM，把你的查询直接翻译成一个 router。
-
但是，从根本的架构角度看，要把它们结合起来非常难。
-
而从组织的角度看，这可能也说不通，因为大家想要的是同类里最好的，而不是一个什么都凑合一点的。
-
但很多情况下，Postgres 现在就是同类里最好的。
-
所以把你的前端押注在一个跟 Postgres 兼容的 Postgres 部署上，也许就能绕过这个问题。
-
那再聊聊数据库市场里的其他部分吧，我们聊过向量数据库了。
-
那这算是看好还是不看好？怎么才算看好，怎么才算不看好？
-
就是说，这是不是一门值得投资的好生意？
-
还是说，既然现在几乎人人都能做向量搜索，它还能继续存在下去吗？
-
我以前当教授的时候，有一件事是这样的：你总会听到各种传言，说谁做得好、谁做得不好，而消息可能是从投资人、前员工、去实习的学生或者随便谁那里来的，也可能是他们去某些地方面试完回来带回来的。
-
所以你会从每个人那里得到一点信息，再拼凑出整个数据领域是什么样子。
-
问题是，现在我在 ClickHouse，所以现在我能看到所有东西。
-
作为投资人，你也什么都看得到。
-
据我所知，做得很好的向量数据公司只有一家，就是 TurboPuffer。
-
而且他们极其专注，专门做向量搜索，追求的是性价比。
-
而这个性价比比其他人好太多了，所以我不认为向量数据库会消失。
-
我觉得它们会以两种方式演变：要么必须变成像 Postgres、像 MySQL 那样的通用系统，你知道，成为记录系统，
-
也就是你在里面存原始元组，再加上它们对应的向量嵌入。
-
要么它们变得像 Elasticsearch 那样，作为一个独立的系统存在。
-
它们会有一份从运营侧拉过来的数据副本。
-
在这种情况下，它们就能比较舒服地作为你额外添加的东西存在下去。
-
而且如果你想要向量搜索最原始、最强的性能，有些情况下你可能就得用这些专门的系统。
-
所以我觉得这不会消失。
-
我只是不觉得——我见过一些预测，说什么，哦，Postgres 会死在向量数据库手里。
-
这不会发生，这不会发生。情况恰恰相反，对吧？
-
图数据库，我们一开始提到过，所以，你知道，不是要贬低它们，但像 Neo4j 现在已经存在 20 年了。当然，是的。
-
而这本该是图数据库、AI 的高光时刻，对吧，那现在到底是什么情况？
-
我说，我在 Hacker News 上跟人有个还没了结的赌约，他说到 2030 年，图数据库市场会超过比它更大的关系型数据库市场。
-
如果这事成真，那我就穿一件写着“我爱图数据库”的 T 恤，还拿它当我的驾照、我的大学证件，把它放到我网站上，直到我死那天，对吧？
-
我挺有把握的，现在是 2026 年，还剩四年，这不会发生。
-
不，它一直就是个利基市场，而且我觉得，因为我是从研究角度看问题，研究表明，如果你在实现引擎时做一些特定的事——ClickHouse 确实这么做了，DuckDB 也做了一部分——有些做法能让你做图的遍历，
-
这本质上就是连接，是表上的自连接。
-
你可以把这些东西实现得非常非常高效。
-
而且你可以轻松超过 Neo4j。这有点太欺负人了。
-
Neo4j，说你自己比 Neo4j 快，就像说，你知道，我比某个坐轮椅的人跑得快，对吧？你确实能跑得快。这有点胜之不武。
-
但我只是说，所有图数据库，我觉得，哪怕是最好的那些，你也根本不会……
-
如果有个系统把研究里的这些优化做了一大堆，而且现在有些系统里真的开始出现了，那你就会输。
-
如果你做图遍历是在客户端和服务器端来回跑，那你就会输给图数据库，也就是说，我得先搞清楚下一个要看的是哪个节点，再回到客户端，然后决定下一个要遍历的节点。
-
如果你那样来回折腾，是的，他们会把你们打败。
-
但就像我说的，SQL 标准现在支持属性图查询。Oracle 有这个。
-
他们曾是把这个扩展推进 SQL 的一大推手。
-
它让你可以在服务器端做这种遍历。
-
所以图数据库，我觉得，是个糟糕透顶的主意。
-
根本没有任何理由让人真的想去用它们。
-
GPU 数据库。
-
我知道你对那块有特别的兴趣。
-
曾经有过一个循环：一代产品出现了，然后又消失了。
-
这看起来像是一次复兴。
-
GPU 数据库是什么，你的预测又是什么？
-
所以 GPU 数据库是一种数据中心系统，查询的执行端全都甩给 GPU 来跑，GPU 要么通过 PCIe 来跑，要么在同一个机箱里，要么在另一个机箱里。
-
我的意思是，人们想给数据系统造加速器的历史，可以追溯到数据系统刚出现的时候。
-
20 世纪 70 年代，它们被称为数据机器，所以人们会造专门的硬件来跑排序和查询执行算子，而这些东西显然在 80 年代初就消亡了，因为等你设计并制造出新的专用硬件的时候，
-
Intel 或 Motorola 就会推出下一代 CPU，或者硬件变得更好，而你原本能获得的那些收益就消失了。
-
所以数据库的硬件加速器基本上在 80 年代就消亡了。
-
90 年代、2000 年代没有太多动静，后来你看到有人开始尝试用 FPGA 做数据库，而现在这东西时不时又会冒出来。
-
有些云厂商会做一点这类事情，但通常是在 NIC 上做过滤，也就是在网络进来的那一侧。
-
所以 GPU 数据库这边，2010 年代又有一堆系统在尝试这件事。
-
我们在大学里办过一系列研讨会。
-
我们邀请了所有做 GPU 数据库的人来演讲，聊聊他们在做什么、做得怎么样，还有为什么他们比现有系统更快。
-
而当时最大的挑战是，用那些系统，你得把整个数据库都放进 GPU 内部的内存里，因为如果你得再通过 PCIe 传回去，那就太慢了。
-
那些创业公司里有一堆就慢慢熄火了。
-
有些现在还在，但它们是专门做可视化的。
-
然后，大概在过去一年左右，NVIDIA 基本上吞掉了一堆这样的 GPU 数据库公司，这些公司本来都在勉强撑着。
-
我以前是其中一家叫 Voltron 的公司的顾问，但他们也拿下了 HeavyDB，所以 NVIDIA 现在正在全力押注这件事。
-
所以，像长期来看，“你要建一个纯 CPU 的数据系统”这个想法到底还站不站得住，还有待观察。
-
再说一次，我听到的说法不一，而且这事儿是公开的。
-
微软呢，你知道，他们现在在云上已经有产品了，可以让你的数据系统在做分析的时候用 GPU 来加速。
-
还有一家主要的数据库公司，我不能说是谁，他们看了 GPU 的经济性之后，觉得不划算。
-
所以，我以前的一个学生现在在威斯康星大学当教授。
-
他现在正在 NVIDIA 休学术假。
-
他们有个项目叫 SirusDB，它不一定是新的数据系统，而是介于现有系统和 CUDA 之间的一个层。
-
所以它支持，你知道，把 DuckDB 的查询放到 GPU 上跑。
-
我觉得他们在 Doris 或者 Starrocks，还有 Data Fusion 里也能做这个。
-
所以在 ClickHouse，我们也一直在考虑这个方向，但这还只是研究。
-
我不知道，有意思的是，你得在 ClickHouse 期望的方式和 CUDA 想要的方式之间做多少转换，数据布局之类的。
-
你怎么在这些不同组件之间组织内存，或者共享内存？
-
这事儿到底是不是真的说得通，还有待观察。
-
但可以肯定的是，这背后有很多研究和投入。而且这个我可以公开说。
-
NVIDIA 显然在推这件事，因为这样能卖出更多 GPU，对吧？
-
因为现在想搞到新的 CPU 本来就够难了。
-
大家都卡在算力上，或者内存很难搞到。
-
计算硬件现在非常贵，也很难拿到。
-
在 GPU 这块，偏偏它又是所有硬件里最难搞、最贵的，现在你却说你的整个数据库都要靠 GPU 来跑？
-
我不知道这说不说得通，至少短期来看是这样。
-
但如果性能提升相当显著，而且有些研究确实表明是这样，那也许就说得通。
-
有没有什么新兴的类别，或者某个类别里有个细分领域，是大家还没怎么谈到的？数据库这方面的？对。
-
我是说，你当然总能为新硬件去搭新的数据系统，可我在这一块的历史战绩实在太差了——我们做过一堆针对实验性硬件的研究，结果每次都被砍掉。
-
而且那甚至都没那么实验性。
-
就像英特尔之前有那个叫 Optane 的持久内存。
-
我们围绕那个做过一大堆构建系统的研究。
-
如果你假设现在你的 DRAM 是持久的，那你把插头一拔，什么东西都不会丢。
-
这会从根本上改变你构建一个数据系统的方式。
-
我们在这方面做了很多工作，然后英特尔就把那条产品线给砍了。
-
我们当时还在研究另一种处理和内存硬件，就好比是 CPU 核心直接放在 DIM 上的 DRAM 内存条。
-
所以数据系统现在就可以说，好吧，我不用再把东西从内存里拉出来、送进 CPU 缓存再计算，我直接把查询发到 DIM 本身，在那儿执行就行了。
-
我们当时在这个叫 Op-Mem 的东西上做了很多工作。
-
那个后来被高通买走，去年又被砍掉了。
-
所以那事儿也没成。
-
所以围绕数据系统或者新硬件，总是有一大堆你可以做的工作。
-
我得说，其实我也不知道答案，对吧？
-
这是我正在试着搞明白的其中一件事，刚才忘了点退出了。
-
所以，就像，你知道的，我们最开头就聊过这个。
-
比如说，智能体工作负载，跟现在人类或者现有应用做的事情，真的有那么大不同吗？
-
如果是的话，那为什么，或者是怎么个不同法？
-
那你能不能，或者说你会怎么去改变一个新系统的开发方式，好更好地利用这一点？
-
那到底会怎么样，你知道的，这到底怎么运作，还得再看。
-
我觉得查询优化里总是有一堆问题，我觉得这些挺有意思的。
-
这仍然是数据系统里最难的部分。
-
增量物化视图，也是另一个大挑战。
-
再说了，但这些并不是没人想过的东西。
-
人们已经尝试做这些事情几十年了。
-
所以我觉得，AGNX 这块现在对我来说可能是最有趣、最相关的东西，就是，这些工作负载会带来什么变化？
-
系统架构里会有什么变化？
-
而且说实话，我不知道答案。我还没看到。
-
我问这个是因为，整体感觉数据库市场正处在其历史上的一个特定时刻，意思是 2010 年代有一波活动爆发，有 SQL 对 NoSQL，那一整套演进。
-
然后出现了 Databricks、Snowflake，现在是 ClickHouse，但就爆发这一点来说，好像有点慢下来了。
-
我猜，你知道的。你是说，停滞了？
-
对，但这种趋势我们以前也经历过，对吧？
-
关系型数据库也有过很多活动，1970 年代、1980 年代，然后到 1990 年代，又是，人们有点，你知道，市场差不多就围绕这些大企业固化了，Oracle、IBM、Teradata，
-
那如果你对数据库的唯一视角来自那种公司，那确实，看起来它已经停滞好多年了。但就像你说的，2000 年代、2010 年代有很多活动，我是说，跟 AI 一比，那一切看起来都停滞了，因为在计算机科学的历史上，
-
以前从来没有过像那样的东西。
-
就像，你知道的，抓一只猎豹，给它喂一堆可卡因，然后把它塞进一辆法拉利里。
-
就像，人们开发这些东西的速度快得离谱。
-
所以跟那个一比，一切看起来都慢、都死了、都停滞了。
-
但说到底，我觉得量会非常重要。
-
我觉得有一个问题是，就像你说的成本和效率，尽量把你现有的硬件能榨出来的最好性能榨出来，试着把那成本降下来，这永远是一个你可以去追的有意思的挑战。
-
但就像，说到底，我不觉得数据长什么样会有巨大变化，大到要我们把对数据库已知的一切全部扔掉。
-
同样地，你不会搞出一套全新的算术或数学概念，来取代一加一等于二。
-
关系模型本身就是你想怎么表示数据的基础。
-
只是说，它的实现方式可以千变万化。
-
所以肯定有很多工作要让这些系统在这方面更高效，但我不觉得你会把一切全都扔掉，也不觉得那些代理需要一种你现在根本想象不到的数据系统。
-
你知道，放在过去，这说不通。所以我不觉得那部分会变。
-
我觉得，就像我说的，总是会有新硬件。
-
我觉得 SQL 肯定还有可以改进的地方。
-
总会有人试图取代 SQL。
-
我觉得那可能是个徒劳的事儿。
-
虽然 SQL 最后可能也会变成那样，就像，你知道，人们现在都不再写汇编了，SQL 可能也会走到那一步，因为 Text-to-SQL 效果太好了。
-
我觉得智能体这些东西特别有意思，而且在我看来，把性能做得更好永远会是一个有趣的挑战，就是我们可以去追的事情。
-
你可以想象一个很疯狂的世界，在那里你说：我不再需要通用型的数据系统了。
-
对每一个单独的应用，我都想直接 vibe code 出一个数据系统，就专门为这一件事服务。
-
然后它就能做到极度专用化。
-
你现在其实就在某种程度上这么做，用代码生成，或者只是对查询的某些部分做 JIT 编译；有些系统已经这么做了，比如 ClickHouse、Postgres，还有德国人做的 Umbra。
-
但是极度专用化，以及怎么让它能持续下去，可能是接下来更大的一个研究问题。
-
所以我不知道这算不算一种矛盾的情况，但一方面，现在这个行业在演进方面确实有点停滞。
-
但与此同时，就像我们希望已经通过这场对话说明的那样，这一层本身比以往任何时候都更重要，这也是为什么你的朋友 Larry Ellison 一直离世界首富很近，或者说曾经很近。他曾经是。
-
他掉下来了，截至今天，他又跌回第八名了。
-
Oracle 远不只是一家数据库公司，但数据库仍然是它的核心产品。
-
我的意思是，它的总部就是数据库的形状，所以……对，对。
-
但没有什么比这更能说明数据库的根本重要性了。不过我得说，没人真的在认真尝试取代 Linux，对吧？
-
我的意思是，确实有面向不同环境、不同硬件的专用操作系统，诸如此类。
-
但没有人试图大规模地彻底取代 Linux。
-
FreeBSD 那个，比伯克利的 BSD 出现得还早。
-
它比 Linux 还早，所以它现在还在。
-
但数据库不一样，总有人觉得他们能做得比别人好，总有新想法冒出来。
-
所以我不会说它是停滞的。
-
我只想说，短期内很多精力会集中在 Postgres 上。
-
而且有些事情是我们可以做来改进它的。
-
但与此同时，我仍然认为会存在这些专用引擎。
-
我也不知道下一个工作负载会是什么。
-
再说一次，我不觉得 agentic 工作负载有什么本质上的不同，因为它们建模的东西，就是人类设计应用的方式。
-
比如向量查找，那跟过去的东西确实很不一样。
-
你需要额外的算子。
-
你不需要额外的索引来做那些事情。
-
说不清楚会不会……我也不知道下一件事是什么，但肯定会有新东西。总会有的。
-
那也许就以这个收尾吧。
-
所以未来五年，我们不一定要知道那会是什么样子，但与此同时，这是不是意味着现在的公司，比如 ClickHouse 这样的，只要继续做得更好、地位更稳固就行，因为根本需求还在，而且没有新一波小的创业公司冒出来。
-
不过你说“更好”，这里面其实有两种理解。
-
一种理解是，现有的查询能不能跑得更快？
-
对，Clickhouse 还有改进空间。我们可以把它做得更好。其他系统也能做同样的事。
-
但就像我说的，从高层看，Clickhouse 现在做的事情在架构上，跟 Snowflake 在 2013 年做的很相似。
-
Databricks 基本上也在照抄一些已经有的想法。
-
大家都在做同样的事，至少在做分析这块是这样。
-
而真正重要的是——这也是 Snowflake 做对的地方之一，是它成功的一部分——是数据库系统周边的东西，比如用户界面、开发者体验，比如怎么把数据灌进去、跟其他东西互操作，这部分他们做得非常好。
-
所以差不多可以说，围绕数据库管理系统这个根基搭起来的那套脚手架，其实非常重要。
-
而且 Clickhouse 实际上还在做的一件事——这对我来说不算研究——是他们随着时间越做越好的一件事，也能帮助扩大这个系统能用来做什么的范围。
-
所以系统的核心内核，那当然可以改进，但 Clickhouse 做的事情和其他系统相比，在最底层其实相当相似，只不过围绕着它的那些东西非常重要。
-
我觉得 Clickhouse 有些事做得很好，也有事可以做得更好；Snowflake 有些事做得很好，也可以做得更好；Databricks 和其他那些玩家也一样。
-
好，谢谢你花时间跟我们聊，也恭喜你这份算是新的工作——你还用说唱类比描述过，对吧，当时是在哪儿说的来着？
-
我的意思是，这就像 Run the Jewels，就像把 LP 和 Killa Mike 凑到一起。
-
那两个人本来就是各自成名的。
-
你把这两个人放到一起，你知道，这就像人们第一次把花生酱和果酱放在一起，对吧？
-
所以我喜欢把我和 Klikowsky 的组合想成那样。
-
好吧，那现在正式记录在案，这是 Mad Podcast 史上嘻哈梗最多的一集。
-
所以我很高兴你在那篇博客文章里找到了这个。
-
那是我的……那不是在测试。
-
那是我的……因为你知道，我写那篇博客文章，是因为我先把话抛出去，想看看 Clickhouse 能不能接受，也看看 Larry Ellison 在里面会怎样，但就像，你知道，我想看看，嘿，你知道，如果你要得到 Andy，你也会一起得到其他别的包袱，好吧。
-
我就知道这期会特别精彩。太感谢了。没错。谢谢你，Matt。
-
祝你有美好的一天。嗨，我是 Matt Turk，又见面了。感谢收听这期 Mad Podcast。如果你喜欢，而且还没订阅，希望你能考虑订阅，或者在你观看或收听这期节目的任何平台上留下好评或评论，我们会非常感激。
-
这真的能帮我们把播客做得更好，也能请到很棒的嘉宾。
-
谢谢，我们下期再见。