張鐵贏 黃 貴 章穎強(qiáng) 王劍英 胡 煒 趙殿奎 何登成

(阿里巴巴集團(tuán) 杭州 310023)(tieying.zhang@alibaba-inc.com)

從20世紀(jì)70年代至今，關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)已經(jīng)發(fā)展了40余年.隨著計(jì)算機(jī)系統(tǒng)硬件的迅猛發(fā)展，基于傳統(tǒng)硬件體系結(jié)構(gòu)的數(shù)據(jù)庫(kù)系統(tǒng)很難發(fā)揮出應(yīng)有的性能.同時(shí)，互聯(lián)網(wǎng)時(shí)代的到來(lái)對(duì)傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)提出了新的挑戰(zhàn).阿里巴巴作為全球最大的互聯(lián)網(wǎng)商務(wù)平臺(tái)，數(shù)據(jù)庫(kù)系統(tǒng)是最重要的基礎(chǔ)軟件之一，并在某種程度上推動(dòng)了阿里巴巴技術(shù)體系的變革.阿里巴巴數(shù)據(jù)庫(kù)系統(tǒng)經(jīng)歷了4個(gè)階段:第1階段在阿里初創(chuàng)時(shí)期，業(yè)務(wù)體量相對(duì)較小，數(shù)據(jù)庫(kù)架構(gòu)為單機(jī)房MySQL單機(jī)數(shù)據(jù)庫(kù).第2階段，隨著阿里巴巴業(yè)務(wù)的快速發(fā)展，單機(jī)房單機(jī)數(shù)據(jù)庫(kù)的架構(gòu)已成為瓶頸，阿里巴巴將單機(jī)MySQL升級(jí)為單城市多機(jī)房IOE體系，瓶頸得以暫時(shí)緩解.第3階段，單城市的容災(zāi)風(fēng)險(xiǎn)和商業(yè)IOE的成本逐漸成為風(fēng)險(xiǎn)點(diǎn)，阿里巴巴開發(fā)了基于MySQL的優(yōu)化分支，并基于該分支實(shí)現(xiàn)了一整套異地多活架構(gòu).第4階段，新硬件的不斷出現(xiàn)，數(shù)據(jù)庫(kù)向高效能、一體化、軟硬件協(xié)同設(shè)計(jì)發(fā)展，阿里巴巴的數(shù)據(jù)庫(kù)技術(shù)也進(jìn)入了全新的階段.

本文介紹阿里巴巴新一代分布式數(shù)據(jù)庫(kù)系統(tǒng)X-DB.基于大規(guī)模業(yè)務(wù)場(chǎng)景需求，X-DB充分利用新硬件的特性，圍繞存儲(chǔ)、網(wǎng)絡(luò)、多核、分布式和異構(gòu)計(jì)算進(jìn)行軟硬一體協(xié)同設(shè)計(jì)，同時(shí)兼容MySQL生態(tài)，重塑關(guān)系型數(shù)據(jù)庫(kù)體系結(jié)構(gòu).

1 背景與相關(guān)工作

數(shù)據(jù)庫(kù)領(lǐng)域發(fā)展至今，經(jīng)歷了3個(gè)重要時(shí)期:

第1個(gè)時(shí)期起源于1970年Codd博士提出的關(guān)系模型[1].在關(guān)系模型中，Codd論述了范式理論和關(guān)系系統(tǒng).在此之前，網(wǎng)狀模型和層次模型可以解決數(shù)據(jù)集中和共享的問(wèn)題，但是在數(shù)據(jù)抽象上仍然有很大欠缺，用戶需要明確數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu)、存取路徑等.關(guān)系模型的出現(xiàn)較好地解決了這些問(wèn)題，其具有嚴(yán)格的數(shù)學(xué)基礎(chǔ)，抽象級(jí)別較高，并且簡(jiǎn)單清晰，便于理解和實(shí)現(xiàn)，很快成為數(shù)據(jù)庫(kù)市場(chǎng)的主流，造就了一批早期的數(shù)據(jù)庫(kù)巨頭，如IBM DB2，Microsoft SQLServer，Oracle，Sybase等.

第2個(gè)重要時(shí)期是2000年以后，隨著互聯(lián)網(wǎng)的快速發(fā)展，低成本的橫向擴(kuò)展成為數(shù)據(jù)庫(kù)的首要需求，NoSQL數(shù)據(jù)庫(kù)應(yīng)運(yùn)而生.典型的系統(tǒng)如BigTable[2]，HBase[3]，Cassandra[4]，DynamoDB[5]，MongoDB[6]等.這一類數(shù)據(jù)庫(kù)系統(tǒng)與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)最大的區(qū)別是犧牲了事務(wù)特性(ACID)，從而不提供或僅提供有限的SQL功能.訪問(wèn)模式較為單一，功能有限.NoSQL數(shù)據(jù)庫(kù)出現(xiàn)的根本原因是互聯(lián)網(wǎng)快速發(fā)展需求與傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)擴(kuò)展性不強(qiáng)的矛盾導(dǎo)致的.

第3個(gè)重要時(shí)期開始于2008年前后，Harizopoulos等人發(fā)表了論文[7]，其明確指出新硬件的出現(xiàn)提供了傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)變革的基礎(chǔ)，并在數(shù)據(jù)庫(kù)系統(tǒng)Shore[8]上進(jìn)行了數(shù)據(jù)庫(kù)關(guān)鍵模塊的成本分析，指明了研究方向.這一時(shí)期，我們稱之為“現(xiàn)代數(shù)據(jù)庫(kù)”的元年.在此之后，工業(yè)界和學(xué)術(shù)界圍繞“現(xiàn)代數(shù)據(jù)庫(kù)”展開了一些列的研究，主要集中在多核(眾核)[9-12]、多CPU(NUMA)[13-14]、內(nèi)存[15-16]、NVM[17-20]、網(wǎng)絡(luò)(RDMA)[21-24]等.其中，對(duì)業(yè)界產(chǎn)生深遠(yuǎn)影響的數(shù)據(jù)庫(kù)系統(tǒng)有HStore[25](VoltDB[26]為其商業(yè)版本)、Hyper[27-28]、HANA[29]、Hekaton[30]、Spanner[31]等.阿里巴巴X-DB便屬于這一時(shí)期的現(xiàn)代數(shù)據(jù)庫(kù).

X-DB充分利用新硬件的特性，基于大規(guī)模業(yè)務(wù)需求，圍繞存儲(chǔ)、網(wǎng)絡(luò)、多核、分布式和異構(gòu)計(jì)算進(jìn)行軟硬一體協(xié)同設(shè)計(jì)，同時(shí)兼容MySQL生態(tài)，重塑關(guān)系型數(shù)據(jù)庫(kù)體系結(jié)構(gòu).本文介紹了X-DB的設(shè)計(jì)理念和軟硬一體模塊，給出了相應(yīng)測(cè)試結(jié)果并加以分析，證明了X-DB設(shè)計(jì)的有效性.

2 X-DB系統(tǒng)設(shè)計(jì)

本節(jié)主要闡述阿里巴巴X-DB數(shù)據(jù)庫(kù)的系統(tǒng)架構(gòu)和設(shè)計(jì)思想.

2.1 設(shè)計(jì)概要

X-DB定位為金融級(jí)全球可部署分布式數(shù)據(jù)庫(kù).金融級(jí)表明X-DB面向交易類型，支持多種隔離級(jí)，不僅可用于阿里巴巴大規(guī)模線上交易場(chǎng)景，還可以用于銀行、證券等金融機(jī)構(gòu)多種交易類型；全球可部署的含義為不同地理位置部署多副本，可以理解為通常所說(shuō)的異地多活.但不同于傳統(tǒng)Oracle或者M(jìn)ySQL的備份機(jī)制，X-DB采用的是一體化設(shè)計(jì)的數(shù)據(jù)強(qiáng)一致多副本.其目的是提供簡(jiǎn)單高效的數(shù)據(jù)庫(kù)運(yùn)維方案，同時(shí)保障數(shù)據(jù)的高可用和強(qiáng)一致.

X-DB分布式數(shù)據(jù)庫(kù)采用單數(shù)據(jù)庫(kù)實(shí)例多租戶多數(shù)據(jù)庫(kù)管理模式，通過(guò)租戶來(lái)進(jìn)行資源分配.X-DB只包含一個(gè)數(shù)據(jù)庫(kù)實(shí)例，在數(shù)據(jù)庫(kù)實(shí)例中可以創(chuàng)建多個(gè)租戶，每個(gè)租戶中可以創(chuàng)建多個(gè)數(shù)據(jù)庫(kù)和多個(gè)用戶.租戶是X-DB資源分配和資源隔離的基本單位，可以為每個(gè)租戶分配不同的系統(tǒng)物理資源(CPU、內(nèi)存、IOPS、磁盤空間、網(wǎng)絡(luò)帶寬等)，租戶間的資源是完全隔離的(不可相互占用).每個(gè)租戶可以指定表數(shù)據(jù)的默認(rèn)位置和副本位置.

Fig. 1 X-DB architecture圖1 X-DB系統(tǒng)架構(gòu)

圖1為X-DB的系統(tǒng)架構(gòu)圖.X-DB提供跨Zone和跨Region的數(shù)據(jù)強(qiáng)一致副本方案.數(shù)據(jù)分片為share-nothing的切分方式，每個(gè)分片即為Partition(圖1中P1，P2，P3,…).數(shù)據(jù)一致性使用X-DB優(yōu)化的Paxos協(xié)議(X-Paxos)作為保障.使用X-Paxos進(jìn)行強(qiáng)一致副本同步和選主，參與的所有成員構(gòu)成一個(gè)Paxos Group，其中選主成功的副本稱為L(zhǎng)eader，其他副本每一個(gè)都稱為Follower，任意時(shí)刻只有Leader對(duì)外提供讀寫服務(wù)，F(xiàn)ollower同步Leader數(shù)據(jù).每組Paxos Group至少需要3個(gè)參與成員.Router Service(SQL路由服務(wù))緩存表的分片位置信息和節(jié)點(diǎn)負(fù)載信息，然后根據(jù)SQL的分區(qū)鍵進(jìn)行節(jié)點(diǎn)路由.可與X-Driver進(jìn)行集成作為X-DB專有驅(qū)動(dòng)部署在客戶端，也可以獨(dú)立部署在云端，支持標(biāo)準(zhǔn)的MySQL驅(qū)動(dòng)的客戶端.對(duì)于確定的分區(qū)鍵條件則直接路由到數(shù)據(jù)所在的節(jié)點(diǎn).對(duì)于不確定的分區(qū)鍵或無(wú)分區(qū)鍵條件的SQL則根據(jù)負(fù)載和就近計(jì)算原則進(jìn)行節(jié)點(diǎn)選擇.

數(shù)據(jù)存儲(chǔ)使用了X-DB的數(shù)據(jù)引擎X-Engine.X-Engine包含了高效的內(nèi)存索引結(jié)構(gòu)，寫入異步流水線處理機(jī)制以及一系列與硬件結(jié)合加速引擎性能的技術(shù)(將在第3節(jié)詳細(xì)論述).同時(shí)，X-DB也可以使用計(jì)算存儲(chǔ)分離的方式，即無(wú)縫插拔阿里巴巴的分布式存儲(chǔ)系統(tǒng)PANGU.使用這種方式(計(jì)算存儲(chǔ)分離)解決了數(shù)據(jù)庫(kù)的快速?gòu)椥陨炜s能力和存儲(chǔ)的可擴(kuò)展能力.

2.2 系統(tǒng)模塊

本節(jié)我們介紹X-DB主要的系統(tǒng)模塊，包括存儲(chǔ)引擎、內(nèi)存索引、并發(fā)控制和混合存儲(chǔ)格式.

2.2.1 存儲(chǔ)引擎

X-DB的存儲(chǔ)引擎稱之為X-Engine.X-Engine使用分層存儲(chǔ)的理念，利用數(shù)據(jù)不同的訪問(wèn)特點(diǎn)，采用相對(duì)應(yīng)的存儲(chǔ)格式，存放在適合的存儲(chǔ)介質(zhì)上，從整體上降低存儲(chǔ)成本.X-Engine借鑒了LSM-Tree[32]思想，寫入的數(shù)據(jù)不會(huì)直接替換掉已有的數(shù)據(jù)，而是追加的方式寫入內(nèi)存表，并寫入WAL(write ahead log)，內(nèi)存表寫入到一定尺寸會(huì)Flush到存儲(chǔ)，寫為有序只讀的SST(sorted string table)文件，當(dāng)SST堆積到一定數(shù)量后，通過(guò)合并操作將相同Key的多個(gè)版本合并掉(只保持活躍事務(wù)引用的多版本，其他不再引用的只保留最新版本)，保持盡可能少的SST文件.

本質(zhì)上來(lái)說(shuō)，這種存儲(chǔ)結(jié)構(gòu)是延遲了寫入刷盤的操作，把所有的隨機(jī)寫入轉(zhuǎn)換為順序追加操作，同時(shí)使用后臺(tái)任務(wù)批量將數(shù)據(jù)寫入磁盤，避免了傳統(tǒng)存儲(chǔ)引擎由于大量隨機(jī)寫頻繁刷臟頁(yè)帶來(lái)的寫入放大的問(wèn)題.這種結(jié)構(gòu)對(duì)大量寫入是非常友好的，使得我們?cè)谔嵘龜?shù)據(jù)庫(kù)寫入吞吐上有機(jī)會(huì)做大量的優(yōu)化，比起基于固定大小頁(yè)面的傳統(tǒng)存儲(chǔ)引擎來(lái)說(shuō)，寫入速度有了量級(jí)的提升；但是伴隨而來(lái)的的代價(jià)是讀取路徑變長(zhǎng)，以及比單純刷臟頁(yè)更重量級(jí)的合并操作.

由于數(shù)據(jù)量的不斷膨脹，很多應(yīng)用每天新寫入的數(shù)據(jù)量以TB計(jì)，而數(shù)據(jù)的熱點(diǎn)非常明顯，使用同一種設(shè)備或是方法來(lái)存儲(chǔ)數(shù)據(jù)是一種浪費(fèi)，而使用不同的存儲(chǔ)系統(tǒng)來(lái)存儲(chǔ)數(shù)據(jù)，又不得不面臨多份數(shù)據(jù)搬遷同步，應(yīng)用面對(duì)異構(gòu)系統(tǒng)的復(fù)雜性等額外問(wèn)題；因此在一套系統(tǒng)中使用混合存儲(chǔ)成為一種必然.X-Engine的核心理念依然是根據(jù)數(shù)據(jù)的冷熱程度對(duì)數(shù)據(jù)分層，以最大程度的匹配當(dāng)前多種不同的存儲(chǔ)介質(zhì)，對(duì)不同熱度的數(shù)據(jù)使用不同的存儲(chǔ)方法，以求在存儲(chǔ)成本和性能之間取得平衡，獲取最大收益.

2.2.2 內(nèi)存索引

內(nèi)存表是數(shù)據(jù)寫入的第一落入點(diǎn)，也是元數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)，要求讀寫都有極高的并發(fā)吞吐，X-Engine采用了Lock-Free(無(wú)鎖)SkipList.SkipList相對(duì)于B-Tree來(lái)說(shuō)，實(shí)現(xiàn)比較簡(jiǎn)單，沒(méi)有B-Tree的節(jié)點(diǎn)分裂操作，容易實(shí)現(xiàn)為L(zhǎng)ock-Free，缺點(diǎn)是因?yàn)閿?shù)據(jù)是用鏈表鏈接起來(lái)，相鄰的數(shù)據(jù)沒(méi)有存儲(chǔ)在連續(xù)的內(nèi)存中，因此CPU cache miss會(huì)比較高.我們比較過(guò)一些內(nèi)存索引數(shù)據(jù)結(jié)構(gòu)的性能: SkipList, B-Tree, MassTree[33],Bw-Tree[34]，目前的實(shí)現(xiàn)中MassTree性能最好，MassTree是一個(gè)B-Tree組成的前綴樹，使每個(gè)節(jié)點(diǎn)適配cache line，利用prefetch加速，獲得比較好的性能.但MassTree在穩(wěn)定性上依然有問(wèn)題，是我們下一步的優(yōu)化實(shí)現(xiàn)的方向.

2.2.3 并發(fā)控制

目前主要的MVCC技術(shù)有2種:

1) 基于兩階段鎖(two phase lock).事務(wù)開始時(shí)對(duì)數(shù)據(jù)集加鎖，事務(wù)提交以后放鎖.不同的隔離級(jí)別，加鎖類型和時(shí)機(jī)不同.對(duì)于只讀事務(wù)，為了提高性能，通常并不加鎖，而是采用快照讀(snapshot read)的方式，在事務(wù)開始時(shí)取得全局已提交事務(wù)的版本，在讀的過(guò)程中通過(guò)可見性判斷，讀取這個(gè)版本之前的已提交數(shù)據(jù).X-DB對(duì)只讀事務(wù)的可見性判斷比較簡(jiǎn)單，存儲(chǔ)的所有數(shù)據(jù)都是多版本的，每次寫事務(wù)開始都會(huì)為每條數(shù)據(jù)分配一個(gè)唯一的遞增的事務(wù)版本號(hào)，寫事務(wù)提交之后更新全局事務(wù)號(hào)；每個(gè)只讀事務(wù)開始前會(huì)讀取當(dāng)前全局的事務(wù)號(hào)，然后與查詢到的數(shù)據(jù)進(jìn)行版本號(hào)的比較，取小于等于讀事務(wù)版本號(hào)并且在所有版本中最大的那一條記錄.

2) 樂(lè)觀并發(fā)控制(optimistic concurrency control, OCC).事務(wù)開始之前計(jì)算事務(wù)涉及的數(shù)據(jù)集(WriteSet & ReadSet)，事務(wù)執(zhí)行的過(guò)程不加鎖，提交前對(duì)WriteSet和ReadSet進(jìn)行校驗(yàn)(Validate)，如果有其他的事務(wù)對(duì)當(dāng)前事務(wù)的數(shù)據(jù)集進(jìn)行了更新，則回滾當(dāng)前事務(wù)并進(jìn)行重試，否則提交事務(wù).OCC適用于事務(wù)之間數(shù)據(jù)沖突很少的場(chǎng)景，在此種場(chǎng)景下事務(wù)的吞吐量會(huì)高于Lock-Based MVCC，但在熱點(diǎn)行沖突比較多的情況下，會(huì)產(chǎn)生大量的事務(wù)回滾重試，性能大大退化.

X-DB同時(shí)支持2種并發(fā)控制技術(shù)，可以根據(jù)應(yīng)用的特點(diǎn)進(jìn)行選擇，在熱點(diǎn)沖突很少的應(yīng)用場(chǎng)景，我們可以選用OCC，反之在熱點(diǎn)沖突明顯的場(chǎng)景，則適用基于鎖的并發(fā)控制.

2.2.4 混合存儲(chǔ)格式

互聯(lián)網(wǎng)龐大的數(shù)據(jù)量帶來(lái)高昂的存儲(chǔ)成本，因此對(duì)數(shù)據(jù)進(jìn)行高效的壓縮，提升數(shù)據(jù)存儲(chǔ)密度成為一個(gè)重要議題；另外,數(shù)據(jù)庫(kù)需要在各種負(fù)載上運(yùn)行，傳統(tǒng)的OLTPOLAP的界限不再清晰，用戶總是希望在一份數(shù)據(jù)上執(zhí)行所有種類的請(qǐng)求，HTAP(hybrid transactionanalytical processing)應(yīng)運(yùn)而生.

X-DB面向的主要業(yè)務(wù)場(chǎng)景是OLTP，主要格式還是按行存儲(chǔ)，不過(guò)為了求取更好的壓縮比率，在局部使用了按列存儲(chǔ)的格式，在這個(gè)基礎(chǔ)上，X-DB使用了基于列編碼進(jìn)行壓縮的方式替代通用壓縮算法進(jìn)行壓縮，是因?yàn)橥ㄓ脡嚎s算法并不關(guān)心數(shù)據(jù)的行列結(jié)構(gòu)，一旦進(jìn)行壓縮以后，原有的結(jié)構(gòu)被完全破壞掉，無(wú)法在壓縮的數(shù)據(jù)上進(jìn)行直接查詢.而X-DB的存儲(chǔ)引擎存儲(chǔ)了數(shù)據(jù)表的schema，可以按schema解釋數(shù)據(jù)的行列結(jié)構(gòu)，識(shí)別每一列的數(shù)據(jù)類型和數(shù)據(jù)的特點(diǎn)尋求更合適的編碼方式進(jìn)行壓縮，取得更好的壓縮比，更關(guān)鍵的是，進(jìn)行壓縮編碼后的數(shù)據(jù)仍然是有結(jié)構(gòu)的，無(wú)需解壓縮即可直接查詢.

3 軟硬一體設(shè)計(jì)

在本節(jié)中，我們?cè)敿?xì)介紹X-DB中軟硬一體模塊的設(shè)計(jì)和實(shí)現(xiàn).

3.1 基于FPGAQAT的數(shù)據(jù)compaction設(shè)計(jì)

X-DB的存儲(chǔ)結(jié)構(gòu)都是基于Copy-On-Write實(shí)現(xiàn)的，所有的修改操作都是寫入新版本增量數(shù)據(jù)，所以無(wú)論是寫入數(shù)據(jù)還是修改元數(shù)據(jù)，都是可以在后臺(tái)進(jìn)行的，對(duì)讀寫操作沒(méi)有影響.X-Engine會(huì)存儲(chǔ)數(shù)據(jù)的多個(gè)版本用于MVCC，在compaction過(guò)程中會(huì)對(duì)不再被事務(wù)所引用的舊數(shù)據(jù)版本進(jìn)行回收.

compaction過(guò)程本身是非常占用系統(tǒng)資源的，需要對(duì)不同級(jí)別之間key range范圍交叉的文件進(jìn)行多路歸并.首先讀取文件所有內(nèi)容，解析所有的行，消耗大量IO;然后進(jìn)行大量的key compare操作，消耗CPU; 最后寫入結(jié)果，同樣占用IO帶寬. 在開啟全速compaction的情況下，寫入性能下降約40%.

為了減少compaction對(duì)系統(tǒng)性能的沖擊，X-DB從多個(gè)方面對(duì)其進(jìn)行優(yōu)化，其中很重要的一點(diǎn)是利用FPGAQAT對(duì)數(shù)據(jù)進(jìn)行壓縮和解壓縮.

得益于新型存儲(chǔ)設(shè)備的IO能力大幅上升，compaction過(guò)程中對(duì)存儲(chǔ)IO能力的占用問(wèn)題得到一定緩解，但是對(duì)CPU資源的消耗對(duì)普通事務(wù)造成的影響愈發(fā)突出.為了解決根本問(wèn)題，X-DB針對(duì)compaction完全異步化的特點(diǎn)，將compaction任務(wù)放到FPGAQAT設(shè)備上執(zhí)行的方案(如圖2所示).

數(shù)據(jù)compaction的過(guò)程在本質(zhì)上是一個(gè)多路歸并操作，X-DB將其抽象為一個(gè)多路datablocks按一定規(guī)則合并為一路datablocks的過(guò)程；FPGA內(nèi)部的流水線可以將數(shù)據(jù)的讀取解碼合并編碼同時(shí)執(zhí)行，可以提供單路處理達(dá)2 GBps的性能，遠(yuǎn)優(yōu)于CPU自己做compaction操作；同時(shí)可以將compaction中非常耗費(fèi)CPU的通用壓縮操作也一并完成，最終CPU在這個(gè)階段只負(fù)責(zé)數(shù)據(jù)的IO.

Fig. 2 Data compaction in X-DB圖2 X-DB數(shù)據(jù)compaction

3.2 RDMA協(xié)同下的數(shù)據(jù)傳輸方案

X-DB擁有分布式強(qiáng)一致能力，內(nèi)部通過(guò)Paxos算法實(shí)現(xiàn)多個(gè)數(shù)據(jù)庫(kù)副本之間的數(shù)據(jù)強(qiáng)一致.傳統(tǒng)的Paxos依賴于操作系統(tǒng)內(nèi)核協(xié)議棧的套接字實(shí)現(xiàn)數(shù)據(jù)通信.在重負(fù)載情況下，多個(gè)副本之間的數(shù)據(jù)通信任務(wù)的并發(fā)和吞吐都非常大，不但占用了大量的系統(tǒng)資源，同時(shí)影響了數(shù)據(jù)庫(kù)的響應(yīng)時(shí)間.

為了提升數(shù)據(jù)傳輸?shù)男阅埽瑫r(shí)降低其對(duì)系統(tǒng)資源的消耗，X-DB從多個(gè)方面進(jìn)行了優(yōu)化，其中非常重要的一個(gè)方面是利用RDMA(remote direct memory access)優(yōu)化了日志寫入和數(shù)據(jù)傳輸流程.RDMA是一種遠(yuǎn)程數(shù)據(jù)直接存取技術(shù)，需要網(wǎng)絡(luò)適配器以及其他網(wǎng)絡(luò)基礎(chǔ)設(shè)施的支持.通過(guò)結(jié)合RDMA技術(shù)，數(shù)據(jù)庫(kù)可以像訪問(wèn)本地內(nèi)存一樣訪問(wèn)遠(yuǎn)程節(jié)點(diǎn)的內(nèi)存，避免了數(shù)據(jù)拷貝和上下文切換，整個(gè)傳輸過(guò)程由硬件實(shí)現(xiàn)，不需要CPU和操作系統(tǒng)參與.

X-DB通過(guò)利用RDMA能大幅度降低系統(tǒng)資源消耗，同時(shí)降低了Paxos達(dá)成一致過(guò)程的時(shí)延，從而降低查詢響應(yīng)時(shí)間.Paxos協(xié)議達(dá)成一致過(guò)程中的網(wǎng)路通信，可以抽象成將Proposer上的日志復(fù)制到法定多數(shù)派的節(jié)點(diǎn)上并持久化，同時(shí)將當(dāng)前節(jié)點(diǎn)狀態(tài)匯報(bào)給Proposer.其中最主要日志的復(fù)制過(guò)程需要經(jīng)過(guò)內(nèi)存拷貝、內(nèi)核態(tài)協(xié)議棧組裝發(fā)送等過(guò)程，是當(dāng)前的主要瓶頸.RDMA的One-Side API中提供了Remote Write原語(yǔ)，可以不需要操作系統(tǒng)內(nèi)核CPU的參與，將本地內(nèi)存中的內(nèi)容復(fù)制到遠(yuǎn)程內(nèi)存中.我們?cè)赬-DB中設(shè)計(jì)了高效的日志緩存數(shù)據(jù)結(jié)構(gòu)，對(duì)RDMA支持友好；同時(shí)使用了Remote Write原語(yǔ)實(shí)現(xiàn)日志復(fù)制和消息匯報(bào)過(guò)程，不但降低了CPU負(fù)載，同時(shí)降低了時(shí)延，提升了數(shù)據(jù)庫(kù)的響應(yīng)速度.

3.3 X-DB的存儲(chǔ)引擎重構(gòu)

基于阿里巴巴大規(guī)模的應(yīng)用需求，我們觀察到數(shù)據(jù)的冷熱特性是非常明顯的，而且與時(shí)間相關(guān).隨著時(shí)間的流逝，越是久遠(yuǎn)的數(shù)據(jù)訪問(wèn)的頻度越低.因此，X-DB的存儲(chǔ)引擎中使用了分層存儲(chǔ)的結(jié)構(gòu).我們將整個(gè)存儲(chǔ)體系劃分為多個(gè)層級(jí)，每一級(jí)使用不同的存儲(chǔ)介質(zhì)，存儲(chǔ)不同熱度的數(shù)據(jù)，并且使用不同的存儲(chǔ)格式.訪問(wèn)熱度比較低的數(shù)據(jù)，存儲(chǔ)在慢速介質(zhì)中，使用高壓縮的方式；與此對(duì)應(yīng)，訪問(wèn)熱度較高的數(shù)據(jù)，存儲(chǔ)在低延時(shí)高吞吐的存儲(chǔ)介質(zhì)中，采用高效的索引方式.在設(shè)計(jì)中，我們首先將數(shù)據(jù)庫(kù)所有的寫入更新都以追加的方式寫入內(nèi)存，在內(nèi)存中建立了一套高效的無(wú)鎖索引結(jié)構(gòu)來(lái)存儲(chǔ)這些更新數(shù)據(jù)，這一層被認(rèn)為是最熱的數(shù)據(jù)，因?yàn)榇蟛糠謶?yīng)用都會(huì)傾向讀最近寫入的數(shù)據(jù)；內(nèi)存中的數(shù)據(jù)也是分層的，越新近寫入的數(shù)據(jù)，層級(jí)越高，內(nèi)存不足時(shí)，將相對(duì)低層級(jí)的數(shù)據(jù)寫出到下一級(jí)存儲(chǔ)中，形成一個(gè)新的層級(jí)，我們稱為L(zhǎng)0,這一層級(jí)的數(shù)據(jù)仍然被認(rèn)為是熱度較高的數(shù)據(jù)，采用NVM(non-volatile memory)的存儲(chǔ)介質(zhì)，L0層的數(shù)據(jù)充當(dāng)了內(nèi)存交換區(qū)(swap)的角色，需要頻繁讀取，而且這一層數(shù)據(jù)也會(huì)逐漸變大，需要定期與更低層級(jí)的數(shù)據(jù)進(jìn)行合并，選用NVM提供更低的讀延時(shí)和更大的IO帶寬.更低層級(jí)的數(shù)據(jù)屬于相對(duì)熱度比較冷的數(shù)據(jù)，這其中也分為若干層次(L1L2)，每一層都分割為固定大小的塊(extent)，每個(gè)層次的塊大小不同，使用統(tǒng)一的索引結(jié)構(gòu).L1以下所有層的數(shù)據(jù)會(huì)根據(jù)讀寫訪問(wèn)的頻率進(jìn)行分類識(shí)別，按extent為單位進(jìn)行統(tǒng)計(jì)，較熱的數(shù)據(jù)塊會(huì)存放在SSD中，使用性能比較高的壓縮算法(Snappy, LZ4, Zstd自動(dòng)適配).而最冷的數(shù)據(jù)塊會(huì)存放在HDD中，因?yàn)槠錁O少被訪問(wèn)，使用按列編碼，再進(jìn)行高壓縮率的壓縮方式存儲(chǔ).采用分層存儲(chǔ)結(jié)構(gòu)，X-DB可以降低綜合存儲(chǔ)成本，并且保證性能不會(huì)下降.

4 實(shí)驗(yàn)與結(jié)果

Fig. 4 compaction performance of QAT and CPU圖4 QAT和CPU壓縮測(cè)試對(duì)比

在本節(jié)中，我們基于本文提出的設(shè)計(jì)和實(shí)現(xiàn)，給出了X-DB存儲(chǔ)引擎的測(cè)試結(jié)果；同時(shí)，我們也給出基于QAT的數(shù)據(jù)壓縮測(cè)試結(jié)果并加以分析.測(cè)試機(jī)型均為CPU:64core, DRAM:512 GB, Disk: NVME SSD 7T, NIC:10Gb.

4.1 X-DB存儲(chǔ)引擎

在本測(cè)試中，我們使用MySQL生態(tài)通用的測(cè)試集Sysbench[35].表數(shù)量設(shè)置為10，每個(gè)表包含20萬(wàn)條記錄，并發(fā)連接數(shù)量為1 000，每個(gè)事務(wù)包含一條讀或?qū)懖僮?讀寫混合測(cè)試中，讀寫比為10∶4.

圖3給出了Sysbench在吞吐率上的測(cè)試結(jié)果.Read-only方面，X-DB存儲(chǔ)引擎對(duì)MySQL(InnoDB)有超過(guò)1倍的提升；Write-only上超過(guò)5倍的提升；讀寫混合下約有2.5倍的提升.相對(duì)于InnoDB，X-DB存儲(chǔ)引擎將更新寫入到高效內(nèi)存索引中，沒(méi)有基于頁(yè)面的原地更新，只需要記錄Redo日志，而無(wú)需Undo日志，大大簡(jiǎn)化了事務(wù)處理的邏輯；同時(shí)大部分熱數(shù)據(jù)是在內(nèi)存中，使用是無(wú)鎖的數(shù)據(jù)結(jié)構(gòu)，相對(duì)于頁(yè)面掃描提取數(shù)據(jù)來(lái)說(shuō)，在熱點(diǎn)讀性能上更為高效.該項(xiàng)測(cè)試是使用CPU進(jìn)行compaction，并沒(méi)有使用FPGA或QAT(QAT測(cè)試請(qǐng)見第4.2節(jié)).

Fig. 3 Performance on Sysbench圖3 Sysbench測(cè)試結(jié)果

4.2 X-DB數(shù)據(jù)壓縮

本節(jié)中我們使用X-DB存儲(chǔ)引擎對(duì)QAT進(jìn)行了測(cè)試.QAT是Intel的數(shù)據(jù)壓縮技術(shù)，全稱為QuickAssist Technology.測(cè)試過(guò)程為隨機(jī)寫入的同時(shí)開啟數(shù)據(jù)壓縮，觀察硬件加速對(duì)數(shù)據(jù)壓縮的性能提升.

測(cè)試使用64線程并發(fā)隨機(jī)寫入，key長(zhǎng)度為8 B， value長(zhǎng)度為240 B， 10張表按主鍵隨機(jī)寫入.寫入數(shù)據(jù)為亂序，刷盤時(shí)壓縮形成數(shù)據(jù)塊.后臺(tái)compaction線程將所有數(shù)據(jù)塊讀取出來(lái)解壓并重新排序，然后壓縮輸出成全局有序的數(shù)據(jù)塊.我們對(duì)比了使用QAT壓縮和使用CPU壓縮的性能(如圖4所示).可以看到，相對(duì)使用CPU壓縮，QAT能夠獲得平均20%以上的性能提升.同時(shí)，使用QAT壓縮時(shí)，服務(wù)器CPU平均使用率更低，寫入性能更為平穩(wěn).基于QAT的測(cè)試結(jié)果，我們計(jì)劃下一步將compaction任務(wù)放到FPGA上，目前該工作正在進(jìn)行過(guò)程中.

5 總 結(jié)

本文介紹了阿里巴巴新一代數(shù)據(jù)系統(tǒng)X-DB.闡述了X-DB的設(shè)計(jì)理念和關(guān)鍵模塊的實(shí)現(xiàn)方法，特別針對(duì)軟硬件協(xié)同設(shè)計(jì)進(jìn)行了具體的分析和論述.實(shí)驗(yàn)結(jié)果表明，本文提出的設(shè)計(jì)思想以及軟硬件一體化的設(shè)計(jì)對(duì)系統(tǒng)性能有較大提升，相對(duì)于InnoDB，X-DB存儲(chǔ)引擎的讀寫有2～5倍的提升，使用QAT后，壓縮速度有了20%的提升.基于本文提出的設(shè)計(jì)思想，X-DB將進(jìn)一步融入新硬件特性，特別是在NVM、多核(多CPU)、RDMA和FPGA方面進(jìn)行更深入的探索，充分發(fā)揮新硬件特性，打造軟硬一體協(xié)同工作的新一代數(shù)據(jù)庫(kù).目前該工作正在進(jìn)行過(guò)程中.

致謝感謝阿里巴巴集團(tuán)張瑞和葉正盛對(duì)本文的指導(dǎo)!

[1]Codd E F. A relational model of data for large shared data banks[J]. Communications of the ACM, 1970, 13(6): 377-387

[2]Chang F, Dean J, Ghemawat S, et al. Bigtable: A distributed storage system for structured data[C] //Proc of the 7th USENIX Symp on Operating Systems Design and Implementation. Berkeley,CA: USENIX, 2006: 15-15

[3]Apache. Apache Hbase[EB/OL]. [2017-11-15]. https://hbase.apache.org/

[4]Apache. Apache Cassandra[EB/OL]. [2017-03-01]. http://cassandra.apache.org/

[5]Sivasubramanian S. Amazon dynamoDB: A seamlessly scalable non-relational database service[C] //Proc of the 2012 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2012: 729-730

[6]MongoDB. MongoDB[EB/OL].[2017-11-15]. https://www.mongodb.com/

[7]Harizopoulos S, Abadi D J, Madden S, et al. OLTP through the looking glass, and what we found there[C] //Proc of the 2008 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2008: 981-992

[8]Johnson R, Pandis I, Hardavellas N, et al. Shore-MT: A scalable storage manager for the multicore era[C] //Proc of the 12th Int Conf on Extending Database Technology: Advances in Database Technology. New York: ACM, 2009: 24-35

[9]Yu Xiangyao, Bezerra G, Pavlo A, et al. Staring into the abyss: An evaluation of concurrency control with one thousand cores[J]. Proceedings of the VLDB Endowment, 2014, 8(3): 209-220

[10]Jung H, Han H, Fekete A D, et al. A scalable lock manager for multicores[C] //Proc of ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2013: 73-84

[11]Porobic D, Pandis I, Branco M, et al. OLTP on hardware islands[J]. Proceedings of the VLDB Endowment, 2012, 5(11): 1447-1458

[12]Tu S, Zheng W, Kohler E, et al. Speedy transactions in multicore in-memory databases[C] //Proc of the 24th ACM Symp on Operating System. New York: ACM, 2013: 18-32

[13]Leis V, Boncz P, Kemper A, et al. Morsel-driven parallelism: A NUMA-aware query evaluation framework for the many-core age[C] //Proc of ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2014: 743-754

[14]Lang H, Leis V, Albutiu M, et al. Massively parallel NUMA-aware Hash joins[G] //LNCS 8921: Proc of IMDM 2013/2014. Berlin: Springer, 2015: 3-14

[15]Larson P A, Blanas S, Diaconu C, et al. High-performance concurrency control mechanisms for main-memory databases[J]. Proceedings of the VLDB, 2011, 5(4): 298-309

[16]Ren K, Thomson A, Abadi D J. Lightweight locking for main memory database systems[J]. Proceedings of the VLDB, 2012, 6(2): 145-156

[17]Arulraj J, Pavlo A, Dulloor S. Let’s talk about storage & recovery methods for non-volatile memory database systems[C] //Proc of the 2015 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2015: 707-722

[18]Arulraj J, Perron M, Pavlo A. Write-behind logging[J].Proceedings of the VLDB Endowment, 2016, 10(4): 337-348

[19]Arulraj J, Pavlo A. How to build a non-volatile memory database management system[C] //Proc of the 2017 ACM Int Conf on Management of Data. New York: ACM, 2017: 1753-1758

[20]Chen Shimin, Jin Qin, Persistent B+-trees in non-volatile main memory[J].Proceedings of the VLDB Endowment, 2015, 8(7): 786-797

[21]Kalia A, Kaminsky M, Andersen D. Using RDMA efficiently for key-value services[C] //Proc of ACM SIGCOMM 2014. New York: ACM, 2014: 17-22

[22]Huang J, Ouyang X, Jose J, et al. High-performance design of HBase with RDMA over InfiniBand[C] //Proc of the 26th IEEE Int Parallel and Distributed Processing Symp. Los Alamitos, CA: IEEE Computer Society, 2012: 774-785

[23]Lu X, Islam N S, Rahman M, et al. High-performance design of Hadoop RPC with RDMA over InfiniBand[C] //Proc of the 42nd Int Conf on Parallel Processing. Los Alamitos, CA: IEEE Computer Society, 2013: 641-650

[24]Mitchell C, Geng Y, Li J. Using one-sided RDMA reads to build a fast, cpu-efficient key-value store[C] //Proc of the 2013 USENIX Conf on Annual Technical Conf. Berkeley, CA: USENIX, 2013: 103-114

[25]Kallman R, Kimura H, Natkins J, et al. H-Store: A high-performance, distributed main memory transaction processing system[J]. Proceedings of the VLDB Endowment, 2008, 1(2): 1496-1499

[26]VoltDB. VoltDB[EB/OL]. [2017-03-01]. http://voltdb.com

[27]Neumann T, Mühlbauer T, Kemper A. Fast serializable multi-version concurrency control for main-memory database systems[C] //Proc of ACM SIGMOD Int Conf on Management. New York: ACM, 2015: 677-689

[28]Neumann T. Efficiently compiling efficient query plans for modern hardware[J]. Proceedings of the VLDB Endowment, 2012, 4(9): 539-550

[29]Franz F, Sang K C, Jürgen P, et al. SAP HANA database: Data management for modern business applications[J]. ACM SIGMOD Record, 2011, 40(4): 45-51

[30]Diaconu C, Freedman C, Ismert E, et al. Hekaton: SQL Server’s memory-optimized OLTP engine[C] //Proc of the 2013 ACM SIGMOD Int Conf on Management of Data. New York: ACM, 2013: 1243-1254

[31]Bacon D F, Bales N, Bruno N, et al. Spanner: Becoming a SQL system[C] //Proc of the 2017 ACM Int Conf on Management of Data. New York: ACM, 2017: 331-343

[32]O’Neil P, Cheng E, Gawlick, D, et al. The Log-structured Merge-tree (LSM-tree)[J]. Acta Informatica, 1996, 33(4): 351-385

[33]Mao Yandong, Kohler E, Morris R, et al. Cache craftiness for fast multicore key-value storage[C] //Proce of the 7th ACM European Conf on Computer Systems. New York: ACM, 2012: 183-196

[34]Levandoski J J, Lomet D B, Sengupta S. The Bw-Tree: A B-tree for new hardware platforms[C] //Proc of the 2013 IEEE Int Conf on Data Engineering (ICDE 2013). Los Alamitos, CA: IEEE Computer Society, 2013: 302-313

[35] GitHub. Sysbench[EB/OL]. [2017-10-08]. https://github.com/akopytov/sysbench