背景

2021年6月1日，螞蟻集團開源 OceanBase 代碼，這款連續兩年占領 TPC-C 榜首的數據庫產品再次擁抱開源。而此時，在開源社區國產數據庫的賽道上還有另外一位明星選手：TiDB。同為關系型數據庫，兩者都采用分布式架構，具備可擴展、高可用、兼容 MySQL 的特性，相同特性背后兩者的實現卻大相徑庭，各有考量。接下來將對兩者架構、特性與性能方面做一些介紹，希望能對業務了解、選擇與使用上有一些幫助。

架構

OceanBase

OceanBase 的核心集群架構主要包括 ObServer，ObProxy 2個模塊，如下圖所示：

1. ObServer 為核心模塊，提供存儲（使用自研 LSM-Tree 存儲引擎）、事務處理、集群管理等功能。從上面架構圖可以看出，OceanBase 按 zone 屬性聚合 ObServer，集群中包含若干個 zone，我們可以把 zone 理解為一個地區，數據中心或者機房。OceanBase 使用分區表管理數據，普通表或者分區表的一個分區在各個 zone 內都存在一份副本，其中主副本負責處理 SQL 請求，并通過 Paxos 協議同步數據。此外 OceanBase 包含租戶的概念，提供資源管理功能，如下圖所示，租戶資源由若干個資源池組成，單個資源池包含若干個相同規格的資源單元，租戶擁有的資源單元分布在不同的 ObServer 上，同一 ObServer 上的資源單元互相隔離（目前支持 cpu 與內存），租戶創建的分區分布在租戶管理的資源單元中。
2. ObProxy 提供集群代理服務，主要功能是高性能轉發 SQL 請求。簡單的解析 SQL 獲取目的分區，根據路由規則和路由表轉發請求到合適的 ObServer 節點。

TiDB

TiDB 集群架構如下圖，主要介紹其中 TiKV, TiDB, PD 3個模塊。

1. TIKV 負責數據存儲，底層使用基于 LSM-Tree 結構的 RocksDB 存儲引擎存儲 k-v 數據。集群中包含若干個 TiKV 節點，單個 TiKV 節點包含若干個數據分片的副本，TiDB 對 kv 按照區間范圍分片（稱為 Region），單個 Region 包含特定數量的副本（稱為 Peer），其中主副本（稱為 Leader Peer）處理讀寫請求，通過 Raft 協議同步數據，對外提供 k-v 事務讀寫接口。
2. TiDB 為 SQL 層，對外暴露遵循 MySQL 協議的端口，負責解析并處理客戶端 SQL 請求。TiDB 解析 SQL 轉化為 k-v 請求，從 PD 模塊獲取時間戳以及 Key 所在 Region 信息，然后作為兩階段提交的協調者處理 SQL 請求，TiDB 自身無狀態，集群中可以部署多個 TiDB 服務分攤客戶端請求。
3. PD 為集群元信息管理模塊，除了管理 Region 信息，為 TiDB 提供時間戳等功能，PD 還是集群的“大腦”，通過調度 Region 副本與主副本在 TiKV 節點間的分布，保障節點負載均衡、Region 健康，為了實現高可用，集群內可以部署多個 PD 服務，并且建議為奇數個。

特性

可擴展

隨著數據量的增加，單機數據庫不得不面對計算、存儲能力不足的問題，傳統的分庫分表方案在解決問題的同時也引入了新的問題：對業務使用不透明，具有侵入性；跨庫 SQL 語句受到限制；跨庫語句難以100%保證事務特性等，針對這個問題，OceanBase和TiDB有不同的解決方案。

1. OceanBase 中 zone 提供主控服務，負責整個集群的資源調度、資源分配、數據分布信息管理以及 Schema 管理等功能。現在 zone 中添加 ObServer 節點時，節點資源會被總控服務管理供租戶使用，集群的計算、存儲等能力得到水平擴展。此外 ObServer 還支持租戶級別的可擴展特性，修改資源單元的數量與規格即可完成租戶能力的水平擴展。就單表而言，業務在建表時需要指定分區鍵（分區鍵必須是主鍵與唯一索引的子集）與分區方式（支持 Hash, Range 和 List 分區，支持二級組合分區）。不同的分區，可以分布在不同的數據節點上，通過分區可以提高系統的可擴展性，可管理性，以及性能。目前的最新版本尚未支持分區分裂的特性（已咨詢OB開發人員，得到反饋該功能正在開發中，預計12月完成），所以目前屬于靜態分區方式。此方式在極端場景下（未進行合理分區），可能會使得系統的擴展性降低。但實際上，OB與WTable、WList的數據分片方式類似，在絕大多數線上場景下，都是可以具備便捷的水平擴展性的。
2. TiDB 對底層 k-v 按區間范圍分片（稱為 Region），當分片包含的數據量達到一定大小時會觸發分裂，我們可以簡單地認為集群管理的 Region 數量沒有上限，那么集群的數據量也就沒有限制。此外當我們向集群中添加/刪除 TiKV 節點時，PD 會調度 Region 分布，盡量保證各節點 cpu，磁盤，io 負載均衡，因此調度完成后，集群的計算、存儲能力是得到水平擴展的。

從上述分析可以看出，OceanBase與TiDB集群均具備水平擴展的特性，此外 OceanBase實現了租戶資源管理功能，支持租戶的水平擴展，具備按需分配的能力，但是當前版本靜態分區的方式對業務使用不夠透明，需要在建表的同時確定合理的分區方式和分區數量；而TiDB Region自動分裂的特性，使得其內部數據切分對業務是透明的，使用起來較為方便，但在實際測試過程中，也會遇到少數Region分裂造成服務性能抖動的現象。

高可用

單點故障時單機數據庫不得不面對的又一難題，傳統的主從方案具備一定的可用性和容災能力，但是并不完全可靠：備機故障時，主備同步會從最大保護模式（實時同步 Redo-Log）切換到最大性能模式（異步同步 Redo-Log），帶來丟失數據的風險；主機故障時備機一般主動切換為主（避免腦裂問題），需要人工干預，這樣則存在較長時間無法提供服務的風險。TiDB 與 OceanBase 均能規避單點故障問題，提供恢復時間目標 RTO <= 30s 及 恢復點目標 RPO = 0 最高級別的災難恢復能力。

1. OceanBase 使用 Paxos 協議同步數據，同樣允許半數以下節點故障。此外前面我們提到了 zone 的概念，OceanBase 支持添加刪除 zone 等操作，基于 zone 的管理操作 OceanBase 很容易實現同城多機房、兩地三中心以及三地五中心等部署方案，實現跨機房、跨地區的容災能力。
2. TiDB 使用 Raft 協議同步數據，允許半數以下節點故障，故障節點主副本所在 Region 重新選主恢復讀寫能力，備副本由于 Region 存在半數以上存活節點讀寫正常，后續 PD 還會主動調度失效的副本到正常節點上，保證 Region 健康。此外 TiDB 支持設置隔離級別（跨數據中心、機房或者 Host），后續 PD 會根據集群拓撲信息調度遷移 Region Peers 以滿足設置的隔離級別。

Raft 與Paxos 都是生產環境下廣泛使用的協議，都具備半數下節點故障的容忍能力，此外兩者都支持對 Region（或分區）副本實現跨機房、跨地區或跨主機的隔離，比較而言 OceanBase 按 zone 組織 ObServe 的實現方案更加簡單直觀，便于業務使用。

兼容 MySQL

為了降低業務遷移與使用成本，TiDB 與 OceanBase 都高度兼容 MySQL 協議與語法，TiDB 文檔宣稱 100% 兼容 MySQL 5.7 協議、MySQL 5.7 常用功能及語法，OceanBase文檔則聲明兼容 MySQL 5.6 絕大部分功能和語法，兩者文檔中都對 MySQL 不支持或者實現有差異的功能特性做了說明。

對于 MySQL 事務特性，TiDB 與 Oceanbase 均支持分布式事務。兩者參考 google Percolator 實現兩階段提交，基于多版本并發控制為事務提供可重復讀與快照隔離兩種隔離級別，詳細介紹可以參考 TiDB 文檔、OceanBase 文檔。

性能

TiDB 與 OceanBase 都在官方文檔中給出了壓測方案與性能數據，但是兩者給出的機器配置不同，這里使用公司機器搭建集群進行壓測獲得了一些性能數據供大家參考了解。

壓測環境

TiDB 使用5.0.0版本，OceanBase 使用3.1.0_CE社區版本，Sysbench 使用1.0.20版本。OceanBase 租戶分配資源36個邏輯 CPU + 100 G 物理內存，TiDB 調整 RocksDB 緩存 100G。測試數據規模為16張表，單表1000萬行數據，每次測試跑300秒。

只讀測試

只讀測試中單個事務中包含5條 SQL語句，分別為1次主鍵查詢與4次主鍵范圍查詢（分別獲取字段，字段和，字段排序以及字段排序后不同值），壓測 QPS 數據如下，不難看出 TiDB 僅在32線程下 QPS 高于 OceanBase，其余線程測試下OceanBase 最佳性能優于 TiDB。

寫入測試

寫入測試中單個事務4條 SQL 語句，分別為更新索引字段、更新非索引字段、刪除行與插入行，壓測 QPS 數據如下，OceanBase 性能一直優于 TiDB，最佳性能也在 TiDB 之上。

總結

上述測試只是一個簡單的初步測試，后續我們會使用最新版本進行更全面與詳細的對比測試。總體上來說，TiDB 與 OceanBase 按照各自的方案實現了可擴展、高可用的特性，并且高度兼容 MySQL 協議與語法。兩者的一些區別包括：TiDB 底層 Region 動態分裂，單表計算、存儲能力可以水平擴展；OceanBase 著重實現了集群資源管理功能，可為租戶按需分配資源。OceanBase使用靜態分區方式，在業務使用時需合理規劃分區，以得到更好的性能以及擴展性。

后話

在2021年10月18日舉辦的DTCC 2021（第十二屆中國數據庫技術大會）中，OceanBase正式發布了開源3.1.1版本，新版本在原有性能優勢基礎之上，打通開源組件和開源的生態更好的協作在一起。譬如：支持 MySQL 5.7 驅動協議；開放了 TABLE API 接口讓 OceanBase 數據庫擁有 NoSQL 的能力，提供 KV 數據庫訪問能力；開放 CDC 接口，提供 OceanBase 對外數據同步接口；同時，新版本支持 20 多個生態工具，支持 Docker 部署，實現全量和增量的數據遷移。接下來我們也會對最新版本進行進一步的性能測試。

在DTCC大會上OceanBase進行了專場分享，其中也包括美團、嗶哩嗶哩、攜程等公司都分享了他們使用OceanBase的經驗及心路歷程。OceanBase方也表示了其認真做開源、持續投入開源的決心和愿景。

如果這篇文章對你有幫助，還請幫忙點贊、轉發 以下，你的支持會激勵我們輸出更多高質量的文章！