背景

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

架構(gòu)

OceanBase

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

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

TiDB

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

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

特性

可擴展

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

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

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

高可用

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

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

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

兼容 MySQL

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

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

性能

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

壓測環(huán)境

TiDB 使用5.0.0版本，OceanBase 使用3.1.0_CE社區(qū)版本，Sysbench 使用1.0.20版本。OceanBase 租戶分配資源36個邏輯 CPU + 100 G 物理內(nèi)存，TiDB 調(diào)整 RocksDB 緩存 100G。測試數(shù)據(jù)規(guī)模為16張表，單表1000萬行數(shù)據(jù)，每次測試跑300秒。

只讀測試

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

寫入測試

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

總結(jié)

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

后話

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

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

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