11張圖帶你了解分布式數(shù)據(jù)庫(kù)的核心知識(shí)

螞蟻集團(tuán)自研數(shù)據(jù)庫(kù)OceanBase已經(jīng)開源，這對(duì)國(guó)產(chǎn)分布式數(shù)據(jù)庫(kù)來(lái)說(shuō)，是一個(gè)重磅消息。一直以來(lái)OceanBase作為商業(yè)數(shù)據(jù)庫(kù)，披露的技術(shù)細(xì)節(jié)并不多,以后又多了一個(gè)可以拿來(lái)研究的優(yōu)秀分布式數(shù)據(jù)庫(kù)。參考1^[1]

根據(jù)官網(wǎng)描述，在5月20日國(guó)際事務(wù)處理性能委員會(huì)(TPC，Transaction Processing Performance Council)官網(wǎng)發(fā)布最新的數(shù)據(jù)分析型基準(zhǔn)測(cè)試(TPC-H)榜單中，OceanBase以 1526 萬(wàn) QphH 的性能總分排名 30,000 GB 第一。這意味著，OceanBase 成為唯一在事務(wù)處理和數(shù)據(jù)分析兩個(gè)領(lǐng)域測(cè)試中都獲得第一的中國(guó)自研數(shù)據(jù)庫(kù)。

1 架構(gòu)

主流的分布式數(shù)據(jù)庫(kù)有兩種架構(gòu)，PGXC和NewSql。

1.1 PGXC

PGXC是指PostgreSQL-XC，指以PostgreSQL為內(nèi)核的分布式數(shù)據(jù)庫(kù)，整體架構(gòu)如下:

PGXC架構(gòu)是對(duì)傳統(tǒng)單體數(shù)據(jù)庫(kù)做了集群，在集群的基礎(chǔ)上加了協(xié)調(diào)節(jié)點(diǎn)，協(xié)調(diào)節(jié)點(diǎn)具有如下作用：

• 客戶端接入
• 進(jìn)程管理
• 分布式事務(wù)管理
• 查詢處理

同時(shí)還增加了分片管理和全局時(shí)鐘。分片管理用來(lái)管理集群的分片信息，全局時(shí)鐘的介紹見下一節(jié)。

雖然PGXC名字的由來(lái)是PostgreSQL組成的分布式數(shù)據(jù)庫(kù)，但是使用其他單體數(shù)據(jù)庫(kù)組成的分布式數(shù)據(jù)庫(kù)，也可以理解為PGXC，比如Golden使用的就是mysql作為內(nèi)核。

1.2 NewSQL

跟PGXC采用傳統(tǒng)單體數(shù)據(jù)庫(kù)為內(nèi)核相比，NewSQL是在NoSQL基于分布式鍵值存儲(chǔ)系統(tǒng)的基礎(chǔ)上構(gòu)建了分布式事務(wù)處理能力。架構(gòu)如下圖：

此外，NewSQL還有兩個(gè)改進(jìn)：

• 對(duì)于HA，放棄傳統(tǒng)數(shù)據(jù)庫(kù)的主從復(fù)制，使用Paxos、Raft等共識(shí)算法來(lái)保證多副本的一致性。
• 對(duì)于存儲(chǔ)，使用LSM樹模型替換B+樹，寫入性能更高。

2 全局時(shí)鐘

2.1 線性一致性

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

先看兩個(gè)不符合線性一致性的示例。

2.1.1 同一個(gè)客戶端

如下圖：client1第一次讀取了x的值是0，第二次讀取時(shí)以為client3修改了x的值，所以讀到了新的值1，但是第三次讀取時(shí)因?yàn)樽x到了別的副本，因?yàn)檫@個(gè)副本還沒(méi)有同步完成，所以讀到了舊的值0。

2.1.2 不同客戶端

如下圖：

client1第一次讀取了x的值是0，第二次讀取時(shí)因?yàn)閏lient3修改了x的值，所以讀到了新的值1，但是在client1第二次讀取之后，client2來(lái)讀取x的值，因?yàn)樽x到了別的副本，因?yàn)檫@個(gè)副本還沒(méi)有同步完成，所以讀到了舊的值0。

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

下面這個(gè)圖就是線性一致性的：

2.2 全局時(shí)鐘

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

一般來(lái)說(shuō)，從一臺(tái)時(shí)間服務(wù)器獲取時(shí)間，就可以實(shí)現(xiàn)全局時(shí)鐘，但是必須保證高可用。下面介紹幾種全局時(shí)鐘的實(shí)現(xiàn)方式：

2.2.1 TrueTime

Google Spanner采用GPS加原子鐘來(lái)分配時(shí)間，支持多點(diǎn)授時(shí)機(jī)制。有兩個(gè)明顯的優(yōu)勢(shì)：

• 多點(diǎn)授時(shí)去中心化，實(shí)現(xiàn)了高可靠。
• 支持全球化部署，這樣可以減少客戶端和時(shí)間服務(wù)器的通信時(shí)長(zhǎng)。

但是也存在一些問(wèn)題：

• 采用物理時(shí)鐘可以出現(xiàn)時(shí)鐘偏移和時(shí)鐘回?fù)堋?/section>
• 多點(diǎn)授時(shí)可能出現(xiàn)系統(tǒng)整體的時(shí)間誤差。

從Spanner的介紹看，時(shí)間誤差在7毫秒以內(nèi)。

2.2.2 混合邏輯時(shí)鐘(HLC)

HLC(Hybrid Logical Clock)，因?yàn)門ruetime依賴于硬件設(shè)備來(lái)實(shí)現(xiàn)，實(shí)現(xiàn)難度大，所以有的數(shù)據(jù)庫(kù)采用了混合邏輯時(shí)鐘，即物理時(shí)鐘和邏輯時(shí)鐘配合使用，同樣采多時(shí)間源、多點(diǎn)授時(shí)，所以也會(huì)有系統(tǒng)整體的時(shí)間誤差問(wèn)題。

2.2.3 Timestamp Oracle

簡(jiǎn)稱TSO，中心化授時(shí)方案，采用單時(shí)間源、單點(diǎn)授時(shí)實(shí)現(xiàn)全局時(shí)鐘，用一個(gè)全局唯一的時(shí)間戳作為xid(全局事務(wù)id)。

優(yōu)點(diǎn)：

• 實(shí)現(xiàn)簡(jiǎn)單
• 單時(shí)間源單調(diào)遞增，可以減少事務(wù)沖突

缺點(diǎn)也很明顯

• 單點(diǎn)授時(shí)，性能會(huì)有瓶頸
• 不適合大規(guī)模集群部署

目前，TiDB、OceanBase都使用了這個(gè)方案。

2.2.4 總結(jié)

Spanner需要借助物理設(shè)備來(lái)實(shí)現(xiàn)，對(duì)其他開源數(shù)據(jù)庫(kù)的參考價(jià)值并不大。

其他無(wú)論采用HLC還是TSO，都有各自的優(yōu)缺點(diǎn)。

還有一種介于兩者之間的授時(shí)方案，單時(shí)間源，多點(diǎn)授時(shí)，使用比較少。

3 HTAP

HTAP英文全稱是 Hybrid Transaction and Analytical Processing，即混合事務(wù)和分析處理，能夠?qū)⑹聞?wù)處理(OLTP)和數(shù)據(jù)分析(OLAP)請(qǐng)求在同一個(gè)數(shù)據(jù)庫(kù)系統(tǒng)中完成。

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

• Google Spanner的PAX，一種新的融合性存儲(chǔ)，即在行存儲(chǔ)的基礎(chǔ)上融合列存儲(chǔ)的特點(diǎn)。
• TiDB的思路，借助Raft協(xié)議在OLTP與OLAP之間異步復(fù)制數(shù)據(jù)，通過(guò)OLAP的特殊設(shè)計(jì)來(lái)彌補(bǔ)異步帶來(lái)的數(shù)據(jù)不一致。

OceanBase采用獨(dú)創(chuàng)的分布式計(jì)算引擎，能讓系統(tǒng)中多個(gè)計(jì)算節(jié)點(diǎn)同時(shí)運(yùn)行OLTP類型的應(yīng)用和OLAP類型的應(yīng)用，實(shí)現(xiàn)了用一套計(jì)算引擎同時(shí)支持混合負(fù)載的能力。

4 RANGE動(dòng)態(tài)分區(qū)

下圖有4條數(shù)據(jù)，

如果按照HASH進(jìn)行分片，一般會(huì)選擇id作為key進(jìn)行HASH計(jì)算，之后根據(jù)計(jì)算結(jié)果把數(shù)據(jù)分配到不同的分片中。這樣做的好處是實(shí)現(xiàn)簡(jiǎn)單，但也存在兩個(gè)問(wèn)題：

• 分片不具備業(yè)務(wù)屬性，可能會(huì)存在業(yè)務(wù)熱點(diǎn)訪問(wèn)的問(wèn)題。
• 分片規(guī)模變化時(shí)，遷移數(shù)據(jù)問(wèn)題。

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

Range動(dòng)態(tài)分區(qū)用在NewSQL架構(gòu)的分布式數(shù)據(jù)庫(kù)中，一般具有下面的特性：

4.1 自動(dòng)合并和拆分

可以給分配的數(shù)據(jù)量設(shè)置閾值，當(dāng)某個(gè)分片的數(shù)據(jù)量超過(guò)最大閾值時(shí)，可以自動(dòng)拆分成2個(gè)分片，當(dāng)分片數(shù)據(jù)量小于最小閾值時(shí)，進(jìn)行分片合并。

4.2 自動(dòng)負(fù)載

當(dāng)某個(gè)分片上的熱點(diǎn)數(shù)據(jù)較多時(shí)，節(jié)點(diǎn)訪問(wèn)壓力會(huì)很大，系統(tǒng)可以自動(dòng)地將這些熱點(diǎn)數(shù)據(jù)訪問(wèn)調(diào)度到不同節(jié)點(diǎn)，以均衡訪問(wèn)壓力。

4.3 減少分布式事務(wù)

分布式事務(wù)的開銷會(huì)遠(yuǎn)遠(yuǎn)大于本地事務(wù)，分布式數(shù)據(jù)庫(kù)可以把頻繁參與同一個(gè)分布式事務(wù)的數(shù)據(jù)調(diào)度到同一個(gè)分片上，這樣就避開了分布式事務(wù)。

Spanner支持

4.4 就近訪問(wèn)

在全球部署的場(chǎng)景下，給用戶分配最近節(jié)點(diǎn)的分片，可以減少訪問(wèn)延時(shí)。

Spanner支持

4.5 高可靠

分布式數(shù)據(jù)庫(kù)的高可靠是分區(qū)級(jí)別的高可靠，下圖是OceanBase中一個(gè)Zone的架構(gòu)圖：

OceanBase基于Paxos算法來(lái)實(shí)現(xiàn)系統(tǒng)的高可用，最小的粒度可以做到分區(qū)級(jí)別。集群中數(shù)據(jù)的每一個(gè)分區(qū)會(huì)被保存到所有的Zone上，分區(qū)的多個(gè)副本采用Paxos協(xié)議進(jìn)行日志同步。每個(gè)分區(qū)和它的副本構(gòu)成一個(gè)獨(dú)立的Paxos復(fù)制組，其中一個(gè)分區(qū)為L(zhǎng)eader，其它分區(qū)為Follower。所有針對(duì)這個(gè)副本的寫請(qǐng)求，都會(huì)自動(dòng)路由到對(duì)應(yīng)的主分區(qū)上進(jìn)行。主分區(qū)可以分布在不同的OBServer上，這樣對(duì)于不同副本的寫操作也會(huì)分布到不同的數(shù)據(jù)節(jié)點(diǎn)上，從而實(shí)現(xiàn)數(shù)據(jù)多點(diǎn)寫入，提高系統(tǒng)性能。

5 percalator模型

分布式數(shù)據(jù)庫(kù)是在BigTable基礎(chǔ)上增加了分布式事務(wù)解決方案。而Percolator模型就是Google提出的構(gòu)建在BigTable之上的分布式事務(wù)解決方案。參考2^[2]

percalator模型采用了2階段提交的思想，這里以銀行匯款為例，賬戶1給賬戶2匯款100元，這2個(gè)賬戶位于不同的分區(qū)上。

5.1 初始狀態(tài)

初始階段，假如初始時(shí)賬戶1上有300元，賬戶2上有500元，如下圖：

上面表格中，":"前面是用時(shí)間戳表示的數(shù)據(jù)版本，后面是數(shù)據(jù)值。第一列是表名，第二列的低版本保存了數(shù)據(jù)，第三列列保存了數(shù)據(jù)上加的鎖。第四列的高版本保存了指向保存數(shù)據(jù)版本的指針，比如6這個(gè)版本保存了指向了5這個(gè)版本數(shù)據(jù)的指針 6:data@5。

5.2 Prewrite

事務(wù)管理器向兩個(gè)分片發(fā)送了Prepare請(qǐng)求，分片收到請(qǐng)求后，為每個(gè)要修改的數(shù)據(jù)行寫日志，并且根據(jù)時(shí)間戳記錄事務(wù)的私有版本，這里的私有版本就是7，這樣就獲得了鎖，其他事務(wù)就不能操作這兩條數(shù)據(jù)了。

如下圖：

從第二列的數(shù)據(jù)可以看到，賬戶1上減少了200元，賬戶2上增加600元。從第三列可以看到賬戶1獲得了primary lock，賬戶2上是指向primary lock的鎖指針。

注意:primary lock的選擇是隨機(jī)的，賬戶1和賬戶2都可以選擇。

5.3 commit

commit階段，協(xié)調(diào)節(jié)點(diǎn)只需要跟擁有primary lock的分片進(jìn)行通信，這里只需要跟賬戶1進(jìn)行通信，從而保證了commit指令的原子性。這時(shí)數(shù)據(jù)如下表：

可以看到賬戶1的primary lock已經(jīng)清除了，同時(shí)增加了8這個(gè)版本，8這個(gè)版本的數(shù)據(jù)指向版本7。這樣7、8兩個(gè)版本都不是私有版本了，其他事務(wù)就可以操作這條記錄了。

私有版本還有一個(gè)作用，就是賬戶1提交失敗后，賬戶2可以根據(jù)私有版本進(jìn)行回滾。

5.4 事務(wù)結(jié)束

commit成功后并沒(méi)有同步清除賬戶2上的私有版本和鎖指針，而是會(huì)啟動(dòng)異步線程來(lái)清除，異步線程清除完成后，最終數(shù)據(jù)如下圖：

可以看到，最終賬戶2清除了鎖指針和私有版本。

賬戶2上的lock沒(méi)有同步清除，其他線程讀取賬戶2時(shí)會(huì)根據(jù)[email protected]查找primary lock，如果發(fā)現(xiàn)primary lock已經(jīng)清除，就可以繼續(xù)讀取。讀取的同時(shí)做一下secondary lock清理工作。

6 總結(jié)

本文主要從5個(gè)方面入手講了分布式數(shù)據(jù)庫(kù)的關(guān)鍵知識(shí)，歡迎大家批評(píng)指正。

參考資料