OceanBase 首席架構師：關聯式資料庫到三代分散式資料庫，我親歷的資料庫演進史

本文嘉賓：楊傳輝（花名：日照），螞蟻集團研究員，OceanBase 創始成員和首席架構師。主導了 OceanBase 技術架構設計，實現分散式資料庫在核心金融場景零的突破。同時，他也主導了 OceanBase TPC-C 測試並打破世界紀錄。著有專著《大規模分散式儲存系統：原理與實踐》。

本文將帶來他從業十幾年的專業思考，期待與大家碰撞想法。

概要

自從 1970 年提出關係模型，關聯式資料庫已經發展了 50 多年的時間，產生了一家市值曾經超過 2000 億美金的公司，Oracle。然而，傳統關聯式資料庫採用集中式架構，無法解決網際網路時代的可擴充套件和高併發問題，這次報告將與大家一起探討下一代分散式資料庫的設計。

關聯式資料庫發展過程

關聯式資料庫領域總共誕生了三點陣圖靈獎得主：關係模型提出者 E.F.Codd，事務模型提出者 Jim Gray，以及 Michael Stonebreaker。

 

關聯式資料庫也是電腦科學所有領域中圖靈獎得主最多的，如果大家有志於獲得圖靈獎，關聯式資料庫也是一個很不錯的選擇。分為幾個流派：最知名的兩個資料庫都屬於 Oracle 公司，分別是商業資料庫 Oracle，以及收購的開源資料庫 MySQL；IBM 是關聯式資料庫理論的提出者，但發展不太好，並沒有抓住關聯式資料庫產業化的機會，反而成就了 Oracle，DB2 資料庫目前主要應用在金融等行業的大機系統中；除了 Oracle、MySQL 和 DB2 以外的主流資料庫都有一個共同的祖先：Ingres。Stonebreaker 除了發明 Ingres，也是  PostgreSQL，Vertica 等多個資料庫的創始人。微軟的 SQL Server 和 Sybase 資料庫也源自 Ingres。

縱觀分散式資料庫的發展，我認為分散式資料庫經歷了三代：

• 第一代分散式表格系統是 NoSQL 系統，代表作是 Google Bigtable；

• 第二代分散式資料庫支援可擴充套件的 SQL 處理，代表作是 Google Spanner；

• 第三代分散式資料庫是透明擴充套件的企業級資料庫，相容傳統集中式資料庫，支援 HTAP 混合負載，且單機價效比很高，代表作是 OceanBase。

分散式資料庫的核心技術

絕大部分技術來源於關聯式資料庫

分散式資料庫的絕大部分技術來源於關聯式資料庫，而不是分散式系統，資料庫領域的技術積累強於分散式領域。

首先，我們一起看看關聯式資料庫的核心技術。學過計算機的同學都聽過一句話： 程式=資料結構+演算法。儲存對應關聯式資料庫的“資料結構”，事務對應關聯式資料庫的“演算法”，SQL 是關聯式資料庫的使用介面。除了儲存、事務、SQL 這三個核心模組以外，關聯式資料庫還支援資料型別、函式、儲存過程等相容性功能，以及效能、成本、安全、可靠等企業級特性。

關聯式資料庫支援事務 ACID，很多大資料系統也會盡量把自己說成是資料庫，然而， 能成為資料庫的根本原因還在於能夠支援事務 ACID，從而應用到 Mission Critical 的核心業務場景。今天，我們經常提到一個詞叫 HTAP 混合負載。其實，商業資料庫一直都支援複雜查詢和混合負載，即在同一套引擎同時支撐 OLTP 交易型負載和 OLAP 分析型負載。真實的企業級應用場景中，純粹的 OLTP 和純粹的 OLAP 都是比較少見的，往往都是既有 OLTP，又有 OLAP。很多網際網路業務之所以很簡單，只需要 KV 儲存，原因在於網際網路業務做了大量的改造，將本來屬於資料庫的邏輯往上移到了應用層。

關聯式資料庫成功的經驗

關聯式資料庫之所以能夠如此成功，我認為原因有三點：

第一，應用驅動創新，應用創新和技術創新相輔相成，產生了一個從理論到技術到產品再到商品的完整資料庫產業；早期的 Oracle 版本也不好用，功能不完善甚至經常遇到穩定性故障，但是，透過應用創新驅動技術創新，讓越來越多使用者使用 Oracle，從而完成了產品技術迭代，戰勝了 IBM DB2 等同時期的競爭對手，這才成就了我們今天看到的 Oracle；

第二，抽象與標準化，抽象關係模型和事務模型，將 SQL 語言和 TPC 測試標準化，從而讓全球資料庫廠商能夠在同一個平臺上良性競爭，共同促進；TPC 標準出來之前，每個資料庫廠商都說自家的產品是最好的，有了 TPC 標準之後，再加上第三方中立的審計組織，到底是騾還是馬，拉出來溜溜就知道了，資料庫廠商也不要把太多精力放在市場宣傳上，而是真正去最佳化資料庫產品；

第三，追求極致效能，成功的關聯式資料庫全部採用 C 語言實現，注重實現細節，最佳化程式碼路徑的 CPU 指令數，在基礎設施層面做到高效能，低延遲，從而大大簡化應用。

當“封閉體系”遇到“開放網際網路”

關聯式資料庫架構的傑出代表是我們常說的 IOE 架構：I 指的是 IBM 小型機、大型機；O 指的是 Oracle 資料庫；E 指的是 EMC 的儲存。IOE 基於專用軟硬體，本質上是一個封閉體系，這個體系的最大問題在於不夠開放，產生了兩個問題：

一是價格非常昂貴。摩爾定律大幅降低了開放的 X86 硬體的成本，而專用硬體無法享受技術紅利，一套專用硬體往往需要上千萬甚至上億人民幣；

二是幾乎無法橫向擴充套件，只能支援垂直擴充套件，透過購買更好的硬體來提升系統的處理能力，從而錯過了雲和分散式時代的技術變革。

傳統集中式資料庫面向的是封閉體系下的 Mission Critical 業務場景，處理的是少量使用者最為關鍵的基礎資料和事務資料，比如賬戶、交易資料；而網際網路是開放體系，處理的是大量使用者的全部行為資料，這些行為資料不僅僅包含基礎資料和事務資料，也包含互動資料，也就是海量使用者併發訪問過程產生的日誌。

這將導致兩類問題：

一是現象級應用帶來的可擴充套件和高併發需求。如天貓雙十一零點峰值的流量是平常的幾十上百倍，需要資料庫系統具備快速彈性擴容的能力；

二是海量資料帶來的分散式架構。集中式架構把硬體故障當成異常處理，而大規模分散式架構把硬體故障看成正常現象，這是一種新常態，需要在軟體層面實現自動容錯，且做到低成本儲存。

網際網路時代的分散式資料庫

首先，讓我們向大規模分散式儲存系統的引領者 Google 公司致敬。

Google 最早在生產環境中應用大規模分散式系統，並且把用到的核心技術公開發表成三篇論文，也被成為“三駕馬車”， 分別是分散式檔案系統 GFS，分散式計算系統 MapReduce，以及分散式表格系統 BigTable。這三個系統第一次提出將硬體故障當成正常現象的設計理念，並在軟體層面實現自動容錯，有一個總控節點 Master 處理後設資料和全域性排程，其它工作節點執行具體的儲存和計算任務。

“三架馬車”很好地支撐了 Google 早期的海量資料處理業務，奠定了 Google 基礎設施的領先優勢，從而支援搜尋廣告等業務快速發展。每個想要學習大規模分散式系統的同學都推薦精讀這三篇論文，裡面用到的技術到今天仍然沒有過時，仍然是理解分散式資料庫的基礎。我所在的 OceanBase 團隊也會定期開展論文閱讀，幫助每個新加入的同學深入理解這三篇論文。

下面我們詳細來看看這三代分散式資料庫的發展過程。

第一代分散式資料庫 NoSQL

第一代分散式資料庫其實是 NoSQL 系統。為了實現可擴充套件，第一代分散式資料庫犧牲了 SQL 和事務，不支援 SQL 語言，不支援跨機事務，只支援單行事務或者單機事務，部分 NoSQL 系統甚至犧牲一致性。11年到13年之間 NoSQL 系統很流行，當時很多人認為資料庫效能瓶頸的根源在於 SQL，只要犧牲 SQL 語義，就能夠一勞永逸地解決高併發場景下資料庫面臨的可擴充套件性和單機效能問題。當時有一些流行的說法，比如"SQL is dead"，"one size does not fit all"，走向了另一個極端，但是做著做著卻發現 NoSQL 系統中用到的核心技術大多都源於關聯式資料庫。OceanBase 團隊 12 年也有爭論，到底是走 NoSQL 路線還是堅持做關聯式資料庫，最終我們還是決定做關聯式資料庫，這才走到了今天。

最流行的兩個 NoSQL 系統分別是 Amazon Dynamo 和 Google Bigtable。

他們的底層儲存分別是一個分散式雜湊表和一棵分散式 B+樹。Dynamo 採用去中心化的設計，引入一致性雜湊來做資料分佈，並採用 NWR 協議，要求寫入的副本個數 W 加上讀取的副本個數 R 大於總副本數 N。Dynamo 系統最大的問題在於犧牲了一致性，需要使用者處理衝突，這個做法最後證明是失敗的，Amazon 後期設計的分散式儲存系統 DynamoDB 就沒有沿用這個做法，而是在內部透過 Paxos 協議保證強一致性。

Google Bigtable 構建在 GFS 之上，實現了強一致性，自動將表格劃分為子表 tablet，實現了 tablet 的自動分裂與合併。Bigtable 只支援單行事務，之所以只有單行事務，我認為根本原因還在於分散式事務實現過於複雜，不容易做到高效。Bigtable 有兩個開源的模仿者，一個是 Hypertable，另一個是今天非常流行的 HBase。

第二代分散式資料庫

第一代 NoSQL 系統對使用者很不友好，關聯式資料庫的效能和擴充套件性問題也並不是因為支援 SQL，於是進一步產生了第二代分散式資料庫。

第二代分散式資料庫以 Google Spanner 為代表。Spanner 支援大部分 SQL，支援分散式事務，但不相容 SQL 標準。Spanner 透過 Truetime 實現了分散式事務全域性時間戳，保證了強一致性，但每次事務提交延時很高，犧牲了單機效能。Spanner 是第一個全球級的分散式資料庫，很好地解決了 Scalable SQL 問題，但犧牲了關聯式資料庫最核心的價效比等企業級特性。Spanner 適合應用在對擴充套件性要求特別高的特定應用場景，例如 Google 本身，但不適合應用在傳統行業的 Mission Critical 業務場景。

第三代分散式資料庫

第三代分散式資料庫是透明擴充套件的企業級資料庫，以 OceanBase 為代表。

第三代分散式資料庫的設計理念是把複雜留給基礎設施，把簡單留給資料庫使用者：業務開發人員和運維人員。

它的底層是可擴充套件的分散式架構，從而享受分散式技術的紅利，如高可用、可擴充套件，相容傳統企業級資料庫的功能，在同一套資料庫引擎中支援 HTAP 混合負載，並同時，追求極致的單機價效比。

追求極致價效比這一點將從根本上影響分散式資料庫的設計，舉幾個例子：

1) Google Spanner 系統透過 Truetime 機制獲取全域性時間戳，這個方案導致事務延遲太高，需要改變；

2) 分散式資料庫可以劃分為 SQL 層和儲存層，Google Percolator 系統的事務和併發控制機制構建在儲存層之上，採用松耦合的設計，影響效能。為了追求極致價效比，需要和傳統關聯式資料庫一樣，把事務層放到儲存層內部，採用緊耦合的設計。

3) 為了追求效能極致，需要扣實現細節，儘可能最佳化讀寫流程的 CPU 指令數，採用 C/C++ 語言實現，手動執行記憶體管理。

第三代分散式資料庫：OceanBase

2021 年是 OceanBase 發展的第十一年，它的成長過程如下圖：

2013 年之前，OceanBase 是一個分散式表格系統，不支援 SQL，應用在阿里電商平臺，包括淘寶收藏夾，天貓評價，淘寶直通車等等。這個架構最大的優勢在於相對簡單，能夠快速開發出來並在生產系統上線。

2014 年到 2017 年，OceanBase 開始支援 SQL 和 Paxos 高可用，逐步演化為一個可擴充套件的分散式資料庫，首次做到在不依賴專用硬體的情況下，資料庫節點故障完全不丟資料且 30 秒之內恢復。透過首創 Paxos 高可用秘方，OceanBase 成功擊敗其它開源資料庫，全面支援支付寶交易、支付、賬務等核心場景。

2017 年之後，OceanBase 開始服務更多的企業客戶，成為一個透明擴充套件的企業級資料庫。OceanBase 先後在 2019 年和 2020 年兩次參加 TPC-C 測試，並取得世界第一的成績。TPC-C 測試既驗證了 OceanBase 的擴充套件能力，也驗證了 OceanBase 的單機效能。

 

今天的 OceanBase 是一個透明擴充套件的企業級資料庫，包含儲存、事務和 SQL 三個核心引擎。

儲存：OceanBase 的儲存引擎是一個兩級分割槽表加上 LSM 樹。

兩級分割槽表源於傳統的關聯式資料庫 Oracle，支援雜湊分割槽、Range 分割槽，以及雜湊和 Range 的各種組合分割槽，能夠透過自動 Range 分割槽解決經常遇到的大賬號熱點問題。兩級分割槽表最大的優勢在於與傳統關聯式資料庫完全相容，且 OceanBase 後臺會自動地將不同分割槽均勻地打散到分散式叢集中，對使用者完全透明。LSM 樹採用 Append only 和批次合併的設計，相比傳統關聯式資料庫的 B+樹，LSM 樹最大的優勢在於壓縮效率高，且支援對線上 OLTP 業務做壓縮，從而大幅降低成本。傳統關聯式資料庫，例如 Oracle 或者 MySQL 也支援壓縮，但是，傳統關聯式資料庫的壓縮在 OLTP 業務往往是不開啟的，只要開啟，效能大幅降低，而 LSM 樹沒有這個問題。

事務：OceanBase 的事務引擎採用兩階段提交加 Paxos 的設計。

這個設計源於 2004 年兩點陣圖靈獎得主 Jim Gray 和 Lamport 聯合發表的一篇論文。Jim Gray 幾十年前就已經提出了兩階段提交協議，用於解決分散式事務多機一致性問題，然而，兩階段提交協議是一個阻塞協議，無法處理節點故障。當協調者或者參與者節點發生故障時，系統只能停服務。透過引入 Paxos，節點故障後 30 秒之內自動恢復，完全不丟資料，也不丟失正在進行中的分散式事務的狀態，從而將兩階段提交協議由理論上升為大規模工業實踐。有了支援容錯的分散式事務之後，就可以在它之上實現分散式索引，分散式修改，分散式查詢等完整關聯式資料庫功能。

SQL：OceanBase 的 SQL 引擎面向 HTAP 混合負載設計。

純粹的 100% OLTP 業務或 100% OLAP 業務都是很罕見的，絕大部分業務都是既有 OLTP 又有 OLAP，也就是 HTAP 混合負載。傳統關聯式資料庫把系統劃分為兩類：OLTP 交易型資料庫和 OLAP 分析型資料庫，並透過 ETL 系統實時或者定期將 OLTP 資料庫的資料拉取到 OLAP 資料庫。

這個方案面臨兩個問題：

1) 時效性，資料倉儲有一個概念叫 T+1，這就是時效性導致的問題；

2) 資料一致性，資料倉儲常出現資料不一致的問題，需要人肉訂正。

OceanBase 透過同一套引擎同時處理 OLTP 和 OLAP 兩種工作負載，大大簡化了應用。有了 HTAP 處理能力之後，對於大部分中等規模的客戶，只需要一套系統，不再需要多套系統。

極 致效能：關聯式資料庫最核心的企業級特性

TPC-C 是目前國際上唯一具有公信力的資料庫功能與效能結合的公開檢測標準。TPC-C 首先測試資料庫的功能，只有功能滿足與傳統集中式資料庫對標的 ACID 強一致特性之後，效能才有意義。

OceanBase 參加 TPC-C 測試，最大的意義並不是跑分有多高，而是證明了一點：基於分散式架構的企業級分散式資料庫能夠實現與集中式資料庫完全對標的 ACID 強一致特性。

有了這一點支撐，由於分散式資料庫能夠透過增加伺服器來提升系統的處理能力，自然能夠跑出更好的結果。OceanBase 在 2019 和 2020 年先後取得 6088 萬和 7.07 億 tpmC 的成績，排名世界第一。這也是分散式資料庫第一次正式透過審計，測試基於公有云，採用與生產環境完全一致的通用機型。

被市場驗證的企業級分散式資料庫

OceanBase 應用在螞蟻集團，支撐了包括螞蟻集團交易、支付、賬務、會員在內的全部核心業務的 100% 流量，今天我們在支付寶每一筆交易和支付操作背後的資料庫都是 OceanBase。

除了螞蟻集團之外，OceanBase 也應用在銀行、保險、證券、運營商等行業的幾百個客戶的核心繫統上。OceanBase 的業務還在快速增長中，也期待越來越多優秀人才加入到 OceanBase，一起為中國資料庫硬核科技做貢獻。

總結

最後做一個小結，傳統集中式資料庫包含儲存、事務、SQL 這幾個核心引擎，以及基於這些核心引擎之上的資料庫功能和效能、成本、安全、可靠等企業級特性。

隨著網際網路時代的到來，為了處理海量使用者的行為資料，集中式資料庫的可擴充套件性和併發處理能力成為瓶頸。為了解決這個問題，分散式資料庫經過了三次迭代：

第一次迭代是分散式儲存系統，也稱為 NoSQL，2013 年之前比較流行，基本思路是犧牲 SQL，犧牲事務、一致性和企業級功能，只支援簡單的 KV 操作從而做到可擴充套件；

第二次迭代是分散式資料庫，以 Google Spanner 系統為代表，支援可擴充套件的 SQL，在第一代 NoSQL 系統的基礎之上引入了 SQL 和分散式事務，保證強一致性，但是不太注重 SQL 相容性和價效比，單機效能往往比較差 ，系統天花板很低；

第三次迭代是透明擴充套件的企業級資料庫，以 OceanBase 系統為代表。分散式架構對業務透明，且支援完備的相容 MySQL 和 Oracle 的企業級功能，支援 HTAP 混合負載 ，採用 C 語言實現，單機效能和系統天花板很高。

我認為，關聯式資料庫的未來必定是企業級分散式資料庫。今天中國有幾百家資料庫公司，很多公司都在做分散式資料庫。隨著時間的推移，相信越來越多的公司會選擇與 OceanBase 類似的技術路線，並逐步演進為透明擴充套件的企業級資料庫。

今天的內容基於我十多年的行業摸索和思考，知識在交流中才更有價值，希望我的分享能給大家一些啟發，也希望大家少走一些 OceanBase 曾經走過的“彎路”，歡迎留言討論，更期待與大家一起把中國資料庫產業做大做強。

附《下一代分散式資料庫設計思考》QA

OceanBase 沒有表 鎖 ，怎麼做到 DML 和 DDL 的？

A：OceanBase 的儲存引擎採用了 schema 和資料分離的設計，簡單的 DDL（例如增加列和刪除列）只需要更新 schema即可，查詢時再根據當時的 schema 解析資料。以刪除列為例，schema 只是標記刪除，讀取時再過濾刪除列，資料列的物理刪除操作在後臺合併時執行。

OceanBase 要做 HTAP，那 OceanBase 有什麼理由，能既做好 A，又做好 P 呢？資源隔離怎麼做得好呢？

A：這裡需要避免走極端，HTAP 可以認為是 OLTP 的增強，提升了實時 OLAP 的能力，但在超大資料量的離線 OLAP 分析上相比離線數倉或者大資料的技術還有一定的差距。只不過當 HTAP 資料庫出現之後，對於絕大部分中等規模的客戶，HTAP 資料庫非常方便，沒有必要為了最後一點極致的分析效能而單獨部署一個數倉，只需要一套 HTAP 資料庫就足夠了。

想了解下 OceanBase 雲原生的想法，shared nothing 和存算分離的關係。

A：我認為這兩種技術不矛盾。儲存計算分離解決了儲存可擴充套件的問題，但寫入不可擴充套件，shared nothing 進一步解決了寫能力可擴充套件的問題。儲存計算分離有一個好處是彈效能力會更好，因為計算節點遷移成本更低。

OceanBase 同時支援 shared nothing 和儲存計算分離，可以把儲存計算分離看成是類似 Oracle 的 ASM（Automatic storage management，自動儲存管理）。

OceanBase 在追求極致價效比方面做了哪些努力？

A：首先，採用緊耦合的設計，儲存和事務模組緊耦合從而做極致最佳化，並儘量做到事務處理本地化。其次，採用 C 語言實現並最佳化讀取路徑的 CPU 指令數，嚴格把關程式碼細節，追求極致。

緊耦合設計對於效能極致很關鍵的，比如 MySQL 為了支援多儲存引擎，採用單機松耦合設計，帶來的問題就是寫兩份 redo log，Oracle 就只需要寫一份資料。分散式資料庫緊耦合和松耦合的效能差異就更加明顯了。

本次分享時間太短了，意猶未盡，後續還有什麼活動可以提前劇透一下嗎？

A：後續 OceanBase 技術團隊會更加頻繁地和大家交流，之後每個月會舉行直播或者各城市 Meetup，每週會輸出一個分散式資料庫技術短影片（影片號 ID：OB小話嘮），與大家保持高頻率交流，期待大家的持續關注，更準備了非常有趣的周邊作為禮物送給大家。

  直播預約  

在《下一代分散式資料庫設計思考》的分享中，OceanBase 首席架構師楊傳輝給大家分享了他從業十幾年的資料庫的經歷，著重介紹了分散式資料庫的三代演變。

是不是還沒聽夠？4 月 28 日 19:00，他將延續三代分散式資料庫演進思路，介紹 第三代分散式資料庫的一體化設計。

你將獲得：

1)  持久化與日誌。如何透過分割槽級日誌實現動態擴充套件，以及 Paxos 和 Raft 協議的權衡。

2)  併發控制與事務。如何透過多版本併發控制和兩階段提交實現事務的隔離性和原子性，並且儘可能最佳化效能。

3)  HTAP 混合負載。透過行列混合儲存、cgroup 隔離等技術兼顧 OLTP 和 OLAP 兩種工作負載，儘量最佳化批處理的 CPU 指令數。