（關注“資料庫架構師”公衆号，提升資料庫技能，助力職業發展）
背景
2021年6月1日，螞蟻集團開源 OceanBase 代碼，這款連續兩年占領 TPC-C 榜首的資料庫産品再次擁抱開源。而此時，在開源社群國産資料庫的賽道上還有另外一位明星選手：TiDB。同為關系型資料庫，兩者都采用分布式架構，具備可擴充、高可用、相容 MySQL 的特性，相同特性背後兩者的實作卻大相徑庭，各有考量。接下來将對兩者架構、特性與性能方面做一些介紹，希望能對業務了解、選擇與使用上有一些幫助。
架構
OceanBase
OceanBase 的核心叢集架構主要包括 ObServer，ObProxy 2個子產品，如下圖所示：
- ObServer 為核心子產品，提供存儲（使用自研 LSM-Tree 存儲引擎）、事務處理、叢集管理等功能。從上面架構圖可以看出，OceanBase 按 zone 屬性聚合 ObServer，叢集中包含若幹個 zone，我們可以把 zone 了解為一個地區，資料中心或者機房。OceanBase 使用分區表管理資料，普通表或者分區表的一個分區在各個 zone 内都存在一份副本，其中主副本負責處理 SQL 請求，并通過 Paxos 協定同步資料。此外 OceanBase 包含租戶的概念，提供資源管理功能，如下圖所示，租戶資源由若幹個資源池組成，單個資源池包含若幹個相同規格的資源單元，租戶擁有的資源單元分布在不同的 ObServer 上，同一 ObServer 上的資源單元互相隔離（目前支援 cpu 與記憶體），租戶建立的分區分布在租戶管理的資源單元中。
- ObProxy 提供叢集代理服務，主要功能是高性能轉發 SQL 請求。簡單的解析 SQL 擷取目的分區，根據路由規則和路由表轉發請求到合适的 ObServer 節點。
TiDB
TiDB 叢集架構如下圖，主要介紹其中 TiKV, TiDB, PD 3個子產品。
- TIKV 負責資料存儲，底層使用基于 LSM-Tree 結構的 RocksDB 存儲引擎存儲 k-v 資料。叢集中包含若幹個 TiKV 節點，單個 TiKV 節點包含若幹個資料分片的副本，TiDB 對 kv 按照區間範圍分片（稱為 Region），單個 Region 包含特定數量的副本（稱為 Peer），其中主副本（稱為 Leader Peer）處理讀寫請求，通過 Raft 協定同步資料，對外提供 k-v 事務讀寫接口。
- TiDB 為 SQL 層，對外暴露遵循 MySQL 協定的端口，負責解析并處理用戶端 SQL 請求。TiDB 解析 SQL 轉化為 k-v 請求，從 PD 子產品擷取時間戳以及 Key 所在 Region 資訊，然後作為兩階段送出的協調者處理 SQL 請求，TiDB 自身無狀态，叢集中可以部署多個 TiDB 服務分攤用戶端請求。
- PD 為叢集元資訊管理子產品，除了管理 Region 資訊，為 TiDB 提供時間戳等功能，PD 還是叢集的“大腦”，通過排程 Region 副本與主副本在 TiKV 節點間的分布，保障節點負載均衡、Region 健康，為了實作高可用，叢集内可以部署多個 PD 服務，并且建議為奇數個。
特性
可擴充
随着資料量的增加，單機資料庫不得不面對計算、存儲能力不足的問題，傳統的分庫分表方案在解決問題的同時也引入了新的問題：對業務使用不透明，具有侵入性；跨庫 SQL 語句受到限制；跨庫語句難以100%保證事務特性等，針對這個問題，OceanBase和TiDB有不同的解決方案。
- OceanBase 中 zone 提供主要服務，負責整個叢集的資源排程、資源配置設定、資料分布資訊管理以及 Schema 管理等功能。現在 zone 中添加 ObServer 節點時，節點資源會被總控服務管理供租戶使用，叢集的計算、存儲等能力得到水準擴充。此外 ObServer 還支援租戶級别的可擴充特性，修改資源單元的數量與規格即可完成租戶能力的水準擴充。就單表而言，業務在建表時需要指定分區鍵（分區鍵必須是主鍵與唯一索引的子集）與分區方式（支援 Hash, Range 和 List 分區，支援二級組合分區）。不同的分區，可以分布在不同的資料節點上，通過分區可以提高系統的可擴充性，可管理性，以及性能。目前的最新版本尚未支援分區分裂的特性（已咨詢OB開發人員，得到回報該功能正在開發中，預計12月完成），是以目前屬于靜态分區方式。此方式在極端場景下（未進行合理分區），可能會使得系統的擴充性降低。但實際上，OB與WTable、WList的資料分片方式類似，在絕大多數線上場景下，都是可以具備便捷的水準擴充性的。
- 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 最進階别的災難恢複能力。
- OceanBase 使用 Paxos 協定同步資料，同樣允許半數以下節點故障。此外前面我們提到了 zone 的概念，OceanBase 支援添加删除 zone 等操作，基于 zone 的管理操作 OceanBase 很容易實作同城多機房、兩地三中心以及三地五中心等部署方案，實作跨機房、跨地區的容災能力。
- 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秒。
| 機器 | 型号 | 服務 |
| 10.10.1.1 | S04 | TiKV、TiDB、PD、Sysbench |
| 10.10.1.2 | S04 | TiKV、TiDB、PD、Sysbench |
| 10.10.1.3 | S04 | TiKV、TiDB、PD、Sysbench |
| 10.10.1.4 | S04 | ObServer、ObProxy |
| 10.10.1.5 | S04 | ObServer、Sysbench |
| 10.10.1.6 | S04 | ObServer |
隻讀測試
隻讀測試中單個事務中包含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方也表示了其認真做開源、持續投入開源的決心和願景。
如果這篇文章對你有幫助，還請幫忙點贊、轉發 以下，你的支援會激勵我們輸出更多高品質的文章！
如果你還想看更多優質文章，歡迎關注我的公衆号「資料庫架構師」，提升資料庫技能，助力職業發展。