前言與歡迎

好的，各位晚安。我的名字是Rajiv Gupta。我是今年FCRC的會議主席。我代表FCRC的所有組織者，歡迎各位參加本次活動。FCRC仍然是一個非常受歡迎的活動。今年有12個主要的ACM會議在這裡舉行，還有大約40場工作坊。涵蓋的主題從計算複雜性到高性能計算應有盡有。今天早上我得知，已經有2300人註冊參加FCRC的活動了。如您所知，本次會議的亮點之一是我們的全體會議。今年我們有五位傑出的演講者，每天一位。請大家務必把握機會。當然，我們今晚將以Professor Stonebraker的圖靈演講開始。非常榮幸他能來到這裡。他決定在此活動中發表演講，這真是一份榮譽。在開始之前，我想花幾分鐘時間感謝在過去幾個月甚至幾年來辛勤工作的一些人。首先，我要感謝我們的全體會議主席Professor Vivek Sarkar。他是Rice University電腦科學系的系主任，他撥出時間組織了全體會議。我對此深表感激。當然，我們的ACM員工為組織這些活動付出了巨大的努力。特別是，我要感謝Donna Capo。事實上，Donna在ACM工作了超過30年，她在1993年組織了第一屆FCRC，並且一次又一次地這樣做，包括今年。我認為不誇張地說，如果沒有她在這裡，我們就不會有這次會議。這真是一項巨大的工程。當然，我感謝所有會議的組織者，也就是各個會議的組織者。他們與Vivek和Donna合作，將一切整合在一起。贊助商慷慨解囊，支持我們的全體會議。希望大家會議順利。接下來，我將邀請ACM主席Professor Alexander Wolff，來自Imperial College London，來介紹Professor Stonebraker。謝謝。

謝謝，Rajiv。晚安。非常榮幸歡迎各位參加由ACM圖靈獎得得主帶來的AM圖靈講座。這項榮譽以英國數學家、科學家和工程師Alan M. Turing命名，常被譽為計算領域的諾貝爾獎。它是電腦科學家能獲得的最負盛名的技術獎項，並且從今年開始，附帶有Google慷慨提供的100萬美元獎金。該獎項授予對計算領域做出持久重要貢獻的個人。像諾貝爾獎一樣，它不是終身成就獎，而是旨在表彰特定的基礎性貢獻。在介紹我們最新的圖靈獎得主之前，我想藉此機會簡要介紹一下我們組織ACM的現狀。我們仍然是全球最大、最負盛名的計算專業人士和學生國際學會，目前在全球擁有111,000名會員。我們的會員數量在過去17年持續增長，儘管產業經歷了各種起伏。有兩個事實可能會讓一些人感到驚訝：我們的會員中居住在北美地區的不到一半，而超過一半是從業人員。當然，ACM以其高品質的出版物和會議項目、充滿活力的特別興趣小組以及數字圖書館而特別聞名。但是，我們組織的這些瑰寶一如既往地不斷演進，以滿足會員的需求，這得益於我們志工的努力和優秀總部員工的支持。例如，ACM的志工和員工正在投入巨大的努力，重新思考學術出版的未來。我們為我們的SIG提供更多選項，以實現其出版內容的公共訪問。我們正在努力滿足所有政府關於我們產出的資助研究成果公共訪問的要求。我們正在認真思考未來發表的文章應該是什麼樣子，以及未來文章的數字集合應該如何呈現。重要的是，ACM獨具特色之處在於，它超越了這些特定的技術項目，支持旨在填補從學校最早階段到大學學習的管道的主要項目，將更多女性和少數族裔帶入計算領域，為政府決策者提供技術建議，並幫助開發中國家發展其當地計算專業並與世界計算機科學家、工程師和教育家社群互動。我們將這些以及許多其他此類項目稱為ACM的「善舉」(good works)，因為它們旨在超越我們狹隘的技術興趣，幫助解決社會挑戰，坦白說，這些挑戰在其他任何地方或任何人那裡都幾乎沒有支持來源。這些善舉是社群中的志工創造和推動的活動，他們投資於他們認為既及時又重要的項目。如果您是計算專業人士或學生，並且如果您想為您的社群乃至更廣泛的社會做出貢獻，我強烈建議您成為或繼續成為ACM會員。在這個方面，我想不出比我們最新的圖靈獎得主Michael Stonebraker更好的榜樣了，自1971年以來，他一直是ACM的持續會員，比我出生早得多。Mike目前是MIT計算科學與人工智慧實驗室的兼職教授，同時也是Intel大數據科學與技術中心的聯合主任。他在加州大學柏克萊分校擔任教授，度過了他大部分的職業生涯，事實上是29年。也許沒有哪位電腦科學家比Mike更能將理論與實踐結合起來。他和他的學生及合作者發明了許多使資料庫系統在市場上成功並持續成功的概念，並通過一系列商業初創公司將這些想法轉化。通過開發Ingress，他引入了查詢修改的概念，並證明了關聯式資料庫的可行性。通過發布Postgres，他引入了物件關聯式模型，將物件導向程式設計的關鍵思想整合到關聯式資料庫語境中。如今，他引入的概念存在於所有主要的資料庫系統中，無論是商業的還是開源的。在他的整個職業生涯中，他也一直是資料庫研究社群的領導者和導師。Mike今晚的演講標題是「The Land Sharks Are on the Squawk Box」。請大家和我一起歡迎2014年ACM圖靈獎得主Michael Stonebraker。

謝謝。好的，如果運氣好的話，這個麥克風開著。攝影師說我必須像前兩位演講者一樣穿西裝打領帶，我說不行，那不是我的風格。所以，你看到的就是真實的我。我們可以把第一張幻燈片放出來嗎？正如Alex所說，我是個資料庫專家。所以我知道你們都不是資料庫專家，因為SIGMOD不在這裡。因此，你需要了解一些關於資料庫的知識，才能理解我今晚要講的內容。所以，這是我接下來要講的一些內容的背景。1970年，Ted Codd撰寫了他開創性的CACM論文。如果你對資料庫有任何興趣，這篇文章是必讀的。他說，所有資料都應該儲存在關聯（relations）中，如果你願意，可以將它們視為表格，這是儲存資料的最簡單可能的資料結構。他說你不應該編寫演算法來尋找你感興趣的資料。你應該只用高階語言表達你想要什麼。如今，這就是SQL。因此，SQL on tables是進行資料庫管理的最佳方式。在1970年代，開發了兩個體現他思想的主要原型系統。第一個是System R，由約15位IBM博士撰寫，另一個是Ingress，由我和幾個學生及一名全職程式設計師組成的臨時團隊撰寫。它們是具備完整功能的資料庫管理系統，體現了Ted Codd的思想。

The Land Sharks Are on the Squawk Box

好的。正如Alex所說，「The Land Sharks Are on the Squawk Box」。Alustra這家公司正在將我一兩年前創辦的Postgres進行商業化，它已瀕臨耗盡資金。我們沒錢了，我的工作是籌集更多資金。正如你們可能都知道的，初創公司會失敗。它們只以一種方式失敗：資金耗盡時。所以這是一個問題，因為我當時正在參加一個家庭活動，在我哥哥的釣魚小屋裡，也就是這張幻燈片裡顯示的地方。我們八個人擠在這個小木屋裡，而land sharks，我們對風險投資支持者的暱稱，正在使用擴音電話（squawk box）與我通話，我則待在這個小木屋的浴室裡。那是在手機還沒有普及的時代。牆上電話的線被拉長穿過浴室門，我正在與鯊魚們談判，試圖獲得更多資金。這是一段令人沮喪的熟悉對話。他們說：「更多錢，更低的價格。」我說：「更少的錢，更高的價格。」最終我們達成了協議，Alustra得以倖存下來，繼續奮鬥。

演講大綱

這是今晚演講的大綱。我要做的是穿插兩個故事。第一個是我妻子和我在1988年進行的一次自行車旅行。第二個是Postgres從80年代後期到90年代中期，大約十年間的開發和商業化過程。這兩個故事都始於情感上的高潮，但正如你們從這張圖表上看到的，前面會有很多減速帶。

自行車之旅：Anacortes到Winthrop

1988年6月4日，我們來到華盛頓州的Anacortes，這是通往Puget Sound外島的渡輪碼頭。我和妻子正要開始向東騎行，沿著North Cascade Scenic Highway前進。我們的目的地是馬薩諸塞州的Boston，大約3500英里的自行車程。我們完全不為從未騎過...

Postgres的誕生與願景

比我們正在繼續開發原型的學術版好得多。繼續在這個代碼線上工作毫無意義。是時候把代碼推下懸崖，開始一個全新的東西了。放棄你已經工作了十年的代碼是一個艱難的決定。但重點是，那麼Postgres將是什麼？Postgres誕生了，它會是什麼樣子？首先，它將會是什麼呢？那時，Ted Codd的論文已經發表了14年，Ingress和System R也存在了一段時間，大量的研究人員拿起了開源版本的Ingress或嘗試了System R，並將其應用於各種不同的問題。一定有大約20篇論文是這種形式的：「這個很棒的關聯式資料庫東西，每個人都在讚美它，所以我們在問題X上嘗試了一下。順帶一提，它沒起作用。所以我們向關聯式模型添加了Y來修復它。」當時的X是地理資訊系統、圖書館資訊系統、電腦輔助設計等很多不同的東西。這揭示了一個顯而易見的事實，那就是Ingress和System R完全專注於商業數據處理。當時這是唯一重要的資料庫市場。我們的目標是做得比當時的商業系統更好，那些系統包括IMS和CODASYL，它們都在做商業數據處理。我們從未考慮過更普遍的問題。我們專注於商業數據處理。研究社群很快指出，當時的關聯式資料庫系統非常脆弱。因此，我們在Berkeley做的一件事就是研究地理資訊系統，比如點、線、多邊形、線組等所有這些東西。幾分鐘後，我們將使用一個員工範例，所以我只是在這裡借用一下。假設我們有一個員工，有姓名和年齡。這是Sam Madden，我的MIT同事。假設有一個與員工或個人相關的矩形。把它想像成他房子地塊的大小，然後把它拉成正方形，做成曼哈頓幾何形狀，讓事情盡可能簡單。所以你可以用四個數字來表示一個盒子：X的最小值和最大值，Y的最小值和最大值。然後，如果你必須做——如果你想獲得分區變更，例如在你房子上做一些線條改進，你必須通知一定距離內的所有人。也就是說，如果你拿出你的地塊，將其擴大到那個距離，你會得到一個更大的矩形，並且你想找到附近地塊的所有與這個擴大矩形重疊的矩形。這是你能想到的最簡單的地理資訊系統查詢，它就在幻燈片的底部。你可以找出如何在SQL中編寫這段代碼。這是經過修改的SQL。我妻子說我不能放真實的SQL語法，所以為了尊重她，我把它簡化了。這是你能想到的最簡單的事情，你需要思考一分鐘才能意識到它是正確的。我很確定它是正確的，但你應該驗證一下。而且很難優化。所以你能想到的最簡單的事情都很麻煩。如果你想嘗試真正困難的事情，就試試「點是否在多邊形內」(point in polygon)。所以在SQL中編寫這些東西效果不太好。

我的想法是，問題在於當時的關聯式資料庫系統，即Ingress和System R，只有浮點數、十進制數、字串和整數作為基本資料類型，僅此而已。問題是GIS不容易用這些資料類型表達。我真正想要的是盒子、多邊形、點以及所有GIS特有的東西。所以假設我可以有一個資料庫系統，它不是前一頁有六個字段，而是只有三個。所以我有名稱、年齡，然後是位置，位置將是一個盒子類型的東西。所以那裡儲存的是盒子的某種表示形式。然後有了那個數據結構，我現在就可以只尋找位置——那是這個表格中的一個字段——與某個擴大矩形重疊的人的名字。這個「重疊」(overlaps)將是一個新的運算符，因為誰說你只能有小於、大於、等於這些運算符？誰說那些是正確的運算符？所以讓我們有一個新的運算符，「重疊」。然後我想有一個函數，誰說我不能有函數？所以我想用前一頁的四個浮點數來製作一個盒子。現在這個查詢的正確性顯而易見了，而且代碼少了很多，所以應該更容易優化。總的來說，我想要的是用戶定義的數據類型（矩形、盒子、多邊形等等）、用戶定義的運算符（比如重疊、包含等等）和用戶定義的函數。那麼為什麼不只是將這個通用機制添加到關聯式資料庫系統中呢？這正是Postgres所做的，或者說Postgres提議要做的。所以這需要將用戶定義的函數添加到資料庫引擎中，然後在查詢執行的適當時候調用它們。當然，像大多數事情一樣，細節決定成敗。資料庫系統必須為對象建立索引才能快速運行。所以它們有B樹和散列作為標準的索引機制。所以你必須對這些新類型的對象使用並發索引。如果你想讓GIS的東西快速運行，這通過B樹和散列是不會發生的。你需要R樹之類的東西，所以你需要能夠添加新型的索引。你需要教導查詢優化器——它是負責找出如何實際執行SQL的東西——關於新類型，然後指定一些資料庫喜歡了解的其他東西。所以細節決定成敗，Postgres，也就是我，我們必須弄清楚這些東西。

自行車之旅：征服喀斯喀特山脈

回到我們的自行車旅行。這是第三天。我們在華盛頓州的Winthrop。你可以在左邊看到我，右邊是Marianne，她是Berkeley大學的一年級新生。我們雇她整個夏天為我們開車並照顧我們18個月大的女兒Leslie，Leslie將在路上度過整個夏天。我的腰以下都很痠痛，但我非常高興。這一天從早上5點開始。一根電線桿接著一根電線桿，一根電線桿。我們從Diablo Lake奮力騎行上坡大約50英里。在此過程中，我們爬升了5000英尺進入喀斯喀特山脈。天氣越來越冷，越來越冷，但即便如此，我們仍然對山口頂附近的暴風雪毫無準備。又冷又濕又累，我們終於到達了恰如其名的Rainy Pass。我們身穿所有帶來的自行車服裝站在山口頂上。從那裡，你可以稍微喘口氣下坡，然後再爬升1000英尺到達Washington Pass的頂部。之後，就可以光榮地騎行下坡進入Winthrop了。正如我所說，我非常高興。前面還有很多山要爬，但我們已經翻過了頭兩座，而且我們證明了我們可以征服山脈。

創新二：規則系統

回到Postgres。Chris Date，一位關聯式資料庫領域的先驅，寫了一篇關於所謂「參照完整性」(referential integrity)的開創性論文。基本上，它與資料庫領域所稱的外鍵(foreign key)和主鍵(primary key)約束有關。這裡有一個非常簡單的小例子，使用了至今仍流行的部門和員工例子，這基本上來自所有早期的關聯式資料庫論文。

employees 表格
name, salary, age, department
Bill, 50000, 25, shoe
Art, 60000, 30, candy
...
department 表格
name, floors, square footage, budget
shoe, 1, 1000, 100000
candy, 2, 2000, 200000
...

你可以看到，在employees表格中，department這一欄實際上是指向另一個表格中一個元組（tuple）的指針。所以你可以看到Bill在shoe部門，它指向另一個表格中的第一條記錄。所以employees表格中的department是一個外鍵。department表格中的department name是一個主鍵。問題是，如果有人來刪除了candy部門，你該怎麼辦？所以第一個表格中的第二行現在不見了。請注意，Art現在有一個懸空指針。那麼，你該怎麼處理懸空指針呢？Chris的解決方案是所有合理的可能性。你可以做的一件事是級聯刪除（cascade delete），也就是你刪除candy部門，並解僱其中所有人。第二件事是移除candy部門，並將所有原先在candy部門的人的department欄位轉換為null。所以他們現在無家可歸了。第三件事是拒絕刪除，因為這會造成混亂。所以你可以讓資料庫系統只說你不能刪除一個裡面還有員工的部門。然後Chris Date有三種相應的在插入時的操作。到那時，他的論文在1981年發表了，而且在商業系統中實現這個功能有很多興趣。所以你可以看到，需要一個相當簡單的小型規則系統來強制執行所有這些功能。問題是，這不是我們唯一需要處理的規則系統。這個參照完整性，請確保它是正確的。到那時，人們已經開始對通用觸發器產生興趣了，觸發器是指自動發生的輔助動作。例如，如果你有一個員工Sam，你更新了他的薪水，則將這個更新級聯到Bill，以確保Bill和Sam賺取相同數額的錢。第三種所需的規則系統是通用完整性約束...

資料庫領域的人討厭這種情況，也就是說，答案取決於執行的順序，這是完全不合理的。由於SQL能夠同時更新一組事物，這被稱為事務（transactions），如果你的規則是順序相關的，那就會完全搞砸。我討厭規則系統的另一點是，你開始看到一些論文，裡面有20行的規則程式，但沒有人能弄清楚它們在做什麼。所以，除了那些熱愛Datalog的人，沒有凡人能理解20行的Prolog程式。

好的，所以我討厭if-then規則系統。因此，我的想法是嘗試押注於別的東西，任何別的東西。所以我的解決方案或提議的解決方案是，既然我們有SQL這個面向集合的語言，為什麼不添加一個我當時稱之為「always」的標記呢？也就是說，任何更新的語義都像是它一直在運行，也就是說它看起來像是總是在執行。所以幻燈片上是一個更新，將Sam的薪水設定為這個數字，將Bill的薪水設定為與Sam相同。如果它看起來像一直在運行，無論你做什麼，這個東西都會一直在運行，而且看起來像一直在運行，這將確保Bill擁有與Sam相同的薪水。這比通用的if-then規則系統具有更清晰的語義，至少是值得研究的另一種方案。所以這就是我們打算探索的，用「always」命令標記SQL查詢。

自行車之旅：越過落磯山脈

好了，我們來到蒙大拿州的Marius Pass。這是第15天。Leslie坐在我的肩膀上。這是光榮的一天。但更特別的是，喀斯喀特山脈和落磯山脈所有無盡的山路都已在我們身後。現在可以一路下坡到芝加哥了。

創新三：無覆寫儲存實現崩潰恢復

好的，Postgres打算押注的第三個原則是崩潰恢復（crash recovery）。在Ingress和System R中，你對資料庫系統如何工作的想法是：你們都看到過這樣的圖，一個資料庫系統管理著一個資料庫，通常畫成一個圓筒。那就是左邊的東西。不幸的是，還有第二個正在管理的資料庫。它叫做日誌（log）。實際上，你有兩個具有不同訪問模式、不同訪問引擎的資料庫，而且必須非常、非常仔細地同步。這一切的目的就是為了能夠從崩潰中恢復。如果你正在進行一個事務，並且你已經更新了一些數據，然後在此時崩潰了，那麼你就只有一個部分完成的事務。你必須將其回退。你必須使用日誌來做這件事。你必須確保在寫入數據之前日誌已經寫入。否則，你就有麻煩了。日誌代碼既醜陋又複雜。而且麻煩的是，它真的、真的必須工作。因為如果它不工作，有一句諺語，墨菲定律說它總是在你最重要的客戶那裡發生，而且是他們最大的問題。如果這發生在足夠重要的客戶身上，你就會上《華爾街日報》的頭版。所以你的日誌代碼必須工作。它必須超可靠，而且它既醜陋又複雜，並且很難測試，因為你不能對一個電腦系統說：「你現在大概崩潰一下吧，這樣我就可以測試我的恢復代碼了。」這就是崩潰恢復的工作方式。它很複雜很醜陋。我們在Ingress中就是這樣做的。我說，我不想再做一次了。太噁心了。所以想法是這樣的。如果你只是不原地更新，而是簡單地寫一個新的記錄，包含你更新的新版本，把舊的記錄留在原地，這就可以作為恢復日誌了。實際上，你正在將數據和日誌合併到一個系統中，使用單一的訪問機制。你所要做的就是仔細地給所有記錄打上時間戳，你就可以擺脫所有這些醜陋的崩潰恢復代碼了。作為一個很好的附帶好處，如果你給所有記錄都打上了時間戳，你不會立即回收舊的記錄。那麼你就可以問：「Alex Wolff上週的薪水是多少？」因為它還在那裡，直到你將其丟棄。所以你還獲得了時間旅行的功能。當然，就像資料庫中的所有其他事情一樣，細節決定成敗。日誌在獨立存在時是寫優化的，這樣你可以非常非常快速地寫入它。當然，資料庫是讀優化的。你想將那些你將一起訪問的記錄聚簇在一起。所以你有一個讀優化的部分和一個寫優化的部分。我的建議當然是，那裡只剩下一個部分了。所以「無覆寫」必須與其他方法具有競爭力的性能。所以這顯然是一個棘手的放置問題。這就是我們接下來要做的工作。

Postgres的遊戲計劃 (約1985年)

所以大約在1985年，Postgres的遊戲計劃是這樣的。我們將押注於抽象數據類型（這就是GIS的東西）。我們將押注於使用這個「always」命令和語法的規則。我們將押注於無覆寫儲存。這就是Postgres的要點。Postgres中還有其他一些東西，但在我看來，這才是重要的東西。

面臨挑戰：北達科他州與Postgres開發

好的。我們開始時充滿希望。這種情況不會持續下去。這兩個努力都不太順利。我們先從自行車旅行說起。我們到達了北達科他州。北達科他州荒涼得令人難以置信。那裡什麼都沒有。它是完全平坦的。你所做的是，你看到前面的下一個穀倉，你朝它騎行一個小時。然後你穿過一個非常小的鎮子，這個穀倉就在鎮子裡。你騎出鎮子，前面，你看到下一個穀倉。你從一個穀倉騎到另一個穀倉。這單調又荒涼。Beth和我互相開玩笑說，北達科他州的州樹是電線桿。但這不是讓我們痛苦的原因。讓我們痛苦的是風。通常，你預期會被穿越大平原的西向東的強風吹過這個州。我們預期只需坐在車座上，以每小時16或18英里的速度被吹著前進。但情況完全不是這樣。1988年夏天，美國中西部北部的天氣很奇怪。風確實很大，但它是從東向西吹。我們正迎著強風騎行，我們正在掙扎著達到每小時七或八英里。這一切在北達科他州一個叫Drake的地方達到了頂點，這個地方大約在州的中央。我們今天只騎了50英里，而不是我們希望達到的80英里。我們筋疲力盡，而且在心理上陷入了真正的低谷。距離樹線和明尼蘇達州邊界還有250英里，我們不確定自己將如何到達那裡。

好的，Postgres的遊戲計劃確實沒有那麼順利。有些奏效了，有些沒有。首先，我們是用C語言編寫Ingress的，我們不想再用C語言編寫更多的資料庫系統。C++還沒準備好。Ada不是一個好的選擇。所以我們說：「好吧，讓我們接受日本第五代計算機提案的酷艾德吧。」讓我們用Lisp語言編寫一個資料庫系統。結果這完全是一場徹底失敗的災難。在幾乎所有方面，Lisp都比真正的語言慢一個數量級。我們把大量代碼推下懸崖，然後重寫了一堆東西。抽象數據類型系統運作得像個奇蹟。我之所以發現這個，是因為我當時仍在為Ingress提供諮詢，我接到了一個Ingress客戶的電話，他說：「你們剛按照ANSI標準規範實現了日期和時間功能，但你們做錯了。」我說：「嗯？多告訴我一些。」他說：「你們實現的是儒略曆（Julian calendar），也就是說，3月15日減去2月15日是30天。抱歉，3月15日減去2月15日是28天，除了閏年，除了雙閏年。」我說：「是的，ANSI系統的規範就是這麼說的。」他說：「好吧，我不想要那樣的時間定義。結果是，至少在當時是這樣，我相信現在可能仍然如此，如果你在華爾街擁有一張債券，無論月份有多長，你每個月獲得的利息數額都是相同的。所以，3月15日減去2月15日是30天，非常感謝。」他想重載減法運算符，以便他能得到正確的答案，這樣他就無需將兩個對象複製到用戶代碼中在那裡進行減法運算。他說：「我為什麼不能只是重載你們的減法概念呢？」好吧，你在Ingress中不能這麼做，但在Postgres中肯定可以。這就是全部的想法。時間旅行功能很有前景，但很難調優。任何曾經研究過日誌結構文件系統的人都能完全理解我在說什麼。所以我們正在繼續研究那些東西。「always」功能根本沒有真正起作用。問題是我設定的目標是必須實現Chris Date參照完整性的所有六種情況，但我沒想出來怎麼做。所以所有那些實現都推下了懸崖，我們回到了方案B。

艱難時期與商業化之路

在接下來的四年裡，我和那位葡萄酒鑑賞家（wine connoisseur，這裡可能是個玩笑或代稱）花了很多時間試圖修復東西。把這想像成在泥沼中艱難跋涉，試圖修復規則系統...

Clayton Christensen所著的《創新者的困境》（The Innovator's Dilemma），我推薦各位都讀一讀。他是Harvard Business School的教授。他書中的基本觀點是，如果你正在銷售過時的技術，而新的技術出現了，你很難在不失去客戶基礎的情況下從舊技術轉變到新技術。所以大公司對Postgres這樣顛覆性的想法真的不感興趣。因此，在我看來，技術最好通過初創公司來實現，這也正是我們所做的。於是我招募了媽媽和她的丈夫，那位個子矮的。Amp One和那位安靜的從Berkeley學術團隊過來了，不久之後Triple Rock也從學術團隊加入了。我招募了那位個子高的shark，他為一家風險投資公司工作。他成為了臨時CEO和主要投資者。我們士氣高昂。我們開始行動了。我們有了錢，我們正在將Postgres當時的查詢語言Quell轉換為現在的星際標準SQL，並且正在強化代碼，提升性能。任何曾經創辦過初創公司的人都知道，初創公司的初期是蜜月期。生活非常美好。

自行車之旅：抵達密西根州

好的，生活依然美好。我們離開了北達科他州。我們離開了明尼蘇達州。我們離開了威斯康星州。我們乘坐渡輪橫渡Lake Michigan，現在我們在密西根州的Ludington。距離Boston不到1000英里了。看起來我們快要成功了。

創業挑戰：Catch-22與下行融資

好的，初創公司持續發展。經歷了一些失誤之後，我們被命名為Illustra。我們獲得了最初的幾個客戶。這就是初創公司的全部目標。我們的資金用完了。我們又籌集了一些資金。還記得我哥哥釣魚小屋裡的談話嗎？我們僱了一個真正的管理團隊。我們僱了經驗豐富的人擔任CEO，Uptone擔任行銷主管，Smooth擔任銷售副總裁。我們有了真正的管理團隊。由媽媽領導的工程團隊運作得非常出色。未來一片光明。我們有一個運作良好的初創公司。

然而，沒有什麼是永恆的。無論是自行車旅行還是Illustra都遇到了進一步的減速帶。自行車旅行方面，我們被密西根州和俄亥俄州宜人的平坦騎行所麻痺，突然之間我們撞上了Allegheny Mountains。Alleghenies的問題是，你會反覆地上下相同的500英尺。而且，至少在這個地區的道路規劃者不相信髮夾彎。所以你會直接爬上這些小山丘。我們將我們的21個檔位調到最低，才能爬上其中一些山丘。這騎行非常費力。Beth和我在庫Ellicottville做了一個戰略決定。我們一直跟隨一套試圖讓我們避開主要道路和交通的自行車地圖，但它們並沒有針對沒有山丘進行優化。所以我們說，讓我們優化以避開山丘。所以在Beth讓Leslie睡覺的時候，我找到旅館老闆，問了以下這個簡單的問題：我們如何在不爬更多山丘的情況下到達Albany？

好的，商業公司突然爆發了危機。危機是，在我們有了幾個客戶之後，下一批客戶，也就是你試圖跨越Geoffrey Moore術語中的「鴻溝」的那一批，他們不想要我們的抽象數據類型。我們有一個不錯的GIS類型庫，但客戶不想要我們的。他們想要主要應用程式供應商的類型庫。在GIS領域，那些供應商是ArcInfo和MapInfo等公司。所以我們的客戶想要從主要應用程式供應商那裡獲得GIS類型庫。當然，我們去與應用程式供應商交談，說：「我們為您提供一個很棒的提案。我們擁有革命性的技術。您可以將您的東西與資料庫搜索整合。在這個過程中，您將獲得崩潰恢復功能。生活會很美好，您所要做的就是與我們合作，將您的代碼轉換為以ADT運行。」所有應用程式供應商都看著我們說：「你們有多少客戶？」我們會說大約20個。他們會說：「等你們有1000個客戶時再來找我們。」換句話說，他們的觀點是，他們將我們視為一個分銷渠道，而不是任何革命性技術，他們說：「好吧，你知道，一旦你們的分銷渠道足夠大到引起我們的興趣，我們樂於使用它。」所以問題是，客戶想要從應用程式供應商那裡獲得ADT。應用程式供應商除非我們有客戶，否則他們不會做ADT。所以我們陷入了一個進退兩難的境地，我們不知道如何擺脫。

好的，正如你可能想像的，事情進展不太順利，這導致我們下次資金用完時，遭遇了所謂可怕的「下行融資」(down round)。融資初創公司的基本想法是，你與風險投資公司，也就是那些land sharks，坐在談判桌前，這是一個零和博弈，分割公司。之後，理念是每次你需要更多資金時，你會招募一個新的投資者。他會設定一個新的、 presumably更高的價格，你以越來越高的估值出售股票。至少理論上是這樣運作的。然而，麻煩是，如果你找不到新的投資者，甚至無法支付與上一輪相同的價格，會發生什麼？這就是所謂的下行融資，正如你可能想像的，這會嚴重稀釋股權，但由於大多數初創公司融資協議中的一個條款，它會雙倍稀釋，該條款規定，如果你發生下行融資，你必須將前幾輪的價格重新定價到新的價格。所以它變得雙倍稀釋。員工不傻。他們會說：「如果你要把我的股權稀釋掉，我為什麼要繼續為這家初創公司工作？」所以這成為當前的land sharks、新的投資者和員工之間的三方談判，這是一個零和博弈，重新分割公司。好吧，我們經歷了一次下行融資。我們可能花了三個月的時間談判和痛苦地處理所有這些事情。到最後，員工的損失大部分得到了彌補，各種投資者持有的公司股份比例略有變化，但這給我留下了可怕的印象，我們浪費了大約三個月的時間，而本來可以取得進展的。無論如何，自行車旅行和Illustra的進展都不順利。

高潮：塞倫迪皮蒂與轉向

當然，沒有什麼是永恆的。這兩段旅程都有高潮。當我問旅館老闆時，他的回答對於任何在1800年代想在東海岸和國家中部之間運輸貨物的人來說都是顯而易見的。你們都知道Erie Canal的存在，所以旅館老闆說：「直接向北騎到Erie Canal，然後右轉。」這正是我們所做的，我們沿著Mohawk Valley順流而下到Albany，現在我們在紐約州的Troy，在自行車的傳說中，有一個「最後一個山丘」的概念，這是你完成之前必須做的最後一件事。所以我們只需要爬升Berkshires到Pittsfield，然後到Boston的路就很輕鬆了。

類似的塞倫迪皮蒂（serendipity，意外之喜）也發生在Illustra身上。你們有些人可能還記得，1995年，網際網路正在蓬勃發展。那是在Netscape時代。那是在Bill Gates去了Cornell並意識到網際網路很重要的時候。Well，Uptone同時也意識到網際網路很重要，許多其他人也是如此。對於初創公司來說，你必須能夠迅速轉變公司方向，這正是我們所做的。我們不再談論抽象數據類型或其他任何東西。我們是「網絡空間的資料庫」，能夠儲存你的網際網路對象，這引起了巨大的轟動。這得益於一場名為「24小時網際網路」的行銷活動，活動中有許多攝影記者在世界各地每小時建立一個網站，而Illustra是這個項目背後的資料庫。引起了很大的轟動。客戶開始找上門來。也許我們已經轉危為安了。情況看起來正在好轉。

基準測試危機

好了，這並沒有在Illustra身上永遠持續下去，所以發生的事情是，當時一家非常主要的網際網路供應商來找我們說：「你們是網絡空間的資料庫。我們想使用你們，但我們必須確保你們會沒問題，所以我們將會用你們與現有的關聯式資料庫系統進行對比測試。」所以我們說：「太棒了，這聽起來很棒。你們為什麼不在文本、地理、圖像以及那類東西上做一個基準測試呢？」這家供應商說：「不用了，謝謝。」在這些網際網路風格問題的內部，總有一個商業數據處理問題在追蹤事物。所以我們將在事務處理上對你們進行基準測試。基本上，就是每秒可以執行多少次簡單的更新並將其作為一個事務提交。好吧，關聯式資料庫供應商在過去幾年一直致力於正是這種商業數據處理的系統優化。我們當然關心GIS、圖像處理、文本等所有那些東西。我們可以進行事務處理，但這不是我們的強項。我們將輸掉這場基準測試，而且會輸得很慘，可能會有一個數量級的差距。Short one和我開始幾乎每天都進行討論。我們到底如何在不完全重寫的情況下提高事務處理性能？我們幾乎一籌莫展。Illustra將面臨重大變革、大量的資金和大量的延遲。

故事的結局

好了，我現在可以告訴你這兩個故事的結局了。正如你可能想像的，騎雙人自行車進入Boston市中心是很愚蠢的。我絕對不會那樣做。所以...

並將「騎行東行」替換為「朝著這個目標採取適當的行動」，直到達到目標，早上起床，朝著這個目標執行一項行動，並且堅持不懈，克服任何障礙。好吧，我們稍後會用到這個算法，所以我將其變成一個宏，並使其實現。所以基本上可以將「make it happen」理解為堅持不懈地實現你的目標並克服任何出現的事情。

好的，現在談論這次自行車旅行的第二個原因是，為什麼會有任何人頭腦清醒的人想要做這件事呢？我可以向你保證，這是一段漫長而艱辛的旅程。正如你之前在這場演講中看到的，它有很多起伏，而且有很多單調乏味的地方。我不能告訴你，騎行穿過國家中部地區很有趣，我當然也不能告訴你，北達科他州很有趣。所以你有很多單調乏味，很多在泥沼中跋涉，經歷沮喪和興奮的時期，而且這是一段漫長而艱辛的旅程。

那麼，為什麼會有人想做這件事呢？好吧，讓我稍微隨意地介紹一下我的履歷。我擁有Michigan University的博士學位。在我看來，獲得博士學位的大部分過程並不是很愉快。在我看來，這被稱為「make it happen」大約五年。那些老教授們會給你設置各種障礙，比如預考和資格考試，他們會確保你的博士論文確實可讀。我第一次資格考試沒通過。回頭看獲得博士學位，我認為這是一個「make it happen」的練習。然後我在Berkeley獲得了一個助理教授職位。目標現在是獲得終身職位。每次你的論文被接受，那就是興奮。每次你的論文被拒絕，那就是沮喪。其中很大一部分是在泥沼中艱難跋涉。我記得那段時期壓力巨大，是「make it happen」的一次巨大練習。這次自行車旅行只是「make it happen」的另一次練習。所以如果我是你，我會得出以下顯而易見的結論。我顯然是「設定好」去尋找「make it happen」的機會，然後去實現它們。

好的，建立Postgres是另一種類似於這樣的練習。你必須有一兩個或三個好點子，然後你必須「make it happen」才能得到一個可用的原型。如果沒有可運行的代碼，沒有人會認真對待你。然後你必須創辦一家公司，僱傭優秀的實現者和才華橫溢的初創公司高管，然後你必須在泥沼中艱難跋涉，努力讓你的產品成功。粗略地說，這就是有一個好點子，然後用十年的時間「make it happen」。所以你可能會再次問，為什麼會有人想為實現這樣的事情而奮鬥十年呢？

好吧，這其實是個反問。答案和自行車旅行一樣。我顯然是「設定好」要做這件事的。你可能會問，好點子從哪裡來？好吧，我很樂意分享我的個人想法。有些人聲稱他們是通過獨自在大自然中與自然交流而獲得好點子的。我喜歡這樣做，但我從未因此獲得任何好點子。相反，我強烈推薦與用戶交流。在資料庫領域，他們是衡量什麼重要性的最終判官。當你與用戶交流完後，再與更多用戶交流，然後為他們的問題提出解決方案，這將確保有人認為你在做的事情很重要，這對我來說，是衡量你所做的事情是否值得做的最終標準。然後當你想出解決方案時，在一個由聰明人組成的批評環境中交流，他們會無情地批評你的想法，我認為這是一件很棒的事情。所以這就是我建議你嘗試獲得好點子的方式。至少在我的領域，這對我來說是有效的。如果你想知道我對什麼是好點子，什麼不是好點子的看法，這可能正是你期望這場演講要談的。反正，我確實做過一次這樣的演講。它在今年International Conference on Data Engineering的網站上。所以如果你想聽那種演講，你可以去看看我的「時光考驗」(test of time)演講。

總結

所以我有幾點結束語，然後我就講完了。這個「make it happen」的精神從何而來？在我看來，如果你沒有很多這種精神，就不要試圖建立一個新穎的資料庫系統。我可以滔滔不絕地用一些心理學術語來解釋我的童年，但這遠超出我的能力範圍來談論這些。所以最簡單的迴避方式就是說，我不知道。那塞倫迪皮蒂呢？塞倫迪皮蒂把我們帶出了北達科他州。我們沒有計劃我哥哥會在正確的時間出現，也沒有計劃風會是那樣。這純粹是塞倫迪皮蒂。Illustra的成功也純粹是塞倫迪皮蒂。所以它通常是一個非常重要的因素。在我看來，關聯式資料庫模型總體上的成功背後有大量的塞倫迪皮蒂，這是無法預見的。但那是另一場演講的主題。我也經歷過壞運氣。壞運氣可以比你想像的更快地扼殺一個初創公司，就像一頭大象突然來踩踏你一樣。所以塞倫迪皮蒂會發生，你只能說，我不可能知道所有事情。

好吧，這樣的演講應該以「那麼從80年代末和90年代初以來發生了什麼」來結束。好吧，我們的雙人自行車，我們稱之為「Boston Bound」，它坐在我們的地下室裡積滿灰塵。自從在Wollaston Beach之後就再也沒有騎過了。我仍然喜歡挑戰體能，最近剛剛爬完了新罕布什爾州所有4000英尺以上的高山。Illustra正如我之前所說，被收購了。它被成功地整合到Informix的代碼庫中，現在仍然是IBM的一個產品，IBM在2000年代初收購了Informix。Postgres中的抽象數據類型系統已經被添加到許多關聯式資料庫系統中。如今，它基本上是關聯式資料庫的標準配備，而且基本上保持原樣。這個想法確實是一個好主意。在我的圖靈獎引文中有提到。然而，塞倫迪皮蒂發揮了巨大作用，Postgres迄今為止最大的影響來自兩位Berkeley的學生，我親切地稱他們為grumpy和sleepy。他們在1995年將學術原型Postgres從Quell轉換為SQL。這與商業活動是並行的。然後一支由志願者組成的臨時團隊，他們與我或Berkeley都沒有任何關係，從1995年以來一直在維護這個開源系統。所以你在網上獲取的Postgres系統來自這個臨時團隊。這是開源的典範。我想提一下，我與此毫無關係。而且這群人，我們都對他們深表感激，因為他們強化了那個代碼線，使其真正可用。那個代碼線也成為了幾家數據倉儲供應商的起點，他們從那個代碼線開始，並在許多方面改進了它。我仍然在構建資料庫系統。我沒有止步於Postgres。在我看來，目前的資料庫世界是，傳統供應商，比如Oracle、DB2和SQL Server，他們，如果你不仔細看，它們的架構大致相同，在我看來，這現在什麼都不適用了。這只是遺留代碼。它應該被送進「疲憊軟體之家」。相反，我一直在構建針對特定垂直市場的引擎，這些引擎擅長解決特定的垂直問題。列式儲存是數據倉儲的明顯方式。我構建了一個這樣的系統。事務處理將轉移到內存中，使用非常輕量級的事務系統。我構建了一個這樣的系統。我們將從商業智能轉向數據科學。這將需要複雜的分析，幾乎所有分析都是定義在陣列上的。我構建了一個這樣的系統。這些系統每一個都需要十年時間來「make it happen」。在後兩個案例中，我仍然參與其中，包括Volt和Paradigm 4。我可以使用這些系統中的任何一個來進行這場演講，而不是Postgres。細節會有所不同，但總體主題是一樣的。

我想以引用以下39位Berkeley的學生和員工的名字來結束，他們在Larry Rowe和我本人的指導下編寫了最初版本的Postgres。我會將這張幻燈片留足夠長的時間，讓你們至少可以讀到一些名字。這些人中有許多人已經取得了輝煌的職業生涯。Joey Hellerstein和Marty Hearst是Berkeley的教授。Mike Olson是Cloudera公司的董事長，這是一家網際網路Hadoop公司。Marcel Kornacker是Impala資料庫系統的首席技術專家，Impala是Cloudera在Hadoop之上提供的一個產品。既然你們可以看到所有這些名字，我欠這些人很多。他們才是真正將我和Larry的想法變成了可運行的代碼的人。我對系統程式設計師心存感激，就像我今天演講中提到的那些人，他們將脆弱的學術原型變成了堅實可靠的商業代碼。資料庫系統的問題在於它們必須真正地工作。你不能隨心所欲地顯示「死亡綠屏」。你的系統必須保持運行，並且必須工作。對於那些能實現這一點的人，我深感敬佩。我敬佩初創公司的管理人員，就像我今天演講中提到的那些人。他們可以在鯊魚密布的水域中引導脆弱的初創公司，做出明智的商業決策。我尤其要感謝我現在的一位合作夥伴Q-Ball，他是我在多個東海岸初創公司的夥伴。當然，沒有風險投資社群的資金，這一切都不可能實現。

非常感謝Mike帶來如此精彩、富有啟發性和趣味性的圖靈講座。Mike將在頒獎晚宴上領取獎項，我想那是在本週六。很遺憾我們沒有時間提問，但我想給各位留下一個想法：如果有人有興趣成為圖靈獎得主，顯然你所要做的就是「make it happen」。謝謝大家。[掌聲]