初創資料庫公司的瘋狂行為：刪掉花 7 個月開發的 27 萬行 C++ 程式碼，用 Rust 全部重寫一遍

C++程式語言已經不是用來構建資料庫的最佳選擇了嗎？

資料庫初創企業 Singularity Data Inc.（中文簡稱奇點無限）最近發表了一篇部落格文章， 宣佈 他們完全刪除掉了 RisingWave 的 27 萬行 C++程式碼庫，並用 Rust 語言從頭開始重寫了一遍系統。

RisingWave 於 2021 年初開始建立，決定重寫時，他們已經花了 7 個月的時間進行開發。按創始人的話說，用 Rust 重寫也意味著“七個月的努力都白費了。對於早期創業公司來說，這是一個瘋狂的決定。特別是在競爭激烈的環境中，對科技初創公司來說，時間幾乎就是一切。”

C/C++ 是用來構建資料庫系統的最流行的程式語言之一。大多數知名的資料庫系統，包括 MySQL、PostgreSQL、Oracle 和 IBM Db2，都是用 C/C++ 建立的。對於現在的資料庫創業企業來說，選擇使用 C++已經不是一個最佳的選擇了嗎？

RisingWave 是什麼？

RisingWave 是初創企業“奇點無限”開發的雲原生流式資料庫，主要服務於需要超低延遲實時資料分析應用。

創始人 &CEO 吳英駿博士 認為 ，因為 Flink 有幾個關鍵特性，比如，作為流計算引擎，不提供資料持久化能力；計算和儲存耦合，雖有極高的可擴充套件性，但彈性難以管理和實現，使用 Flink 來支援流式應用程式可能會非常昂貴等等......所以在雲時代，“Flink 可能不再是流處理的最佳答案”。

為了簡化流處理，他們重新審視了一個古老的研究方向：流式資料庫。流式資料庫的思想可以追溯到資料流管理系統 (DSMS)的早期提議，它用與資料庫中的資料管理相同的方式管理資料流。與許多其他資料庫一樣，RisingWave 被設計為可以提取資料、儲存資料並回應來自終端使用者的併發訪問請求，所有這些請求都可以用 PostgreSQL 風格的 SQL 來表達。

因此，RisingWave 的定位不僅是一個 SQL 資料庫系統，還提供流處理能力：使用流資料，執行連續查詢，並以物化檢視的形式動態維護結果。另外，它還採用分層架構，建立在現代雲基礎架構之上，利用雲資源為使用者提供對成本和效能的細粒度控制。與傳統的 SQL 資料庫相比，RisingWave 最終目標是給使用者提供以低延遲處理流資料的能力，如在大資料場景下實現亞秒級商業分析。

據國內媒體 報道 ，“奇點無限”於 2021 年 7 月宣佈獲種子輪近千萬美元融資，由雲啟資本領投，融資用於產品開發和團隊組建。該公司在北京、上海、舊金山灣區設有辦公室，媒體報道將之定位為“一家國際化的資料庫初創公司”。

2022 年 4 月，“奇點無限”開源了 Rust 編寫的 RisingWave ： https://github.com/singularity-data/risingwave

其部落格文章顯示，RisingWave 開源後就很快成為了“使用 Rust 編寫的第一大熱門專案”。

為什麼換掉 C++？

2021 年初開始構建該資料庫時，RisingWave 團隊選擇了用 C++ 來實現自己的新一代的流式資料庫。當時的創始團隊由多位具有 10 年以上相關經驗的資深 C++ 工程師組成。

隨著公司規模擴大，工程師人員的增加，他們開始被 C++的“缺點”所困擾：程式碼可讀性差、存在記憶體洩露和 segmentation fault 等。於是，經過約 7 個月的開發階段後，團隊開始有了質疑：“C++ 語言是編寫新資料庫系統的正確選擇嗎？”

C/C++ 無疑是用於構建資料庫系統的最流行的程式語言之一，大多數著名的資料庫系統都是用 C/C++ 建立的。因此對於這麼一家從零開始構建大規模資料庫系統的早期創業公司來說，既然大量的資料庫是用 C/C++ 構建的，那麼它就已被證明是一種可行的系統程式語言；除此之外，C++ 還為開發人員提供了開發高效能程式的機會，提供了對記憶體和計算的細粒度控制。

但壞處是：

• 雖然 C++ 為程式設計師提供了很大的靈活性，但它是有代價的。非常容易寫出 bug，還極其難以除錯，尤其是併發程式設計。

• 依賴管理可能很麻煩。雖然如 CMake 工具可以自動配置 C++ 專案的編譯，但開發者仍然需要手動配置和安裝依賴庫。

更為麻煩的是：

• STL 庫缺乏對一些現代程式設計工具的支援，依賴的社群專案大多數還都缺乏長期支援。

• 質量保證具有挑戰性。C++ 支援的特性如此之多，以至於不同的開發人員可以以截然不同的風格編寫 C++。不同背景的開發人員在一個團隊中，保持程式碼可讀性有困難。此外，C++ 程式碼中的 bug 很難識別，因此審查程式碼會變得令人生畏。

另外，流式資料庫通常用於對延遲非常敏感的關鍵任務。因此只能使用以下語言構建 RisingWave：保證零成本抽象，不會有效能上限；不需要執行時垃圾收集，可以控制可能由記憶體管理引起的延遲峰值。

考慮到這兩個效能目標，經過一個月的討論之後，RisingWave 做出了從 C++ 遷移到 Rust 的決定。

（截圖來自網路）

雖然 Rust 也含有不好的一面，比如“碎片化的非同步生態系統、繁瑣的錯誤處理”等，但出於“安全、易於使用、易於學習、易於管理”四大原因，所以 RisingWave 認為 Rust 是一個更好的選擇，可以減輕開發人員的精神負擔，為高效的大規模協作鋪平道路。

（圖片來源： https://singularity-data.com/blog/building-a-cloud-database-from-scratch-why-we-moved-from-cpp-to-rust ）

作出決定後，RisingWave 團隊花了約兩個月的時間完全刪除之前的 C++ 程式碼庫，並用 Rust 重寫了一遍系統，總共刪除了 276,406 行程式碼。

寫在最後

儘管 Rust 帶來了明顯的好處，但重寫整個程式碼庫並不是一件好玩的事情，而且這件事也不代表“每個資料庫團隊都可以放棄 C++轉而選擇用 Rust”。

吳英駿博士在文中表示，其實還有些關鍵因素存在：一是當時他們正在重構程式碼庫以適應新的系統架構，重寫（至少一部分）程式碼庫是不可避免的事情；二是團隊中有一些 Rust 愛好者不斷向其他工程師宣傳 Rust，並說服整個團隊用 Rust 重寫是一個實用的選擇；三是 2021 年夏天后工程團隊迅速擴大，大大加快了程式碼庫的重寫速度。如果缺少這些因素，就不會讓他們作出遷移到 Rust 的決定。

Rust 是很酷的程式語言，值得每個人都嘗試一下，但是重寫專案卻要認真考慮，“Rust（或任何其他語言）永遠不會決定專案的命運，但做出明智的選擇可能會為你節省數百甚至數千人月”。

參考連結：