前段時間，數(shù)據(jù)庫創(chuàng)業(yè)公司 RisingWave Labs 發(fā)表博文，宣布徹底刪除RisingWave（該公司的云原生流數(shù)據(jù)庫）的 27 萬行 C++ 代碼，并用 Rust 語言重寫。

為此，我們采訪了該公司的創(chuàng)始人兼首席執(zhí)行官吳英駿博士，詳細(xì)探討了重寫的前中后期準(zhǔn)備工作、遇到的問題以及經(jīng)驗教訓(xùn)。

放棄 Rust，最初的選擇是 C++

提問：選擇哪種編程語言與 RisingWave 的功能有關(guān)系嗎？

吳英駿：RisingWave 是一款云原生流式數(shù)據(jù)庫，主要服務(wù)于需要超低延遲實時的數(shù)據(jù)分析應(yīng)用。其定位不僅是一個 SQL 數(shù)據(jù)庫系統(tǒng)，還提供流處理能力：使用流數(shù)據(jù)執(zhí)行連續(xù)查詢，并以物化視圖的形式動態(tài)維護(hù)結(jié)果。另外，RisingWave 采用了分層架構(gòu)，建立在現(xiàn)代云基礎(chǔ)設(shè)施之上，利用云資源為用戶提供成本和性能的細(xì)粒度控制。

這個架構(gòu)最大的特點在于，資源是無限的。由于有無限的資源，性能就不會成為特別大的問題——只要添加資源，性能就能提到提升。但資源是收費的，設(shè)備也是收費的，我們希望能在保證用戶性能的前提下，降低整個系統(tǒng)的成本，讓普通用戶以較為低廉的價格使用我們的服務(wù)，這也是我們的核心設(shè)計理念。

這與編程語言的選擇沒有太大關(guān)系，開發(fā)一款數(shù)據(jù)庫可以使用各種各樣的語言，比如 C++、Rust、Java，Scala 等，一些交易系統(tǒng)可能還會考慮 Haskell。不過即便是二十年前，也很少有人用 Java 、Basic、Python 這類語言構(gòu)建數(shù)據(jù)庫，主要因為這些語言的運行效率和性能均不高。

因此，我們主要希望選擇一門高性能的編程語言，而所謂的高性能語言不外乎 C++、Rust 或者一些小眾語言，如果又想被用戶廣泛接受，那基本上就是 C++ 和 Rust。

提問：據(jù)了解，你們團隊最初選擇的是 C++，還集結(jié)了多位擁有 10 年以上經(jīng)驗的 C++ 工程師。當(dāng)初你們是看中了 C++ 的哪些特質(zhì)，還是說你們只是遵從了市場上大部分?jǐn)?shù)據(jù)庫系統(tǒng)的選擇？

吳英駿：我本人比較擅長 C++，不管是讀博期間還是創(chuàng)業(yè)之前開發(fā)的所有數(shù)據(jù)庫都是用 C++ 編寫的，我沒有用其他任何語言寫過項目。

創(chuàng)業(yè)之初，有人提議使用 Rust，理由是 Rust 很火。但在我看來，這算不上一個充分理由，我們又不是想成為網(wǎng)紅，選擇一門語言不能僅僅是為了火，我們需要考慮哪種語言適合團隊，以及數(shù)據(jù)庫領(lǐng)域的通用語言是什么。在數(shù)據(jù)庫領(lǐng)域，雖然 TiDB 的存儲引擎 TiKV 是用 Rust 寫的，但這不足以證明用 Rust 寫的數(shù)據(jù)庫系統(tǒng)都能成功，相反絕大多數(shù)成功的數(shù)據(jù)庫系統(tǒng)都是用 C++ 編寫的。

從招聘的角度來看，我們肯定希望招募到數(shù)據(jù)庫領(lǐng)域的專家，而擁有多年數(shù)據(jù)庫領(lǐng)域經(jīng)驗的專家大多來自如今的主流數(shù)據(jù)庫提供商——這些數(shù)據(jù)庫也基本都是用 C++ 寫的。

相較而言，Rust 是一門比較年輕的語言，缺少重量級項目。盡管實際上很多項目都使用了Rust，其中一些還是相對流行的項目，但還算不上重量級的大工程，生態(tài)系統(tǒng)或多或少有些不足。

綜上，最終我們決定使用 C++ 作為主要開發(fā)語言。

選擇用 Rust 重寫

提問：你們團隊已經(jīng)在這個項目上投入了 7 個多月，你也提到時間對于創(chuàng)業(yè)公司而言是非常寶貴的，是因為什么契機讓你們覺得不重寫不行了？

吳英駿：首先，C++ 比較常見的問題是內(nèi)存泄漏，但這類 Bug 比較容易修復(fù)，我們覺得可以忍。其次，依賴管理很痛苦，雖然 CMake 工具可以自動配置 C++ 項目的編譯，但使用起來還是很麻煩，我們?nèi)匀恍枰謩优渲貌惭b依賴庫；STL 庫缺乏對一些現(xiàn)代編程工具的支持，依賴的社區(qū)項目大多數(shù)還缺乏長期支持。最后，我們招聘到的成員 C++ 水平參差不棄，每個人都有自己的風(fēng)格，非常難以統(tǒng)一，導(dǎo)致閱讀代碼的難度過大，審查代碼更是勞心勞力。隨著越來越多人員的加入，C++ 問題暴露得越來越頻繁，在此期間不斷有工程師提出是否可以考慮用 Rust 重寫。

另外，流式數(shù)據(jù)庫通常用于處理對延遲非常敏感的關(guān)鍵性任務(wù)。因此，構(gòu)建 RisingWave 的編程語言必須滿足以下要求：保證零成本抽象，不能有性能上限；不需要運行時垃圾收集，可以控制由內(nèi)存管理引起的延遲峰值。

起初，我們并不想更換語言，畢竟已經(jīng)寫了這么久。但最終我們決定，如果支持用 Rust 重寫的工程師可以成功重寫一個獨立的模塊，我們就考慮重寫整個數(shù)據(jù)庫。與此同時，我也想起之前在 AWS Redshift 工作中遇到的一個 Bug，三個人不斷調(diào)試了兩周都無解，最終發(fā)現(xiàn)是內(nèi)存泄漏的問題。如果現(xiàn)在項目繼續(xù)下去很可能也會遇到類似的情景，假設(shè)那時產(chǎn)品已經(jīng)有了很多用戶，我們還需要因為這種內(nèi)存泄露的問題調(diào)試許久，那就得不償失了。所以就在那個時候，我們開始認(rèn)真考慮是否要用 Rust 重寫。

經(jīng)過慎重評估，我們需要花費大約兩個月的時間就可以用 Rust 重寫原來七個月寫的代碼，這個時間差主要是由于項目的邏輯框架已在項目前期梳理清楚。暑假期間公司招了大量實習(xí)生，人手比較充足，且很多實習(xí)生都有 Rust 的基礎(chǔ)，這些都提升了重寫的速度。最后，經(jīng)過全公司的表決投票，我們開始重寫。

在替換的過程中，我們選擇逐個模塊替換，這也保證了整個過程不會出現(xiàn)很嚴(yán)重的問題。

提問：用 Rust 重寫以后，C++ 代碼風(fēng)格不統(tǒng)一的問題得到解決了嗎？

吳英駿：風(fēng)格不統(tǒng)一的問題肯定不是用 Rust 就能解決的，但相對 C++ 會有很大程度的改善。C++ 中關(guān)于指針等的寫法很難統(tǒng)一，還容易造成安全性的問題。

提問：C++ 中一些語言層面的缺陷由來已久，在使用 C++ 作為主要開發(fā)語言之前，你沒有遇到過上述問題嗎？

吳英駿：我之前也遇到過，但在我上學(xué)期間，Rust 還不完善，用戶很少，因此不會考慮到用 Rust 去開發(fā)數(shù)據(jù)庫。此外，我之前接觸的數(shù)據(jù)庫都是比較成熟的產(chǎn)品，比如 IBM DB2，所以我的大部分工作時間都在調(diào)試，很難有精力和時間去重寫一個誕生于幾十年前的數(shù)據(jù)庫。

在大型企業(yè)內(nèi)部，只有不太重要的項目或者用戶數(shù)量不多的項目才有可能被重寫，否則就需要投入大量的精力和資源。對于起步階段的創(chuàng)業(yè)公司來說，還是有機會重寫的，一旦面對客戶交付的壓力，重寫就不太可能了。

提問：在重寫之前，系統(tǒng)已經(jīng)完成了多少？

吳英駿：簡單來說，框架已是比較清晰的水平。重寫不至于發(fā)現(xiàn)之前的 Bug，但通過重寫，我們確實會考量各個部分設(shè)計的合理性。

Rust 的優(yōu)勢

提問：Rust 有哪些有優(yōu)勢？

吳英駿：首先，安全性絕對是一大優(yōu)勢，這對數(shù)據(jù)庫項目非常重要。其次，包管理需要的工作量非常少，C++ 有非常多的庫，包管理非常復(fù)雜，你需要花費幾個小時才能搞清楚如何在 CMake 里面配置一個包管理工具，即便在配置之后也需要花費很多時間，比如無法安裝，還可能遇到重名的問題（其他項目中使用的變量名稱與我們庫中的名字重合了），這些問題都需要手動解決，而且改起來費時費力。

重寫的收益

提問：重寫前后的收益情況如何？

吳英駿：一句話總結(jié)：收益巨大。從收益比的角度看，我們損失的是時間，因為分段重寫大概花費了一個月左右，但這些時間并沒有白白浪費，這個過程讓我們又反思了一遍不同模塊的設(shè)計思路，改掉了其中不合理的部分。對數(shù)據(jù)庫系統(tǒng)而言，這是一個長周期的項目，早期孵化階段時間的寶貴程度和正式上線后肯定是有區(qū)別的。當(dāng)對象是直接用戶時，數(shù)據(jù)庫系統(tǒng)出現(xiàn)任何問題都是不能忍的。

我們收獲的是系統(tǒng)更加穩(wěn)定、安全，且代碼清晰，尤其是包管理部分有非常大的提升。此外，Rust 本身在高速發(fā)展中，整個社區(qū)非常有活力，提問基本都能夠得到及時回復(fù)，這是 Rust 生態(tài)系統(tǒng)帶給我們的優(yōu)勢。

使用 Rust 重寫代碼的注意事項

提問：重寫之后，原來那批 C++ 工程師都自學(xué)了 Rust 嗎？

吳英駿：團隊中的部分工程師之前就掌握了 Rust，只是未在工作中使用，這部分工程師還是比較容易轉(zhuǎn)換的。我們也專門讓一些工程師評估從零開始學(xué) Rust 需要多久，絕大多數(shù)工程師基本能夠在一個月之內(nèi)掌握 Rust，但還達(dá)不到全面掌握，只是可以使用 Rust 寫一些代碼。

整個過程比較順利，因為部分工程師會利用業(yè)余時間自學(xué) Rust，并將經(jīng)驗傳播給其他人，這是非常重要的。我認(rèn)為，如果公司決定重寫，那么公司內(nèi)部必須有一到兩位，甚至更多位擁有 Rust 實戰(zhàn)經(jīng)驗的工程師，或者至少愿意利用業(yè)余時間學(xué)習(xí)，并將經(jīng)驗傳授給其他人，這可以降低整個公司的學(xué)習(xí)難度，畢竟 Rust 的學(xué)習(xí)曲線是比較陡峭的。

提問：擁有其他編程語言基礎(chǔ)對于學(xué)習(xí) Rust 有影響嗎？

吳英駿：會有差異，而且比較明顯。對于其他語言，比如 Python，最大的特點是簡化編程，開發(fā)人員不需要考慮內(nèi)存管理等問題，但 Rust 需要這方面的基礎(chǔ)，所以擁有不同的語言背景，對于學(xué)習(xí) Rust 的成本有不同的影響。

提問：Rust 一直存在編譯時的問題，你們有感受到嗎？

吳英駿：Rust 確實存在編譯時問題，但 C++ 的編譯相對也很慢，所以目前還可以忍受。如果編譯時間過長，工程師會定期查看編譯過程，并嘗試是否有辦法可以縮短這個時間。

提問：你會建議什么類型的公司或者業(yè)務(wù)團隊在什么情況下選擇重寫代碼庫？

吳英駿：如果是大型公司內(nèi)部選擇重寫，大概率表明項目本身不是那么重要，或者是核心項目的邊緣模塊，用戶沒有那么多、公司又有錢、有資源、有人力，這種情況下可以考慮重寫。對于創(chuàng)業(yè)公司而言，早期還有精力重寫，一旦用戶量上來就會面臨交付壓力，基本不太會做這種決定。

此外，你需要搞清楚換編程語言的理由，出于性能、安全性或者其他原因，而不只是因為某種語言很火。以數(shù)據(jù)庫領(lǐng)域為例，現(xiàn)在很多成功的數(shù)據(jù)庫誕生距今已有十年以上，經(jīng)歷了長時間的磨煉，其實轉(zhuǎn) Rust 的需求并不大。總的來說，我認(rèn)為考慮實際的需求非常重要，你需要綜合考慮再做決定。

提問：你覺得目前 Rust 的生態(tài)環(huán)境如何？

吳英駿：整體來看 Rust 的生態(tài)環(huán)境比較不錯，主要問題在于缺少大型項目驗證，比如 Go 最成功的項目是 Kubernetes。但我們也看到不少科技公司考慮使用 Rust 重寫某些服務(wù)，比如 InnoDB，也看到很多公司加入了 Rust 基金會，比如 AWS、Google、Facebook 等。我相信，有了這些公司的長期支持，未來會出現(xiàn)一些非常不錯的項目，Rust 會變得越來越好。

提問：選擇用 Rust 重寫與團隊規(guī)模和狀態(tài)之間是否有關(guān)系？

吳英駿：我覺得重寫和團隊規(guī)模的關(guān)系不是很大，但我更建議年輕的團隊選擇 Rust，當(dāng)然這也因人而異。至于最終是否要轉(zhuǎn)，也要考慮團隊大多數(shù)人的意見，因為在學(xué)習(xí)了一段時間之后，發(fā)現(xiàn)還是沒有熟練掌握 Rust 可能會有很強的挫敗感，這需要團隊成員的共同努力，僅憑興趣很難做好。此外，僅憑興趣決定創(chuàng)業(yè)以及對外提供商業(yè)化服務(wù)，這也是非常不負(fù)責(zé)的。