Oracle 發力 MySQL，MariaDB 成功上市，大規模融資銳減

又一年過去了，生活還在繼續，現在是反思去年資料庫世界所發生事件的絕佳時機。

連結：https://ottertune.com/blog/2022-databases-retrospective/

作者 | Andy Pavlo

譯者 | 王雪迎責編 | 鄭麗媛

隨著 DBMS 供應商之間基準性能競爭的逐漸平息，顯現出一片寂靜的景象。我喜歡寫年終回顧，所以很高興能和大家分享 2022 年資料庫領域的亮點以及我對它們的看法。

大融資減少，大時代放緩

正如我去年所討論的那樣，2021 是資料庫融資充足的一年。隨著投資者繼續尋找下一個 Snowflake，大量資金投入到開發新 DBMS 的初創企業中。

2022 年初，隨著眾多大型融資輪的發佈，似乎是上一年的又一次重演。盛況始於 2 月，Timescale 發佈 1.1 億美元的 C 輪系列融資、Voltron Data 發佈 1.1 億美元種子和 A 輪系列融資，以及 Dbt Labs 發佈的 2.22 億美元 D 輪系列融資。

Starburst 於 3 月宣佈 2.5 億美元的 D 輪系列融資，用以擴展其 Trino 產品。到了 5 月，Imply 為其商業版 Druid 發佈了價值 1 億美元的 D 輪系列融資。DataStax 在 6 月份的 IPO 中獲得了 1.15 億美元的資金。最後，SingleStore 在 7 月放棄了 1.16 億美元的 F 輪系列融資，然後在 10 月又增加了 3000 萬美元。

在 2022 年上半年，還有幾家規模較小的公司推出了令人印象深刻的 A 輪系列融資，包括 Neon 為無伺服器 PostgreSQL 產品進行的 3000 萬美元 A 輪系列融資、ReadySet 為其查詢快取層產品進行的 2900 萬美元的 A 輪系列融資、Convex 為其基於 PostgreSQL 構建的應用程序框架進行的 2600 萬美元的 A 輪系列融資，以及 QuestDB 時間序列 DBMS 的 1500 萬美元 A 輪系列融資。儘管我們沒有構建新的 DBMS 或相關架構，但 OtterTune 在 4 月份發佈了自己的 1200 萬美元 A 輪系列融資。

但隨後，大規模融資在 2022 年下半年戛然而止。除了早期初創企業的融資規模較小，具有豐富經驗公司的融資額也沒超過 9 位數。10 月，RisingWave 為其流處理引擎進行了價值 3600 萬美元的 A 輪系列融資。Keebo 為他們的 Snowflake 查詢加速器籌集了 1050 萬美元的 A 輪系列融資。11 月，我們看到 MotherDuck 宣佈了 4500 萬美元的種子 + A 輪系列融資，用於 DuckDB的商業化雲版本，之後 EdgeDB 在 11 月進行的 1500 萬美元的 A 輪系列融資。最後，SurrealDB 兄弟獲得了 600 萬美元的種子輪融資（這並不是一個詳盡的列表，我可能還錯過了一些）。

資料庫市場中唯一一個值得注意的金融事件是，MariaDB 在 12 月通過 SPAC 的「災難性」上市——其股價在首個交易日即下跌了 40%。

我的看法：

與 2021 相比，2022 年大型融資輪減少有兩個原因：

最顯而易見的原因是整個科技行業已經降溫，這部分是由於對通脹、利率和加密經濟崩潰的擔憂。
另一個原因是，在大環境變得糟糕之前，每一個有能力拿下大輪融資的人都已經這麼做了。例如，Starburst 在 2021 年進行了價值 1 億美元的C輪系列融資之後，又於 2022 年進行了 D 輪融資。

在過去兩年中籌集了大量資金的資料庫公司，需要快速籌集到更多資金，以保持增長勢頭。還有人評論說，這些公司得到的金額令人吃驚。壞訊息是，除非整個科技行業的環境有所改善，大型機構投資者再次開始當街撒錢，否則這些資料庫公司將陷入困境，市場無法維持如此多的資料庫獨立軟體供應商（ISV）。

對於這些估值數十億美元的公司來說，唯一的出路是 IPO，否則就是破產。問題是對於大多數此類公司來說，收購它們太貴了，除非風投願意大幅削減其估值。此外，進行大型併購的主要科技公司（如亞馬遜、Google、微軟等）已經擁有自己的雲資料庫產品，因此尚不清楚誰將會收購這些資料庫初創企業。

亞馬遜在 2021 以 20 億美元的估值收購 Clickhouse 是沒有意義的，因為他們已經從 Redshift 每年賺了數十億美元——這個問題並非 OLAP 資料庫公司獨有，OLTP 資料庫公司很快也將面臨同樣的問題。

我並不是唯一一個對資料庫初創企業的命運做出如此悲觀預測的人。Gartner 分析師預測，到 2025 年，50% 的獨立 DBMS 供應商將倒閉。我認為這有明顯的偏見，但我認為能夠生存下來的，將是那些努力改進或增強 DBMS，而不是取代它們的公司（例如，dbt、ReadySet、Keebo 和 OtterTune 等）。

我無法評價 SPAC 的「快速 IPO」方式（MariaDB 的上市方式）是不是一個好主意，此類金融手段不屬於我的專業領域（即資料庫）。但由於這與美國前總統對其社交媒體公司所做的事情類似，我認為這可能是一個見不得人的交易。

區塊鏈資料庫仍然是一個愚蠢的想法

有種說法很盛行，即關於 Web3 如何代表人們構建新應用程序的方式發生了根本變化。Web3 運動的核心宗旨是在區塊鏈資料庫中儲存狀態，而區塊鏈本質上是去中心化的日誌結構資料庫（也就是賬本），它使用 Merkle 樹的某些變體和 BFT 共識協議來維護增量校驗和，以確定要儲存到資料庫中的下次更新。這些增量校驗和是區塊鏈確保資料庫日誌記錄不可變的方式：客戶端使用這些校驗和來驗證以前的資料庫更新沒有被更改。

區塊鏈是先前想法的巧妙融合，但認為去中心化賬本就是每個人無論如何都應該構建 OLTP 應用的想法是錯誤的。從資料庫的角度來看，對於加密貨幣以外的任何實際用例，它們都無法提供超過現有 DBMS 技術的任何東西。此外，任何聲稱「在區塊鏈資料庫中提供比現有 DBMS 更好的安全性和可審計性」的說法都是錯誤的。

因此，如果加密貨幣是區塊鏈資料庫的最佳用例，那麼 2022 年的加密市場崩潰也於事無補，這隻會進一步阻礙了它們的未來。在本次討論中，我忽略了 FTX 的崩潰，因為它似乎是直接的欺詐行為，與資料庫無關。然而我要指出的是，FTX 和所有其他加密貨幣交易所一樣，並沒有在區塊鏈資料庫上運行業務，而是使用 PostgreSQL。但其他與加密貨幣無關的區塊鏈資料庫使用案例，如貿易和遊戲平臺，都由於其不切實際或欺詐而失敗。

我的看法：

評估一項技術時要遵循的一條規則是，一旦企業發佈了有關它的電視廣告，它就不再是「新的」。舉個例子，如果當 IBM 開始宣傳某項技術時，它還沒有令人信服的使用案例，那麼就永遠不會有了：IBM 在 2002 年的一次商業廣告中宣傳 Linux 是一個熱門的新事物，但當時已有數千家公司（包括Google）將其作為主要伺服器作業系統。

因此，當 IBM 發佈其 2018 年區塊鏈商業廣告時，我就知道這項技術不會超越加密貨幣，因為去中心化區塊鏈可以解決集中式 DBMS 無法解決的問題。甚至，今年 IBM 宣佈關閉其與航運巨頭馬士基（Maersk）的供應鏈 IT 基礎設施改造項目（他們在商業廣告中大肆宣傳過此項目），在我看來也並不奇怪。

與由可信機構控制的、只允許可信客戶端直接連接的、精心編寫的事務性 DBMS 相比，區塊鏈的效率非常低。除了加密貨幣或設置陷阱等非法活動外，幾乎所有現實世界的互動都以這種方式進行。我們需要信任他人，建立一個運轉良好的社會。例如，我授權託管 OtterTune 網站的公司從我們的信用卡中扣款，他們信任雲提供商託管他們的軟體——但沒有人需要區塊鏈資料庫來進行這些交易。

從工作量證明（PoW）轉換為能源密集度較低的權益證明（PoS）共識機制，確實提高了區塊鏈資料庫的性能，但這隻會影響資料庫的吞吐量，區塊鏈事務延遲仍然以幾十秒為單位。如果解決這些長延遲的方法是使用參與者較少的 PoS 區塊鏈，那麼應用程序最好只使用 PostgreSQL，並對這些參與者進行身份驗證。

感興趣的話，可以參閱 Tim Bray 的這篇精彩文章（https://www.tbray.org/ongoing/When/202x/2022/11/19/AWS-Blockchain），了解他與 AWS 高層就區塊鏈是否存在可行進行的內部討論。請注意，他說 AWS 在 2016 年便得出結論，即區塊鏈資料庫是一種尋找問題的解決方案，比 IBM 推出區塊鏈商業廣告還早兩年。不過儘管 AWS 最終在 2018 年發佈了 QLDB 服務，但它與區塊鏈不是一回事，它是一個不使用 BFT 共識的集中式可驗證資料庫。客戶對 QLDB 的接受程度並不高，尤其是與亞馬遜極為成功的 Aurora 產品相比。

新資料庫系統

2022 年有幾個關於新 DBMS 軟體的重要發佈。

Google AlloyDB

最大的重磅炸彈是 5 月份Google雲發佈了新的資料庫服務。AlloyDB 並非構建在 Spanner 之上，而是 PostgreSQL 的一個修改版本，它將計算層和儲存層分離，並支持直接在儲存中處理 WAL 記錄。

Snowflake Unistore

6 月，Snowflake 發佈了他們帶有「混合表」的新 Unistore 引擎，以支持 DML 操作的低延遲事務。當查詢更新表時，更改會傳遞到 Snowflake 的列式儲存。對此，SingleStore 方面有些不滿，表示他們在這個領域擁有一些專利，但沒有任何結果。

MySQL Heatwave

在 Oracle 意識到亞馬遜從 MySQL 中賺到的錢比他們還多之後，他們最終決定在 2020 年為 MySQL 構建自己的雲產品。但他們並不只是製作一個 RDS 的克隆，而是使用一個名為Heatwave的記憶體向量化 OLAP 引擎來擴展 MySQL。2021年，Oracle 宣佈他們的 MySQL 服務也支持自動資料庫最佳化（但與 OtterTune 提供的不同）。去年，Oracle 終於意識到他們不是領先的雲供應商，並同意在 AWS 上支持 ‍MySQL Heatwave。

Velox

Meta 於 2020 年開始構建 Velox，作為 PrestoDB 的新執行引擎。兩年後，他們宣佈了這個項目，並發表了一篇關於它的 VLDB 論文。Velox 不是一個完整的 DBMS：它不帶 SQL 解析器、元資料目錄、最佳化器或網路支持。相反，它是一個具有記憶體池和儲存聯結器的 C++ 可擴展執行引擎，可以使用 Velox 構建一個完整的 DBMS。

InfluxDB Iox

與帶有 Velox 的 Meta 一樣，Influx 團隊在過去兩年中一直致力於開發他們的新 IOx 引擎。最終他們宣佈，將於 10 月推出帶新引擎的 GA 版本。InfluxDB 基於 DataFusion 和 Apache Arrow 從頭開始構建 IOx。值得慶幸的是，我在 2017 年警告 Influx 的 CTO，使用 MMAP 是個壞主意，之後他們也在新系統中放棄了 MMAP。

我的看法：

資料庫是我生命中第二重要的東西，所以我很高興看到去年的所有發展。

我對 AlloyDB 的熱評是，它是一個簡潔的系統，並且投入了大量的工程設計，但我仍然不知道它有什麼新奇之處。AlloyDB 的架構類似於 Amazon Aurora 和 Neon，其中 DBMS 儲存具有額外的計算層，可以獨立於計算節點處理 WAL 記錄。儘管Google雲已經擁有可靠的資料庫組合（如 Spanner 和 BigQuery），但它覺得有必要建立 AlloyDB，以試圖趕上亞馬遜和微軟。

值得關注的長期趨勢是 Velox、DataFusion 和 Polars 等框架的激增。連同像 Substrait 等項目，這些查詢執行元件的商品化意味著所有 OLAP DBMS 在未來五年內將大致相當。與其完全從頭開始構建新的 DBMS，或者強行對現有系統做分支（例如 Firebolt 對 Clickhouse 所做的分支），不如使用 Velox 這樣的可擴展框架。這意味著每個 DBMS 都將具有十年前 Snowflake 所獨有的向量化執行能力。由於在雲中，儲存層對每個人來說都是相同的（例如 Amazon 控制 EBS/S3），DBMS 產品之間的關鍵區別將難以量化，例如 UI/UX 方面和查詢最佳化。

一位資料庫先驅的逝去

更令人沮喪的是，2022 年 7 月，我們失去了 Martin Kersten。Martin 是 CWI 的一名研究員，也是幾個有影響力的資料庫項目領導者，包括 1990 年代的第一個分散式記憶體 DBMS（PRISMA/DB）和 2000 年代的第一個列式 OLAP DBMS（MonetDB）。Martin 於 2020 年被荷蘭政府授予皇家爵士頭銜，特別表彰他在資料庫方面做出的貢獻。

MonetDB 程式碼庫是其他幾個 OLAP 系統項目的基礎。2000 年代後期，Peter Boncz 和 Marcin Żukowski 將其分支為 MonetDB/X100，並將其商業化為 Vectorwise（現在稱為 Actian Vector）。之後 Marcin 使用他在 MonetDB 原始程式碼上開發的許多技術，與他人共同創立了 Snowflake。最近，Hannes Mühleisen 創建了一個名為 MonetDBLite 的嵌入式 MonetDB 版本，然後他再次將其重寫為現在的 DuckDB。

Martin 對現代資料庫系統的貢獻怎麼強調都不為過。如果你在使用任何現代分析型 DBMS（例如 Snowflake、Redshift、BigQuery、Clickhouse），那麼你必將受益於 Martin 及其學生在過去 30 年開發中取得的許多進展。

我的看法：

我承認，與 Mike Stonebraker 這樣的人相比，Martin 可能並不為資料庫研究界以外的人所熟知。我一直認為 Martin 是歐洲版的 Stonebraker：他們都是多產的資料庫研究人員，又高又瘦，戴著眼鏡，年齡相仿。

除了研究之外，Martin 總會花上大把時間，並渴望與他人討論資料庫架構。我最後一次見到他是在疫情之前的 VLDB 2019。他和我爭論了將近一個小時，說強調他認為在 MonetDB 中使用 MMAP 是正確的選擇——他斷言，因為 MonetDB 專注於只讀 OLAP 工作負載，所以 MMAP 就足夠了。我感覺很糟糕，因為他還要說服在 Youtube 上觀看我資料庫課程的學生，隨後我便給他發郵件，告訴他為什麼我認為 MonetDB 的設計並不完善。