編譯 | Tina

“如果今天重新開始，我不確定還會不會建議 18 歲的人去學計算機?！?/p>

說這話的人，是數(shù)據(jù)庫領域的圖靈獎得主 Mike Stonebraker，中文常譯作“石破天”。他是 Ingres 和 Postgres 背后的關鍵創(chuàng)造者，也是數(shù)據(jù)庫領域最重要的人物之一。在他看來，計算機科學未來很可能不再是一個增長型行業(yè)。

這期訪談里，Stonebraker 把半個數(shù)據(jù)庫行業(yè)都點名罵了一遍。

他罵 Oracle，直接說 Larry Ellison 當年是在“撒謊”：把還沒實現(xiàn)的功能賣給客戶，把未來說成現(xiàn)在，然后讓第一批客戶幫自己 debug。

他罵 Google，說 Google 當年推 MapReduce 和最終一致性，是“愚蠢”的。很多人只是因為“Google 很聰明”，就盲目相信它一定知道自己在干什么。但在 Stonebraker 看來，Hadoop 低效得離譜，最終一致性也只適合極少數(shù)場景。等到 Spanner 出來，Google 自己也等于承認了：事務、一致性這些數(shù)據(jù)庫老問題，根本繞不過去。

他也罵 AWS：Amazon 同時維護大概 15 種數(shù)據(jù)庫，而他認為真正需要的可能只有 3 種。圖數(shù)據(jù)庫、各種重復功能的數(shù)據(jù)庫，在他看來，很多都沒有足夠性能和市場理由繼續(xù)存在。

但更有意思的是，他對今天這波 AI 的看法。

在他看來，現(xiàn)在所謂的 agentic AI，本質上是“大模型 + 一層系統(tǒng)包裝”，而且大多數(shù)還停在“只讀”階段。一旦進入真正的“讀寫”世界——比如轉賬、庫存更新——問題立刻回到數(shù)據(jù)庫的老問題：事務、一致性、原子性。這不是 AI 問題，而是分布式數(shù)據(jù)庫問題。

還有一點，是他對大模型寫 SQL 的判斷。

在公開 benchmark 上，模型已經(jīng)能做到 80%+ 的準確率，看起來只差一步就能上生產。但在他們用真實數(shù)據(jù)倉庫做的測試里，結果是——0%。即使加上 RAG、甚至把 join 條件直接喂給模型，最多也只能到 35%。而一個熟練的人類工程師，可以做到 90% 以上。所以他直接下了一個結論：這項技術，至少在可見的未來，還不夠格進入生產環(huán)境。

下面是完整訪談。

1 Postgres：最好用的起點，不是終點

主持人：我想先從 Postgres 的起源講起。不過在那之前，我更想從最開始問：你是怎么進入數(shù)據(jù)庫這個領域的？

Mike Stonebraker：我畢業(yè)之后，很幸運被伯克利錄用。當時我很清楚，如果繼續(xù)做我博士期間的方向，是沒什么前途的，無論當時還是現(xiàn)在都是如此。最好的路徑，是找到一個真正懂行的導師帶你入門。

于是 Gene Wong 把我?guī)г谏磉?，說我們一起做點東西吧。那是 1971 年，也就是 Edgar F. Codd 在 CACM 《美國計算機學會通訊》發(fā)表開創(chuàng)性論文后的第二年。

Gene 說，不如我們研究一下數(shù)據(jù)庫。當時主要有兩個陣營：一個是 Codasyl 提案，你可能沒聽過，它是一個低層的“意大利面式”網(wǎng)絡結構，你需要通過指針去遍歷執(zhí)行查詢；另一個是 IBM 的方案，也就是 IMS，是一種層次化的數(shù)據(jù)結構，本質是樹。

其實 IBM 當時也意識到，樹結構并不通用，無法解決很多問題，于是他們又加了一些擴展，把它改造成一種受限的網(wǎng)絡結構。但那明顯是個很糟糕的補丁。

Codasyl 也有很多問題：它非常底層，很難調試，而且一旦你的 schema（當時還不這么叫）發(fā)生變化，基本就得全部推倒重來，因為它完全綁定在物理層。

相比之下，Codd 的關系模型非常合理。所以 Gene 說，那我們就來實現(xiàn)這個吧，這是下一步該做的事情。于是我們在 1972 年開始做 Ingres，當時我還是伯克利的助理教授。你也知道，助理教授大概有五年時間證明自己，要么拿 tenure，要么被淘汰。Ingres 就是我拿 tenure 的關鍵項目，我在 1976 年拿到了終身教職。

事情就是這么開始的。后來又有一些機緣。當時很多人會做原型系統(tǒng)，基本就是學生作業(yè)級別的代碼——自己能跑，別人用不了。我們先完成了前 90%，能跑起來；然后不知道為什么，又花了額外的“90%”，把它真正打磨成一個可用系統(tǒng)。

伯克利版本的 Ingres 是真正能用的。接下來幾年，大概有 100 所大學開始用它，因為 Unix 開始流行。這是一個能跑在 Unix 上的免費數(shù)據(jù)庫系統(tǒng)，在學術界非常受歡迎。于是開始有很多人來伯克利參觀，說這東西很酷，你們最大的應用場景是什么？但我們只能說，其實并不大。

這個問題在 Arizona State University 的一個項目中被徹底暴露。他們考慮用 Ingres 管理 4 萬名學生的數(shù)據(jù)。他們可以接受用 Bell Labs 的非官方操作系統(tǒng)，也可以接受用我們這個“非官方”的數(shù)據(jù)庫系統(tǒng)，但最后項目失敗了，因為 Unix 上沒有 COBOL，而他們是一個 COBOL shop。

不支持的操作系統(tǒng)、不支持的數(shù)據(jù)庫系統(tǒng)，再加上沒有 COBOL——直接讓我們變得毫無相關性。

唯一的出路就是創(chuàng)業(yè)。于是 1980 年，我們拿了當時的風投，成立了 Ingres 公司，把系統(tǒng)遷移到 VMS 這樣的“真正操作系統(tǒng)”上，并提供商業(yè)支持，這就是商業(yè)化的開始。

主持人：我看到 Ingres 當時在和 Oracle Corporation 競爭。技術上你們明顯更好，但 Oracle 還是贏了，他們是怎么做到的？

Mike Stonebraker：Larry Ellison 是個非常厲害的銷售。他會把“現(xiàn)在”和“未來”講得毫無區(qū)別，本質上就是對客戶撒謊。

他會把還不能用的功能賣出去，然后讓第一批客戶幫他 debug。我認為這是一種很不正當?shù)纳虡I(yè)行為，對客戶撒謊是不可接受的。

舉個例子，有個功能叫“引用完整性”（referential integrity）。比如你開除了一個員工，而他是某個部門最后一個人，那你是刪除這個部門，還是保留一個“空部門”？類似這種邏輯。

Ingres 實現(xiàn)了這個功能。而 Oracle 當時的做法是：在手冊里寫兩頁文檔，解釋什么是引用完整性（大家都同意這個定義），但在頁面底部寫一句——“尚未實現(xiàn)”。

主持人：我采訪過 Sun Microsystems 的人，他們對 Ellison 的評價也差不多。還有一個說法是，當 Oracle 收購 MySQL 后，大家轉向了 Postgres，這也讓 Postgres 成為主流開源數(shù)據(jù)庫。那么，從 Ingres 到 Postgres，最大的變化是什么？

Mike Stonebraker：最核心的變化，其實來自一開始的一個需求。當年我們想支持一個 GIS（地理信息系統(tǒng)），需要處理點、線、多邊形等數(shù)據(jù)類型。但 Ingres 只支持整數(shù)、浮點數(shù)、字符串這些標準類型，沒法高效支持 GIS，所以在這個方向上完全失敗。

這件事一直在我腦子里。

后來還有一個例子。大概 1985 年，關系數(shù)據(jù)庫引入了日期時間標準，Ingres 按照標準實現(xiàn)了公歷時間。結果有個客戶打電話來說，你們實現(xiàn)錯了。

我說怎么會，我們完全按公歷實現(xiàn)的，日期計算也完全正確。他說，這不是我要的。他做的是債券業(yè)務，在他的世界里，每個月的利息是固定的，不管這個月是 28 天還是 31 天。也就是說，他的“日期減法”規(guī)則和現(xiàn)實世界不一樣。比如 3 月 15 日減 2 月 15 日，他認為是 30 天。但在 Ingres 里，這些邏輯是寫死的。他只能把數(shù)據(jù)取出來，在應用層計算，再寫回去，效率直接下降 2 到 3 倍。

他問我，為什么不能自定義減法？這就是問題所在。這是一個你需要“債券時間”的場景，就像你需要點、線、多邊形一樣。于是 Postgres 被設計成一個可擴展類型系統(tǒng)。你可以定義任意數(shù)據(jù)類型，而且運行效率很高。這就是 Postgres 最核心的思想。

當然，大多數(shù)商業(yè)場景用標準類型就夠了，但數(shù)據(jù)庫逐漸擴展到更多領域，比如抽象數(shù)據(jù)類型、存儲過程等，這些都需要擴展能力。

此外，Postgres 還支持繼承（當時 AI 研究者需要），也支持“時間旅行”（歷史數(shù)據(jù)查詢），不過實現(xiàn)得很糟糕，后來被移除了。但總體來說，它包含了大量非常有意思的特性。

主持人：你提到你很擅長招到優(yōu)秀工程師。你是怎么識別這些“非常厲害的人”的？

Mike Stonebraker：通常一眼就能看出來。我對“難度”是有感覺的。如果一個學生完成的工作量是我認為合理水平的三倍，那他就是非常優(yōu)秀。

主持人：你還有一句話挺有意思：“我受不了那些不夠聰明的人，很難和他們交流?！蹦悄阍趺磁袛嘁粋€人不夠聰明？

Mike Stonebraker：很簡單，跟他聊一會兒就知道了。你問他技術細節(jié)，比如他的碩士論文做了什么、具體怎么實現(xiàn)、錯誤處理怎么做、用了多少進程、為什么不用線程——你問這些深入的問題，很快就能看出來。

主持人：你之前提出過一個觀點，叫“One size fits none”，也就是“一套通吃的數(shù)據(jù)庫并不是最優(yōu)解，實際上誰都不適合”。

Mike Stonebraker：對，通用型數(shù)據(jù)庫系統(tǒng)并不是最優(yōu)解。所謂 one size fits all，實際上往往是誰都不適配。你真正需要的，是針對具體需求定制的數(shù)據(jù)庫方案。

主持人：那你現(xiàn)在看到的數(shù)據(jù)庫產品里，哪些還屬于這種“通用型一把梭”？

Mike Stonebraker：我在 2004 年寫那篇論文的時候，我們當時手上正好有一個學術項目，后來變成了 StreamBase。流處理引擎和關系型數(shù)據(jù)庫看起來完全不像一回事。與此同時，我們也已經(jīng)有了列式存儲做數(shù)倉的大致思路，后來由 Vertica 把它做火了，而列存和行存看起來也完全不是一類系統(tǒng)。

所以當時其實已經(jīng)擺在眼前了三種差異極大的實現(xiàn)，它們彼此幾乎沒有相似性，但在各自場景下，性能都比傳統(tǒng)方案高一個數(shù)量級。這已經(jīng)很能說明問題了。只要數(shù)據(jù)庫系統(tǒng)不是為你的場景設計的，你就會直接損失一個數(shù)量級的性能。

我覺得今天還是這樣。比如 ClickHouse 就是列存。Pinecone 在基于文本的向量處理上，也比那種用用戶自定義類型硬塞進去的方案更快。所以這件事到今天依然成立。我也不覺得在多個不同實現(xiàn)之上套一層統(tǒng)一 parser 有什么難度。只是 Postgres 到現(xiàn)在也沒這么做，它沒有真正實現(xiàn)列存，所以在大型數(shù)據(jù)倉庫場景里并沒有競爭力。它也沒有多節(jié)點支持，而對于大規(guī)模數(shù)據(jù)倉庫來說，這已經(jīng)是最基本的門檻能力了。所以我覺得，這件事今天和當年一樣成立。

不過，另一件同樣成立的事是，如果你只是想先把事情做起來，手頭有個數(shù)據(jù)庫問題，那答案通常還是選 Postgres。它有一個巨大的開發(fā)者社區(qū)，有各種各樣的數(shù)據(jù)類型實現(xiàn)，是免費的，也很容易招到懂 Postgres 的人，能很快啟動。

所以我認為，作為滿足最低通用需求的選項，它非常好。只要你不是要做到每秒一百萬次事務，也不是要支撐一個 PB 級的數(shù)據(jù)倉庫，它都完全夠用。也就是說，在低端場景里，那個“通用解”就是 Postgres，絕對沒問題；但到了高端場景，這個結論就不成立了。

2 索引一出現(xiàn)，GPU 就很難發(fā)揮作用

主持人：GPU 會不會給數(shù)據(jù)庫優(yōu)化帶來一些新的機會？

Mike Stonebraker：也許會。但我覺得最大的挑戰(zhàn)在于，GPU 本質上是 SIMD，也就是 single instruction, multiple data，單指令多數(shù)據(jù)。而這和索引恰恰是相沖突的。

只要索引是正確答案，GPU 大概率就不是一個好答案。

另外，你還得把整個系統(tǒng)架構好，確保從存儲到計算的帶寬不會成為瓶頸。如果 GPU 只是掛在 CPU 旁邊做個附加件，那很多時候 CPU 和 GPU 之間那條總線本身就成了瓶頸。

主持人：你能解釋一下，為什么在 SIMD 這種模式下，索引效果會變差嗎？

Mike Stonebraker：比如說，我現(xiàn)在要查 Ryan 的工資，我手上有一棵 B 樹。你先訪問 B 樹根節(jié)點，找到那個把 Ryan 分到某一邊的分隔鍵，然后沿著指針往下走，這就是一次確定無疑的內存訪問。接著再做一遍，再做一遍，通常要重復三四次。

這種過程是很難并行化的。所以答案就是，索引本身就不適合并行化。

主持人：你剛提到 B 樹。那你們最早實現(xiàn) Ingres 第一版的時候，這些東西都是手寫的嗎？我猜那時候應該也沒有現(xiàn)成的 B 樹庫可用吧？

Mike Stonebraker：對，Ingres 最早的版本全部都是從零寫的。

主持人：那里面最難實現(xiàn)的部分是什么？

Mike Stonebraker：查詢優(yōu)化器。

主持人：為什么它這么難？

Mike Stonebraker：因為它真的難。這東西在算法層面就很復雜。直到今天，如果你去問任何資深數(shù)據(jù)庫程序員，系統(tǒng)里最難的部分是什么，他們大概率還是會說，優(yōu)化器。

3 Google 是選錯了方向，Amazon 是選太多方向

主持人：MapReduce 在 2000 年代初出來之后，幾乎一下子席卷了整個數(shù)據(jù)領域。很多人都非常震撼，覺得 Google 真懂，覺得這就是最先進的東西。但看你當年的論文和觀點，你似乎非常不認同。你為什么那么強烈反對 MapReduce？

Mike Stonebraker：因為當時有很多其實并不怎么明白的人，會想當然地覺得，Google 很聰明，他們一定知道自己在干什么，所以我們照著做就行了。于是大家就開始搞 Hadoop，或者往 Hadoop 那套上靠。

但 Hadoop 的效率低得離譜。

當時像 Dave DeWitt，還有參與我們 2011 年那篇論文的其他人，我們都懂分布式數(shù)據(jù)庫，也知道用分布式數(shù)據(jù)庫系統(tǒng)可以把 Hadoop 打得很慘。我們 2011 年那篇論文基本上講的就是這件事。后來事實也證明，確實如此。

但 Google 做蠢事不止這一件。

他們當時還認為，eventual consistency，也就是最終一致性，是正確的并發(fā)控制方式。這在那個時期也是 Google 從上往下灌輸?shù)囊惶讝|西。但這根本不對。所有數(shù)據(jù)庫領域的人都在說，你們簡直瘋了，因為它只解決一種非常特定的問題，而且這種問題在真實世界里其實很少見。

主持人：那他們?yōu)槭裁磿プ非?eventual consistency（最終一致性）？

Mike Stonebraker：設想一下，你有一個東海岸數(shù)據(jù)庫和一個西海岸數(shù)據(jù)庫，它們互為副本，你希望兩邊保持一致。

如果我現(xiàn)在要做一個事務，把西海岸倉庫里某種商品的庫存減一，那在提交事務之前，我就得把這個更新同步到東海岸，再確認那邊也更新成功。然后為了確保整個提交真正完成，還要再來一次往返通信，確認兩邊都正確提交了。分布式提交就是這么貴，到今天也還是貴。

于是就有人想，那我只在西海岸先把庫存減一，然后異步發(fā)一條消息過去，不把它放在事務里，這樣東海岸那邊“最終”也會減一。

反過來，如果東海岸那邊也賣掉了一件，它也異步發(fā)消息過去，最后兩邊慢慢收斂成一致。

問題在于，如果系統(tǒng)允許庫存降到 0 以下，那就會出現(xiàn)一種情況：東海岸和西海岸的人同時賣掉最后一件貨。最終系統(tǒng)里的庫存就會變成負一。也就是說，有一個人最終拿不到貨。

如果你像 Amazon 一樣，可以說“通常 24 小時內發(fā)貨”，那你也許還能接受一定程度的超賣。但大多數(shù)企業(yè)做不到。所以 eventual consistency 根本行不通。

我們很久以前提到過 referential integrity，參照完整性。其實在銷售系統(tǒng)里，也有類似的完整性約束，比如“庫存必須大于等于 0”。而 eventual consistency 在這種約束下就是會失效。

后來 Google 的 Jeff Dean 終于也意識到了這個問題。等他們做 Spanner 的時候，Spanner 用的就是傳統(tǒng)事務系統(tǒng)。也就是說，Google 后來徹底放棄了 eventual consistency，也徹底放棄了 MapReduce。

主持人：所以本質上的權衡，就是用正確性換性能？

Mike Stonebraker：對，就是性能和數(shù)據(jù)完整性之間的權衡。如果你根本不在乎你的數(shù)據(jù)，那你當然可以接受這些糟糕的后果。

主持人：那 Google 當年做這些你認為明顯錯誤的事情時，你有沒有和他們團隊交流過？

Mike Stonebraker：我們在 2011 年那篇論文之前找他們聊過。我們說，要不要合作做點東西？但他們沒興趣，直接拒絕了。

主持人：除了 Google，你在別的大科技公司身上，也見過類似你明確不認同的數(shù)據(jù)庫方案嗎？比如 Amazon 或 Facebook？

Mike Stonebraker：我大概三年前去 Amazon 做過一次演講，當時我把我認為他們做錯的地方全都講了一遍。

我覺得 Amazon 的問題在于，他們同時支持大概 15 種不同的數(shù)據(jù)庫系統(tǒng)，而這大概多了 12 種。

我覺得這和他們自己的文化有關。我當時就跟他們說，你們支持的數(shù)據(jù)庫種類太多了。但到現(xiàn)在為止，他們也沒有決定淘汰任何一種。

主持人：為什么你覺得 15 種應該縮到 3 種？

Mike Stonebraker：因為他們支持圖數(shù)據(jù)庫，而大家其實早就知道，圖數(shù)據(jù)庫幾乎從來都不是性能最優(yōu)的方案。

如果你喜歡圖那種節(jié)點和邊的用戶界面，沒問題。你完全可以在關系型數(shù)據(jù)庫上面加一層，把這種用戶模型提供給你。

他們現(xiàn)在很多數(shù)據(jù)庫系統(tǒng)，其實都有別的數(shù)據(jù)庫在做同樣的事，而且做得更好。所以結論就是，那些性能不夠好、市場規(guī)模又不足以支撐維護成本的數(shù)據(jù)庫，都應該被淘汰。

主持人：你一直以學術界的身份，對整個行業(yè)產生了非常大的影響。我有一個問題一直很好奇：你為什么不直接去工業(yè)界工作？比如去 AWS 之類的公司，做一個資深的 distinguished engineer，不是也一樣能施加影響嗎？為什么你更喜歡待在學術界，用現(xiàn)在這種方式發(fā)揮作用？

Mike Stonebraker：因為那樣你就會有老板。你會被公司的規(guī)則束縛，發(fā)表論文會受限制，去會議上演講會受限制，連去研究競爭對手在做什么也會受限制，因為很多東西公司不會愿意讓你對外談，尤其不會愿意讓你去碰競爭對手不想公開的事。

不過更重要的是，我真的很喜歡待在創(chuàng)業(yè)公司里。Postgres 的商業(yè)版后來被 Informix 收購之后，我曾經(jīng)在 Informix 兼職工作。那是一家兩千人的公司，我完全感覺不到自己能帶來什么變化，因為那里充滿了官僚氣，基本上總裁想怎樣就怎樣。

所以我覺得我大概不適合那種環(huán)境。我不擅長搞辦公室政治，也不擅長和那些我覺得不聰明的人打交道。所以歸根結底，我和大公司確實有點合不來。

4 把 Linux 上半部分，換成數(shù)據(jù)庫

主持人：我想聊聊 Deboss。我覺得這是個很有意思的技術模型。你能不能解釋一下，Deboss 到底是什么？

Mike Stonebraker：這個學術項目大概是 2019 年、2020 年左右開始的。它的緣起，和 Matei Zaharia 有很大關系。他當時既是斯坦福的教授，也是 Databricks 的聯(lián)合創(chuàng)始人，還是 Spark 最早的作者。

他說，Databricks 當時本質上是在云上跑用戶的 Spark 作業(yè)。任何一個時刻，他們都可能在同時調度上百萬個 Spark 任務。所以他們必須寫一個能夠在百萬規(guī)模上決定“下一個該跑誰”的調度器。

他說，他們試過操作系統(tǒng)領域的人寫的各種調度器，但都擴展不上去。最后他們把所有調度數(shù)據(jù)都放進了 Postgres 數(shù)據(jù)庫里，本質上是由一個 Postgres 應用來做調度。

這件事一下子就點醒了我們。因為歸根結底，操作系統(tǒng)里大多數(shù)事情，本質上都是在大規(guī)模地管理數(shù)據(jù)。而這類事情，本來就應該用數(shù)據(jù)庫技術來做。所以我們的想法就變成了：為什么不干脆把 Linux 至少上半部分，用數(shù)據(jù)庫系統(tǒng)替換掉？

這就是那個學術項目最初的核心。我們在 2020 年代初，和伯克利、斯坦福一起做這件事，結果非常成功，清楚地證明了這條路是能走通的。

在這個過程中，斯坦福那邊還給 JavaScript 做了一層擴展，因為你總得有一個編程環(huán)境，能和底層實現(xiàn)通信。如果你上面跑的是某種編程語言，下面承載它的“操作系統(tǒng)”本質上又是一個數(shù)據(jù)庫，那最自然的做法，就是把所有狀態(tài)都放進數(shù)據(jù)庫里。他們也正是這么做的。

于是我們手里就同時有了一個新的編程語言模型，和一個新的操作系統(tǒng)模型。接下來很自然的問題就是，能不能把它做成一家公司？后來我們去找風投，幾乎所有人的回答都一樣：如果你們覺得自己能替代 Linux，那就是在做夢。不過，你們這套編程語言的東西倒是挺有意思。

因為我們實際上做的是一種 JavaScript 擴展，它可以讓任意程序天然擁有數(shù)據(jù)庫系統(tǒng)的很多優(yōu)點。比如狀態(tài)是持久化的，可以有事務，失敗之后可以自動 failover，等等，都是那類非常好用的能力。所以我們在 2023 年拿到了融資，成立了 Deboss 公司。項目一直就叫這個名字，所以公司也沿用了這個名字。不過本質上，我們做的其實已經(jīng)更接近編程語言業(yè)務了。

現(xiàn)在 Deboss 提供了一套 TypeScript、一套 Java、一套 Go 和一套 Python，它們基本是無縫的。你寫出來看起來就像普通原生程序一樣。

在云時代，幾乎所有因素都在推動你把應用組織成 workflow。所以我們決定，直接支持工作流系統(tǒng)。Deboss 在這四種語言里提供的 workflow 模型里，每一步，也就是每個小的 micro app，無論你怎么叫它，都是事務性的。整個 workflow 是持久化的，也就是說一旦某一步完成了，它不會被忘掉。

而且很明顯，如果市場有這個需求，我們也可以把整個 workflow 做成原子性的。也就是說，整個流程要么完整執(zhí)行完，要么看起來就像從來沒發(fā)生過。所以它有很多非常好的性質，而且速度比現(xiàn)有競品快得多，用起來也容易得多。公司現(xiàn)在就在這個方向上持續(xù)賣產品和做創(chuàng)新。

說白了，就是你要把應用的狀態(tài)做成持久化，那就把它放進數(shù)據(jù)庫；然后再想辦法把它做快。我覺得他們現(xiàn)在的商業(yè)模式，和我們前面聊的也很一致，就是先把最底層、最直接使用這些東西的程序員吸引進來。

我們一直在做的事情就是：去問這些一線程序員，你們缺什么，我們還沒有什么；然后盡快把這些能力補上，再說服他們來試。我們在創(chuàng)業(yè)公司這邊已經(jīng)做得非常成功了，因為這些公司只想選最好的東西?，F(xiàn)在我們也開始慢慢打進大公司。

這是一個很有意思的市場。到目前為止，大概三分之二的客戶都在做 agentic AI。也就是說，他們有一個大語言模型，外面再包一層各種組件，給它補充更多信號。

而目前大多數(shù) agentic AI，其實還是只讀型的。比如你要預測 Ryan 會不會是一個好客戶，那么系統(tǒng)只是跑一堆邏輯，最后產出一個結果交給別人。它本質上是 read-only，并不會真的去修改 Ryan 的信用評分之類的東西。

但我覺得很快，整個世界都會轉向讓 agent 去做 read-write 的應用。一旦到了那一步，這類系統(tǒng)就會變得非?！皵?shù)據(jù)庫化”，而 Deboss 恰恰非常擅長處理這種東西。

比如說，你想寫一個 agent，或者兩個 agent，讓它們把我賬戶里的 100 美元轉到你賬戶里。那它們就必須先扣掉我的余額，再給你的余額加上 100，而且兩個 agent 必須就“提交”這件事達成一致，否則就得把一切回滾。

換句話說，這個 workflow 必須是我前面說的 atomic，也就是要么全部發(fā)生，要么看起來從未發(fā)生。

所以我覺得，這個市場里的需求接下來還會繼續(xù)升級，大家會越來越希望這些系統(tǒng)不僅能讀，還能寫。我認為這對整個市場是利好，對 Deboss 也是利好。

主持人：那現(xiàn)在市場上提供給應用開發(fā)者的這個產品，和最初那個研究項目已經(jīng)不太一樣了。最初那個項目是真的打算把操作系統(tǒng)內部的核心狀態(tài)都替換成數(shù)據(jù)庫。我得說，這真的很酷。我以前從來沒想過，操作系統(tǒng)所有狀態(tài)都能放進數(shù)據(jù)庫里。不過這里面總該有些代價吧？

Mike Stonebraker：其實沒有什么明顯的代價。一個構建在 DBMS 之上的文件系統(tǒng)，比 Linux 文件系統(tǒng)更快。調度引擎的性能，也能和其他調度引擎打平。你還可以讓所有東西都具備 failover 能力，也就是說，你幾乎不用再額外做什么，就能得到高可用。

所以答案是，基本沒什么缺點。

主持人：那 Linux 為什么不把這套東西吸收進去，自己升級掉呢？

Mike Stonebraker：理論上他們應該這么做。換句話說，底下那些設備驅動之類的臟活累活當然還是應該保留，因為那部分東西太多了，也沒人想重寫。但除此之外，其他部分都應該被數(shù)據(jù)庫式實現(xiàn)替代。

主持人：你跟 Linux 圈子的人提過這件事嗎？他們通常是什么反應？

Mike Stonebraker：在當年的學術項目階段，只要我把這個想法講給操作系統(tǒng)領域的人聽，他們就會非常有威脅感，覺得這是數(shù)據(jù)庫那幫人要來搶地盤了。

編程語言領域的人也差不多。他們也會覺得，怎么，你現(xiàn)在是說編程環(huán)境的 runtime 也該用數(shù)據(jù)庫來實現(xiàn)？

主持人：這個很有意思。如果它在技術上真的是對的，那也許遲早會接管掉現(xiàn)有方案。

Mike Stonebraker：Java 花了 10 年才被廣泛接受。我只是覺得，這種事情的時間常數(shù)本來就很大。

5 在真實數(shù)據(jù)倉庫里，LLM 寫 SQL 的準確率是 0%

主持人：我們前面聊了很多數(shù)據(jù)庫的過去。我也很好奇，你怎么看數(shù)據(jù)庫領域那些還沒解決的問題，以及未來會是什么樣子？

Mike Stonebraker：這里我想講兩件事。第一件是，和其他人一樣，大概三年前，我們開始研究大語言模型到底適合做什么。

我們一直在嘗試把現(xiàn)在所謂的 text-to-SQL 用到真實世界的數(shù)據(jù)庫上，尤其是真實世界的數(shù)據(jù)倉庫。我們已經(jīng)在四個真實生產環(huán)境的數(shù)據(jù)倉庫上測試過這項技術。我們拿到了這些系統(tǒng)里真實的工作負載，也就是實際用戶在系統(tǒng)里跑過的查詢，然后再反向還原出與這些 SQL 對應的自然語言描述。

所以我們手里現(xiàn)在有四套 benchmark，每套都同時包含文本和 SQL。

主持人：你說的 text-to-SQL，是指人類用自然語言去提示模型嗎？比如我直接用英文說一句話？

Mike Stonebraker：對，比如“把所有四歲以上的人找出來”，或者“告訴我 MIT 所有拿過圖靈獎的教授”。按這個說法，大語言模型應該很擅長做這種事。

現(xiàn)在公開的 text-to-SQL benchmark 里，有一個叫 Spider，另一個叫 Bird。最好的大語言模型系統(tǒng)在這些 benchmark 上表現(xiàn)其實還不錯，準確率大概能到 80% 甚至更高。算不上超人類，但已經(jīng)相當不錯了，已經(jīng)到了你會認真考慮拿來用的程度?，F(xiàn)在排行榜上的成績差不多是 85% 的準確率。也就是說，你會覺得它可能還沒完全 ready for prime time，但看上去已經(jīng)很接近了。

但在我們的 benchmark 上，大語言模型的準確率是 0%。如果你再給它加上 RAG 之類各種增強技巧，準確率能到 10%。如果你在 prompt 里直接把 from clause 給它，也就是把實際要訪問的表、實際要做的 join 條件全都告訴它，那準確率大概能到 35%。

所以，這項技術按“能不能上生產”這個標準來看，還完全不夠格，而且短時間內都看不到真正能上生產的可能，甚至可能永遠都到不了那一步。

主持人：差別到底出在哪里？

Mike Stonebraker：第一，數(shù)據(jù)倉庫里的數(shù)據(jù)并不在大模型的訓練語料里。大語言模型基本是拿公開語料訓練出來的，而數(shù)據(jù)倉庫里的真實業(yè)務數(shù)據(jù)根本不在里面。有一句老話說得很對：如果模型以前沒見過這些數(shù)據(jù)，至少沒反復見過幾次，那它基本不可能把它正確“吐”出來。這是第一點。

第二，Spider 和 Bird 這類 benchmark 里的查詢復雜度，大概也就是 10 到 20 行 SQL。但真實世界的數(shù)據(jù)倉庫里，SQL 往往是 100 行起步，復雜度根本不是一個量級。

第三，Spider 和 Bird 的 schema 很干凈。表名都很直觀，列名也很直觀，沒有冗余。但數(shù)據(jù)倉庫不是這樣。數(shù)據(jù)倉庫里經(jīng)常到處都是物化視圖，這意味著大量冗余；列名也經(jīng)常是那種帶下劃線、縮寫一堆、看起來根本猜不出含義的命名方式，完全不直觀。

這會讓問題變得困難得多。再加上，真實系統(tǒng)里還有大量非常“本地化”的、非常特殊的數(shù)據(jù)。比如 MIT 有個 “J-term”，指的是一月份一個月的學期。這并不是 MIT 獨有，但也絕不是那種足夠常見、足夠普及、能出現(xiàn)在訓練語料里的概念。

所以，數(shù)據(jù)不在訓練集里，查詢更復雜，schema 又是一團亂麻，再加上一堆系統(tǒng)特有的數(shù)據(jù)，這幾件事疊在一起，就讓這套東西根本跑不起來。而且我知道的每一個數(shù)據(jù)倉庫，基本都符合這些特征。所以我的判斷是，這項技術現(xiàn)在不行，短期內也不會行。

主持人：那你們現(xiàn)在怎么做？

Mike Stonebraker：首先，我們把自己的 benchmark 發(fā)出來了，叫 Beaver。它是那四個真實數(shù)據(jù)倉庫做過匿名化和抽象化處理之后形成的版本。所以，如果有人真覺得自己特別擅長做 text-to-SQL，那就來跑一個真正像樣的 benchmark，不要再拿那些“假的” benchmark 自我感覺良好。

第二，結合我剛才說的這些問題，如果你沒有 join 條件，沒有 from 子句，那基本就已經(jīng)沒戲了。更進一步，如果你不能把一個復雜查詢拆成更簡單的幾部分，你也還是沒戲。

所以這讓我覺得，真正合理的做法是，把檢索系統(tǒng)拿到的輸入先變成更簡單的片段，而且這些片段里要明確包含 from 子句和 join 條件。這是第一點。

第二點是，一旦你要同時跟兩個不同的結構化數(shù)據(jù)庫打交道，比如一個數(shù)據(jù)倉庫再加一個 CRM 系統(tǒng)，那在我看來，用大模型去做結構化數(shù)據(jù)之間的 join，就是個餿主意。你最好還是把它們保留成表，用 SQL 去做 join，這樣靠譜得多。

所以我們現(xiàn)在的思路是，盡量把一切都變成表。比如我們現(xiàn)在在和德國慕尼黑市交通部門合作，他們有六個全職員工，專門回復市民投訴和咨詢。問題五花八門，比如“為什么我家門口那個路口，綠燈時間不夠我走過去？”“為什么有軌電車停站時間不夠我上車？”“為什么這趟電車一小時才來一班？”全是這種問題。

而他們背后的數(shù)據(jù)來源非常雜。電車時刻表是 SQL，紅綠燈時序是 SQL，路口信息是 CAD，德國聯(lián)邦層面的交通法規(guī)是文本，慕尼黑市自己的法規(guī)也是文本。也就是說，你得把 SQL、SQL、CAD、文本、文本，這幾類東西做關聯(lián)。

我們的思路就是，把它們全都轉成 SQL，或者說全都轉成表，再用一種本質上接近查詢優(yōu)化器的方式去做 join。這就是我們現(xiàn)在在做的事情。我相信別人會有別的思路，但我覺得這個方向非常有潛力，因為大家真的非常想把這件事做成。這是第一件事。

第二件事，是我們前面聊過的 agentic AI。只要它從只讀走向可讀可寫，它立刻就會變成一個分布式數(shù)據(jù)庫問題。你需要原子性、一致性，所有這些老問題都會重新回來。我覺得這也是一個非常有意思的方向。所以現(xiàn)在我主要就在做這些事情。

主持人：在你們這個 benchmark 上，大模型現(xiàn)在是 0%。那人類大概能到多少？比如一個真的懂 SQL 的人，平均能做到什么水平？

Mike Stonebraker：只要你先把自然語言里的歧義消掉，一個熟悉 SQL、也看得懂 schema 的程序員，準確率會非常高。

主持人：比如 90% 以上？

Mike Stonebraker：對，至少是這個量級。

主持人：明白了。老實說，我還是有點驚訝，大模型在這種 benchmark 上居然會低成這樣。也許等這期節(jié)目播出去之后，會有 Anthropic 那邊的人聯(lián)系你，說我們來試試看之類的。

Mike Stonebraker：我很愿意知道他們能做到什么程度。因為這對那些真想深入理解數(shù)據(jù)庫的人來說，其實是個很好的機會。

6 計算機科學，可能不再是增長型行業(yè)

主持人：如果有人想系統(tǒng)學習數(shù)據(jù)庫，你會推薦什么技術書或者論文材料？

Mike Stonebraker：我和 Joe Hellerstein 出過一本“紅皮書”，名字就叫 Readings in Database Systems。雖然現(xiàn)在已經(jīng)是八年前的書了，但如果你想看八年前以及更早那些經(jīng)典材料，我覺得它仍然是一套非常好的閱讀入口。再往后的話，就去看數(shù)據(jù)庫領域后來那些比較重要、比較流行的論文。

主持人：如果你能回到剛畢業(yè)的時候，帶著今天的認知給自己一些建議，你會說什么？

Mike Stonebraker：當年我剛到伯克利任教時，幾乎沒多想，就說那我們來寫一個數(shù)據(jù)庫系統(tǒng)吧?？赡菚r候我們對數(shù)據(jù)庫幾乎一無所知，對實現(xiàn)也一無所知，編程能力也不像 Bill Joy 那樣強。所以，一上來就做這么瘋狂的事，其實本身就非常瘋狂。

但人就是這樣，先狠狠干，邊做邊學，邊學邊把事情做出來。所以我覺得答案就是，要跳出框框去想，要敢想一些瘋狂的念頭，然后真的去做。

不過對我來說，現(xiàn)在更值得問的問題其實是：如果你今天才剛開始，你會選什么專業(yè)？

因為我覺得，計算機科學未來很可能不再是一個增長型行業(yè)。我不確定我今天還會不會建議 18 歲的人去學計算機。

醫(yī)療保健和各種建筑、維修這類工種，看起來都還是相對安全的選擇；其他很多方向，風險都大得多。

當然，如果你已經(jīng)快拿到 PhD，正在考慮接下來怎么辦，那事情就簡單多了。去拿你能拿到的最有聲望的工作，找一個愿意帶你的導師，然后挑一個不是順著潮流走的方向。比如我們現(xiàn)在做的這個 Rubicon，就絕對不是順著主流在跑。所以，去找一個不隨大流的方向，想辦法把它做成。

我和我太太以前都跟孩子說過一句話：“去追隨你的熱情，錢總會自己解決?！钡f實話，我一點都不信這句話。不過我覺得，你還是只能這么跟孩子說，跟孫子也只能這么說。

主持人：如果你自己并不相信這句話，為什么還要這么說？

Mike Stonebraker：我太太就是個很好的例子。她本科是計算機科學，碩士也是計算機科學，但她其實真正想做的是老師，中小學老師?？伤改府敃r跟她說，這不行，收入太低了。

我覺得她從那以后，一直都對這個決定有遺憾。她并不是真的熱愛計算機科學，那對她來說只是個謀生手段。

所以我覺得，還是應該去找一件你真正有熱情的事。這樣至少你不會挨餓。你可能不會賺很多錢，但大概率會比做一件自己根本沒熱情的事過得更開心。

因為我認識很多人，他們把工作純粹當成工作，真正的生活只發(fā)生在下午 5 點到第二天早上 8 點之間。我完全不是這種感覺。我是真的很喜歡我在做的事。無論我賺很多錢還是沒賺很多錢，這一點都不會變。

原視頻鏈接：

https://www.youtube.com/watch?v=YPObBOwIrHk

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經(jīng)許可禁止轉載。

「AMD AI 開發(fā)者日 2026」定檔，不僅能聽到前沿 AI 技術分享，更能參與專家指導的實戰(zhàn)工作坊，5 月 19 日上海見！