Mike Stonebraker 是 2014 年圖靈獎得主，他對數(shù)據(jù)庫系統(tǒng)的奠基性貢獻幾乎寫進了所有相關(guān)教科書。從 Ingres、Postgres，到 Vertica、VoltDB、SciDB，再到最近的 DBOS，每一個都是真正成就了諸多商業(yè)公司的工程系統(tǒng)。

最近他做客 Meta 資深工程師 Ryan Peterman 的播客，與其進行了一個小時的對話。他說話直接，不太客氣。聊到 Larry Ellison 時，他說那人“把現(xiàn)在時和將來時混為一談，本質(zhì)上是在對客戶撒謊”；聊到 Google 當(dāng)年力推的 MapReduce 和最終一致性，他說“那不是 Google 唯一一件愚蠢的事”；聊到亞馬遜同時維護著十五個數(shù)據(jù)庫系統(tǒng)，他說“多了十二個”；

（來源：Youtube）

他也表達了對如今 AI 的看法。在他看來，現(xiàn)在多數(shù) agentic AI 還停在“只讀”，給一個客戶算個分、出個預(yù)測，并不真的去改數(shù)據(jù)庫里的字段。一旦 agent 開始做讀寫，比如兩個 agent 協(xié)作完成一筆轉(zhuǎn)賬，問題就立刻落回數(shù)據(jù)庫的老地盤：事務(wù)、一致性、原子性。

說到大模型寫 SQL，他甩出來幾個數(shù)字。在 Spider、Bird 這些公開 text－to－SQL 基準上，最好的模型已經(jīng)能拿到 85％ 準確率，看起來差一步就能上生產(chǎn)。但 Stonebraker 團隊用四個真實生產(chǎn)數(shù)據(jù)倉庫做了一個新基準 Beaver，在這個基準上，大模型的準確率是 0；加上 RAG 也只到 10％；把 join 條件直接喂給模型，最多到 35％。同樣的任務(wù)，一個懂 schema 的 SQL 工程師能做到 90％ 以上。所以他的結(jié)論是：這項技術(shù)，至少在可見的未來，還不夠格進生產(chǎn)。

談及對年輕人的建議，他說如今已不太確定是否要推薦十八歲的小孩去主修計算機科學(xué)，“醫(yī)療和建筑業(yè)是穩(wěn)妥的選擇”。

下面是這次對話的完整內(nèi)容：

在伯克利，被一個懂門道的人帶進門

Peterman：我第一件想聊的事是 Postgres 是怎么起步的。我想從更早的地方開始，你最初是怎么進入數(shù)據(jù)庫這個領(lǐng)域的？

Stonebraker：我畢業(yè)之后很幸運被伯克利招了進去，但我心里清楚一件事：把博士時候做的東西繼續(xù)往下做，不會有什么前途。那時候和今天一樣，能找到一個懂門道的導(dǎo)師把你帶進門，你就比別人快一截。Gene Wong 把我收到他翼下，他現(xiàn)在還在干活。他說，咱倆一起搞點事情吧。

那是 1971 年，Ted Codd（關(guān)系數(shù)據(jù)庫理論奠基人）那篇開創(chuàng)性的論文發(fā)表在 CACM（《Communications of the ACM》，計算機領(lǐng)域的頂級刊物）上是 1970 年。Gene Wong 說，我們?nèi)パ芯肯聰?shù)據(jù)庫這塊。當(dāng)時關(guān)系模型有兩個對手。一個叫 CODASYL 提案（1960 年代提出的網(wǎng)狀數(shù)據(jù)庫標(biāo)準，把數(shù)據(jù)按“指針網(wǎng)”組織），你大概太年輕沒聽說過。它是個底層的、像意大利面一樣纏繞的網(wǎng)狀結(jié)構(gòu)，要查一條數(shù)據(jù)得一路追指針。另一個是 IBM 的 IMS（Information Management System，IBM 的層次數(shù)據(jù)庫系統(tǒng)，今天還在賣），數(shù)據(jù)是樹形組織的。但 IBM 自己當(dāng)時就承認樹不夠通用，解決不了很多人的問題，于是又加了一層補丁，把它變成一個受限的網(wǎng)狀結(jié)構(gòu)，一看就是個糟糕的補丁。

CODASYL 那套問題一堆。層級太低，調(diào)試起來要命。它還有個性質(zhì)：一旦你的 schema（數(shù)據(jù)結(jié)構(gòu)定義）有任何變化，基本就得把所有東西扔了重來，因為它整個根扎在物理層面。而 Codd 那套東西完全說得通。所以 Gene 說，咱們就來造一個這樣的玩意兒吧，下一步顯然該試這個方向。1972 年他開始造 Ingres（INteractive GRaphics REtrieval System）的雛形，那時候我剛到伯克利當(dāng)助理教授。

Peterman：Ingres 是怎么從一個原型走到真的能用的？

Stonebraker：美國大學(xué)里的助理教授一般有五年的考核期，要么熬到終身教職，要么走人。Ingres 就是我拿到終身教職的敲門磚，1976 年我拿到了。

那個年代很多人寫的原型都是“實驗室風(fēng)”，自己機器上能跑，拿給別人就跑不動了。Ingres 我們先投入了第一個 90％ 讓它能跑起來，然后不知道為什么，又投入了下一個 90％ 讓它真正好用。所以伯克利版的 Ingres 是真能用的。接下來幾年大概有一百所大學(xué)開始跑它，因為 Unix 起來了，而 Ingres 是一套免費的、跑在 Unix 上的數(shù)據(jù)庫。它在學(xué)術(shù)圈相當(dāng)流行。

我們在伯克利開始接待大量訪客，他們會說，這東西看起來真不錯，你們最大的 Ingres 應(yīng)用是什么？我們只能說，其實不太大。

當(dāng)亞利桑那州立大學(xué)考慮用 Ingres 跑他們四萬學(xué)生的學(xué)籍?dāng)?shù)據(jù)時，這個問題得到了充分的印證。他們要裝一個不被支持的操作系統(tǒng)（貝爾實驗室的 Unix），要跑一個不被支持的數(shù)據(jù)庫（伯克利這幫人搞的 Ingres），這兩條他們都能接受。但項目最后死在第三條上：Unix 上沒有 COBOL（一種主要用于商業(yè)數(shù)據(jù)處理的老牌編程語言），而他們是個 COBOL 的店。不被支持的操作系統(tǒng)、不被支持的數(shù)據(jù)庫，再加上沒 COBOL，我們就被判了死刑。

唯一的出路是開公司。1980 年我們拿到了那個年代意義上的風(fēng)險投資，成立了 Ingres 公司，把 Ingres 移植到 DEC 公司（數(shù)字設(shè)備公司，當(dāng)年的小型機巨頭）的 VMS 上，一個真正的操作系統(tǒng)、一家真正能支持產(chǎn)品的公司。這就是商業(yè)化旅程的起點。

Larry Ellison 把現(xiàn)在時和將來時混為一談

Peterman：我看到 Ingres 當(dāng)時是和 Larry Ellison 的 Oracle 在競爭。從能力上看 Ingres 明顯更好，他們怎么還能跟你們爭？

Stonebraker：Larry Ellison 是個一流的銷售。他當(dāng)時基本上把現(xiàn)在時和將來時混為一談，說白了就是對客戶撒謊。他會發(fā)不能用的東西，讓早期客戶幫他 debug。我覺得他做的是非常不光彩的生意，對客戶撒謊在我看來是不可原諒的。

舉個例子，有一個東西叫“參照完整性”（Referential Integrity，關(guān)系數(shù)據(jù)庫里的一種約束：一張表里對另一張表的引用必須真實有效，不能指向不存在的記錄）。比方說你解雇了一個員工，而他正好是某個部門的最后一個人，那你是要把這個部門刪掉，還是留一個空殼部門？諸如此類。Ingres 公司把參照完整性實現(xiàn)了。Oracle 公司寫了兩頁手冊，先把參照完整性的定義寫出來，這部分大家都同意，然后在底下加了一行：尚未實現(xiàn)。

Peterman：有意思。我之前采訪過一個在 Sun Microsystems 干過的人，他對 Larry Ellison 的看法也差不多，覺得這人有點不光彩?？磥硎莻€共識。我還在某處看到你說過，Oracle 收購 MySQL 的時候，所有人都怕了，轉(zhuǎn)去用 Postgres。

Stonebraker：那就是 Postgres 取代 MySQL、成為首選開源關(guān)系型數(shù)據(jù)庫的起點。

一個債券交易員的電話，催生了 Postgres

Peterman：你造了 Ingres，里面有大量技術(shù)創(chuàng)新，讓它比對手強。但最后它還是沒了，你做了 Postgres。Ingres 沒做、而 Postgres 做了的那件關(guān)鍵的事是什么？

Stonebraker：一開始就有一件事埋在我們腦子里。學(xué)術(shù)版 Ingres 最早的目標(biāo)是要支持隔壁那位 Praveen Varah 教授要做的地理信息系統(tǒng)（GIS）。要支持 GIS，你得有點、線、多邊形、線組這些數(shù)據(jù)類型。但 Ingres 顯然搞不定，我們放進 Ingres 的數(shù)據(jù)類型是標(biāo)準那幾樣：整數(shù)、浮點、文本字符串。在這之上你不可能高效地支持 GIS 類型。所以作為一個 GIS，學(xué)術(shù)版 Ingres 是個徹頭徹尾的失敗。這件事一直放在我們腦子后面。

另一件事時間上稍微往后跳一下，但能把這個點說透。大概 1985 年，ANSI（美國國家標(biāo)準協(xié)會）剛提了一個關(guān)系數(shù)據(jù)庫的日期時間標(biāo)準。商業(yè)版 Ingres 把日期時間實現(xiàn)了，用的是標(biāo)準的格里高利歷。我那時候跟商業(yè)版那邊也有聯(lián)系，同時還在伯克利當(dāng)教授。

我接到一個 Ingres 客戶的電話。他說，你們?nèi)掌跁r間實現(xiàn)錯了。我說，我們實現(xiàn)的就是格里高利歷啊，你能做減法，月份有 30 天或者 31 天，二月除外、閏年除外，日期減法就是按你期望的方式工作的。

他說不對，那不是我要的。他做的是債券金融工具。出于某種原因，他的債券每個月付的利息一樣，不管這個月有幾天。他有買債券的日期、賣債券的日期，他想直接做減法，乘以票息率，得到付給客戶的利息。但他要的減法是：3 月 15 日減 2 月 15 日等于 30 天，因為他那套日歷就是這么定義的。結(jié)果他不得不把兩個日期取出來，在用戶代碼里做減法，再把答案塞回數(shù)據(jù)庫，效率掉了兩到三倍。

他說，我為什么不能直接重載你定義的減法，換成我要的版本？當(dāng)然，Ingres 是寫死的。

但他要的東西，本質(zhì)上跟前面那個“點、線、多邊形”是一回事。他要的是債券時間。Postgres 的設(shè)計目標(biāo)就是有一個可擴展的類型系統(tǒng)，你想要什么數(shù)據(jù)類型都行，而且都是高效的。這就是 Postgres 的核心，它有這種靈活性。

業(yè)務(wù)數(shù)據(jù)處理多數(shù)時候用標(biāo)準類型就夠了，但關(guān)系數(shù)據(jù)庫開始擴散到各種地方，人們想要的是抽象數(shù)據(jù)類型，或者叫存儲過程，叫法很多。這種可擴展性給了Postgres 巨大的適用面，這是 Postgres 最大的事情。

Postgres 也支持了當(dāng)時 AI 那幫人想要的繼承機制。我們還做過時間旅行（time travel，讓數(shù)據(jù)庫能查詢歷史時點狀態(tài)），但實現(xiàn)爛得一塌糊涂，過了一陣就被拿掉了。但不管怎么說，Postgres 確實包含很多有意思的東西。

Peterman：你想招的是非常出色的軟件工程師。你之前說過，你找這種人沒什么困難。你怎么識別那種“非凡”的工程師？

Stonebraker：通常很明顯。我對什么事大概有多難，心里有數(shù)。如果他們在學(xué)校里干完的量是我覺得合理水平的三倍，那他們就是非常出色的人。

Peterman：反過來，你說過一句很有意思的話：“我受不了不那么聰明的人，跟他們說話很費勁?！蹦阌质窃趺醋R別一個人不聰明的？

Stonebraker：這事很容易，你跟他聊幾句，很快就能看出來。你的碩士論文做的是什么？具體怎么工作的？錯誤條件你怎么處理的？用了多少進程？為什么不用線程？就是問深度的技術(shù)問題。

一種數(shù)據(jù)庫不可能解決所有問題

Peterman：你做過一個演講，后面也有篇論文，講的是“一種數(shù)據(jù)庫通吃所有場景”是錯的，你想要的是針對具體需求的數(shù)據(jù)庫方案。今天市面上你看到哪些數(shù)據(jù)庫還在試圖通吃？

Stonebraker：我寫那篇論文是 2004 年。我們當(dāng)時有一個學(xué)術(shù)項目，后來變成了 StreamBase（流處理數(shù)據(jù)庫），流處理引擎跟關(guān)系數(shù)據(jù)庫長得一點都不像。我們還有一個列存（按列存儲數(shù)據(jù)，更適合分析型查詢）的雛形，做數(shù)據(jù)倉庫用的，后來 Vertica（基于列存的分析型數(shù)據(jù)庫）把它推開了，列存跟行存也長得一點都不像。三種完全不同的實現(xiàn)，互相沒有任何相似，每一種都比對手快一個數(shù)量級。所以很清楚，你跑一個不是為你這類工作負載設(shè)計的數(shù)據(jù)庫，你就要付一個數(shù)量級的代價。

我覺得今天還是這樣。ClickHouse（開源列式分析數(shù)據(jù)庫）是個列存，Pinecone（向量數(shù)據(jù)庫）做文本向量處理比“用戶自定義類型”那條路要快。所以這個判斷基本沒變。

技術(shù)上沒什么難度把一個統(tǒng)一的解析器架在多種實現(xiàn)之上。Postgres 到現(xiàn)在為止選擇不這么做。它沒有列存實現(xiàn)，所以在大型數(shù)據(jù)倉庫上它不具備競爭力。它也沒有多節(jié)點支持，對大數(shù)據(jù)倉庫來說這是入場券。所以這個觀點今天和當(dāng)年一樣成立。

不過另一個角度也對：如果你想快點干起來，有數(shù)據(jù)庫需求，選 Postgres。社區(qū)巨大，各種數(shù)據(jù)類型實現(xiàn)都有，免費，你能找到 Postgres 直接用。在你撐到每秒百萬級事務(wù)之前，它都用得挺好。在你支撐 PB 級數(shù)據(jù)倉庫之前，它就是那個最優(yōu)解。低端，Postgres 就是絕對的“一種通吃”。高端，這話就不成立了。

Peterman：GPU 會不會給數(shù)據(jù)庫優(yōu)化帶來什么新機會？

Stonebraker：可能。但我覺得最大的挑戰(zhàn)在于，GPU 是 SIMD（Single Instruction Multiple Data，單指令多數(shù)據(jù)），這跟索引正好是反著來的。所以只要“索引”是正確答案的地方，GPU 大概就不是好主意。另外架構(gòu)上你得讓從存儲到 GPU 的帶寬不成為瓶頸。如果 GPU 是 CPU 的附加件，那 CPU 到 GPU 的總線很多時候就是瓶頸。

Peterman：你能解釋一下為什么 SIMD 下索引就不那么有效？

Stonebraker：比方說我要找 Ryan 的工資，我有一棵 B 樹（一種平衡樹索引結(jié)構(gòu)）。你先到根節(jié)點，找到 Ryan 落在哪一邊的分隔符，順著指針走，那是一次內(nèi)存訪問；然后再來一遍，這樣跑三四層。這種過程沒法很好地并行。所以答案是：索引并行不起來。

Peterman：你剛才說 B 樹。第一版 Ingres 那會兒，這些都是你們手寫的嗎？那時候應(yīng)該沒有現(xiàn)成的 B 樹庫。

Stonebraker：對。Ingres 最早的版本完全是從零寫的。

Peterman：那次實現(xiàn)里最難的是哪部分？

Stonebraker：查詢優(yōu)化器（數(shù)據(jù)庫里負責(zé)把 SQL 查詢翻譯成最優(yōu)執(zhí)行計劃的模塊）。

Peterman：為什么這個最難？

Stonebraker：算法上就是難。你今天去問任何一個資深的數(shù)據(jù)庫工程師，最難的部分是什么，他還是會說優(yōu)化器。

那不是 Google 唯一一件愚蠢的事

Peterman：MapReduce 在 2000 年代初出來，在數(shù)據(jù)世界掀起了風(fēng)暴，大家覺得 Google 真懂行，這是面包發(fā)明以來最好的東西。但我看你當(dāng)時和你后來的論文，你強烈不同意。為什么？

Stonebraker：那時候有一大批不太開竅的人，他們說 Google 這么聰明，他們做的肯定是對的，Google 怎么說我們就怎么做。于是一窩蜂上 Hadoop（MapReduce 的開源實現(xiàn)）。但 Hadoop 的效率低得離譜。當(dāng)時 Dave DeWitt（數(shù)據(jù)庫領(lǐng)域元老，威斯康星大學(xué)教授）和我們 2011 年那篇論文的幾個作者都懂分布式數(shù)據(jù)庫，我們清楚分布式數(shù)據(jù)庫系統(tǒng)能把 Hadoop 按在地上摩擦，那篇論文基本就是這么寫的。事實證明也是如此。

而那不是 Google 唯一一件愚蠢的事。同一時期 Google 還在大力鼓吹“最終一致性”是做并發(fā)控制的正確方式，這是他們居高臨下發(fā)布的。但所有數(shù)據(jù)庫圈的人都說，你們腦子壞了，它只解決一小類特殊問題，而那類問題在實際中很少出現(xiàn)。

Peterman：他們?yōu)槭裁醋贰白罱K一致性”？

Stonebraker：這個想法是這樣：你東海岸有個數(shù)據(jù)庫，西海岸有個數(shù)據(jù)庫，互為副本，你想讓它們保持一致。

如果你說，我做一個事務(wù)把西海岸倉庫的小部件數(shù)量減一，提交這個事務(wù)之前，我要先把消息發(fā)到東海岸更新它，再發(fā)回來確認，然后還要再來一輪消息確保兩邊都正確提交，那做一個分布式提交是很貴的，今天也還是這樣。

所以那個想法是：你在西海岸做更新、把庫存減一，只是異步發(fā)個消息出去、不放進事務(wù)里，東海岸最終會被減一。同時如果你在東海岸把另一種貨品減一，你也異步發(fā)消息，西海岸最終也會收到，最后一切收斂。

但如果允許庫存跌破零，會發(fā)生這種事：東海岸和西海岸的人同時賣掉了最后一個小部件，最后倉庫狀態(tài)變成負一，有人拿不到他的貨。

如果你像亞馬遜那樣說“通常 24 小時內(nèi)發(fā)貨”，那也許還能允許超賣。但大多數(shù)企業(yè)做不到。所以最終一致性就是不工作。我們前面提到過參照完整性，在銷售系統(tǒng)里，參照完整性的約束就是“庫存大于負一”，這個約束在最終一致性下崩了。Google 的 Jeff Dean（Google 首席科學(xué)家，MapReduce 和 Spanner 的主要作者之一）后來想清楚了這件事。他們做 Spanner（Google 的全球分布式數(shù)據(jù)庫）的時候，Spanner 是一個傳統(tǒng)的事務(wù)系統(tǒng)，Google 完全放棄了最終一致性，完全放棄了 MapReduce。

Peterman：所以這個權(quán)衡基本上是用正確性換性能。

Stonebraker：是性能 vs 數(shù)據(jù)完整性。如果你不在乎你的數(shù)據(jù)，那你就愿意接受壞事發(fā)生。

Peterman：你當(dāng)時跟 Google 團隊聊過嗎？

Stonebraker：2011 年那篇論文之前我們找過他們，問要不要合作做點事。他們沒興趣，拒絕了。

Peterman：其他大公司呢？亞馬遜、Facebook，有沒有你強烈不同意他們做法的？

Stonebraker：大概三年前我在亞馬遜做過一次演講，把所有我覺得他們做錯的事都講了。亞馬遜的問題是他們在維護十五個不同的數(shù)據(jù)庫系統(tǒng)，大概多出了十二個。他們有自己的文化，我說你們維護的數(shù)據(jù)庫系統(tǒng)太多了。到現(xiàn)在為止他們一個也沒退役。

Peterman：為什么你說十五個應(yīng)該只留三個？

Stonebraker：比方說他們在維護一個圖數(shù)據(jù)庫。但大家都清楚，圖數(shù)據(jù)庫在性能上幾乎從來不是首選。如果你喜歡“節(jié)點和邊”那種用戶接口，沒問題，在關(guān)系數(shù)據(jù)庫之上做一層殼，把這個用戶模型給你就行。他們大多數(shù)數(shù)據(jù)庫系統(tǒng)，都有另一個數(shù)據(jù)庫系統(tǒng)在該做的事上做得更好。所以答案是：任何在足夠大的市場里不具備性能競爭力的數(shù)據(jù)庫系統(tǒng)，你都該退役它，因為維護要錢。

我跟笨人打交道有困難

Peterman：你從學(xué)術(shù)界深刻地影響了產(chǎn)業(yè)。我有個問題：為什么不直接去工業(yè)界？為什么你更愿意留在學(xué)術(shù)界用這種方式產(chǎn)生影響，而不是去 AWS 之類的地方做個杰出工程師？

Stonebraker：因為那樣你頭上就有個老板，有公司規(guī)章，限制你發(fā)表論文的自由，限制你去會議講東西的自由，限制你去探查競爭對手在做什么的自由。但更主要的是，我喜歡做創(chuàng)業(yè)。

商業(yè)版 Postgres 后來被 Informix（1980－1990 年代的關(guān)系數(shù)據(jù)庫巨頭之一）收購，我那時在 Informix 兼職。那是一家兩千人的公司，我感覺做不出什么改變，它官僚，總裁要什么就是什么。我天生不適合搞政治，搞不來。我跟我覺得笨的人打交道有困難。所以我跟大公司有點麻煩。

Peterman：我想聊一下 DBOS，這是個很有意思的技術(shù)模型。能解釋一下 DBOS 是什么嗎？

Stonebraker：我們 2019、2020 年左右開始這個學(xué)術(shù)項目。當(dāng)時 Matei Zaharia（Spark 的創(chuàng)造者，Databricks 聯(lián)合創(chuàng)始人）在斯坦福任教。他說，Databricks 那時候基本上就是在云上跑用戶的 Spark（一種主流的分布式數(shù)據(jù)處理引擎）任務(wù)，任意時刻可能有上百萬個 Spark 任務(wù)在調(diào)度，得寫一個能在百萬級別工作的調(diào)度器。

他說他們試過所有 OS 圈那些人寫的調(diào)度器，都不行，扛不住。所以最后他們把所有調(diào)度數(shù)據(jù)放進了一個 Postgres 數(shù)據(jù)庫，基本就是用一個 Postgres 應(yīng)用來做調(diào)度。

然后我們就意識到：你在操作系統(tǒng)里大部分時間做的事，就是在管理大規(guī)模數(shù)據(jù)。你應(yīng)該用數(shù)據(jù)庫技術(shù)來做這件事。那干脆把 Linux 的上半部分換成數(shù)據(jù)庫系統(tǒng)好了。

那就是這個學(xué)術(shù)項目的主旨。我們在 20 年代初在伯克利和斯坦福做這個，做得相當(dāng)成功，確實能跑通。過程中斯坦福那邊給 JavaScript 寫了一個擴展，因為你需要某種編程入口跟你的實現(xiàn)對話。

如果你做的是一個跑在數(shù)據(jù)庫之上的“操作系統(tǒng)”，而你又有一個編程語言運行時，那很自然就是把所有狀態(tài)都放到數(shù)據(jù)庫里，他們就是這么做的。所以我們既有一個創(chuàng)新的編程語言模型，也有一個創(chuàng)新的操作系統(tǒng)模型。

接下來當(dāng)然是想，能不能做公司？我們跟風(fēng)投聊，沒有一個人不說“你想取代 Linux 那是做夢”，但他們都說，你這個編程語言部分很有意思。我們的 JavaScript 擴展能讓任何程序都擁有數(shù)據(jù)庫系統(tǒng)的那些好性質(zhì)：狀態(tài)是持久的，你可以有事務(wù)，失敗時可以故障轉(zhuǎn)移，這些好東西。

2023 年我們拿到融資成立了 DBOS（Database Operating System）公司，這一直是項目的名字。但我們做的實際上是編程語言生意。今天 DBOS 有 TypeScript 版本、Java 版本、Go 版本、Python 版本，都是無縫的，看起來就是普通程序，但跑在云的世界里。

Peterman：這跟最初那個“用數(shù)據(jù)庫替換操作系統(tǒng)內(nèi)核”的研究項目相比，是不是收窄了？

Stonebraker：現(xiàn)在每個人都有動機把應(yīng)用結(jié)構(gòu)組織成“工作流”。所以我們決定就支持工作流系統(tǒng)。DBOS 在那四種語言下支持的工作流，里面的每一步，叫微操作也好叫別的也好，都是事務(wù)性的。工作流是持久的，一步走完不會被忘記。如果有人有市場需求，我們可以做到工作流是原子的：整個工作流要么完成，要么看上去從未發(fā)生過。它的性質(zhì)非常好，比競爭對手快很多、用起來也容易很多。公司在這塊賣得很好，也在持續(xù)創(chuàng)新。

整個想法是，把應(yīng)用的狀態(tài)放到數(shù)據(jù)庫里讓它持久化，然后想辦法跑得快。商業(yè)模式是先抓底層程序員，跟他們說，你需要什么我們沒有，告訴我們，我們盡快加上，把人拉過來試。

Peterman：今天 DBOS 的客戶主要在哪些場景？

Stonebraker：我們在很多創(chuàng)業(yè)公司里很成功，他們想選最好的東西。我們也開始打進大客戶。今天大概三分之二的客戶在做 agentic AI，一個大語言模型，周圍加一堆增強信號的東西。目前為止 agentic AI 大多是只讀的，比如你要給“Ryan 是不是好客戶”產(chǎn)出一個預(yù)測，跑一堆東西出一個新結(jié)果給某個人。本質(zhì)上是只讀的，你沒真的去改 Ryan 的信用評級。

我估計很快整個世界就會用 agent 做讀寫應(yīng)用，那它就會變得非?！皵?shù)據(jù)庫”，而 DBOS 在這塊做得特別好。比方說你寫兩個 agent，把我賬戶里的 100 美元轉(zhuǎn)到你賬戶：一個 agent 把我賬戶減 100，另一個把你賬戶加 100，這兩個 agent 必須要么都提交、要么全部回滾，也就是說工作流必須是我說的“原子的”，要么發(fā)生，要么看起來沒發(fā)生過。我覺得這個市場對原子性的需求會越來越高，這對 DBOS 是好事。

Peterman：那今天向應(yīng)用開發(fā)者交付的 DBOS，跟最初那個“把操作系統(tǒng)內(nèi)核換成數(shù)據(jù)庫”的研究版本不一樣了。這其實挺酷的，我以前沒想過把操作系統(tǒng)所有狀態(tài)都放進數(shù)據(jù)庫。這里一定有什么權(quán)衡吧？

Stonebraker：在 DBMS（Database Management System，數(shù)據(jù)庫管理系統(tǒng)）之上寫的文件系統(tǒng)比 Linux 文件系統(tǒng)更快。調(diào)度引擎跟其他調(diào)度引擎相比也有競爭力。所有東西都能故障轉(zhuǎn)移，你不用做任何額外的事就拿到了高可用。答案是沒什么壞處。

Peterman：那為什么 Linux 不去吸收這個，把自己升級一下？

Stonebraker：你希望他們這么做。意思是，把所有設(shè)備驅(qū)動那些雜事留在底層，東西多沒人想碰，把上面的東西全部換成數(shù)據(jù)庫實現(xiàn)。

Peterman：你跟 Linux 圈的人提過嗎？他們的反應(yīng)通常是什么？

Stonebraker：學(xué)術(shù)項目階段，我跟操作系統(tǒng)那幫人提的時候，他們會覺得很被冒犯，覺得這是數(shù)據(jù)庫圈的人在搶他們的地盤。編程語言的人也一樣，他們覺得編程環(huán)境的運行時該是他們的，我們說運行時該用數(shù)據(jù)庫做，他們也不爽。

Peterman：有意思。但如果客觀上是對的，可能它最后會贏。

Stonebraker：Java 也用了 10 年才被廣泛接受，這種事的時間常數(shù)我覺得就是大。

在我們的基準上，大語言模型得 0 分

Peterman：咱們聊了很多過去的事，我想知道你怎么看數(shù)據(jù)庫領(lǐng)域那些沒解決的問題和未來。

Stonebraker：有兩件事我想說。第一件，跟所有人一樣，三年前我們開始看大語言模型能干什么。我們一直在做 text－to－SQL（讓模型把自然語言問題翻譯成 SQL 查詢）。我們想讓它在真實世界的數(shù)據(jù)庫上工作，尤其是真實世界的數(shù)據(jù)倉庫。我們在四個生產(chǎn)級的數(shù)據(jù)倉庫上試，拿到了真實的用戶工作負載、真實運行的查詢，讓真實用戶回過頭給我們提供這些 SQL 對應(yīng)的自然語言文本。所以我們有四個真實的 text－to－SQL 基準。

Peterman：你說 text－to－SQL，意思是人用自然語言對模型說，比如“四歲以上的所有人”這種？

Stonebraker：比方說“告訴我所有在 MIT 拿過圖靈獎的教授”。LLM 應(yīng)該擅長這件事。Text－to－SQL 已經(jīng)有公開基準，一個叫 Spider，一個叫 Bird（兩個學(xué)術(shù)界主流的 text－to－SQL 基準數(shù)據(jù)集）。最好的 LLM 系統(tǒng)在這些基準上挺不錯，80％ 準確率以上，當(dāng)前榜首大概 85％，你會考慮用它，雖然還不到生產(chǎn)級。

但在我們的基準上，大語言模型的準確率是 0％。如果你給它加上 RAG（檢索增強生成）和所有那些花招，能到 10％。如果你在 prompt 里直接告訴它 from 子句，也就是把所有要訪問的表、所有要做的連接條件都喂給它，準確率到 35％ 左右。這東西離生產(chǎn)級很遠，而且短期內(nèi)大概也到不了，如果它真的能到的話。

那區(qū)別在哪？

第一，數(shù)據(jù)。LLM 是在 The Pile（Eleuther AI 制作的開源大模型訓(xùn)練語料庫，800GB 文本）上訓(xùn)練的，數(shù)據(jù)倉庫里的數(shù)據(jù)不在 The Pile 里。有句老話，如果你之前沒見過這數(shù)據(jù)幾次，你沒機會把它復(fù)述出來。這是第一。

第二，查詢復(fù)雜度。Spider 和 Bird 上的查詢大概十到二十行 SQL，真實世界數(shù)據(jù)倉庫里是一百行 SQL，復(fù)雜度差一個量級。

第三，schema。Spider 和 Bird 里的 schema 是干凈的，表名是助記的，列名是助記的，沒有重復(fù)。但真實數(shù)據(jù)倉庫里，人們到處建物化視圖（materialized view，預(yù)先計算好的查詢結(jié)果，加速分析），意味著到處有冗余；列名經(jīng)常是 underscore＿z＿uppers＿andre＿blah 這種，毫無助記性，很難。還有他們有特異數(shù)據(jù)，比方說 J－term（MIT 等美國大學(xué)一月份的一個迷你學(xué)期）在 MIT 是個流行詞，一月份的一個一個月學(xué)期，這個詞不只 MIT 有，但也不普及，不在 The Pile 里。特異數(shù)據(jù)、查詢復(fù)雜、schema 一團糟，這三件事在我知道的每個數(shù)據(jù)倉庫里都成立。所以這技術(shù)就是不工作，短期內(nèi)也不會工作。

Peterman：那你們怎么辦？

Stonebraker：第一，我們把基準發(fā)表了，叫 Beaver，是這四個數(shù)據(jù)倉庫的脫敏抽象版本。如果你覺得自己 text－to－SQL 做得很好，來真基準上試，別老在假的上跑。

第二，接著我剛才說的，如果你拿不到 from 子句、拿不到所有連接條件，你就完蛋；如果你不把查詢拆成更簡單的小塊，你也完蛋。這告訴我什么呢？你想給檢索系統(tǒng)更簡單的小塊，小塊里要包含 from 子句、要包含連接條件。這是一。

第二，你一旦想跨兩個不同的結(jié)構(gòu)化數(shù)據(jù)庫聊，比如你的數(shù)據(jù)倉庫和你的 CRM 系統(tǒng)，那很顯然，用 LLM 做結(jié)構(gòu)化數(shù)據(jù)連接是個壞主意。你最好把它們留在表里，做 SQL 連接。所以我們的視角是，把所有東西都變成表。

我們在跟德國慕尼黑交通部合作。他們有六個全職的人在回答市民投訴性的查詢，比方說“為什么我家旁邊的路口綠燈時間不夠我過馬路”、“為什么電車停的時間不夠我上車”、“為什么電車一小時才來一班”。他們的數(shù)據(jù)庫里有什么？電車時刻表是 SQL，信號燈時序是 SQL，路口圖是 CAD（計算機輔助設(shè)計文件），德國聯(lián)邦的相關(guān)法規(guī)是文本，慕尼黑市的相關(guān)法規(guī)也是文本。所以你要做的是 SQL × SQL × CAD × 文本 × 文本的連接。

我們的視角是把它們?nèi)孔兂?SQL、變成表，然后用一個相當(dāng)于查詢優(yōu)化器的東西做連接。這就是我們現(xiàn)在在做的事。我覺得別人會有別的想法，但這是個非常肥沃的領(lǐng)域，因為人們真的想做這件事。這是一。

第二，前面說的 agentic AI，一旦它變成讀寫，它就是個分布式數(shù)據(jù)庫問題，你要原子性、要一致性、要那一整套東西。我覺得這是非常有意思的領(lǐng)域。這就是我現(xiàn)在在做的。

Peterman：你剛才說的那個基準，LLM 現(xiàn)在拿 0 分，人能拿多少？如果你找一個真懂 SQL 的人，他能打多少？普通人呢？

Stonebraker：一旦把自然語言部分消歧之后，一個懂 SQL、了解 schema 的程序員，準確率會非常高。

Peterman：90％ 這個量級？

Stonebraker：至少。

Peterman：好。我挺意外大模型在這種基準上得分這么低。也許這期播客出去之后會有 Anthropic 的人聯(lián)系你或者怎樣。

Stonebraker：我很想知道，因為這會是個很棒的成功故事。

計算機科學(xué)不一定還是個增長行業(yè)

Peterman：對那些想深入理解數(shù)據(jù)庫的人，你會推薦什么材料？有什么頂級的技術(shù)書？

Stonebraker：文獻里的論文。我和 Joe Hellerstein（伯克利數(shù)據(jù)庫教授，與 Stonebraker 長期合作）出過一本叫《Readings in Database Systems》的“紅皮書”，但已經(jīng)八年了。作為八年前的讀物我覺得它很好。除此之外就是文獻里有名的論文。

Peterman：如果你能回到剛畢業(yè)那會兒，以你今天知道的事給自己一個建議，你會說什么？

Stonebraker：我剛到伯克利接那份工作的時候，沒怎么思考過就說，我們來寫一個數(shù)據(jù)庫系統(tǒng)吧。當(dāng)時我們對數(shù)據(jù)庫一無所知，對實現(xiàn)也一無所知，我們也不是 Bill Joy（BSD Unix 主要作者，Sun Microsystems 聯(lián)合創(chuàng)始人）那種水平的程序員。開局做這種事，真的相當(dāng)瘋狂。但你硬著頭皮干，讓它能跑起來，一路上學(xué)。所以答案是：跳出框架，想些瘋狂的事，去做。

更好的問題是：如果你今天剛開始，會主修什么？因為我覺得計算機科學(xué)未來不一定是一個增長行業(yè)。我現(xiàn)在不太確定我會推薦 18 歲的小孩去主修計算機科學(xué)。

我覺得醫(yī)療和建筑這些行業(yè)是穩(wěn)妥的賭注，其他都看起來風(fēng)險大不少。如果你即將拿到博士學(xué)位、要決定接下來做什么，那其實容易：挑你能拿到的最有聲望的工作，找一個愿意幫你的導(dǎo)師，選一個不隨大流的方向。比方說我們的項目 Rubicon，就是不隨大流的。

我和我太太總跟人說，跟隨你的熱情，錢總會有的。但說實話我一秒鐘都不信這話，我覺得這只是你必須告訴孩子和孫子的話。

Peterman：既然你不信，為什么你必須這么說？

Stonebraker：我太太就是個例子。她有計算機科學(xué)的碩士和本科學(xué)位，但她想做 K－12 老師。她父母說，你不能這么做，賺不到錢。我覺得從那以后她一直后悔這個決定。她對計算機科學(xué)沒什么熱情，只是把它當(dāng)個手藝干。所以答案是：找你有熱情的事做，你不會餓死，可能賺不到大錢，但你大概率會比做你沒熱情的事更快樂。

我認識很多人把工作僅僅當(dāng)工作，生活是發(fā)生在下午五點到早上八點之間的事。我完全不是這樣，我真的喜歡我做的事，賺多少錢不重要。

參考資料：

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

排版：胡巍巍

注：封面/首圖由 AI 輔助生成