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

計算機不再是朝陽產(chǎn)業(yè)？

編譯 | 王啟隆

出品丨AI 科技大本營（ID：rgznai100）

過去這些年，數(shù)據(jù)庫世界里最流行的幾套說法，幾乎都能在邁克·斯通布雷克這里撞上一堵墻。

你跟他說大模型正在重寫一切，他會告訴你，他們拿四個真實生產(chǎn)級數(shù)據(jù)倉庫測過，今天最熱的 Text-to-SQL 在自己的基準上得分是 0。你跟他說 Hadoop 和 MapReduce 曾經(jīng)開啟了一個新時代，他會很不客氣地說，那不過是谷歌干過的一件蠢事。你如果再把他當年開發(fā)的 Postgres講成一套可以吞掉所有場景的終極答案，他也不會順著這個行業(yè)共識往下說。

這不是一場溫和的數(shù)據(jù)庫懷舊訪談。

這是 Ryan Peterman 播客和圖靈獎得主、Postgres 奠基者 Mike Stonebraker的一場長談。兩個人一路從 Ingres 怎么在 1970 年代起步，聊到 Oracle 當年怎么賣貨，聊到 Postgres 為什么要把類型系統(tǒng)做成可擴展，聊到為什么查詢優(yōu)化器直到今天仍然是數(shù)據(jù)庫里最難啃的骨頭，也聊到他現(xiàn)在最關心的兩件事：

大模型到底能不能真的把自然語言變成生產(chǎn)環(huán)境里的 SQL？

Agent 真開始讀寫世界之后，數(shù)據(jù)庫系統(tǒng)會不會重新回到舞臺中央？

這位八十多歲的數(shù)據(jù)庫老兵，他罵的很多東西，今天恰好又以新面貌回來了。大家重新迷上通用平臺，迷上一個系統(tǒng)吃掉一切，迷上只要模型夠強就能抹平結(jié)構(gòu)化世界的復雜度，迷上把正確性往后放、先把速度和規(guī)模做出來。Stonebraker 基本是在把這些流行信念一條條掀開，說數(shù)據(jù)庫世界從來不是這樣運轉(zhuǎn)的。

要點速覽

• MapReduce 是谷歌干過的蠢事之一。谷歌后來連 eventual consistency 這條路也走錯了，最后還是回到了 Spanner 這種傳統(tǒng)事務系統(tǒng)。

• Postgres 是今天最好的默認答案，但只是默認答案。社區(qū)大、免費、好招人、通用能力強，這些都是真的。可一旦進入百萬級事務、PB 級倉庫、多節(jié)點和列存這些高端場景，通用系統(tǒng)就不再夠用了。

• Postgres 從 Ingres 走出來，核心不是再造一個關系型數(shù)據(jù)庫，而是要做一個可擴展的類型系統(tǒng)，讓數(shù)據(jù)庫能真正處理 GIS、金融債券時間這類標準類型之外的世界。

• 數(shù)據(jù)庫最難的部分還是查詢優(yōu)化器。幾十年過去，最難的地方?jīng)]變。

• 對聰明工程師和普通工程師的區(qū)分方式：不看套路，不看包裝，直接追問你到底做了什么、錯誤怎么處理、為什么這樣實現(xiàn)，深問幾輪，水平就藏不住了。

• 把應用狀態(tài)更深地放回數(shù)據(jù)庫，讓工作流天然擁有持久化、事務、故障轉(zhuǎn)移這些特性。因為未來大量讀寫型 Agent，最后都會重新撞上數(shù)據(jù)庫問題。

• 如果今天重新開始，他都不確定還會不會建議 18 歲的人主修計算機科學。

“甲骨文靠對客戶撒謊贏了市場”

主持人：今天我們請到的是邁克·斯通布雷克（Mike Stonebraker）。他是圖靈獎得主，因?qū)?Postgres 等數(shù)據(jù)庫系統(tǒng)做出的開創(chuàng)性貢獻而聞名。首先我想聊聊 Postgres 是如何起步的。為此，我想從最開始講起。你是如何進入數(shù)據(jù)庫系統(tǒng)構(gòu)建這個領域的？

Mike Stonebraker：畢業(yè)那年，我有幸被伯克利大學聘用。當時很明顯的一點是，我必須尋找新的研究方向——我讀博期間做的那些東西，在當時和現(xiàn)在看來都沒什么前途。如果能被一位深諳門道的導師收于麾下，你就能贏在起跑線上。所以，目前依然健在且精神矍鑠的尤金·王（Gene Wong）把我?guī)У搅怂拈T下，他說：“咱們一起搞點什么吧。”

那是 1971 年，也就是泰德·科德（Ted Codd）在《美國計算機學會通訊》（CACM）上發(fā)表那篇開創(chuàng)性論文的第二年。尤金·王說：“咱們來看看數(shù)據(jù)庫這塊的東西吧。” 當時市面上的競爭者是一個叫CODASYL的提案，你可能太年輕都沒聽說過。那是一個底層的、像意大利面一樣糾纏不清的網(wǎng)絡模型，你需要通過順藤摸瓜找指針來執(zhí)行查詢。另一個替代方案是 IBM 提出的名為IMS的層次化模型，這東西現(xiàn)在還有。它是層次化數(shù)據(jù)，也就是把數(shù)據(jù)組織成樹狀結(jié)構(gòu)。

即使在當時，IBM 也意識到樹狀結(jié)構(gòu)不夠通用，無法解決很多人的問題。所以他們東拼西湊，硬是把它改造成了一個受限的網(wǎng)絡結(jié)構(gòu)。明眼人一看就知道那是個粗劣的補丁。

而 CODASYL 提案也有各種致命缺陷。除了過于底層且極難調(diào)試之外，它還有一個毛病：一旦你現(xiàn)在的所謂“數(shù)據(jù)模式（Schema）”發(fā)生任何變化，你基本上就得把所有東西推倒重來，因為它完全被焊死在了物理層面上。相比之下，泰德·科德的理論簡直無懈可擊。

所以尤金說：“咱們也造一個這樣的系統(tǒng)吧。這顯然是下一步該嘗試的方向。”于是，1972 年，當我還是一名伯克利助理教授的時候，我們開始構(gòu)建 Ingres。如你所知，作為助理教授，你有五年的時間來證明自己的實力，要么被解雇，要么拿到終身教職。所以，Ingres 就是我拿到終身教職的敲門磚，這在 1976 年如愿以償。這就是一切的起點。

接下來的發(fā)展又是機緣巧合。在當時，很多人做出來的原型系統(tǒng)都充滿了“學生氣”，意思是代碼雖然能跑，但如果交給別人，別人根本跑不起來。所以我們花了前一半的精力做出了一個能跑的雛形，然后不知怎么地，我們又投入了另一半的精力把它打磨到真正穩(wěn)定運轉(zhuǎn)的程度。所以加州大學版本的 Ingres 是真正能用的。在接下來的幾年里，大約有一百多所大學開始運行它，因為Unix當時正在崛起，而這是一個能在 Unix 上運行的免費數(shù)據(jù)庫系統(tǒng)。它在學術界非常受歡迎。

我們開始在伯克利接待大量的訪客，他們會說：“哇，這玩意兒看起來真酷。你們運行過的最大的 Ingres 應用程序是什么？” 我們不得不尷尬地回答：“沒多大。” 這一點在亞利桑那州立大學考慮用 Ingres 來管理他們?nèi)?4 萬名學生的學籍數(shù)據(jù)時，被展現(xiàn)得淋漓盡致。他們可以克服從貝爾實驗室獲取不受支持的操作系統(tǒng)的困難，也可以克服運行我們這幫伯克利家伙搞出來的不受支持的數(shù)據(jù)庫系統(tǒng)的困難。但是，當他們發(fā)現(xiàn) Unix 上沒有 COBOL 語言支持時，這個項目徹底泡湯了，因為他們完全是一個依賴 COBOL 的團隊。所以，不受支持的操作系統(tǒng)、不受支持的數(shù)據(jù)庫系統(tǒng)，再加上沒有 COBOL，注定了我們要被邊緣化。

很顯然，擺脫這種困境的唯一出路就是創(chuàng)辦一家公司。所以 1980 年，我們拿到了當時那種形式的風險投資，創(chuàng)立了 Ingres 公司，把 Ingres 移植到了DEC 的 VMS上——那是一個真正的操作系統(tǒng)。我們擁有了一家能為 Ingres 提供支持的真正公司，這也是我們商業(yè)之旅的開端。

主持人：我看到 Ingres 當時在和拉里·埃里森（Larry Ellison）的 Oracle 競爭。我也看到 Ingres 顯然比他們提供的產(chǎn)品更好，但你們依然在某種程度上處于競爭狀態(tài)。他們是怎么競爭的？

Mike Stonebraker：拉里·埃里森是個絕佳的推銷員。在當時，他能把“現(xiàn)在時”和“將來時”混為一談，說白了就是對客戶撒謊。他會把根本不能用的東西發(fā)貨，然后讓第一批客戶幫他調(diào)試。我認為他使用了一些極其見不得光的商業(yè)手段。對客戶撒謊，我認為是違背良知的。

舉個例子，數(shù)據(jù)庫里有個東西叫“參照完整性（referential integrity）”，意思是如果你解雇了一名員工，而他是某個部門的最后一個人，你是想把這個部門一起刪掉，還是讓它變成一個幽靈部門？就是這類問題。Ingres 公司實現(xiàn)了參照完整性。而Oracle 公司只是寫了兩頁手冊，上面印著大家都認可的“參照完整性定義”，然后在最底下用小字寫著：“尚未實現(xiàn)”。

主持人：很有意思。我曾采訪過一位在太陽微系統(tǒng)（Sun Microsystems）工作過的人，他對拉里·埃里森也有類似的評價，覺得他有點不太光彩。看來這是個共識。我也在其他地方看到過你的說法，當 Oracle 收購 MySQL 時，大家都感到恐慌，紛紛轉(zhuǎn)向了 Postgres。這也是 Postgres 取代 MySQL 成為首選開源關系型數(shù)據(jù)庫的契機。

你創(chuàng)造了 Ingres，里面包含了很多技術創(chuàng)新，使它優(yōu)于當時的現(xiàn)有產(chǎn)品，但最終它還是退出了歷史舞臺，你又開發(fā)了 Postgres。Ingres 有什么是做不到的，而 Postgres 做到了？

Mike Stonebraker：在最開始指導我們的大方向，其實源于學術版 Ingres 的初衷：我們要為隔壁的 Pravin Varaiya 教授想要的一個地理信息系統(tǒng)（GIS）提供支持。為了支持 GIS 系統(tǒng)，你需要點、線、多邊形、線組這類數(shù)據(jù)。很顯然 Ingres 做不到，因為我們在 Ingres 里放入的數(shù)據(jù)類型都是標準的：整數(shù)、浮點數(shù)、文本、字符串。你無法在這些基礎之上高效地支持 GIS 數(shù)據(jù)類型。所以，作為 GIS 系統(tǒng)的底層，學術版的 Ingres 是一個徹底的失敗。這件事一直留在我們腦海里。

另外發(fā)生的一件事，雖然在時間順序上有點錯位，但能很好地說明問題。大概在 1985 年，ANSI 剛剛提出了關系型數(shù)據(jù)庫的日期和時間標準。商業(yè)版 Ingres 使用標準的公歷實現(xiàn)了日期和時間。當時我既參與商業(yè)版 Ingres 的工作，同時也是加州大學的教授。我接到一個 Ingres 客戶的電話，他說：“你們把日期和時間實現(xiàn)錯了。” 我一頭霧水：“啊？我們實現(xiàn)了公歷，你可以做減法。除了二月和閏年，每個月有 30 或 31 天。所以日期的減法運算完全符合你的預期啊。”

但他告訴我，在他的特定領域里，他要的根本不是這個。他在處理債券金融工具，無論一個月有多長，他的金融債券在每個月產(chǎn)生的利息都是一樣的。他有買入債券的日期和賣出債券的日期。他想做一個減法，乘以票面利率，然后說：“這就是我們付給你的利息。”但當然，在他那里的減法定義是：3 月 15 日減 2 月 15 日等于 30 天，因為這就是他那個日歷的定義。

所以他不得不把兩個日期提取到用戶代碼中，在代碼里做減法，然后再把結(jié)果放回去，這讓他的效率降低了兩到三倍。他問：“為什么我不能直接用我想要的邏輯，重載你們的減法定義呢？” 當然，在 Ingres 里，這都是寫死在底層代碼里的。

問題在于，這是一個你需要“債券時間”的場景，就像你需要點、線和多邊形一樣。Postgres 在架構(gòu)之初就設計了一個可擴展的類型系統(tǒng)。你可以擁有任何你想要的數(shù)據(jù)類型，而且效率極高。這就是 Postgres 的核心要義：它具備極高的靈活性。在商業(yè)數(shù)據(jù)處理中，大多數(shù)人對標準數(shù)據(jù)類型很滿意，但關系型數(shù)據(jù)庫開始滲透到各種其他領域。所謂的抽象數(shù)據(jù)類型或存儲過程具有極大的適用性，所以這成了 Postgres 最大的殺手锏。

我們還支持了當時人工智能領域的家伙們想要的“繼承”功能。我們甚至支持了“時間旅行（歷史數(shù)據(jù)查詢）”。不過那部分的實現(xiàn)簡直爛透了，后來就被移除了。總之，Postgres 里有大量非常巧妙的設計。

“我受不了不夠聰明的人”

主持人：你提到你想招募非凡的軟件工程師，而且我記得你以前說過，你找這樣的人毫不費力。在招聘時，你是如何辨別出他們就是那些非凡之才的？

Mike Stonebraker：通常這很明顯。我對事情的難度有很好的直覺。如果他們在學校里完成的工作量，是我認為合理預期工作量的三倍，那他們就是不可思議的天才。

主持人：反過來說，你有一句很有意思的話，我把它記下來了。你說：“我受不了那些不夠聰明的人。和他們交流太費勁了。” 你是如何辨別那些不夠聰明的人的？

Mike Stonebraker：這其實非常簡單。你和他們聊一聊，很快就能試探出他們到底聰不聰明。“你的碩士論文寫的是什么？你具體做了什么？它是怎么運作的？你是如何處理錯誤情況的？你開了多少個進程？你為什么不用線程？”你只需要問他們深度的技術問題。

主持人：你做過一次演講，好像背后還有一篇論文，提出了這樣一個觀點：萬金油式（one-size-fits-all）的數(shù)據(jù)庫系統(tǒng)并不是最優(yōu)解，試圖適應一切的系統(tǒng)實際上什么都適應不好。你真正需要的是針對特定需求量身定制的數(shù)據(jù)庫解決方案。你認為當今市面上有哪些數(shù)據(jù)庫產(chǎn)品是這種“萬金油”？

Mike Stonebraker：在 2004 年我寫那篇論文的時候，我們有一個學術項目，后來演變成了Streambase。一個流處理引擎看起來和關系型數(shù)據(jù)庫毫無相似之處。我們還有了用于數(shù)據(jù)倉庫的列式存儲的初步構(gòu)想，后來被Vertica發(fā)揚光大，它看起來和行式存儲也完全不同。所以這里有三個截然不同的實現(xiàn)，它們彼此毫無相似之處，而且在各自的領域，它們都比其他系統(tǒng)快上一個數(shù)量級。很明顯，通過這三個例子可以看出，當你運行一個并非為你特定場景架構(gòu)的數(shù)據(jù)庫系統(tǒng)時，你就要犧牲一個數(shù)量級的性能。

我認為這在今天依然成立。ClickHouse是一個列存數(shù)據(jù)庫。Pinecone在基于文本的向量處理上，比用戶自定義類型要快得多。我認為情況依然如此，而且在多個底層實現(xiàn)之上套用一個通用的解析器，并沒有什么難度。只是 Postgres 至今選擇不這么做。他們沒有實現(xiàn)列式存儲，所以我認為他們在大型數(shù)據(jù)倉庫領域缺乏競爭力。他們也沒有多節(jié)點支持。同樣，對于擁有大型數(shù)據(jù)倉庫的人來說，這是入場券。所以我認為這個觀點今天依然像過去一樣正確。

不過有一點也是事實：如果你想快速起步，你遇到了一個數(shù)據(jù)庫問題，答案就是選擇 Postgres。它有龐大的編程社區(qū)，各種數(shù)據(jù)類型的實現(xiàn)，它是免費的，而且你很容易招到懂 Postgres 的人來推進工作。作為滿足最低通用需求的選項，它是極好的。只要你不是想實現(xiàn)每秒一百萬次的事務，它就完全沒問題。只要你不是想支撐一個 PB 級的數(shù)據(jù)倉庫，它就能運轉(zhuǎn)良好。在低端場景，它絕對是正確的“萬金油”。但在高端場景，這套就行不通了。

主持人：GPU 會為優(yōu)化數(shù)據(jù)庫提供一些新的機會嗎？

Mike Stonebraker：也許會，但我認為巨大的挑戰(zhàn)在于 GPU 是 SIMD（單指令多數(shù)據(jù)流）架構(gòu)，而這簡直是索引的死穴。只要索引是正確的解決方案，GPU 可能就不是個好主意。此外，你必須在架構(gòu)上確保來自存儲的帶寬不會成為瓶頸。如果 GPU 只是 CPU 的一個附加組件，那么連接 GPU 和 CPU 的總線往往就會成為瓶頸。

主持人：你能解釋一下為什么在使用 SIMD 時，索引的效果會大打折扣嗎？

Mike Stonebraker：假設我在查找瑞恩的薪水，而且我有一個 B 樹索引。你走到 B 樹的根節(jié)點，找到包含瑞恩所在區(qū)間的分割點。你順著指針往下走。這絕對是一次內(nèi)存訪問。然后你再重復這個過程，大概要重復三四次。這個過程是無法很好地并行化的。所以答案就是：索引無法很好地并行化。

“谷歌當年干的蠢事，不止 MapReduce 一件”

主持人：你提到了 B 樹。當你們最初實現(xiàn)第一版 Ingres 時，所有這些都是你們手寫的嗎？因為我想象當時大概沒有什么現(xiàn)成的 B 樹代碼庫之類的東西。

Mike Stonebraker：是的，最初版本的 Ingres 全都是從零開始手寫的。

主持人：那個實現(xiàn)過程中最難的部分是什么？

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

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

Mike Stonebraker：它非常棘手。它在算法上實在太難了。如果你去問任何一位資深的數(shù)據(jù)庫程序員最難的部分是什么，他們至今依然會說是優(yōu)化器。

主持人：MapReduce 大概在 2000 年代初問世，它席卷了整個數(shù)據(jù)領域。人們對它印象深刻，覺得谷歌真的知道自己在干什么，這是有史以來最棒的發(fā)明。但當我查閱文獻以及你當時的看法時，似乎你非常不認同。你為什么如此不看好 MapReduce？

Mike Stonebraker：我認為當時有很多不太懂行的人說：“谷歌真的很聰明。他們肯定知道自己在干什么，所以他們說什么我們就做什么。”

于是他們開始搞Hadoop。但是 Hadoop 的效率低得令人發(fā)指。當時，大衛(wèi)·德威特（David DeWitt）和其他參與了我們 2011 年論文的人，我們非常了解分布式數(shù)據(jù)庫，并且明白用一個分布式數(shù)據(jù)庫系統(tǒng)就能把 Hadoop 打得落花流水，這基本上就是那篇 2011 年論文的核心觀點。當然，事實也確實如此。

但谷歌干的蠢事可不止這一件。谷歌當時還認為，“最終一致性（eventual consistency）”是處理并發(fā)控制的正確方式。在那個時期，這是谷歌高層定下的基調(diào)。而所有的數(shù)據(jù)庫專家都說：“你們簡直瘋了。” 因為它只能解決一種非常特定類型的問題，而那種問題在實際應用中極少出現(xiàn)。

主持人：他們?yōu)槭裁匆非笞罱K一致性？

Mike Stonebraker：他們的設想是，你在東海岸有一個數(shù)據(jù)庫，在西海岸也有一個數(shù)據(jù)庫，它們互為副本。你希望它們保持一致。如果你說：“我要執(zhí)行一個事務，我要把西海岸倉庫里的小商品數(shù)量減一”，那么在提交這個事務之前，你需要去更新東海岸的倉庫。這需要花費一次消息往返的代價來更新它。然后為了確保萬無一失，還需要另一次往返消息來確認兩邊都正確地提交了。執(zhí)行分布式提交是非常昂貴的，現(xiàn)在依然如此。

所以他們的想法是，你在西海岸執(zhí)行更新，把小商品減一，然后你只是異步發(fā)送一條消息，且不放在事務里，這樣“最終”東海岸的倉庫也會減一。與此同時，如果你在東海岸，你把食品減一。你發(fā)送一條異步消息。最終，西海岸會收到它，最終一切都會塵埃落定。

如果你的系統(tǒng)允許庫存出現(xiàn)負數(shù)，那么當東海岸和西海岸的人同時賣出最后一件商品時，最終倉庫的狀態(tài)就會變成負一，然后就會有人收不到他們的商品。如果你像亞馬遜那樣，允許標明“通常在 24 小時內(nèi)發(fā)貨”，那也許你可以超賣，但大多數(shù)企業(yè)做不到這一點。所以最終一致性根本行不通。

我們剛才花了很長時間聊參照完整性。在銷售系統(tǒng)中，參照完整性就是一個完整性約束：庫存必須大于負一。而最終一致性在這里就行不通了。谷歌的杰夫·迪恩（Jeff Dean）最終想明白了這一點，所以當他們開發(fā) Spanner 時，Spanner 用回了傳統(tǒng)的事務系統(tǒng)，谷歌也徹底放棄了最終一致性，徹底放棄了 MapReduce。

主持人：所以這本質(zhì)上是用正確性來換取性能。也就是性能與數(shù)據(jù)完整性之間的權(quán)衡。如果你不在乎你的數(shù)據(jù)，那你才愿意承受糟糕的結(jié)果。在谷歌做這些你認為錯得離譜的事情時，你和他們的團隊交流過嗎？

Mike Stonebraker：在 2011 年那篇論文發(fā)表之前，我們和他們談過，提議說：“我們?yōu)槭裁床缓献鞲泓c東西呢？” 但他們不感興趣。所以他們拒絕了。

主持人：你有沒有看到其他大型科技公司的數(shù)據(jù)庫或數(shù)據(jù)庫解決方案中，也有你強烈不認同的例子？比如亞馬遜或 Facebook。

Mike Stonebraker：大概三年前我在亞馬遜做過一次演講，我告訴了他們所有我認為他們做錯的地方。我認為亞馬遜的問題在于他們同時在支持 15 種不同的數(shù)據(jù)庫系統(tǒng)，這大概多出了 12 種。他們有自己的企業(yè)文化，我說：“你們支持的數(shù)據(jù)庫系統(tǒng)太多了。”但到目前為止，他們還沒有選擇淘汰其中的任何一個。

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

Mike Stonebraker：他們在支持一個基于圖的數(shù)據(jù)庫系統(tǒng)，而業(yè)界早就達成共識，圖數(shù)據(jù)庫系統(tǒng)幾乎從來都不是性能最優(yōu)的選擇。如果你喜歡那種處理節(jié)點和邊緣的用戶界面，沒問題。你可以在關系型數(shù)據(jù)庫系統(tǒng)之上加一層，給你提供那種用戶模型。

他們的大多數(shù)數(shù)據(jù)庫系統(tǒng)，總能找到另一個在特定領域做得比它更好的系統(tǒng)。我的答案是，如果一個數(shù)據(jù)庫系統(tǒng)在一個足夠大的市場里沒有性能優(yōu)勢，無法證明其維護成本的合理性，你就應該把它淘汰掉。

主持人：你從學術界對工業(yè)界產(chǎn)生了深遠的影響，我有一個想法：為什么不直接在工業(yè)界工作呢？為什么你更傾向于留在學術界，以你現(xiàn)在的方式施加影響，而不是直接去 AWS 之類的公司謀個差事，做個極其杰出的工程師？

Mike Stonebraker：因為那意味著你會有個老板。會有公司規(guī)章制度，限制你發(fā)表論文，限制你去參加會議發(fā)表演講，限制你去刺探競爭對手那些他們不愿向同行透露的底牌。但最主要的是，我真的非常喜歡置身于初創(chuàng)公司中。在商業(yè)版的 Postgres 被 Informix 收購后，我曾在 Informix 兼職工作過，那是一家有 2000 人的公司，我感覺自己根本發(fā)揮不了什么作用，因為那里官僚主義嚴重，總裁想要什么，他就能得到什么。我覺得我天生不適合搞辦公室政治。我做不好那個，而且我很難跟那些我認為愚蠢的人打交道。所以在大公司里，我會遇到很多麻煩。

對剛 Linux 的 DBOS

主持人：我想聊聊 DBOS。我覺得這是一個非常有趣的技術模型。你能解釋一下 DBOS 是什么嗎？

Mike Stonebraker：我們大概在 2019 年、2020 年左右啟動了這個學術項目。當時的核心背景是，斯坦福大學的教職員工、也是Databricks的創(chuàng)始人之一，同時也是 Spark 最初創(chuàng)造者的馬泰·扎哈里亞（Matei Zaharia）提出了一些痛點。他說，當時 Databricks 基本上是在云端運行人們的 Spark 任務。他說在任何給定時間，他們可能要調(diào)度一百萬個 Spark 任務。所以必須編寫一個調(diào)度器，來決定接下來運行誰，而且要達到百萬級的規(guī)模。他說他們嘗試了操作系統(tǒng)專家編寫的所有調(diào)度器，但都無法支撐這種規(guī)模。

于是，我們把所有的調(diào)度數(shù)據(jù)都放進了一個 Postgres 數(shù)據(jù)庫里，基本上就是用一個 Postgres 應用程序來做調(diào)度。然后我們突然恍然大悟：操作系統(tǒng)里絕大多數(shù)的工作，本質(zhì)上都是在大規(guī)模地管理數(shù)據(jù)，而你本就應該用數(shù)據(jù)庫技術來做這件事。那么，我們?yōu)槭裁床桓纱?strong>用一個數(shù)據(jù)庫系統(tǒng)來替換掉 Linux 至少上半部分的功能呢？

這就是那個學術項目的核心思想。我們在 2020 年代初在伯克利和斯坦福研究了這個項目，而且非常成功。它顯然是行得通的。在這個過程中，斯坦福的團隊為JavaScript編寫了一個擴展程序，因為你需要一個編程環(huán)境來與你的底層實現(xiàn)進行交互。如果你在做一種編程語言，并且運行在一個本質(zhì)上是數(shù)據(jù)庫的操作系統(tǒng)之上，那么最顯而易見的做法，就是把所有的狀態(tài)都存在數(shù)據(jù)庫里。他們正是這么做的。所以我們擁有了創(chuàng)新的編程語言模型，以及創(chuàng)新的操作系統(tǒng)模型。

當然，接下來的想法就是，我們能創(chuàng)辦一家公司嗎？我們?nèi)ズ惋L險投資人談，他們異口同聲地說：“想取代 Linux，你是在做夢。不過，你們那個編程語言的東西倒是很巧妙。” 我們擁有的，相當于 JavaScript 的擴展，它能讓任何程序都具備數(shù)據(jù)庫系統(tǒng)的所有優(yōu)秀特性。數(shù)據(jù)是持久化的。你可以使用事務。如果系統(tǒng)崩潰了，它會自動故障轉(zhuǎn)移。全都是這些絕妙的特性。

所以我們在 2023 年拿到了融資，成立了公司，這就是DBOS 公司。我們決定用這個名字，因為它一直都是這個項目的名字，但我們實際上做的是編程語言的生意。目前，DBOS 擁有 TypeScript 版本、Java 版本、Go 版本和 Python 版本，它們幾乎是無縫對接的。它跑起來就像是普通的程序一樣。

在云端世界里，把你的應用程序構(gòu)建成工作流是絕對的大勢所趨。所以我們決定，我們要支持一個工作流系統(tǒng)，就這么簡單。DBOS 在這四種語言中支持的工作流，其各個步驟、各個微應用（不管你怎么稱呼它們），都是具備事務性的。工作流是持久化的，所以一旦你完成了一個步驟，它就不會被遺忘。很明顯，如果有市場需求，我們可以讓工作流具備原子性，這意味著整個工作流要么全部完成，要么就像從未發(fā)生過一樣。它擁有非常棒的特性，而且比競爭對手快得多，也容易使用得多。

公司目前正在這個領域進行銷售和創(chuàng)新。核心理念是，當你把應用程序的狀態(tài)放入數(shù)據(jù)庫時，你想讓它持久化，然后你再想辦法讓它跑得快。正像我們之前聊到的，他們的商業(yè)模式非常明確，就是去吸引基層程序員的興趣。所以我們的策略一直是：“告訴我們，基層程序員們，你們需要什么我們還沒有的東西，快速把它做出來，然后說服人們?nèi)L試。” 我們在吸引那些想要選擇最佳方案的其他初創(chuàng)公司方面非常成功，而且我們也開始在大型企業(yè)中取得突破。

這是一個非常有趣的市場，我認為目前最關鍵的一點是，大概有三分之二的客戶在做智能體 AI（agentic AI），這意味著他們有一個大語言模型，周圍環(huán)繞著一堆提供更多信號的組件。到目前為止，絕大多數(shù)的智能體 AI 都是只讀的，意思是你想預測一下瑞恩會不會成為一個好客戶。它只是運行一些數(shù)據(jù)，然后生成一個新結(jié)果交給某人。基本上是只讀的，這意味著你并沒有真正去更新瑞恩的信用評分。

我認為這個領域很快就會演變?yōu)椋菏褂弥悄荏w來執(zhí)行讀寫應用程序，而這將使它們變得非常“數(shù)據(jù)庫化”。DBOS 非常擅長處理這類事情。舉個例子，如果你想寫一個智能體，或者兩個智能體，把 100 美元從我的賬戶轉(zhuǎn)到你的賬戶。你需要從我的賬戶扣款，在你的賬戶加錢，這兩個智能體必須同意提交，否則你就得把一切回滾。也就是說，工作流需要具備我所說的原子性，要么全部發(fā)生，要么就像從未發(fā)生過。我認為這個市場的需求會隨著人們對讀寫操作的渴望而不斷攀升。我認為這對市場是個好兆頭，對 DBOS 也是個好兆頭。

主持人：所以現(xiàn)在市場上提供給應用程序開發(fā)者的東西，和最初那個把操作系統(tǒng)內(nèi)核替換成數(shù)據(jù)庫的研究項目是不一樣的。我明白了。這真的很酷。我從未想象過用一個數(shù)據(jù)庫來替換操作系統(tǒng)的所有狀態(tài)。這其中的權(quán)衡是什么？

Mike Stonebraker：寫在數(shù)據(jù)庫管理系統(tǒng)（DBMS）之上的文件系統(tǒng)，比 Linux 文件系統(tǒng)還要快。調(diào)度引擎與其他調(diào)度引擎相比也毫不遜色。你可以讓一切都具備故障轉(zhuǎn)移能力，所以你不需要做任何額外的工作就能獲得高可用性。答案是，真的沒有任何缺點。

主持人：那為什么 Linux 不吸收這項技術，用它來升級自己呢？

Mike Stonebraker：你當然希望他們會這么做。換句話說，你應該把所有那些設備驅(qū)動之類的雜七雜八的東西留在最底層，因為這類東西很多，也沒人愿意去碰它們，然后用數(shù)據(jù)庫實現(xiàn)來替換掉其他所有的東西。

主持人：你向 Linux 社區(qū)的人提過這件事嗎？他們通常是什么反應？

Mike Stonebraker：當年做學術項目的時候，如果我向操作系統(tǒng)專家提到這個，他們會感到極大的威脅，他們的反應是：“這是搞數(shù)據(jù)庫的家伙想來搶地盤。” 我覺得編程語言領域的人也是一樣的反應：“實現(xiàn)編程環(huán)境運行時的最佳方式，竟然是使用數(shù)據(jù)庫。”

主持人：這很有意思。我是說，如果它客觀上是正確的，那它也許終將接管一切。

Mike Stonebraker：畢竟，Java 也花了 10 年時間才被廣泛接受。我認為這需要一個漫長的時間周期。

大模型得分 0%？

主持人：我們聊了很多數(shù)據(jù)庫的過去，我很好奇你對數(shù)據(jù)庫領域未解之謎的看法，以及你認為未來會是什么樣。

Mike Stonebraker：好的。我想談兩件不同的事情。第一件事是，和所有人一樣，三年前我們開始研究大語言模型到底能干什么。我們一直試圖讓現(xiàn)在所謂的 Text-to-SQL（自然語言轉(zhuǎn) SQL）在真實的數(shù)據(jù)庫中發(fā)揮作用，特別是在真實的生產(chǎn)級數(shù)據(jù)倉庫中。

我們在四個不同的生產(chǎn)級數(shù)據(jù)倉庫上測試了這項技術，我們獲取了實際用戶在系統(tǒng)中運行的真實工作負載，并讓他們逆向工程出與該查詢序列對應的自然語言文本。所以我們擁有了四個基準測試的文本和 SQL 對照數(shù)據(jù)。

主持人：當你說 Text-to-SQL 時，是指像人類用英語向模型發(fā)出提示詞那樣嗎？

Mike Stonebraker：那些文本可能是：“告訴我麻省理工學院所有年齡超過四歲且獲得過圖靈獎的教授。” 大語言模型據(jù)說很擅長這個。現(xiàn)有的 Text-to-SQL 基準測試，有一個叫 Spider，另一個叫 BIRD，最頂尖的 LLM 系統(tǒng)在這些基準測試上表現(xiàn)相當不錯。準確率能達到 80% 甚至更高。雖然還沒達到超人類的水平，但也相當不錯了。你是會考慮使用它們的。目前的排行榜上大概有 85% 的準確率，已經(jīng)很接近實用了。

主持人：你說它也許還沒完全準備好投入實際應用，但看起來確實相當不錯了。

Mike Stonebraker：然而，在我們的基準測試里，大語言模型的得分是 0%。如果你用 RAG（檢索增強生成）和各種技巧來強化它們，準確率能提升到10%。如果你在提示詞中直接給出 FROM 子句——換句話說，告訴它所有需要訪問的實際表名，以及所有需要連接的 JOIN 條件——準確率能上升到大概35%。所以，這項技術的現(xiàn)狀就是，它根本沒有準備好投入實際應用，而且在很長一段時間內(nèi)都不會，甚至可能永遠都不會。

主持人：區(qū)別到底在哪兒？

Mike Stonebraker：第一，LLM 是在公共語料庫（the pile）上訓練出來的。而數(shù)據(jù)倉庫的數(shù)據(jù)并不在那個語料庫里。有一句老話：如果你以前沒有見過這些數(shù)據(jù)幾次，你根本不可能把它吐出來。這是第一點。

第二，Spider 和 BIRD 測試里的查詢復雜度，大概也就是 10 到 20 行 SQL 代碼。但在真實世界的數(shù)據(jù)倉庫里，那是 100 行 SQL 代碼。復雜度完全不在一個量級。

第三，Spider 和 BIRD 里的數(shù)據(jù)模式（Schema）非常干凈。表名是見名知意的。列名是見名知意的，而且沒有重復。但在數(shù)據(jù)倉庫里，人們到處都在用物化視圖。這意味著存在數(shù)據(jù)冗余，而且列名經(jīng)常是下劃線、Z、大寫字母等等亂七八糟的東西。它們根本不能見名知意。這讓難度大大增加。

最后，他們還有各種極其特殊的數(shù)據(jù)。比如“J-term”在麻省理工學院是個很常見的詞。它是指一月份的一個為期一個月的學期。這并非麻省理工獨有，但也不是很普及。所以，它不在訓練語料庫里，包含極其特殊的數(shù)據(jù)，查詢并不簡單，而且數(shù)據(jù)模式一團糟。這些因素加在一起，讓它根本無法工作。而我所知道的每一個數(shù)據(jù)倉庫都是這副德行。我認為這項技術目前根本行不通，而且在短期內(nèi)也別指望它能行得通。

主持人：那你該怎么辦？

Mike Stonebraker：首先，我們發(fā)布了我們的基準測試。它叫Beaver，是這四個真實數(shù)據(jù)倉庫的匿名化和抽象化版本。如果你覺得自己做 Text-to-SQL 真的很牛，那就來試試真實的基準測試，別玩那些假的。

第二，借用我剛才說的，如果你沒有所有的 JOIN 條件，沒有 FROM 子句，你就徹底完蛋了。更重要的是，如果你不把查詢拆解成更簡單的部分，你也會完蛋。這對我來說意味著，你需要給你的檢索系統(tǒng)提供更簡單的組件，其中包括 FROM 子句和 JOIN 條件。這是第一點。

第二，一旦你想同時與兩個不同的結(jié)構(gòu)化數(shù)據(jù)庫對話，比如你的數(shù)據(jù)倉庫和你的 CRM 系統(tǒng)，那在我看來，用 LLM 來做結(jié)構(gòu)化數(shù)據(jù)的 JOIN 絕對是個餿主意。你最好還是讓它們保持表的形式，然后在 SQL 里做 JOIN。

我們的觀點是，我們正在嘗試把一切都變成表。我們正在和德國慕尼黑市的交通部合作，他們有六個全職人員專門回答市民的投訴和質(zhì)詢，問題大概是這種：“為什么我家旁邊的十字路口，綠燈時間短得不夠我走過去？” 各種各樣的問題。“為什么電車停靠的時間不夠我上車？” “為什么電車一小時才來一趟？”

他們的數(shù)據(jù)庫里，電車時刻表是 SQL。紅綠燈時序是 SQL。十字路口的地圖是 CAD。德國聯(lián)邦關于這些東西的法規(guī)是文本。慕尼黑市的法規(guī)也是文本。所以你得把 SQL、SQL、CAD、文本和文本連接（JOIN）在一起。我們的觀點是，把它們?nèi)嫁D(zhuǎn)換成 SQL，全變成表，然后用一個類似查詢優(yōu)化器的東西來做 JOIN。這就是我們正在研究的方向。我想其他人會有其他的思路，但我認為這是一個極其肥沃的領域，因為人們真的非常需要解決這個問題。這是第一件事。

第二件事，我們之前聊到了智能體 AI（agentic AI）。一旦它涉及到讀寫操作，它就變成了一個分布式數(shù)據(jù)庫問題，你會需要原子性、一致性等等所有這些特性。我認為這是一個非常有趣的領域。所以這基本上就是我現(xiàn)在正在研究的東西。

主持人：在那個目前得分是 0% 的基準測試上，人類能拿多少分？比如你找一個真正懂 SQL 的人，普通人類能得多少分？

Mike Stonebraker：一旦你消除了文本中的歧義，一個熟悉數(shù)據(jù)模式的資深 SQL 程序員能達到極高的準確率。

主持人：好的。大概至少能到 90% 之類的。哇，我真驚訝 LLM 在這種基準測試上得分這么低。也許這期節(jié)目播出去之后，某個在 Anthropic 工作的人會聯(lián)系你，說：“咱們來試試……”

Mike Stonebraker：我很樂意看看結(jié)果，因為如果成了，那將是一個了不起的成功故事。

大模型得分 0%？

主持人：對于那些想要深入理解數(shù)據(jù)庫，并且正在尋找學習資料的人來說，有沒有哪本書是你推薦的頂尖技術書籍，或者是文獻中的經(jīng)典論文？

Mike Stonebraker：喬·海勒斯坦（Joe Hellerstein）和我出版過一本被稱為“紅皮書”的書，叫《數(shù)據(jù)庫系統(tǒng)讀本》（Readings in Database Systems）。它現(xiàn)在已經(jīng)出版八年了。我覺得它作為八年前的閱讀材料是非常棒的，除此之外，可以去讀讀文獻中那些廣受歡迎的論文。

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

Mike Stonebraker：當年我剛在伯克利接下那份工作時，我們連想都沒怎么想，就說：“咱們寫個數(shù)據(jù)庫系統(tǒng)吧。” 我們對數(shù)據(jù)庫一無所知，對底層實現(xiàn)一竅不通。我們也不像比爾·喬伊（Bill Joy，Sun的聯(lián)合創(chuàng)始人）那樣是編程高手。所以，一開始就去做那么瘋狂的事情，真的是挺瘋狂的。但你投入了精力，你讓東西運轉(zhuǎn)起來，你在這個過程中不斷學習。所以答案是：跳出框架思考。敢于有瘋狂的想法，并努力去實現(xiàn)它們。

對我來說，這根本不是什么顯而易見的事。更好的問題是，如果你今天才剛起步，你會選擇什么專業(yè)？因為我認為計算機科學在未來可能不再是一個朝陽產(chǎn)業(yè)了。我不太確定我還會不會建議 18 歲的年輕人們?nèi)ブ餍抻嬎銠C科學。我認為醫(yī)療保健和建筑行業(yè)是安穩(wěn)的選擇，而其他一切看起來風險都要大得多。

如果你即將拿到博士學位，正在猶豫該做什么，我覺得事情很簡單。接受你能拿到的最有名望的工作，找一位愿意幫你的導師，然后選一個不隨波逐流的領域。就像我們做的那個叫 Rubicon 的項目，絕對是不隨波逐流的。選一個逆流而上的方向，然后努力讓它大放異彩。

我和我妻子都曾說過：“追隨你的熱情。錢的問題總會迎刃而解的。”其實我骨子里根本不相信這句話，但我覺得你必須這么告訴你的孩子和孫子們。

主持人：如果你不相信這句話，那你為什么還要這么告訴他們？

Mike Stonebraker：我妻子就是個很好的例子。她有計算機科學的本科學位和碩士學位，但她真正想做的是一名中小學教師。她的父母說：“你不能去教書，那賺不到足夠的錢。” 我覺得從那以后，她一直都在后悔那個決定。她對搞計算機科學并沒有什么熱情；那對她來說只是個謀生的手藝。

所以我認為，找到你熱愛的事業(yè)，你大概率不會餓死——你可能賺不到大錢，但我認為你會有很大的機會，比做一份你不熱愛的工作要快樂得多。因為我認識的很多人，他們僅僅把工作看作是一份工作，認為真正的生活是下午 5 點下班后到第二天早上 8 點上班前的那段時間。我完全不這么想。我真的熱愛我所做的一切。無論我賺不賺錢，這都無所謂。

（投稿或?qū)で髨蟮溃簔hanghy@csdn.net）