罵谷歌干蠢事、炮轟甲骨文、AI在真實數據庫測試得分為0！83歲圖靈獎數據庫教父的硅谷“狂人日記”

編譯 | 王啟隆

文章來源：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 點上班前的那段時間。我完全不這么想。我真的熱愛我所做的一切。無論我賺不賺錢，這都無所謂。