計算機還是好專業嗎？傳奇人物深夜長談，給年輕一代的肺腑之言

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

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

這不是一場溫和的數據庫懷舊訪談。

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

大模型到底能不能真的把自然語言變成生產環境里的 SQL？

Agent 真開始讀寫世界之后，數據庫系統會不會重新回到舞臺中央？

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

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

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

即使在當時，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 做到了？

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

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

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

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

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

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

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

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

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

不過有一點也是事實：如果你想快速起步，你遇到了一個數據庫問題，答案就是選擇 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：它非常棘手。它在算法上實在太難了。如果你去問任何一位資深的數據庫程序員最難的部分是什么，他們至今依然會說是優化器。

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

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

主持人：他們為什么要追求最終一致性？

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

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

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

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

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

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

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

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

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

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

對剛 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 也是個好兆頭。

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

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

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

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

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

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

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

大模型得分 0%？

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

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

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

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

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。

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

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

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

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

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

大模型得分 0%？

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

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

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

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

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

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

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

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