傳承 or 創新 ？解密分散式資料庫自研修煉之路
一直以來，資料庫的核心研發團隊都十分神祕，作為隱藏在幕後的隱士高人，他們對資料庫研發的心得是什麼？他們又對資料庫的未來發展有什麼看法呢？本文就由巨杉資料庫核心技術研發團隊的“老司機”，分享分散式資料庫的自研修煉之路。
資料庫研發的最難點——技術基因與創新
資料庫軟體，特別是一款真正企業級的產品，並不是大家想象中僅開發一款軟體那樣簡單。
追溯資料庫技術的發展歷程，資料庫（database）一詞最早流行於系統研發公司的技術備忘錄中，到目前已有 40 多年的歷史。在這期間，資料庫軟體 / 平臺逐漸成為一個功能複雜、架構龐大、安全要求很高的龐大軟體產品體系。因此，在此發展基礎之上，技術基因傳承 和技術創新 成為資料庫技術的最關鍵兩個點，但這兩項關鍵點恰恰是資料庫研發的最難點，為什麼這麼說呢？
從應用層面上講，大部分使用者是從 30 年前就開始使用資料庫的老客戶，例如銀行、政府等。他們通常無法承擔全盤遷移的風險，因此在業務技術架構上，難免保留了各個時代的歷史遺留。比如，北美一些銀行的核心 IT 系統，直到目前仍然執行在 40 年前的技術平臺之上。所以，這也要求企業級的資料庫需要具備很強的相容能力，不但可以保證舊業務的執行，還可以持續進行技術創新。
同時，基礎軟體特別是資料庫的研發，和其他應用軟體有很大的不同。其中最大的一個不同點就是開發語言 和開發模式 。
從計算機的發展來看，C 語言是最面向機器語言（彙編程式碼）的，原則上每一行 C 程式碼都可以很精準地對映到一些彙編指令上。因此，C 語言對作業系統底層的操控最為精準。而 C++ 則是在 C 語言之上發展起來的面嚮物件語言，雖然在底層程式設計中 C++ 的高階特性被使用得非常少，但是其設計模式對於模組化開發很有幫助。因此，使用 C++ 既可以兼顧對作業系統底層最精準的把控，也可以將一些面向物件的理念融入程式碼中，在複雜系統構建時起到重要作用。
而如今，一些新型開發語言則不是面向物件的，所以在設計模式上不適合大型複雜系統的開發。同時，這些語言簡化了很多 C/C++ 裡最為重要的指標概念。而對於大部分能力不高的程式設計師或者沒有非常完善測試框架的專案，不能完美把握指標這類高階特性，則會在大型專案開發中經常造成記憶體洩露和崩潰漏洞等問題。
但是，對於有著 DB2 資料庫核心研發經驗的巨杉資料庫而言，從人員能力，到程式碼質量管理，到測試框架的完善都能夠完美駕馭這類高階特性，能夠最大程度挖掘出作業系統和資料庫底層的效能與處理能力。
資料庫研發團隊—技術基因與積累
IBM 是最早提出“關係型資料庫”這一概念和理論體系的公司。從技術上看，傳統三大關係型資料庫已經具有很深遠的技術儲備，而 DB2 是三大傳統關係型資料庫中唯一的分散式產品。
在 DB2 工作的十幾年裡，給我感受最深的就是其技術底蘊和沉澱。比如，在 Unix 真正支援執行緒機制之前，針對多執行緒模型，甚至是針對不同的硬體裝置，DB2 早已使用匯編語言實現了邏輯執行緒的切換和呼叫，這些機制在當時其實是相當領先的。另外在研發團隊上，IBM 的實驗室也是臥虎藏龍。那些最初使用匯編語言開始的技術專家們，也一直參與資料庫、作業系統和編譯器底層的研發工作，可以說正是他們創造了最早的關係型資料庫的概念，也是他們真正把資料庫打造成為一個通用的軟體平臺。
因此，資料庫核心研發團隊的基因很重要。就像上面提到的技術複雜度和產品歷史跨度問題，新一代基礎軟體產品團隊要圍繞老一輩的“老司機”構建。而 DB2 團隊就是依靠多位具有傳統資料庫開發經驗的“老炮兒”，實現了 IBM 資料庫產品技術經驗和基因的沿襲。
然而，國內基礎軟體的人才積累還不夠，目前還沒有完全形成基礎軟體領域的武林門派，這也是近年來基礎軟體和 AI 領域國內企業瘋狂往外招人的原因。
而巨杉資料庫團隊擁有以王濤為代表的很多 DB2 團隊的核心技術專家，以及來自華為的技術核心團隊成員，是技術基因和技術創新很好的結合。
資料庫發展方向
對於大部分應用程式來說，賬戶資訊、配置資訊、維度表這類資料量相對比較可控，真正爆炸性增長的是流水類資料。一個應用程式裡面絕大部分表不會太大，真正特別大使得傳統關係型資料庫存不下的表相對來講數量都是可控的，因此有很多 workaround 都可以搞定這個問題，這也是為什麼傳統以來大家用分庫分表雖然麻煩，但也不是解決不了應用問題。
所以，資料庫真正面臨的痛點是“微服務”下，資料服務的資源池化。
應用程式在從傳統煙囪式構建，向微服務轉型的過程中，在每一個微服務都放上一個獨立的資料庫已經是不可能的事情了。這種情況下，資料服務資源池需要直接面向上層成百上千個，來自不同開發商、不同團隊的開發能力不一、應用型別不同、SLA 安全級別不同等等的各類需求。
因此，資源池必須擁有彈性擴張、資源隔離、多租戶、可配置一致性、多模式（支援各類 SQL 協議）、叢集內可配置容災策略等一系列功能，同時每個資料庫例項的計算和儲存能力需要滿足能夠無限擴張的條件，畢竟有些微服務可能會涉及到極多的流水資料，不能限定每個資料庫例項使用的資源僅侷限於一臺物理裝置。
所以說，單純為了分散式的 OLTP 只是解決了不構成剛需的問題（分庫分表早可以解決），但是在微服務應用開發的環境下，資料庫更是要從資源池化的角度對上層提供服務，同時資源池中的每個資料庫例項內部也要支援分散式交易等一系列特性，做到與傳統資料庫的全相容。
巨杉資料庫新發版本：效能提升 2-3 倍
近期，巨杉資料庫會發佈一個新的版本，不僅在 OLTP 場景下效能會有大的提升，同時也對於 SQL 處理能力上有很大提升。
另外在分散式的交易型業務下，整體效能提升將比現在版本有 2~3 倍的提升，對比同類產品效能將高出 5~6 倍，也請期待巨杉資料庫接下來的系列技術專題和技術活動。
雖然巨杉資料庫團隊很多都是來自 IBM、華為的“傳統企業級 IT 人”，大家都習慣低調地隱藏在幕後，但是現在是技術圈一個變革的新時代，SequoiaDB 巨杉資料庫已經開源了，所以今後也會讓巨杉資料庫團隊的技術大牛們多多參與社群活動，分享我們做資料庫核心研發的心得，也和大家一起進步。
作者介紹：
Danny Chen，巨杉資料庫核心研發成員，資深資料庫架構師。超過 20 年的資料庫核心研發經驗，是一名資料庫資深工程師和架構師，曾經作為 IBM DB2 核心研發團隊成員參與了 DB2 ，DPF 等產品的架構設計和研發工作。