導讀開源數據庫OceanBase（https://github.com/oceanbase）作為單機分

導讀 開源數據庫OceanBase（/oceanbase）作為單機分布式一體化架構的數據庫，其OLTP的能力已經廣為人知。實際上，由于原生分布式的特性，OceanBase早期版本就具備了較好的HTAP能力，并在版本有了長足進步，在近期發布的版本中又得到強化。本文將圍繞OceanBase HTAP能力，從以下七部分解析其核心技術和功能特性，并披露相關性能數據。

【資料圖】

全文目錄：

1. OceanBase核心特性及技術架構

2. 執行引擎：OceanBase性能優化實現

3. 高級查詢優化器：影響執行引擎效果

4. 存儲引擎：決定行列混合存儲效果

5. 資源隔離：防止TP業務與AP業務互相影響

6. 快速導入：Direct Path特性

7. 總結

8. Q&A

分享嘉賓｜張鑫 奧星貝斯 OceanBase開源架構師

編輯整理｜阿東同學 中國科學院大學

內容審核｜李瑤

出品社區｜DataFun

01

OceanBase核心特性及技術架構

1. OceanBase的發展歷程

首先，介紹一下OceanBase的發展歷程。OceanBase始于2010年，起初是淘寶內部的一個項目，旨在解決淘寶收藏夾功能的需求。直至今日，當大家使用淘寶的收藏夾時，存儲后臺仍然是OceanBase。OceanBase經歷了十多年的發展，歷經幾個階段。其中，第一個階段是OceanBase的版本，著重磨練OceanBase的分布式能力。

在第一個階段之后， OceanBase迎來了架構層面大的升級，也就是 版本，成為全分布式的多點寫入的分布式型關系型數據庫。從這一時間點開始， OceanBase進入螞蟻集團。截止到 2016 年，螞蟻集團和網商銀行的全部核心系統，包括交易、支付賬務都已經使用 OceanBase作為后臺的業務處理數據庫。到 2017 年， OceanBase走出螞蟻集團，對外做一些商業化 。近兩年，在互聯網金融，特別是銀行、保險、通信、能源等行業大范圍推廣，如攜程等公司的核心系統已經采用OceanBase。

的核心特性

下面簡單介紹一下 OceanBase的核心特性。

高性能。 在 2019 年和 2020 年分別做了 TPC-C 的打榜，無論在學術界還是在工業界，TPC-C 都是 OLTP 領域比較權威的評測標準。2020 年，以 億 tpmC 的記錄打破世界紀錄，并在 2019 年的基礎上提升了 10 倍的性能。

高可用性。 當少數機器出現故障的時候，OceanBase可以做到在 8 秒之內就快速恢復整個業務系統，保持整個業務系統的連續性。

高擴展性。 OceanBase不僅可以做水平擴展的分布式數據庫，還可以做很好的垂直擴展，后面會有數據跟大家分享。在彈性方面，螞蟻集團歷年的雙十一都非常依賴于 OceanBase來做彈性的擴縮容，在雙十一的前一周，會把集群的規模擴到可以滿足雙十一當天高峰大促的并發的要求，然后在雙十一過后，又可以快速地把資源釋放出來，這是極致彈性的能力。

MySQL 和 Oracle兼容。 在用戶接口方面，企業版 OceanBase同時支持 MySQL 和 Oracle 的兩種兼容模式，用戶可以在同集群里面創建，兩種不同的租戶可以同時工作。社區版 OceanBase目前只兼容MySQL模式，實際上底層是同一套存儲引擎，由于是完全自研的，因此所有功能都是一體化的設計。

HTAP： 很多用戶都知道OceanBase本身在 OLTP 這塊的能力做得不錯，并打破了 TPC-C 記錄，印象中會覺得OceanBase是一款 OLTP 型的數據庫。但其實，OceanBase是具備 TP、AP 混合負載的HTAP關系型數據庫，OLAP能力在TPC國際事務處理性能委員會的TPC-H基準測試中刷新過世界紀錄，并在 到演進過程中不斷增強。

低成本。 OceanBase不同于傳統的 B+樹的存儲引擎，自研的存儲引擎采用 LSM-Tree，并且結合業務特點做了非常多的針對性優化。最具特色的一點就是數據壓縮，同樣的數據在 MySQL 和Oracle數據庫上，OceanBase的數據庫磁盤占用空間大概是傳統的1/3 到 1/4，甚至有些場景可以做到 1/ 10。

原生多租戶的能力。 在集群里面可以創建多個租戶，服務多個不同的業務，這一層是在數據庫的集群內部做的，不需要依賴于外部的虛擬化的一些機制，租戶之間的資源完全隔離，并且后續可以隨意擴展。

安全性。 支持透明加密、傳輸加密、安全審計等。

其它。 OceanBase在 2017 年開始商業化之后，大力發展周邊生態工具。從企業的視角來看， OceanBase具備完整的從數據庫開發到遷移，再到評估、運維及診斷的全生命周期的配套工具。

的整體架構

下圖是OceanBase數據庫的整體架構，它由若干個ZONE組成。每個ZONE有多個OB服務器，這些節點共同組成了一個完整的數據庫集群系統。

在OceanBase數據庫中，數據的表進行了分片，如圖所示，P1、P2、P3等。每一個分片稱為一個分區。同一份數據在不同的ZONE里會有多個副本。例如P1，它在第2個ZONE和第3個ZONE都有相同的數據備份。相同分片的數據同步是通過Paxos一致性協議進行的。

OceanBase在2020 年參加 TPC-C 評測時，整個集群由 1500 多個節點組成，是一個非常大的集群規模，如果業務不需要大集群， OceanBase也可以做到單機部署。

上圖展示的是實際的生產數據，來自螞蟻內部真實的業務系統。峰值的數據處理能力達到了 6100 萬次每秒，單個集群規模超過 1000 臺，單庫有 6PB 的數據，最大一張表超過了 3200 億行。RPO=0指的是在機器發生故障之后，保證數據不丟失。RTO < 8 秒，就是在少數機器出現故障之后，能夠在 8 秒之內快速恢復業務。

這張圖是OceanBase分別在2019年和2020參加TPC-C測評的結果。這里壓測的億tpmC數據，即每秒可以處理2000多萬次事務。需要說明的是，這里的事務并非僅指數據庫請求。

在TPC-C的模型中，有許多由復雜SQL語句組成的部分，因此綜合吞吐量非常高。在這里，高并發處理能力體現在曲線上。在TPC-C評測中，要求程序以最高峰值平穩地運行兩個小時，并進行兩個小時的采樣。在這兩個小時的采樣期間，整體性能的波動不得超過3％。OceanBase為自己提供了最高的標準，并進行了實際測評。從圖表中可以看出，實際運行時間為8個小時，整體波動小于1％。在數據庫或LSM-Tree架構中，抖動是個相當重要的問題。實際上，LSM-Tree存儲引擎每次需要進行轉儲和合并，這通常會引起一定程度的抖動。然而，經過多年的內部打磨和外部用戶實踐的應用，OceanBase進行了大量的優化和改進，使得其整體平穩性能達到了極高水平。

此外， OceanBase是當時唯一通過TPC-C官方審核的分布式數據庫，也是中國唯一通過官方審核的數據庫。

在2020 年又參加了 OLAP 方面的打榜，即 TPC-H 的評測，以30000 GB 的數據拿了當時世界第一的結果。

大家可以看右邊這張圖，是OceanBase自己和自己的比較，從的版本和的版本相對于在聯機分析處理(OLAP)這塊的性能的對比，可以看到它的提升非常顯著，整體以TPC-H為代表的OLAP能力也有了極大的提升。

現在對于許多復雜查詢，人們普遍認為TPC-H相對簡單，尤其是對于跨數據庫的優化器來說，TPC-H對優化器的能力考驗也許被視為次要的。因此，OceanBase在去年推出了版本，今年又推出了版本，下半年還將推出版本，進一步提高復雜查詢和優化執行能力。

版本相比于之前的版本，在大小為100G的倉庫上進行對比，整體性能提升了300秒，有了三倍的提升。現在版與版又有了更多的提升。

OceanBase整體性能提升的技術實現方式是什么？以下將簡要介紹OceanBase執行引擎的能力。

首先，OceanBase的執行引擎在最初的設計中就考慮到了處理TP和AP的需求。因為從業務場景來看，很難區分查詢是TP還是AP，也很難區分它是小規模查詢還是大規模查詢。因此，初始設計就要兼顧這兩種情況。

大家對于MySQL可能比較熟悉，MySQL對于簡單高頻的查詢處理非常出色，但在處理大規模數據方面仍有不足。然而，OceanBase從最開始就定位為分布式數據庫，用戶期望其具備大規模數據處理的能力。在執行引擎方面，OceanBase做了一些優化，既可以支持串行執行，也可以支持并行執行。串行執行主要面向TP業務場景，而并行執行則可以在多個節點之間進行并行查詢，并且查詢能力可以垂直和水平擴展。在TP領域中，時延是一個重要的指標，而不僅僅是吞吐量。因此，串行執行更多地針對TP進行優化。在串行執行時，數據有時需要跨機訪問。因此OceanBase的執行引擎也有兩種策略，一種是通過拉取跨機數據并使用數據拉取策略進行計算，另一種是將計算下推到下面的節點中，然后再將計算結果取回。這兩種策略都是執行引擎支持的，具體如何執行取決于優化器的決策。

1. 并行執行調度

并行執行引擎將SQL查詢計劃拆分成多個分片，每個分片可能涉及多個數據。也可以拆分成若干子片，每個子片稱為DFO，DFO組成整個查詢的數據流。在并行調度時，可以將整個數據流劃分為多個片段，相鄰片段可以并行調度，逐步上傳數據。當然，并行度可以根據用戶自定義進行指定。

OceanBase是一個具有豐富并行查詢策略的分布式數據庫。舉個例子，在AP場景中，數據會根據主鍵或分區鍵拆分成若干個分片，也稱為分區。例如，R1和R2兩張表，其中有a和b兩個列。以b列作為分區鍵，表中數據會根據b列的哈希值不同分散在多臺機器上。與單機數據庫不同的是，OceanBase可以靈活地處理并行處理數據。

表的連接有4種最基本的方式。由于列b是分區列而a是普通列，因此如果對R1表的b列和R2表的b列做連接查詢，可以將每個分片對應起來。因為分區策略是相同的，就可以分別對每個分區進行連接。這種方式被稱為分區連接（partition with join）。在這種情況下，同一張表的分區之間不需要進行數據交叉。

如果是分區列 b 列和另外一張表的普通列a列做 join ，可以把不分區的 R2 這一列求哈希值以后根據它對應的在 a 表上的分區方式，把它 shuffle 到 R1 表的分區上面，這種方式叫部分 partition with join。

第三種情況是當完全使用a列進行連接時，由于沒有分區，因此所有數據都存在于不同的分片中。此時，可以直接對所有a列進行哈希，然后在不同的機器上進行連接。

最后一種情況是當R2表是一張小表時，可以將該表廣播到R1表的每個分區中，無論條件如何。這四種策略實際上都需要在優化時進行自動選擇。

2. 自適應執行

自適應執行以 group by分組算法為例，比如要把上面的查詢按照 b 列做分組，然后按照 c 列做求和，每個分組做求和的簡單的查詢。在分布式場景里面，可以在每個分區上先做求和的動作，然后再把所有的分區的計算結果聚合起來。

每個分區上做分組是否值得，主要取決于每個分區有多少個不同的 b 值。做聚合的時候，先要為表建哈希表，建哈希表其實是有代價的。比如 100 行數據，建了哈希表之后它還是有 100 個不同的值，那么建哈希表其實是浪費的，對數據的消減作用非常小。這在優化器來看是沒辦法決定的，因為聚合以后有多少不同的值，優化器預先是不知道，所以就需要做自適應的執行。優化器遇到這種場景會判斷第一個分片上的消減作用是大還是小。如果消減作用是非常小的，那么在后面的分區上做的時候，就不需要再創建哈希表，而是直接把數據推到上一層，去做計算。這就是自適應引擎的策略。

在 OLAP 領域中，優化器的能力非常重要，執行引擎的能力有很多，用的好不好依賴于優化器是否能產生一個好的執行計劃。經過多年的深入研究和實踐，OceanBase 的優化器已經達到了非常高的水平，并在螞蟻集團內部以及一些大型銀行和保險公司的核心業務場景中得到了驗證。對優化器的核心算法進行了精心優化，增加了許多專門針對特定場景的規則和策略。在 OceanBase 中采用了兩階段的方式生成執行計劃，首先生成串行執行計劃，然后在需要時對最優的執行計劃進行并行化。

1. 一階段分布式查詢優化

這種兩階段執行計劃生成方式存在一些問題。例如在下圖中，從串行計算的角度來看，根據算法復雜度，AB執行計劃的時間只需要100毫秒，因此執行計劃被認為是更優的。然而，這并不意味著生成兩個階段的執行計劃再并行化會得到最優的執行方案。

實際上還是需要考慮數據分布的情況，在例子中的R1、R2、 R3 這三張表，數據到底位于哪些機器上？即使在第一個階段分析，看到耗時是更高的 150 毫秒的執行計劃，但是因為它對于后邊的排序，或者說數據的分布是有用的，因此需要把這個執行計劃也保留下來，等執行編譯之后再看最終的執行計劃哪個更好。

所以這部分的優化，就是把之前的兩階段的執行計劃變成一階段，可以帶來很大的好處，整體上在秒級別可以完成 50 張表的連接。

2. 并行下壓

前文講到的 group by 的例子是有下壓的策略， OceanBase 的版本對于有一類的執行計劃是不能夠做并行下壓的，在 之后可以完全支持，因為引入了三階段下壓的策略。

舉個例子，就是一種帶有distinct的聚合函數使用group by的情況。核心部分需要把數據查出來后，對不同的c值進行sum求和，并進行消重。但是因為需要對c列進行消重后再求和，所以無論有多少個分區，分區間并行都無法充分利用。因此，在版本中OceanBase采用引入了三階段的下壓策略實現并行。首先在每個分區上進行消重，然后再進行哈希，把每個分片上先在c列上消重，再將每片的1、2和3值聚合起來進行消重，這就是3號算子。接著在第二層上進行最后的求和操作，最后再進行整體的求和。這種策略對于一些復雜查詢有著非常明顯的提升。

前面講的都是 SQL 引擎，下面來介紹一下 OceanBase的存儲引擎，存儲引擎對于這種 HTAP 場景影響非常大。這是 OceanBase整個存儲引擎的結構，可以看到是比較簡單的LSM-Tree 的結構。

1. 行列混合存儲及編碼壓縮

數據存儲可以被看作是有序的鍵值對，所有更新操作都以增量方式記錄到內存中。在讀取時，將磁盤上的數據、內存的數據和內存中更新的數據合并，提供讀取服務。此外，還有塊緩存和行緩存等各種緩存。定期整理增量數據和基線SSTable數據，進行合并，這是LSM-Tree的基本邏輯。

相對于使用"B+樹"的存儲引擎，LSM-Tree的最大優點就是它的整個更新過程沒有隨機寫入。所有的插入和更新都先直接寫入內存，相當于聚合大量的數據并按順序寫入磁盤。

為什么之前沒有提出這個策略？這實際上與硬件的發展有很大關系。現在LSM-Tree這種存儲引擎不僅適用于OLTP，對于OLAP方面也有很大的優勢。其優點在于，它的基線數據只有在下一次合并時才會修改，因此，這部分數據在磁盤上可以高度壓縮。

除了通用壓縮，由于行列混合的模式，OceanBase的行列混合模式可以通過按列的方式進行壓縮。數據表按數據分成多個Row Group，并按列的方式存儲在磁盤上。因此，在磁盤上，每個數據塊都是以列為緊湊的存儲方式存儲，這對于壓縮非常有利。剛才為什么說“同一塊數據從MySQL遷移到OceanBase可能有三倍的壓縮率”？主要是由于LSM-Tree，在編碼后，又進行了通用壓縮，因此具有非常高的壓縮比率。并且，它能夠在線進行這種壓縮算法，而B+樹無法實現。OceanBase的好處主要在于LSM-Tree的后臺整理數據的特性，因為SSTable的基線數據在下一次合并和整理時是后臺處理的，而不是在用戶執行插入操作時直接進行壓縮。

可以想象一下，如果是 B+樹，實時地做在線的壓縮動作，其實對于壓縮算法的要求是非常高的。如果把它變成后臺動作，可以非常高效地做壓縮，并且可以選擇更好的壓縮算法。

2. 查詢過濾下壓

又因為磁盤上是列式的存儲，所以對于 OLAP 來說，這種大規模的數據掃描以及數據分析，可以把整個查詢的filter過濾算子做下壓，并且在不解壓的情況下就做過濾。

比如，一個數據表有性別一列，通常只有男女兩種類別。實際上，經過壓縮后，男性和女性屬性值只占用一個比特，從而可以實現高度壓縮。在數據處理時，可以在數據字典上進行過濾，然后通過已壓縮值進行高效處理，實現高效性。

此外，OLAP引擎經常采用的策略在OceanBase的存儲引擎中得到了充分的體現。這也是因為OceanBase的存儲引擎既滿足了TP高并發低延遲的要求，又能夠在大規模數據處理時充分利用列存的優勢。因此， OceanBase是TP和AP存儲引擎的完美結合。

前面都是講存儲引擎和執行引擎的邏輯，但在實際業務中，很多時候很難區分它是 TP 還是AP，在混合的場景下，大家會傾向于保護TP 的這些查詢的資源，防止一些大的 AP 的查詢爭用資源，影響TP 的時延。因此引出了資源隔離的概念。

OceanBase本身是原生的多租戶的數據庫，前面介紹的架構其實比較簡單，在其架構上層還有租戶的概念。在OceanBase的集群中，可以有若干個租戶，相當于虛擬的容器，每個容器可以看作是數據庫的實例。這些容器主要限制CPU、內存和IOPS的使用。有了這項技術，就可以實現多租戶，就做到了剛才所說的CPU和內存的隔離。同樣的技術也可以用于HTAP，即TP和AP負混合負載的場景。因此，另外一項技術——資源組得以發展。

資源組的工作方式是什么？如果業務中既有在線交易作業，又有批處理作業，就需要以某種方式告訴數據庫哪些是批處理作業，哪些是在線交易作業。簡而言之，可以通過區分用戶，并告知數據庫哪些是批處理作業，哪些是TP類的業務。然后，根據這些用戶綁定的資源組，可以控制總使用的CPU或內存不超過某個限制。

如果資源組隔離不足，也可以采取一些物理隔離的方法。由于數據采用多副本的方式存儲，可以采用讀寫分離的方法，TP的請求訪問主副本，分析查詢則訪問從副本。此外，還可以增加只讀副本，專門用于AP分析。這些都是資源隔離的方法。

最后介紹一個小特性，即快速導入，主要針對一些 AP 的場景， AP型的系統經常需要和外部做一些數據的交互，所以在 的時候，專門做了快速導入 Direct Path特性。

數據庫的導入有幾種方式，第一種是“load data”，幾乎所有數據庫都支持它。另外就是通過 SQL 語句，直接從一張表中查詢數據，然后將其寫入到另一個表中。還有一種方式是通過 tableAPI 接口，可以使用外部客戶端等工具將 CSV 等文件導入，在導入后，數據首先會記錄到某個節點上，并在節點上進行分析。根據分區規則，將相應數據分發到相應的機器上。

在主節點內，如果在導入過程中表本身還有在線更新，可能會產生沖突。但在此類快速導入場景下，大多數被導入的表在寫入時不會非常頻繁。因此，基于這一特點，實際上會先鎖定表的修改，并生成影子表。整個大規模導入期間表被鎖定，讀取仍然可以繼續進行，但寫操作被鎖定。然后，在數據導入時繞過 SQL 層和 LSM-Tree 的內存層，直接生成最終的存儲層，即列存儲。前面也提到過它被稱為 SSTable。同時，生成的數據還要與原始增量數據合并一次，以生成最終影子表，然后再進行切換。

旁路導入技術也在內部進行了實際評測。參見下圖，第一個維度就是這張表是不是有主鍵，是不是按順序排列；第二個維度就是機器的大小。從兩個維度整體來看，首先因為有主鍵，會多一次排序，所以時間會長一些。整體來看利用了旁路導入的特性，導入的性能是有 4 到 5 倍的提升。

OceanBase作為原生分布式數據庫，無論做 TP 還是AP，都有一些基礎的高可用能力以及高性能的能力。OceanBase做了非常多的OLAP相關工作，包括大查詢、復雜的分析查詢，幾十張表的join，以及支持各種窗口函數層次查詢，還支持表函數，甚至可以支持自定義窗口函數等。從數據集成的角度來說，OceanBase支持DB link，可以把其它數據庫的一張表的數據通過這種方式做查詢。數據導入導出方面，在文中介紹了快速導入以及一些導出工具。

最后當前正在做外表的功能，將在下一版本中發布，歡迎關注，歡迎參與共建/oceanbase

以上就是本次分享的全部內容。大家如果感興趣可以掃碼加入以下社區答疑群。

08

問答環節

Q1:相同計算資源情況下， OceanBase和 Snowflake Doris Clickhouse 的查詢性能對比如何？有沒有發表過類似的測試的技術白皮書之類的資料，可以給到用戶社區用戶網上可以查看？

A：這塊其實之前也有一些做過一些測試對比，但是如果從我們角度來說，肯定會說比其他產品測試下來的效果好，其實相比這些列存數據庫整體性能是差不多的，但是具體的性能，還是用戶自己測出來的效果會更有說服力。有一些用戶有做過測試，相比 clickhouse 這些在 AP 能力其實是差別不大了。

測試白皮書這塊目前還暫時還沒有，用戶可以根據自己的實際場景，做一些性能的對比測試。

Q2: OceanBase的安全性和高可用性穩定性如何？

A：這塊其實大家可以放心一些，因為首先在剛才也有介紹到，在螞蟻集團內部核心交易、賬戶系統等，這些支付寶的這些后臺的數據庫，都是 OceanBase，從很早開始就不斷地用 OceanBase替換掉Oracle， MySQL，它的安全性、穩定性已經是經過很多年的驗證。

高可用性目前因為本身它是這種分布式的數據庫，原生的就是具備高可用能力，因為數據是通過 Paxos 一致性協議做復制，所有的數據提交都要保證多數派。如果少數節點出現故障的情況下，整個集群基本不會受到什么影響。

今天的分享就到這里，謝謝大家。