螞蟻集團自研數據庫OceanBase已經開源，這對國產分布式數據庫來說，是一個重磅消息。一直以來OceanBase作為商業數據庫，披露的技術細節并不多,以后又多了一個可以拿來研究的優秀分布式數據庫。參考1[1]

根據官網描述，在5月20日國際事務處理性能委員會(TPC，Transaction Processing Performance Council)官網發布最新的數據分析型基準測試(TPC-H)榜單中，OceanBase以 1526 萬 QphH 的性能總分排名 30,000 GB 第一。這意味著，OceanBase 成為唯一在事務處理和數據分析兩個領域測試中都獲得第一的中國自研數據庫。

1 架構

主流的分布式數據庫有兩種架構，PGXC和NewSql。

1.1 PGXC

PGXC是指PostgreSQL-XC，指以PostgreSQL為內核的分布式數據庫，整體架構如下:

PGXC架構是對傳統單體數據庫做了集群，在集群的基礎上加了協調節點，協調節點具有如下作用：

客戶端接入
進程管理
分布式事務管理
查詢處理

同時還增加了分片管理和全局時鐘。分片管理用來管理集群的分片信息，全局時鐘的介紹見下一節。

雖然PGXC名字的由來是PostgreSQL組成的分布式數據庫，但是使用其他單體數據庫組成的分布式數據庫，也可以理解為PGXC，比如Golden使用的就是MySQL作為內核。

1.2 NewSQL

跟PGXC采用傳統單體數據庫為內核相比，NewSQL是在NoSQL基于分布式鍵值存儲系統的基礎上構建了分布式事務處理能力。架構如下圖：

此外，NewSQL還有兩個改進：

對于HA，放棄傳統數據庫的主從復制，使用Paxos、Raft等共識算法來保證多副本的一致性。
對于存儲，使用LSM樹模型替換B+樹，寫入性能更高。

2 全局時鐘

2.1 線程一致性

線性一致性(Linearizability)是分布式系統中最強的一致性模型，總體思想是保證讀取多個不同副本的客戶端，跟讀取同一個副本讀到的結果一樣，即整個系統看起來像只有一個副本。

先看兩個不符合線性一致性的示例。

2.1.1 同一個客戶端

如下圖：

client1第一次讀取了x的值是0，第二次讀取時因為client3修改了x的值，所以讀到了新的值1，但是第三次讀取時因為讀到了別的副本，因為這個副本還沒有同步完成，所以讀到了舊的值0。

2.1.2 不同客戶端

如下圖：

client1第一次讀取了x的值是0，第二次讀取時因為client3修改了x的值，所以讀到了新的值1，但是在client1第二次讀取之后，client2來讀取x的值，因為讀到了別的副本，因為這個副本還沒有同步完成，所以讀到了舊的值0。

線性一致性要求，任何一個客戶端讀取返回新值后，后面所有客戶端(包括相同客戶端和不同客戶端)讀取也必須返回新值

下面這個圖就是線性一致性的：

2.2 全局時鐘

從上面的描述可以看到，線性一致性是建立在事件的先后順序之上的。所有操作必須記錄在一條時間線上，任意兩個事件都有先后順序。但是，集群中各個節點都有各自的時間線，怎么實現時間上的順序性呢。這時就需要一個全局的絕對時間，就是這里講的全局時鐘。

一般來說，從一臺時間服務器獲取時間，就可以實現全局時鐘，但是必須保證高可用。下面介紹幾種全局時鐘的實現方式：

2.2.1 TrueTime

google Spanner采用GPS加原子鐘來分配時間，支持多點授時機制。有兩個明顯的優勢：

多點授時去中心化，實現了高可靠。
支持全球化部署，這樣可以減少客戶端和時間服務器的通信時長。

但是也存在一些問題：

采用物理時鐘可以出現時鐘偏移和時鐘回撥。
多點授時可能出現系統整體的時間誤差。

從Spanner的介紹看，時間誤差在7毫秒以內。

2.2.2 混合邏輯時鐘(HLC)

HLC(Hybrid Logical Clock)，因為Truetime依賴于硬件設備來實現，實現難度大，所以有的數據庫采用了混合邏輯時鐘，即物理時鐘和邏輯時鐘配合使用，同樣采多時間源、多點授時，所以也會有系統整體的時間誤差問題。

2.2.3 Timestamp Oracle

簡稱TSO，中心化授時方案，采用單時間源、單點授時實現全局時鐘，用一個全局唯一的時間戳作為xid(全局事務id)。

優點：

實現簡單
單時間源單調遞增，可以減少事務沖突

缺點也很明顯

單點授時，性能會有瓶頸
不適合大規模集群部署

目前，TiDB、OceanBase都使用了這個方案。

2.2.4 總結

Spanner需要借助物理設備來實現，對其他開源數據庫的參考價值并不大。

其他無論采用HLC還是TSO，都有各自的優缺點。

還有一種介于兩者之間的授時方案，單時間源，多點授時，使用比較少。

3 HTAP

HTAP英文全稱是 Hybrid Transaction and Analytical Processing，即混合事務和分析處理，能夠將事務處理(OLTP)和數據分析(OLAP)請求在同一個數據庫系統中完成。

HTAP需要在計算和存儲兩個層面支持OLTP和OLAP，存儲是基礎。OLTP通常使用行式存儲，OLAP則一般使用列式存儲，差異很大。HTAP解決這個差異的方式有兩種：

Google Spanner的PAX，一種新的融合性存儲，即在行存儲的基礎上融合列存儲的特點。
TiDB的思路，借助Raft協議在OLTP與OLAP之間異步復制數據，通過OLAP的特殊設計來彌補異步帶來的數據不一致。

OceanBase采用獨創的分布式計算引擎，能讓系統中多個計算節點同時運行OLTP類型的應用和OLAP類型的應用，實現了用一套計算引擎同時支持混合負載的能力。

4 RANGE動態分區

下圖有4條數據，

如果按照HASH進行分片，一般會選擇id作為key進行HASH計算，之后根據計算結果把數據分配到不同的分片中。這樣做的好處是實現簡單，但也存在兩個問題：

分片不具備業務屬性，可能會存在業務熱點訪問的問題。
分片規模變化時，遷移數據問題。

Range分片技術跟HASH相比，很大的不同是數據并沒有被打散。比如上表中，我們可以把數據按照城市進行分片，這樣數據讀取效率會更高。

Range動態分區用在NewSQL架構的分布式數據庫中，一般具有下面的特性：

4.1 自動合并和拆分

可以給分配的數據量設置閾值，當某個分片的數據量超過最大閾值時，可以自動拆分成2個分片，當分片數據量小于最小閾值時，進行分片合并。

4.2 自動負載

當某個分片上的熱點數據較多時，節點訪問壓力會很大，系統可以自動地將這些熱點數據訪問調度到不同節點，以均衡訪問壓力。

4.3 減少分布式事務

分布式事務的開銷會遠遠大于本地事務，分布式數據庫可以把頻繁參與同一個分布式事務的數據調度到同一個分片上，這樣就避開了分布式事務。

Spanner支持

4.4 就近訪問

在全球部署的場景下，給用戶分配最近節點的分片，可以減少訪問延時。

Spanner支持

4.5 高可靠

分布式數據庫的高可靠是分區級別的高可靠，下圖是OceanBase中一個Zone的架構圖：

OceanBase基于Paxos算法來實現系統的高可用，最小的粒度可以做到分區級別。集群中數據的每一個分區會被保存到所有的Zone上，分區的多個副本采用Paxos協議進行日志同步。每個分區和它的副本構成一個獨立的Paxos復制組，其中一個分區為Leader，其它分區為Follower。所有針對這個副本的寫請求，都會自動路由到對應的主分區上進行。主分區可以分布在不同的OBServer上，這樣對于不同副本的寫操作也會分布到不同的數據節點上，從而實現數據多點寫入，提高系統性能。