> *本文轉載自微信公眾號“機器之心（ID:almosthuman2014），原文[《破世界紀錄的國產資料庫OceanBase，如今入選了國際頂會VLDB 2022》](http://mp.weixin.qq.com/s?__biz=MzA3MzI4MjgzMw==&mid=2650857785&idx=1&sn=71d2dbe7484348927e935cd5ba685172&chksm=84e52547b392ac51b19aab57491be060b36841aeba3ed7591f7029f2a9087b02eca5ebda9d76&scene=21#wechat_redirect)”

近年來中國資料庫蓬勃發展，各種排行榜單不一而足，雲原生、Sharding、混合負載等新名詞層出不窮。

但盛景之下，各家資料庫的技術實力究竟如何？

日前，OceanBase 研究成果論文《OceanBase: A 707 Million tpmC Distributed Relational Database System》，被資料庫國際頂會 VLDB 2022 接收。VLDB 與SIGMOD、ICDE 並稱為全球資料庫三大學術頂會，收錄研究機構以及工業界在資料庫領域最前沿、最頂級的研究成果。

![Image](https://img.alicdn.com/imgextra/i2/O1CN0150Zd5P1i88P4jIgyg_!!6000000004367-2-tps-834-374.png)

論文連結：https://vldb.org/pvldb/vol15/p3385-xu.pdf

論文介紹了 OceanBase 的設計目標、設計標準、基礎設施和關鍵元件，以及在 1500 多臺伺服器（分佈於 3 個區域）的分散式叢集中透過 TPC-C 基準測試並取得全球最高成績背後的技術細節。

VLDB 評審專家也對 OceanBase 給予了高度評價：「作為創造 TPC-C 基準測試世界紀錄的大規模分散式關聯式資料庫系統，其架構和重要元件在論文中得到了非常全面的概述。OceanBase 設計並實現了一個分散式資料庫，並在 OLTP 工作負載上實現了前所未有的效能和可擴充套件性。」

OceanBase 無疑是中國資料庫的代表，而這篇論文則為我們提供了一個深入中國資料庫技術的很好的通道。讓我們研讀論文，看看 OceanBase 為何能創下超過 7.07 億 tpmC 世界紀錄。

## OceanBase 的「一體化架構」是什麼？

先從 OceanBase 的設計思路講起，作為一個分散式關係型資料庫系統和可擴充套件的多租戶系統，它基於 Share Nothing 架構，具備跨地域容錯能力。

下圖 1 為 OceanBase 的整體架構概覽。從上到下看，應用層傳送請求至代理層（OBProxy），經代理服務路由後傳送至實際服務資料的資料庫節點（OBServer），最後執行結果沿逆向路徑返回至應用層。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01GpeCWM205zdMFB7a2_!!6000000006799-2-tps-842-664.png)

每個節點都有自己的 SQL 引擎、事務處理引擎和儲存引擎，執行在普通 PC 伺服器組成的叢集之上，各個節點之間完全對等。這些節點分屬於若干個可用區（Zone），每個節點屬於一個可用區。圖示 OceanBase 資料庫叢集中的資料有三個副本，每個 Zone 存放一份。這三個 Zone 構成一個整體的資料庫叢集，為使用者提供服務。

透過這種方式，OceanBase 用計算機網路將物理上分散的多個資料庫單元連線起來，**構成了一個在邏輯上統一的單一資料庫**，其中不同的元件以不同的方式實現了高可用性。

雖然擁有與其他分散式資料庫系統（DBMS）相似的目標，如水平可擴充套件性和容錯性等，但鑑於 MySQL 及 Oracle 等資料庫的盛行，以及經典關係型資料庫經受住了時間考驗的關鍵技術和特性，OceanBase 在設計時考慮到了典型的 RDBMS 相容性需求，尤其注重業務的遷移成本和使用者的學習成本。

由此，OceanBase 資料庫在經典關係型資料庫的基礎之上引入了分散式，實現了高可用和可擴充套件。研究人員指出 OceanBase 資料庫具有以下 6 大特性：

- 高效能：儲存上採用讀寫分離架構，對計算引擎進行全面的效能最佳化，實現準記憶體資料庫效能；

- 低成本：使用 PC 伺服器，用高儲存壓縮比降低儲存成本，進而有效降低計算成本，並利用多租戶部署充分利用系統資源；

- 高可用性：資料多副本儲存，少量副本的故障不會影響資料可用性。透過「三地五中心」方式的部署，實現了城市級的故障自動無損容災；

- 強一致性：Paxos 保證強一致性。預設情況下在主副本中執行讀寫操作，以確保強一致性；

- 可擴充套件性：叢集節點都是點對點，每個節點具備計算和儲存能力，且沒有單點瓶頸。支援線性、線上擴縮容；

- 相容性：除後臺協議外，相容常見的 MySQL 函式和 MySQL 前端，只需零修改或少量修改，事務便可以從 MySQL 遷移到 OceanBase。

實現這些的背後，主要歸功於兩個核心關鍵技術——分散式高效儲存引擎和分散式事務處理引擎。

### 高壓縮比的分散式儲存引擎

OceanBase 具有一個類似於 Google Bigtable 的日誌結構合併樹（Log-Structured Merge-tree，LSM-tree）儲存系統，並基於 LSM-tree 架構形成了自己的儲存引擎。該儲存引擎設計並實現了非對稱讀寫資料塊儲存系統以及每日增量主要壓縮，其效能接近於記憶體資料庫。

在設計思路上，OceanBase意識到要借鑑經典資料庫的優勢，例如儲存計算分離、一體化設計（即採用同一套引擎實現事務處理 OLTP 和事務分析 OLAP，基於資源組的邏輯隔離），以及採用本地化處理以實現極致效能。

那麼，如何在分散式資料庫上實現這些特性？

下圖 3 為 OceanBase 分散式儲存引擎的整體概覽。從平衡成本與效能層面看，LSM-tree 架構更適合資料編碼和壓縮，部分額外 CPU 消耗換來的是儲存成本的大幅降低，對 OLTP 服務的效能沒有影響。在某些場景中使用編碼特性來提高效能，如更高的快取命中率、更快的查詢和更低的 I/O 成本。因此 OceanBase 使用了基於 LSM-tree架構的儲存引擎，平衡「效能」和「壓縮比」。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01c2sHtQ1aqXsgNTPfl_!!6000000003381-2-tps-842-516.png)

OceanBase 還根據使用者表（User Table）指定的方式對微塊中的資料進行編碼和壓縮。在使用者表中開啟編碼後，每個微塊中的資料將按照列維度（column dimension）在列中進行編碼，如此可以幫助使用者壓縮資料，同時透過提取列中的特徵資訊加快後續查詢速度。經過編碼和壓縮後，支援進一步使用使用者指定的通用壓縮演算法對微塊資料進行無失真壓縮，以提高資料壓縮率，比如支付寶的一個業務系統從 Oracle 遷移到 OceanBase，資料從 100TB 壓縮到了 33TB。

針對集中式資料庫無法實現儲存層橫向擴充套件、儲存成本高昂的問題，OceanBase 將使用者資料和日誌資料分離，比如日誌資料基於 Paxos 協議使用三副本（五副本）儲存，而使用者資料本身可以使用兩副本（三副本/四副本）進行儲存，在保障相同可用性的前提下，資料日誌分離可節省 20%-40% 的使用者資料儲存成本。

### 分散式事務處理引擎：Paxos + 2PC

在分散式事務處理引擎設計方面，傳統二階段提交（2PC）協議常被用來實現分散式事務，但在 Share Nothing 架構中，如果一個節點在二階段事務執行過程中出現故障，則該節點在賬戶上的操作狀態不可訪問。此外，該節點可能會很快恢復，也可能長時間無法恢復或永久損壞，無法評估其狀態，導致分散式事務的執行結果也無法確定。

針對分散式場景下的故障恢復和併發控制難題，**OceanBase 資料庫將 Paxos 分散式一致性協議引入 2PC，提出了名為「OceanBase 2PC」的創新性二階段提交協議，使得分散式事務具備了自動容錯能力**，首次在金融核心系統做到 RPO=0，也正是憑藉這項技術，OceanBase 成為支付寶的最終選擇。

下圖 5 為 Paxos + 2PC 概覽，二階段提交的每個參與者（participant）都包含了多個副本，並且它們可以透過 Paxos 協議輕鬆獲得。當一個參與者節點出現故障時，Paxos 可以快速選出另一個副本來替代原先參與者以繼續提供服務，並恢復原先參與者的狀態，進而可以確定分散式事務的執行，並繼續推進二階段提交協議的完成。

![Image](https://img.alicdn.com/imgextra/i4/O1CN01aYqy6z1j1YKLJ2Qun_!!6000000004488-2-tps-842-418.png)

為了提升分散式事務處理的效能並降低延遲，OceanBase 選擇透過最佳化參與者和協調者（Coordinator）的操作，進一步改進傳統的二階段提交協議。

下圖 6 展示了傳統 2PC 與 OceanBase 2PC 的架構比較。與傳統的 2PC 相比，OceanBase 2PC 中 Coordinator 不需要持久化狀態，而是在故障恢復時由參與者共同協商。基於這種實現方案，prepare 成功即可應答使用者，不需要等到第二輪 commit 成功再應答使用者，從而將 Paxos 同步的次數從 3 個減少到 2 個，並將事務延遲進一步縮短為僅 1 個 Paxos 同步。當然，這種方案也增加了故障處理的複雜度。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01v3tzig1ZX1Nf8rKsS_!!6000000003203-2-tps-842-710.png)

## 自我重新整理，兩度創下 TPC-C 效能世界紀錄

有了上述積累，OceanBase 團隊向國際資料庫權威測試 TPC-C 發起了挑戰。

TPC 是一系列事務處理和資料庫基準測試的規範。其中，TPC-C（Transaction Processing Performance Council）是針對線上事務處理（OLTP）的基準測試模型，使用一個商品銷售模型對 OLTP 系統進行測試，可以比較好地觀察出資料庫服務的穩定性、效能以及容災等特性。

TPC-C 測試中包含以下五類事務，包括：NewOrder 新訂單的生成，Payment 訂單付款，OrderStatus 最近訂單查詢，Delivery 交付配送，StockLevel 庫存缺貨狀態分析。測試開始前，TPC-C Benchmark 會規定被試資料庫的初始狀態，並使用 tpmC 值（Transactions per Minute）衡量系統最大有效吞吐量（MQTh，Max Qualified Throughput）。

2019 年 10 月，OceanBase 成功透過 TPC-C 測試，並以 6088 萬 tpmC 的線上事務處理效能，創下了當時的世界紀錄。2020年 6 月，OceanBase 再次參與測試並二度登頂 TPC-C 榜單，以超過 7.07 億 tpmC 的成績，重新整理了自己之前的紀錄。

同樣值得關注的，還有 OceanBase 在測試中所展現出的各項服務的穩定性，這個我們稍後看論文。

### 嚴苛的 TPC-C 基準測試

就像任何合格的產品在銷售前要經過有關部門與行業協會的審批與認準一樣，**透過國際事務委員會（TPC）的 TPC-C 測試，說明了一個資料庫系統透過了國際認證，可以與全世界的資料庫產品同臺競技**。

OceanBase 論文披露了第二次 TPC-C 基準測試的技術細節。拓撲結構如下圖 7 所示，共部署 2360 臺阿里雲 ECS 伺服器，並使用 400 臺遠端終端模擬器（remote terminal emulator，RTE）來模擬 559,440,000 個使用者。同時部署 400 臺網路伺服器，每個網路伺服器接收來自數個 RTE 的請求，透過 OceanBase 的 SQL 引擎將 TPC-C 事務實現為 SQL 儲存過程，並透過開放式資料庫連線（ODBC）呼叫資料伺服器。

再說 OceanBase 叢集，它由 1557 臺伺服器組成，採用 Share Nothing 架構連線。每臺伺服器具有 84 個 vCPU（2.5GHz Intel Xeon Platinum 8163 Skylake 超執行緒處理器），712GB RAM 和 3.5TB*4 SSD。這些伺服器平均分成 3 個可用區，每個區域部署 519 臺伺服器。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01Z6abEi1WaHLwBSew3_!!6000000002804-2-tps-842-548.png)

作為一個分散式資料庫，在 TPC-C 這個原本為集中式資料庫而設的基準上取得如此成績，OceanBase 團隊遇到並解決了以下四個挑戰。

第一個挑戰是**基準規範的永續性要求**。測試時，OceanBase 資料庫系統在商用硬體上執行，選擇了具有 3 個區域部署的單個 Region。每個 Paxos 組由 3 個副本組成，即全能型副本、資料型副本和日誌型副本。相較於使用 3 個全能型副本，這種配置將 MemTable 使用的 RAM 減少 2/3，將基線資料使用的儲存減少 1/3。此外，透過消除資料型副本和日誌型副本上重做的 redo log，某些 CPU 週期也得以縮短。

第二個挑戰是**關於生成基準測試初始資料的耗時過程**。考慮到每個倉庫（TPC-C 的基本資料單元）的行數（499,000+）、每個 OceanBase 節點的倉庫數（共計55,944,000 和 36,000）以及所需資料量，基礎測試的初始資料生成任務非常繁重。

為了縮短初始資料生成時間，OceanBase 叢集首先配置為 1 個副本，而不是 3 個副本和 no-logging。另外，在初始資料生成期間透過單個事務將數千個行批次插入資料庫。所有初始資料插入後，OceanBase 被重新配置為 3 個副本，即全能型副本、資料型副本和日誌型副本，然後分割槽得以自動重新複製和重新平衡。No-logging 也被關閉，並且系統在完成上述重新複製、重新平衡以及主要壓縮後準備好進行測試。

第三個挑戰是 **ITEM 表**。由於 ITEM 表在 TPC-C 基準上被事務頻繁地訪問，因此應該在每個 OceanBase 節點上進行復制，以避免遠端訪問並保證效能。此外，對於 ITEM 表上的任何事務而言，都必須滿足 ACID 屬性。因此，ITEM 表被配置為了一個同步複製表。

第四個挑戰是根據 TPC-C 基準規範，**基準測試測量間隔期間累積效能吞吐量的變化不應超過 2%**。對於 OceanBase 而言，它有幾個後臺操作，比如次要壓縮、 混合壓縮 （將幾個次要壓縮合併為一個）以及將次要壓縮從全能型副本複製到資料型副本。所有後臺操作的 CPU 線性池得到保留以將效能吞吐量變化降至最低。

此外，MemTable 大小的上限應該選得足夠小，以便在 RAM 被新事務耗盡之前完成次要壓縮。它還必須足夠大以利用每個節點 RAM 併產生最少的次要壓縮。最後，8 小時基準測試測量間隔期間的效能吞吐量累積變化小於 1%。

### 詳細效能結果

使用上述配置，TPC-C 基準測試分別在 3、9、27、81、243、510 和 1554 臺伺服器的 OceanBase 叢集上執行，測試間隔為 8 小時。結果如下圖 8 所示，**tpmC 效能分數隨著資料節點的增加呈線性上升，具有高度擴充套件性，在 1554 臺伺服器上執行時超過 7.07 億**，這一新的世界紀錄相較 2019 年 10 月 OceanBase 自己創造的 6088 萬 tpmC 提升了近 11 倍。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01zc6u811lgQuSZDmTy_!!6000000004848-2-tps-842-558.png)

新訂單（New-Order）響應時間如下圖 10 所示。圖 10(a) 報告了**新訂單事務型別的最大、90％、平均和最小響應時間曲線圖，後三項數值基本重合**。最小響應時間為 103 ms，平均和 90％ 響應時間接近，最小與最大差距分別為 5ms 和 33ms。圖 10(b) 展示了新訂單響應時間分佈，其中絕大多數新訂單事務在 20ms 內完成。

![Image](https://img.alicdn.com/imgextra/i1/O1CN012VxoSE21edCgrGHQb_!!6000000007010-2-tps-842-390.png)

**從新訂單的角度，我們可以發現 OceanBase 具有很強的可擴充套件性。**原因在於：1）無狀態 OBProxy 的透明轉發大大減少了分散式事務，並最佳化了本地事務；2）OceanBase 2PC 加速了分散式事務處理；3）儲存過程加速了事務執行；4）最佳化的 LSM-tree 減少了事務寫入操作；5）非常高效的快速 SQL 引數化有助於 OLTP 短查詢場景。

支付（Payment）響應時間如下圖 11 所示。圖 11(a) 報告**支付事務型別的最小、平均、90％ 和最大響應時間曲線圖，前三項數值重合。**最小平均響應時間為 110ms（3 個節點），最大平均響應時間為 123ms（1554個節點）；最小 90％ 響應時間為 114ms（3個節點），最大 90％響應時間為 154ms（1554個節點）。圖 11(b) 展示了具有 1554 個節點的支付響應時間分佈。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01W1Kqny1e4gxk8WR7a_!!6000000003818-2-tps-842-392.png)

訂單狀態（Order-Status）響應時間如下圖 12 所示。圖 12(a) 報告了**訂單狀態事務型別的最大、90％、平均和最小響應時間曲線圖，後三項數值大致重合**。最小和最大平均響應時間分別為 107ms 和 117ms，最小和最大 90％ 響應時間分別為 109ms 和 141ms。圖 12(b) 展示了具有 1554 個節點的訂單狀態響應時間分佈。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01mZkwz71LWC2kLdDck_!!6000000001306-2-tps-842-392.png)

配送（Delivery）響應時間如下圖 13 所示。圖 13(a) 報告 **事務型別的 90％、最大、最小和平均響應時間曲線圖，其中 90％ 響應時間大於平均響應時間**。對於第 3、9、27、81、243 和 510 個節點，最小和最大平均響應時間分別為 17ms 和 19ms，而最小和最大 90％ 響應時間分別為 22ms 和 27ms。圖 13(b) 展示了具有 1554 個節點的交付響應時間分佈。

![Image](https://img.alicdn.com/imgextra/i2/O1CN01cSkOvk1EvekoDxWXN_!!6000000000414-2-tps-842-396.png)

存貨水平（Stock-Level）響應時間如下圖 14 所示。圖 14(a) 報告**存貨水平事務型別的最大、90％、平均和最小響應時間曲線圖，後三項數值基本重合**。90％ 的響應時間大於平均響應時間。最小和最大平均響應時間分別為 109ms（3 個節點）和 120ms（1554 個節點），最小和最大 90％ 響應時間分別為 114ms（3 個節點）和 152ms（1554 個節點）。圖 14(b) 展示了具有 1554 個節點的存貨水平響應時間分佈。

![Image](https://img.alicdn.com/imgextra/i1/O1CN01tt1Wes1l1fexTSAM6_!!6000000004759-2-tps-842-396.png)

## 中國資料庫未來：在不斷突破中前行

在短短十餘年的發展歷程中，OceanBase 經歷了多次產品定位和技術創新升級。

這一期間，OceanBase 成為全球唯一在 TPC-C 和 TPC-H 測試（用於評測資料庫的分析型查詢能力）上都重新整理了世界紀錄的分散式資料庫。

![Image](https://img.alicdn.com/imgextra/i3/O1CN01LCtEAA1feFK8KUGYb_!!6000000004031-2-tps-842-216.png)

從 OceanBase 的技術理念角度看，首先確保的是穩定可靠。例如，OceanBase 系統內部有一個資料校驗機制，自動對多個副本之間進行實時的事務一致性校驗和定期的基線資料一致性校驗，為了實現該校驗功能，會犧牲一些效能，且對儲存格式的設計方案有一定約束，但 OceanBase 認為這是必須的，是資料庫最基本最樸素的第一原則。

OceanBase 的分割槽技術使其非常重要的分散式能力之一，能夠解決大表的容量問題和高併發訪問時的效能問題。分割槽是指按照使用者指定的一定規則，將表分成更小、更易於管理的部分，例如二級分割槽和基於虛擬列的分割槽。與分片相比，分割槽的好處有很多，比如訪問 OceanBase 資料庫的應用邏輯上只需訪問一張表或一個索引、分割槽對應用程式完全透明且不會影響它們的業務邏輯、訪問分割槽表不需要修改 SQL 語句等。

從分散式 NoSQL 儲存系統到分散式 NewSQL 關聯式資料庫系統，OceanBase 還總結了以下實踐經驗：1）應用層不應使用資料庫系統作為鍵值儲存系統，應依賴資料庫的高階特性；2）儲存過程對於OLTP應用還是有很大價值的；3）對於使用分散式資料庫的應用程式，由於分散式系統網路和節點的故障率較高，每個事務和每個 SQL 都應該設定一個超時時間，如果應用程式設定了超時，資料庫可能會在許多失敗情況下重試以提高健壯性，無限超時時間在複雜情況下可能會導致邏輯死鎖，不利於整體容災。

從 2019 年 10 月首次榮登TPC-C效能榜首，到 2020 年 6 月再破世界紀錄，OceanBase 讓中國資料庫擁有了挑戰甚至戰勝 Oracle、MySQL 等國外主流資料庫的底氣。

2021 年 6 月，OceanBase 宣佈開源，開放 300 萬行核心程式碼，允許所有社群參與者對程式碼進行自由修改、使用和引用。OceanBase 社群也同時上線。目前，開發者在開源社群能夠完整使用 OceanBase 資料庫核心。

當然，作為一個以通用資料庫為定位的資料庫產品，OceanBase 還有需要完善的地方，接下來也會遇到各種挑戰，但在 TPC-C 效能這件事情上，OceanBase 已經不用試圖證明什麼。

本次透過論文的方式，將 OceanBase 的技術突破及創新向學界和工業界分享，成為 VLDB 2022 分散式資料庫領域全球唯一獲得可復現認可徽章（Artifact Available Badge）的工業論文，OceanBase 已經為資料庫產業提供了有價值的新的思考。我們衷心期待 OceanBase 發展出一個與 MySQL、PostgreSQL 同等規模的一體化資料庫產品和社群。

分享｜破世界紀錄的OceanBase，如今入選了國際頂會VLDB 2022

相關文章