OceanBase 分布式關系數據庫架構與技術

陽振坤 楊傳輝 韓富晟 王國平 楊志豐 成肖君

（北京奧星貝斯科技有限公司 北京 100102）

1970 年Edgar.F.Codd 博士發明關系模型[1]以及隨后SQL 語言的出現，關系數據庫系統從1980 年代起逐步發展成為了業務信息系統的基石.由于業務信息系統的穩定性、可用性、實時性和高性能的要求以及事務的原子性（Atomicity）、數據的一致性（Consistency）、事務操作的隔離性（Isolation）、事務修改的持久性（Durability）（即ACID 屬性），關系數據庫的技術門檻非常高，當前全世界廣泛使用的關系數據庫系統都是集中式系統，可以離線、垂直擴展(scale-up)，難以在線、水平擴展(scale-out)，處理能力和容量有限.

1990 年代，隨著互聯網的發展和普及，以電子商務為代表的各種線上業務產生了百倍、千倍于線下實體店（商場、酒店、工廠等）的并發訪問量和數據量，遠遠超出了集中式關系數據庫的處理能力和存儲容量，對應用系統進行拆分并對數據庫進行分庫分表幾乎成為了唯一可行的手段.然而，這種削足適履的辦法意味著應用系統的重構，低效率、低性能的跨庫訪問和跨庫事務，外鍵、全局唯一約束、全局索引等只能被束之高閣，數據分析無法直接進行，數據管理的成本顯著增加.

分布式關系數據庫具備在線、敏捷的水平伸縮能力，能夠很好地克服業務的高并發以及海量數據的挑戰.然而，與集中式關系數據庫相比，分布式關系數據庫更加復雜，在高可用、數據一致性、事務性能等方面面臨更大的技術挑戰.

2019 年，OceanBase 分布式關系數據庫[2-3]通過了國際事務處理性能委員(TPC)的TPC-C 聯機事務處理基準測試[4]并打破Oracle 保持了9 年的性能記錄.2021 年，OceanBase 通過了TPC-H 聯機分析處理基準測試[5]并登頂性能榜首(@30 000 GB).OceanBase是迄今為止唯一獲得了TPC-C 和TPC-H 性能榜首的數據庫.

1 OceanBase 系統架構

作為一個分布式關系數據庫，OceanBase 集群由若干可用區（Zone）組成，通常是1～5 個Zone，圖1 是一個3-Zone 集群.每個Zone 包含1 個或多個Ocean-Base 節點，稱為OBServer.每個OBServer 由SQL 引擎、事務引擎和存儲引擎等構成.每個Zone 都包含了整個系統的全部數據，Zone 內每個OBServer 管理其中的部分數據即若干數據分片，單個Zone 內各個OBServer 管理的數據彼此沒有交集.每個數據分片在每個Zone 里都有一個副本，這些副本構成該數據分片的Paxos 組[6].

盡管應用系統可以通過與任何一個OBServer 建立連接來訪問OceanBase 數據庫，但通常情況下應用系統通過OBProxy（OceanBase Database Proxy）來訪問OceanBase 數據庫，以屏蔽OBServer 節點乃至Zone的上下線、負載均衡等導致的數據在OBServer 之間的遷移等.

2 高可用和數據一致性

高可用和數據一致性是業務系統對關系數據庫的根本要求，大部分業務都要求至少99.99%即4 個9 的可用率，重要業務和關鍵業務則要求99.999%即5 個9 的可用率.傳統集中式關系數據庫采用了高可靠的服務器和存儲以及基于主備鏡像的主庫+備庫的高可用解決方案，但這個方案有2 個不足：

1）成本高昂.高可靠服務器和高可靠存儲的價格十分昂貴，顯著地增加了成本.

2）主副本（主庫）故障后備副本（備庫）數據有損.若備副本與主副本完全同步，則主副本的每一筆事務必須到達備副本并持久化后才能認為成功，一旦備副本故障或者主副本與備副本之間的網絡異常，那么主副本的寫入將被阻塞，從而導致服務中斷，這對于大部分業務是無法接受的.因此盡管主副本與備副本之間號稱主備鏡像，但實際上備副本數據通常略微落后于主副本，一旦主副本故障，則備副本的數據并不完整即修復點目標(recovery point object,RPO)大于0，這使得業務恢復面臨較大的挑戰，特別是在金融等數據一致性要求較高的業務場景.

分布式關系數據庫由多個節點組成，整個系統出現節點故障的概率隨著節點數的增加而快速增加，如表1 所示.

Table 1 Availability Rate of Distributed System表1 分布式系統的可用率%

因此，即使每個節點的可用率都是5 個9（99.999%），當節點數達到10 時整個系統的可用率只有99.99%，而當節點數達到100 時整個系統的可用率只有99.90%，這已經無法滿足大部分業務的需求，而普通PC 服務器的可用率顯著低于5 個9.

為了解決分布式關系數據庫高可用和數據一致性問題，2013 年OceanBase 引入Paxos 分布式一致性協議[6].

如圖2 所示，數據庫每個分區（未分區的表被當作單分區表，下同）由1 個主副本和2 個備副本組成，主副本執行了1～5 共計5 個事務，每個事務都在提交前把事務日志同步給備副本1 和備副本2，其中備副本1 收到了事務1、3 和4 的日志，備副本2 收到了事務1、3、4 和5 的日志，由于事務2 沒有在超過半數參與者上持久化成功，因此事務2 被回滾，其余4個事務成功提交.

圖2 OceanBase 的3 副本分布式架構Fig.2 Three-replica distributed architecture of OceanBase

Paxos 分布式一致性協議的引入帶來的顯著好處：

1） 主副本故障后系統可在短時間內自動選舉出新的主副本，新的主副本通過與活著的備副本握手快速補齊自身可能缺失的事務數據，然后繼續提供服務.

2） 系統無需高可靠的服務器和存儲等硬件.即使是普通的PC 服務器，2 臺服務器同時出故障的概率也非常低.對可用性要求特別高的業務，可以采用5 副本即1 個主副本和4 個備副本，這樣即使2 個節點同時故障，數據庫服務也可以在短時間內無損、自動地恢復.

基于Paxos 分布式一致性協議，從0.5 版本開始，OceanBase 實現了少數副本，例如3 副本（圖3a）時單個副本故障、5 副本（圖3b）時2 個副本故障后，RPO 為0，且RTO（recovery time object）小于30 s，從4.0 開始，RTO 降為了8 s.

圖3 OceanBase 的3 副本和5 副本Fig.3 Three replicas and five replicas in OceanBase

3 分布式事務

OceanBase 的數據以分區為單位進行管理，任何時刻每個分區都屬于且只屬于一個日志流，日志流用于記錄所包含的分區的數據操縱語言（data manipulation language，DML）對應的WAL(write ahead log)日志，OceanBase 通過在日志流中記錄事務操作的日志完成對事務的提交.

數據庫的事務功能要保證ACID 四個基本特性[7]，在數據庫系統內部有2 個重要的模塊來實現這4 種特性，即故障恢復模塊和并發控制模塊.

故障恢復模塊通過日志系統和事務提交協議實現原子性和持久性這2 個特性.日志系統保證了事務的修改日志的持久化，并且在出現故障等異常時也能將日志恢復出來，進而恢復事務的全部操作，也就保證了事務的持久性.事務提交協議通過日志持久化的原子性，以實現事務的原子性.

并發控制模塊用于協調多個并行執行的事務的操作順序，通過識別并控制有沖突的多個修改操作和讀取操作，保證事務執行的隔離性語義和數據的一致性.

接下來首先介紹日志系統，然后介紹事務提交協議，之后將并發控制內容分成寫寫操作和讀寫操作兩部分進行介紹.

3.1 Paxos 一致性協議

OceanBase 將事務日志存入多臺機器的多個副本中，比如3 副本或5 副本.如果少數副本出現故障（如機器掉電、硬盤損壞等），日志可以從活著的多數副本中恢復出來，保證數據不會丟失.Paxos 一致性協議[6]用于在各個副本之間同步事務產生的日志，實現了少數派副本故障時自動容災切換和故障恢復.

一致性協議有選舉和日志同步2 個主要的部分.

1）選舉.OceanBase 的選舉協議針對無主選舉和有主改選2 種場景分別處理.當系統剛啟動時或者主副本節點故障時，各個選舉的參與者發現沒有主副本后會進行無主選舉，OceanBase 無主選舉協議會在最短的時間內選舉出優先級最高的副本作為新的主副本節點，并開始提供服務.有主改選發生在主副本節點認為自己不再能勝任主副本節點的工作或人工干預時，主副本節點會將作為主副本的角色轉讓給其他節點，同時自身降級為備副本節點.

2）日志同步.正常工作時，主副本節點把數據庫的事務日志同步給其他副本，所有副本按照一致性協議對該日志進行確認，當日志獲得多數成員的確認后即完成了日志的寫入.以常見的3 副本為例，主副本將日志同步給其他2 個副本，當包括主副本在內的任意2 個副本接受了日志并在本地硬盤中成功持久化，則日志就寫入成功，出現任意副本的故障時，剩余的2 個副本中至少會有一個副本包含剛寫入的日志，保證日志不會丟失.

3.2 兩階段提交

在單個日志流中，一個事務的日志通過一致性協議獲得多數派確認后事務的修改就被持久化地記錄了下來，事務也就完成了原子提交.對于一個分布式事務，事務的修改涉及多個日志流，日志要在對應的日志流中記錄，此時，任何一個日志流的持久化成功都不能代表整個事務的提交，需要事務涉及的所有日志都持久化成功才能保證事務提交的完整性.OceanBase 通過“兩階段提交協議”保證分布式事務的原子性.

經典的兩階段提交協議中[8]，協調者與參與者都會執行多次持久化日志的操作，協調者記錄事務的執行流程和最終提交狀態，參與者記錄局部事務的持久化狀態，從使用者視角看到分布式事務的提交延遲需要至少4 次日志提交的延遲之和.OceanBase實現了優化的兩階段提交協議，顯著縮短了事務提交的延遲.

為了讓兩階段提交協議可以在更短的時間內完成，OceanBase 的策略是不依賴協調者記錄的事務的狀態日志，而是依賴參與者記錄的操作日志，在兩階段執行過程中如果出現了系統故障，那么由參與者互相校驗事務的日志是否記全了，最終依然可以通過確認超過半數的參與者都記全了各自的操作日志，來確認事務最終提交的狀態.如果不是超過半數的參與者都記全了日志，那么事務就沒有完成提交，最終就是回滾狀態.OceanBase 的兩階段提交協議將事務的提交延遲減小到只有一次日志同步，顯著提高了事務提交的效率.

如圖4 所示，當事務開始提交時有2 個參與者P0 和P1，OceanBase 選擇某個參與者作為協調者，該協調者只有內存狀態沒有持久化狀態.協調者首先會給所有的參與者發送事務的Prepare 請求，各個參與者收到此請求后，會將事務中所做的修改提交到日志中并進行持久化.待Prepare 日志持久化成功后，參與者發送Prepare ok 消息給協調者.當協調者收到所有參與者的Prepare ok 消息后，事務的所有修改均已提交到日志中并持久化成功，無論出現何種異常事務均可以恢復，所以此時事務事實上已經提交完成，因此協調者應答客戶端事務提交成功.與此同時，協調者發送Commit 給各個參與者，通知他們提交事務，因為事務實際已經提交，所以各參與者的提交動作可以異步完成.

圖4 OceanBase 兩階段提交協議Fig.4 Two-Phase Commit Protocol in OceanBase

3.3 寫寫之間的并發控制

2 個同時執行的事務如果修改同一條數據，后執行修改操作的事務需要等待先執行修改操作的事務完成后才能執行，這樣才能保證對于數據修改的正確語義，也才能保證數據的一致性[7,9].

在OceanBase 中，事務修改的每一行數據都記錄事務的標識，此標識也用來標記該行數據是否正在被事務修改.當一個事務執行修改操作時，首先需要判斷被修改的行是否有其他事務的修改標識，如果有則判斷對應的事務當前的狀態，如果事務是正在執行中的狀態，那么當前行依然被活躍事務修改，后續的事務必須等待之前的事務執行結束，如果事務已經處于提交或者回滾狀態，那么當前行則可以被后續的事務繼續修改.

3.4 讀寫之間的并發控制

OceanBase 采用多版本并發控制[10]的方法來處理并發的事務讀取操作與修改操作.在OceanBase 中，事務修改的數據都不是原地更新，而是生成新的版本，對于同一行數據，每次修改后的數據版本都存在.數據的版本號是全局的，在事務提交時確定事務的提交版本號，作為此事務修改的所有數據的版本.

在OceanBase 里，提供事務版本號的服務叫全局時間戳服務（global timestamp service, GTS），此時間戳服務每秒可以處理幾百萬次請求，OceanBase 采用了聚合方式，每臺服務器同一時間并發的事務可以聚合起來取時間戳，大大降低對于時間戳服務的請求.在2020 年OceanBase的第2次TPC-C測試中，OceanBase每分鐘要執行15 億個事務，時間戳服務完全可以支持.

讀取操作使用的版本號有2 種獲取方法，對于可串行化隔離級別（Serializable）的事務，在事務開始時從全局時間戳服務獲取1 次，作為整個事務所有讀取操作使用的版本號.對于讀已提交（Read Committed）隔離級別的事務，在每條SQL 語句開始執行時從全局時間戳獲取一次，作為本語句的讀取版本號.

讀取操作執行的過程中，對于每一行需要讀取的數據會選擇小于等于讀版本號的最大的數據版本作為讀取的版本.這樣的操作能夠實現所有的讀取操作讀取到的是系統的一個快照，因為對于一個事務來說其修改的數據使用的是同一個提交版本號，所以讀取操作要么全部讀取到，要么全都不讀取，不會出現讀取一部分的情況.

4 LSM-tree 存儲系統

關系數據庫需要保證事務的持久性，為了抵御突發的電力等故障，數據需要保存到硬盤（機械磁盤或固態盤）等非易失性存儲介質即持久化，事務的日志需在事務提交前持久化.由于各種硬盤都是塊設備即按一定尺寸大小的塊對齊進行讀寫，比如4 KB等，通常關系數據庫都采用了定長塊（4 KB，8 KB 等）原地更新的方式，如圖5(a)所示.

圖5 OceanBase 存儲引擎Fig.5 Storage engine of OceanBase

OceanBase 選擇了基于LSM-tree[11]的存儲架構，如圖5(b)所示.跟傳統的定長塊原地更新的存儲架構相比，LSM-tree 存儲有顯著的不同，即修改數據（修改增量）記在內存、基線數據只讀等.

LSM-tree 存儲有顯著的優勢：

1）寫入性能好，且存儲設備無需隨機寫能力.

2）周期地（每天）進行修改增量與基線數據合并，由于這樣通常避開業務高峰，因此系統的CPU、I/O和網絡資源等有一定的空閑，故可對數據進行一些較為消耗CPU、I/O 和/或網絡等的處理，比如數據壓縮、數據統計等，且不對系統性能產生負面影響.這使得OceanBase 通常有3 倍或更高的數據壓縮率，降低用戶存儲成本，卻不會降低業務吞吐量或增加業務延時.表2 是部分用戶業務從MySQL/Oracle 遷移到OceanBase 時遷移前后數據量的對比.

Table 2 Some User Business Data Compression Rates of OceanBase表2 部分用戶業務的OceanBase 數據壓縮率

3）基線數據只讀，這簡化了數據存儲的數據結構和數據緩存的實現.

4）既適合行存又適合列存，解決了基于定長塊原地更新的數據庫的列存數據難以實時更新的難題，使得數據庫既能進行交易處理，又能進行分析處理.

當然，LSM-tree 存儲也有一些劣勢：

1）讀需要融合修改增量和基線數據.

2）數據寫入較多時，修改增量需要轉儲到硬盤以釋放內存.

3）需要周期地（每天）進行修改增量與基線數據的合并.

4）SQL 執行的代價模型既需要考慮基線數據又需要考慮修改增量.

針對這些劣勢，OceanBase 在設計和實現中進行了相應的處理和優化，減少了這些劣勢帶來的性能和功能等方面的影響.

5 分布式SQL 優化器

查詢優化器是關系數據庫系統的核心組件之一，是衡量關系數據庫系統成熟度的“試金石”.查詢優化理論誕生已有四十多年，學術界和工業界已經形成了一些比較完善的查詢優化框架，其中包括IBM System-R[12]的優化框架和Volcano[13]/Cascades[14]的Top-down 優化框架.然而，圍繞查詢優化的核心難題始終沒有改變，即如何利用有限的系統資源來選擇一個“好”的執行計劃.作為一個分布式關系數據庫系統，OceanBase 需要克服分布式查詢優化的挑戰.

OceanBase 查詢優化器的設計參考了System-R的設計，圖6 展示了OceanBase 查詢優化器的總體框架.OceanBase 查詢優化器主要由計劃優化模塊和計劃管理模塊組成，其中計劃優化模塊負責生成最優的執行計劃，計劃管理模塊負責緩存和演進執行計劃.接下來，依次介紹OceanBase 的查詢改寫機制、分布式計劃生成機制、計劃緩存機制和計劃演進機制.

圖6 OceanBase 查詢優化器框架Fig.6 Query optimizer framework of OceanBase

5.1 查詢改寫

查詢改寫是指利用查詢改寫規則對查詢語句進行重寫或轉換，以便更好地利用數據庫的索引、優化技術和查詢處理算法來提升查詢性能.OceanBase 設計并實現了大量的查詢改寫規則，涵蓋了不同的關系代數之間的相互轉換.這些策略一部分來自于已有的文獻，如謂詞移動[15]、子查詢提升[16]、分組上拉和分組下壓[17]等；然而，當前已有的研究并沒有也無法窮盡所有的改寫策略，很多已有的改寫策略仍有提升的空間，并且還有許多值得探索的新策略.OceanBase 在服務大量的客戶過程中，對業務SQL 使用模式進行抽象并提出了許多新的改寫策略.

例如，已有的數據庫系統實現了 OR 展開的技術來優化以下查詢：

原始查詢中，T1 和T2 表之間只有一個OR 條件的連接謂詞，只能進行笛卡爾積.經過OR 展開后，T1 和T2 表之間是兩次等值連接，可以應用更多的連接算法.但是，該策略僅適用于內連接，不適用于其他連接類型.為此，OceanBase 設計實現了針對不同連接類型的OR 展開策略，能夠將外連接、半連接、反連接上的OR 連接謂詞展開為等值連接.

當前，OceanBase 查詢優化器已經積累了多種針對不同關系代數式的改寫策略，能夠滿足復雜查詢的多個方面的改寫需求.除了一些常見的簡單改寫策略之外，其中有少部分復雜策略是基于已有文獻實現的，更多復雜策略則是基于業務場景的抽象得到的.在整個模塊的發展過程中，查詢優化器還積累了許多基礎改寫算法，例如判定2 個關系代數的包含關系和判定謂詞的空值拒絕性質等.這些基礎算法在不同的場景中被不同的改寫策略復用，使得OceanBase 能夠快速實現多種新型的改寫策略.

5.2 計劃生成

計劃生成主要負責枚舉所有等價的執行計劃，并根據代價模型選擇代價最小的執行計劃.OceanBase使用自底向上的動態規劃算法來進行計劃枚舉[12].首先，它會枚舉基表路徑，然后再枚舉連接順序和連接算法，最后按照SQL 語義的順序枚舉其他算子.與單機關系數據庫系統相比，OceanBase 的分布式架構在計劃枚舉中引入了許多額外的復雜因素，如分區信息、并行度、分區裁剪和分布式算法等.這些因素從根本上增加了分布式計劃枚舉的復雜性，并顯著擴大了其計劃枚舉空間.

為了應對分布式計劃枚舉的復雜性，業界大多數系統[18]采用了二階段的計劃枚舉方法.第一階段假設所有表都是單機的，并依賴現有的單機計劃枚舉能力選擇一個本地最優的執行計劃.第二階段將第一階段的單機執行計劃通過適當的規則轉換成一個分布式執行計劃.這種二階段的分布式計劃枚舉方法通過枚舉部分計劃空間來降低分布式計劃枚舉的復雜性，但會導致計劃次優的問題.核心問題在于第一階段優化時沒有考慮分區信息，因此可能會選擇次優的連接順序和單機算法.

為了解決二階段計劃次優的問題，OceanBase 采用了一階段的計劃枚舉方法.計劃枚舉的其中一個目標是為執行計劃中的每個算子選擇一種具體的實現方法.在單機的場景下，算子的實現方法只需要考慮單機的實現，但在分布式的場景中，算子的實現方法除了要考慮單機實現之外，還需要考慮其分布式的實現.以數據庫中的連接算子為例，常見的單機算法有hash join、merge join 和nested loop join 等，常見的分布式方法有partition-wise-join，hash-hash distribution join 和broadcast distribution join 等.OceanBase 一階段計劃枚舉的核心思想是同時枚舉算子的本地算法和分布式算法，并使用分布式代價模型來計算代價，而不是通過二階段的方式分階段地枚舉算子的本地算法和分布式算法.通過這種方式，OceanBase 可以從根本上解決二階段計劃枚舉導致的分布式計劃次優的問題.

相較于二階段的計劃枚舉方法，OceanBase 一階段的計劃枚舉方法能夠完整枚舉出所有的分布式計劃空間，但也會引入計劃枚舉效率問題，尤其是在復雜查詢的場景下.為了解決這一問題，OceanBase 發明了大量快速裁剪計劃的方法，并新增了新的連接枚舉算法來支持超大規模表的計劃枚舉，從而根本性地提升了分布式計劃枚舉的性能.我們的實驗結果也表明，在OceanBase 中，可以在秒級內完成對50張表的分布式計劃枚舉.

5.3 計劃緩存

查詢優化是數據庫中非常耗時的一個過程.隨著查詢復雜度的增加，相應的計劃數量也會呈指數級增長，查詢優化本身也變得異常復雜.因此，對于執行速度本身很快的查詢來說，查詢優化帶來的開銷也變得不可忽視.為了降低查詢優化的性能開銷，與其他關系數據庫一樣，OceanBase 對執行計劃進行了緩存.

與Oracle 的RAC 架構不同，OceanBase 的sharednothing 分布式架構給計劃緩存帶來了額外的挑戰.由于OceanBase 中特定的分布式算法對分區的位置信息有強烈的依賴，有時可能無法使用已緩存的執行計劃來執行相同的查詢.例如，在OceanBase 中，如果緩存的執行計劃包含了A表和B表進行partitionwise-join 的算子，而partition-wise-join 要求A表和B表對應的分區位于同一臺機器上，如果A表或B表發生了分區遷移，它們可能就無法執行partition-wisejoin 操作，這時緩存的執行計劃可能就變得無效，需要重新生成計劃.

為了解決這個問題，OceanBase 會為每一條SQL緩存多個執行計劃.在計劃緩存階段，OceanBase 會遍歷執行計劃，并從依賴位置信息的算子中提取位置信息約束，然后將該執行計劃與約束一起緩存到計劃緩存器中.在計劃匹配階段，如果存在多個緩存計劃，OceanBase 會按照平均執行時間從小到大的順序進行匹配，找到第一個滿足分區位置約束的計劃進行執行.如果沒有滿足約束的計劃，就重新生成計劃并將其加入到計劃緩存器中.通過這種方式，OceanBase 成功解決了分布式計劃的緩存問題，并提升了分布式查詢的性能.

5.4 計劃演進

在關系數據庫系統中，因為數據增刪導致統計信息的變化、數據庫的升級以及Schema 的變更等，執行計劃發生變化是一個比較常見的現象.為了避免由于執行計劃變化而導致的性能回退問題，Oracle 12c 引入了離線計劃演進[19]的方案.該方案的核心思想是始終執行經過驗證的基線計劃，而不執行未經驗證的新計劃.只有在新計劃經過離線演進并通過驗證后，才可以使用它.然而，離線計劃演進的問題在于，在用戶未進行干預之前，不能立即使用性能更好的新計劃.與Oracle 的離線計劃演進方案不同，OceanBase 提出了一種基于用戶實時流量的在線計劃演進方法，該方法的主要優勢是能夠快速接受性能更好的新計劃.

圖7 展示了OceanBase 的在線計劃演進方法.在優化器生成新的計劃時，該方法首先檢查是否存在歷史基線計劃.如果不存在，則直接執行新計劃并將其添加到基線計劃集合中；否則，選擇基線計劃和當前新計劃進行在線演進.如果演進成功，就用新計劃替換舊的基線計劃，否則直接舍棄新計劃.

圖7 OceanBase 在線計劃演進方法Fig.7 Online plan evolution method of OceanBase

OceanBase 使用內部表存儲歷史的基線計劃集合.為了完整地復現基線計劃，OceanBase 在內部表中存儲了原始的SQL 和用于復現該計劃的完整Outline數據.Outline 數據是OceanBase 中一組可用于固定執行計劃的Hint 組合.同時，為了降低在線演進可能導致的潛在性能問題，OceanBase 采用了自適應的演進策略，即根據當前新計劃和基線計劃的執行時間，動態地調整新計劃和基線計劃的流量比例.如果新計劃的執行性能優于基線計劃，則將更多流量分配給新計劃；否則，將更多流量分配給基線計劃.

與其他關系數據庫相比，OceanBase 的在線計劃演進方法能夠快速接受性能優越的新計劃，避免了性能較差的新計劃對數據庫穩定性的影響，減少了數據庫的運維工作.

6 多租戶

OceanBase 數據庫采用了集群內原生多租戶設計，不依賴于外部容器等實現了一個集群內的多個互相獨立的數據庫服務.通過實現原生多租戶，可以實現3 個功能：

1）實現資源隔離，使得每個數據庫服務的實例不感知其他實例的存在，并通過底層控制確保租戶數據的安全性；

2）簡化了集群的部署和運維，能夠原生提供安全、靈活的 DBaaS (Database as a service)服務；

3）實現一個集群對原來多個數據庫實例的資源整合，降低硬件資源總體成本.

6.1 租戶的概念

租戶（tenant）是一個邏輯概念.在 OceanBase 數據庫中，租戶是資源分配的單位，是數據庫對象管理和資源管理的基礎，對于系統運維，尤其是對于云數據庫的運維有著重要的影響.租戶在一定程度上相當于傳統數據庫的“實例”概念.租戶之間是隔離的，類似于操作系統的虛擬機或容器.在數據安全方面，OceanBase 數據庫不允許跨租戶的數據訪問，以確保用戶的數據資產沒有被其他租戶竊取的風險.在資源使用方面，OceanBase 數據庫表現為租戶獨占其資源配額.總體上來說，租戶既是各類數據庫對象的容器，又是資源（CPU、內存、存儲I/O 等）的容器.

租戶有系統租戶和用戶租戶2 種類型.系統租戶是集群默認創建的租戶，與集群的生命周期一致，負責管理集群和所有租戶的生命周期.因為系統租戶只用來管理其他租戶，并存儲集群的元數據，為了設計簡單，系統租戶僅支持單點寫入，不具備擴展能力.

用戶租戶是為用戶創建的租戶，對外提供完整的數據庫功能，支持 MySQL 和 Oracle 兩種兼容模式.用戶租戶支持服務能力水平擴展到多臺機器上，支持動態擴容和縮容，內部會根據用戶的配置自動創建和刪除日志流.

新建一個租戶的時候，管理員需要定義其資源單元配置（UNIT_CONFIG）、所在Zone 列表（ZONE_LIST）、每個Zone 中資源單元數目（UNIT_NUM）這3 個因子.其中，資源單元配置包括CPU、內存、存儲IOPS、存儲空間限制等物理資源的規格限制.系統允許通過在線調整租戶的資源單元配置，實現資源的垂直擴容縮容；通過在線調整資源單元數目，實現租戶資源的水平擴容縮容；通過增刪Zone 列表，實現租戶數據和服務副本數的增刪，從而調整單個租戶的容災等級，也可以用來實現租戶數據的跨數據中心遷移.

6.2 資源隔離

OceanBase 數據庫中把資源單元（UNIT）當作給租戶分配資源的基本單位，一個資源單元可以類比于一個包含CPU、內存、存儲資源的容器.一個節點上可以創建多個資源單元，在節點上每創建一個資源單元都會占用一部分該節點的相應資源.

一個租戶可以在多個節點上放置多個資源單元，但一個租戶在單個節點上只能有一個資源單元.一個租戶的多個資源單元相互獨立，每個節點控制本地多個資源單元間的資源分配.類似的技術是 Docker容器和虛擬機，但 OceanBase 并沒有依賴 Docker 或虛擬機技術，而是在數據庫內部實了資源隔離.在數據庫內原生實現資源隔離有4 個優勢：

1）資源共享，降低單個租戶成本；

2）支持輕量級租戶，如資源單元可以支持0.5c CPU 規格；

3）實現快速的規格變化和快速遷移；

4）便于實現租戶內更細粒度的資源隔離和優先級管理.

通過實現資源隔離，用戶租戶之間可以實現：

1）內存隔離；

2）CPU 在隔離的同時，允許共享；

3）存儲IOPS 在隔離的同時，允許共享.

6.2.1 CPU 的隔離

為了控制CPU 分配，每個資源單元可以指定MIN_CPU，MAX_CPU 這2 個參數.MIN_CPU 決定了在一個調度周期內最少給該租戶保留的時間片，MAX_CPU 決定了最大分配的時間片.當節點上實際使用的CPU 低于所有資源單元的MAX_CPU 總要求時，所有資源要求都得到滿足；否則，超出部分按MAX_CPU 與MIN_CPU 之間的差值決定的權重共享.實現時，節點內通過控制活躍線程數來控制租戶CPU 的占用，但由于 SQL 執行過程中可能會有 I/O 等待、鎖等待等，所以1 個線程無法用滿1 個CPU，節點會按需給每個虛擬 CPU 啟動多個線程.

在典型的工作負載中，大量高并發的短事務，往往和少量低頻但資源消耗較多的“大查詢”混合在一起.相比于大查詢，讓短查詢盡快返回對用戶更有意義，即大查詢的查詢優先級更低，當大查詢和短查詢同時爭搶 CPU 時，系統會限制大查詢的 CPU 使用，即用于大查詢的線程被限制在一定的比例.一方面，當一個線程執行的 SQL 查詢耗時超過閾值，這條查詢就會被判定為大查詢, 一旦判定為大查詢，如果大查詢使用的線程比例達到上限，則該大查詢的線程會進入等待狀態，為其它工作線程讓出CPU.當一個工作線程因為執行大查詢被掛起時，作為補償，系統按需新建工作線程.另一方面，系統會根據執行歷史，在開始執行前就判定一個查詢為“大查詢”.

6.2.2 IOPS 的隔離

除了存儲容量，數據庫硬盤（包括本地硬盤、云盤等）的IOPS 也是影響性能的關鍵因素.有時用戶希望不同租戶的硬盤帶寬可以完全隔離，就像他們運行在不同的物理硬盤上一樣；有時用戶則希望系統提供一定的靈活能力，租戶間實現閑時共享、忙時隔離.OceanBase 使用iops.{min, max, weight}三元組描述一個租戶的硬盤（云盤等）帶寬規格，iops.min 描述硬盤帶寬的下限，這部分資源為租戶預留資源；iops.weight 描述租戶的資源權重，如果一個租戶實際使用的硬盤帶寬超過了iops.min，那他通過iops.weight 與其他租戶劃分資源；iops.max 描述硬盤帶寬的上限，租戶使用的硬盤帶寬不允許超過該上限.

如果租戶要求硬盤帶寬完全隔離，則設置iops.max = iops.min，該租戶的硬盤帶寬按照iops.min的值剛性保留.如果租戶希望自己的硬盤帶寬除了保底能力外，還有一定的彈性上浮空間，可以配置iops.max ＞ iops.min，并根據業務自身的權重配置合理的iops.weight，從而按需使用共享的硬盤帶寬.作為關系數據庫，iops.min 預留硬盤資源的能力對在線事務處理提供穩定的時延是很重要的.而對于OLAP 型業務負載，則可以把iops.min 配置為0，完全共享硬盤帶寬，以最大化利用資源.

6.3 資源單元的均衡

系統需要對資源單元進行管理，并通過把資源單元在多個節點間調度，對系統資源進行有效利用.

1）資源單元的分配，即新建一個資源單元時，系統需要決定其分配到哪個節點上.

2）資源單元的均衡，即在系統運行過程中，系統根據資源單元的資源規格等信息對資源單元進行再平衡的一個調度過程.

單一類型資源的多機負載均衡比較容易實現，只需要計算單一資源的利用率，并通過資源單元的遷移達到每個節點上的資源均衡.當系統中有多種資源需要進行分配和均衡時，僅使用其中一種資源的占用率去進行分配和均衡很難達到較好的分配和均衡效果，為此，在多種資源（CPU 、 內存）均衡和分配時，為每種資源分配一個權重，作為計算節點總的資源占用率時該資源所占的百分比.而每種資源的權重，依賴于集群中該資源的總體使用率，即某種資源使用的越多，則該資源的權重就越高.

6.4 云服務

2022 年，國內公有云數據庫已經占據整個數據庫市場一半以上的份額[20].作為一款分布式關系數據庫，水平伸縮能力使得OceanBase 十分契合公有云服務.

OceanBase 云服務有2 種類型：租戶級實例服務和集群級實例服務.使用租戶級實例服務時，使用者不感知OceanBase 集群資源，只要按需對租戶進行擴容和縮容等操作，以滿足業務發展的需求并節省成本.使用集群級實例服務時，使用者不僅可以按需對集群進行擴容和縮容，還可以在集群內創建和管理租戶，對這些租戶按需進行擴容和縮容等，通過充分發揮租戶級資源共享的能力，以最大化利用集群資源，滿足業務的需求并降低成本.

OceanBase 已經在多個國際主流云平臺上提供OceanBase Cloud 云服務，OceanBase的MySQL和Oracle兼容性大大降低了業務遷移到OceanBase Cloud 的風險和成本，目前已有大量用戶使用OceanBase Cloud云服務，并且在快速增長中.

7 性能測試和對比

與OceanBase 類似，MySQL MGR 使用Paxos 協議實現分布式一致性（Oracle 等尚無類似的技術方案）.本文使用比較常見的Sysbench、TPC-H 測試工具對OceanBase 和MySQL 的OLTP 和OLAP 性能進行了對比.MySQL 版本是8.0.31 Community Server，OceanBase 版本是4.2.1，測試使用的數據庫服務器是阿里云r7.8xlarge ECS，硬件配置是32 vCPU(Intel Xeon Platinum 8369 B CPU @ 2.70 GHz) 、256 GB 內存，日志盤和數據盤使用阿里云云盤，云盤的最大性能吞吐量可以達到350 MB/s.

測試工具的版本是Sysbench 1.1.Sysbench OLTP測試一共創建30 張表，單張表有100 萬行的數據量，壓測客戶端部署在同機房一臺獨立的服務器上，壓測時長為5 min，在壓測時會調整客戶端的壓測并發數，讓MySQL 和OceanBase 跑出各自最好的性能.Sysbench OLTP 讀寫混合場景是個讀多寫少的多表事務，一個事務包括18 條讀寫SQL，包括點查詢、范圍查詢、求和、排序、去重、增刪、更新等，OLTP 只讀場景只運行其中的14 條讀SQL，OLTP 只寫場景只運行其中的4 條寫SQL，性能指標TPS 指的是每秒處理的事務數.

7.1 單機模式

MySQL 和OceanBase 都提供了單機部署的形態，這種數據庫部署形態下的高可用完全依賴硬件的可靠性，數據庫軟件本身沒有高可用能力.

在單機模式下，所有表的數據集中在一臺服務器上.圖8 表明，OceanBase 在各種場景下的性能都優于MySQL；在只寫事務的場景下，OceanBase 的性能是MySQL 的2 倍多；在其他2 個場景下，OceanBase 的性能是MySQL 的1.27 倍.

圖8 單機模式下OceanBase 和MySQL 的性能對比Fig.8 Performance comparison between OceanBase and MySQL in stand-alone mode

7.2 單主模式

與OceanBase 類似，MySQL MGR 是基于Paxos協議的分布式數據庫集群，事務提交必須經過半數以上的節點同意方可提交.本文采用比較常用的三節點的部署進行分布式數據庫集群的性能對比.單主模式表示一個節點為主、另外兩個節點為備，備副本節點從主副本節點同步事務日志，只有主副本節點能夠提供讀寫訪問，當主副本節點故障時，其中1個備副本節點會被自動選舉為新主，兼顧數據一致性和可用性.

下述性能測試采用了3 臺ECS.r7.8xlarge 服務器，sysbench 測試的參數跟單機模式相同，為了避免對數據庫性能的影響，客戶端和OceanBase 的代理服務部署在獨立的機器上，OceanBase 代理服務在分布式部署模式下負責路由請求到數據所在的數據庫服務器的組件.在分布式集群單主模式的部署下，所有表格的主副本節點會集中在一臺服務器上，類似單機模式，sysbench 測試運行的事務都是單機多表事務，寫事務的日志需要同步到超過半數（2 臺）的機器，預期寫性能比單機部署會有所下降，讀性能影響不大.

OceanBase 的3 副本單主部署下，讀寫混合、只讀和只寫3 個場景的性能較單機部署分別下降8%、3%、20%；MySQL 的3 副本單主部署下，讀寫混合、只讀和只寫三個場景的性能較單機部署分別下降12%、1%、19%.在OLTP 只寫場景下，OceanBase 的性能是MySQL 的近2 倍，讀寫混合和只讀場景OceanBase的性能分別是MySQL 的1.34 倍和1.25 倍，如圖9 所示.

圖9 3 副本單主模式OceanBase 和MySQL 的性能對比Fig.9 Performance comparison between OceanBase and MySQL in three-replica single-master mode

7.3 多主模式

分布式集群的多主模式指任何一個數據庫節點都可以寫，即3 個節點都是主副本節點，每條用戶請求訪問的數據可能分布在不同的主副本節點上，3 個數據庫節點是完全對等的.

性能測試采用的數據庫服務器是阿里云3 臺ECS.r7.8xlarge 型號的ECS 服務器，Sysbench 測試使用的數據量和表數量跟單機模式、分布式集群單主模式相同.為了避免對數據庫性能的影響，客戶端和OceanBase 的代理服務部署在獨立的機器上，并且確保壓力機不會是性能的瓶頸.在多主模式的部署下，Sysbench 30 張表格的主副本節點會隨機分布在3 臺ECS 服務器上.Sysbench OLTP 是個多表的測試場景，對應的數據庫事務基本上都是需要從3 臺機器上讀寫數據的分布式事務，3 臺數據庫服務器的資源開銷是相當的.

OceanBase 多主模式相對于單主模式，OLTP 讀寫混合場景的TPS 提升了86%，只讀事務場景的TPS提升了156%，只寫事務場景的TPS 提升了49%.除了只寫事務場景，MySQL 多主模式較單主模式也有不錯的性能提升，但性能較OceanBase 仍然有較大的差距，讀寫混合、只讀和只寫3 個場景下，OceanBase的性能分別是MySQL 的1.27 倍、1.09 倍和3.1 倍，尤其在OLTP 只寫場景下，OceanBase 的性能有3 倍多的優勢，如圖10 所示.

圖10 3 副本多主模式OceanBase 和MySQL 的性能對比Fig.10 Performance comparison between OceanBase and MySQL in three-replica multi-master mode

本文也對比了MySQL 和OceanBase 在多機3 副本多主的集群模式下處理復雜SQL 的性能，采用比較流行的TPC-H 作為測試工具，測試采用的數據量是100 GB.實驗數據表明，在多機3 副本多主模式下OLAP 復雜查詢，OceanBase 的性能是MySQL 的6～327 倍，如圖11 所示.

圖11 OceanBase 和MySQL 的TPC-H 22 條SQL 查詢耗時對比Fig.11 Time-consuming comparison of TPC-H 22 SQL queries between OceanBase and MySQL

8 相關工作

分布式關系數據庫融合了分布式系統和傳統關系數據庫2 個方面的理論和技術，兩者的發展都對分布式關系數據庫產生了顯著的影響.

8.1 分布式系統

Google 分布式文件系統（GFS）[21]實踐了如何在一組普通PC 服務器和普通數據中心網絡之上構建一個可靠的海量數據存儲系統來面向大文件提供高吞吐率的文件讀寫.GFS 每個文件由若干chunk 組成，每個chunk 有若干個副本（典型為3），分別存儲在多個chunk server 上.執行寫入時，通過主從復制把數據同步寫入到多個副本上.為了自動容災和提升寫入性能，GFS 允許副本里出現重復的記錄并允許空的占位記錄，需要應用在讀取時候特殊處理，這一設計與之前的要求強一致性甚至與Posix 兼容的文件系統有顯著不同.Google 分布式文件系統的masterchunk server 架構、自動容災處理、多副本、原子追加等經典設計，對之后的分布式存儲系統產生了很大的影響，比如開源的Hadoop 分布式文件系統（HDFS）.

MapReduce[22]提供了一種用于海量數據處理的編程模型和分布式處理框架.用戶只需要定義一組簡單的map 和reduce 函數，系統將自動把計算過程在一組普通PC 服務器上并行化，并自動處理任務劃分、任務調度、中間結果傳輸、節點故障容災等.MapReduce 刻畫了利用分布式系統分析處理海量數據的關鍵特征，對后來的大數據系統產生了深遠的影響.

8.2 NoSQL 數據庫

Bigtable[23]構建在GFS 之上，是一個用來管理PB 級的結構化數據的分布式存儲系統.Bigtable 的數據模型是一個支持元素級多版本的稀疏表，其中，元素的鍵和值都是無類型的二進制串.為了支持實時更新，存儲結構采用了LSM-tree 的數據結構，對表的修改在記錄持久化日志后，存儲在內存Memtable 中，并在后臺按需與硬盤上的SSTable 文件進行合并.Bigtable 的數據模型后來被稱為寬列模型，是NoSQL類數據庫的典型代表，開源項目HBase 和Cassandra都受到其影響.Bigtable 只支持單行內的事務，不支持通用事務，也就無法通過維護二級索引來加速查詢.

Dynamo[24]是同時期另一個NoSQL 系統，它是一個分布式鍵值存儲系統.為了在設計上達到極高的可用性目標，它的架構采用了去中心化的分布式架構，所有節點對等，整個系統中的組件避免任何中心節點.Dynamo 使用一致性哈希對數據進行分片，使得容災處理和擴容、縮容時數據遷移量最小.為了寫操作的高可用，系統選擇放棄故障時的強一致性，只保證最終一致性.Dynamo 無主副本節點的異步數據復制協議，適合于跨數據中心部署.

8.3 分布式關系數據庫

Bigtable 雖然具有良好的擴展性，但是因為只支持單行事務，應用的并發修改無法確保數據集的一致性，提升了應用開發的難度和成本.為了解決這個問題，Percolator[25]在Bigtable 的模型和服務之上，通過在行數據中添加版本和鎖信息，對應用提供了支持快照隔離級別的通用事務.但是因為任意的多行寫操作都需要作為分布式事務處理，且對鎖狀態多副本持久化和延遲清理，這并不適合對事務處理時延有嚴格要求的OLTP 系統.

Google Spanner[26-27]實現了一個跨全球部署的分布式數據庫，提供了外部強一致性，并支持SQL 語言.Spanner 把數據進行分片，每個分片有多個副本，通過基于Paxos 協議的分布式狀態機保證多副本間的數據一致.Spanner 對后續的類似系統產生了顯著影響，例如CockroachDB[28]和YugaByteDB[29]等.Spanner開發了TrueTime 時間服務以提供全球范圍內誤差很小的時間戳服務，避免了跨地域獲取事務版本號的開銷，但這要求讀寫操作必須在對應的時間戳所示時間之后進行從而增加了讀寫延時，同時TrueTime需要多臺高精度的GPS 原子鐘以提供精確的時間，限制了它的業務應用和部署場景.

9 下一步工作

作為一個分布式數據庫，OceanBase 實現了高可用以及在線水平擴展.未來，OceanBase 期望能夠在同一套系統內更好地處理多種不同的工作負載和數據類型，無論是事務型還是分析型，大數據還是小數據，結構化數據還是半結構化數據，滿足企業從小到大成長過程中的全生命周期數據管理需求.OceanBase系統的后續技術發展方向包括5 個方面：

1）HTAP 混合負載.多數業務不僅需要交易處理（OLTP），還需要對業務進行多個維度的分析、生成各種報表（OLAP）等，當前OceanBase 的OLTP 功能比較豐富，而OLAP 功能還有待進一步完善，OLTP和OLAP 事務處理的優先級、資源隔離等方面還有待進一步完善.未來將進一步豐富OLAP 功能，通過列式存儲等技術提升OLAP 的執行性能，并完善OLTP和OLAP 混合執行能力.

2）Oracle/MySQL 兼容功能.在功能支持方面，OceanBase 兼容絕大部分MySQL 功能和大部分Oracle功能，包括存儲過程、數據庫安全等，然而，系統的查詢優化能力與Oracle 相比有一定的差距，數據庫功能也不如Oracle 豐富.未來將加強SQL 查詢優化和并行執行能力，提升Oracle 兼容性，進一步完善MySQL兼容性，進一步降低從Oracle/MySQL 遷移到該系統的成本.

3）多模態數據處理.多數業務不僅需要處理結構化數據，還需要處理其它類型的數據，例如地理信息數據、文檔數據和鍵值數據等半結構化數據，并基于這些數據執行事務、分析、在線搜索等各種操作.通過使用一套系統處理多種數據，能夠簡化企業的技術棧，降低企業的業務系統實現的復雜度.當前，OceanBase 的關系模型數據管理功能比較豐富，其它數據模型管理功能還有不少需要完善之處.未來將進一步豐富多模數據管理功能，并探索多種數據模型之間的互通操作.

4）多云原生數據庫.OceanBase 支持多種不同的部署模式，包括公有云、專有云和獨立軟件部署.公有云、多云、混合云將會是未來的趨勢，因此，后續OceanBase 將會進一步增強對全球主流云平臺的支持和適配，并進行軟硬件協同優化以實現更好的性價比.

5）自治數據庫.當前OceanBase 運行維護參數較多，運行維護人員學習和使用有一定的學習成本.未來我們計劃利用機器學習和人工智能技術來分析系統運行環境狀態和日志數據等信息，從而實現較為智能的動態系統參數調整、系統優化、在線預警、實時監測等，實現智能診斷、智能調優、智能運維等.

OceanBase 作為一個基礎軟件，生態構建至關重要.2021 年6 月1 日，OceanBase 將內核代碼（超過300萬行）在GitHub[30]開源，目前已經有成百上千的企業使用OceanBase 開源版本.未來，OceanBase 會繼續堅持開源開放的路線，進一步加大對用戶、開發者、合作伙伴的支持力度，基于開源社區的協作模式，通過大量用戶的反饋不斷迭代，不斷提升OceanBase 的成熟度，更好地滿足用戶的需求.

作者貢獻聲明：陽振坤提出論文思路、整體架構設計，參與文獻調研，撰寫和修訂論文；楊傳輝、韓富晟、王國平、楊志豐參與文獻調研和論文撰寫；成肖君參與文獻調研和論文撰寫，并負責性能對照實驗.