X-DB：軟硬一體的新型數據庫系統

張鐵贏 黃 貴 章穎強 王劍英 胡 煒 趙殿奎 何登成

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

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

本文介紹阿里巴巴新一代分布式數據庫系統X-DB.基于大規模業務場景需求，X-DB充分利用新硬件的特性，圍繞存儲、網絡、多核、分布式和異構計算進行軟硬一體協同設計，同時兼容MySQL生態，重塑關系型數據庫體系結構.

1 背景與相關工作

數據庫領域發展至今，經歷了3個重要時期:

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

第2個重要時期是2000年以后，隨著互聯網的快速發展，低成本的橫向擴展成為數據庫的首要需求，NoSQL數據庫應運而生.典型的系統如BigTable[2]，HBase[3]，Cassandra[4]，DynamoDB[5]，MongoDB[6]等.這一類數據庫系統與傳統關系型數據庫最大的區別是犧牲了事務特性(ACID)，從而不提供或僅提供有限的SQL功能.訪問模式較為單一，功能有限.NoSQL數據庫出現的根本原因是互聯網快速發展需求與傳統關系型數據庫擴展性不強的矛盾導致的.

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

X-DB充分利用新硬件的特性，基于大規模業務需求，圍繞存儲、網絡、多核、分布式和異構計算進行軟硬一體協同設計，同時兼容MySQL生態，重塑關系型數據庫體系結構.本文介紹了X-DB的設計理念和軟硬一體模塊，給出了相應測試結果并加以分析，證明了X-DB設計的有效性.

2 X-DB系統設計

本節主要闡述阿里巴巴X-DB數據庫的系統架構和設計思想.

2.1 設計概要

X-DB定位為金融級全球可部署分布式數據庫.金融級表明X-DB面向交易類型，支持多種隔離級，不僅可用于阿里巴巴大規模線上交易場景，還可以用于銀行、證券等金融機構多種交易類型；全球可部署的含義為不同地理位置部署多副本，可以理解為通常所說的異地多活.但不同于傳統Oracle或者MySQL的備份機制，X-DB采用的是一體化設計的數據強一致多副本.其目的是提供簡單高效的數據庫運維方案，同時保障數據的高可用和強一致.

X-DB分布式數據庫采用單數據庫實例多租戶多數據庫管理模式，通過租戶來進行資源分配.X-DB只包含一個數據庫實例，在數據庫實例中可以創建多個租戶，每個租戶中可以創建多個數據庫和多個用戶.租戶是X-DB資源分配和資源隔離的基本單位，可以為每個租戶分配不同的系統物理資源(CPU、內存、IOPS、磁盤空間、網絡帶寬等)，租戶間的資源是完全隔離的(不可相互占用).每個租戶可以指定表數據的默認位置和副本位置.

Fig. 1 X-DB architecture圖1 X-DB系統架構

圖1為X-DB的系統架構圖.X-DB提供跨Zone和跨Region的數據強一致副本方案.數據分片為share-nothing的切分方式，每個分片即為Partition(圖1中P1，P2，P3,…).數據一致性使用X-DB優化的Paxos協議(X-Paxos)作為保障.使用X-Paxos進行強一致副本同步和選主，參與的所有成員構成一個Paxos Group，其中選主成功的副本稱為Leader，其他副本每一個都稱為Follower，任意時刻只有Leader對外提供讀寫服務，Follower同步Leader數據.每組Paxos Group至少需要3個參與成員.Router Service(SQL路由服務)緩存表的分片位置信息和節點負載信息，然后根據SQL的分區鍵進行節點路由.可與X-Driver進行集成作為X-DB專有驅動部署在客戶端，也可以獨立部署在云端，支持標準的MySQL驅動的客戶端.對于確定的分區鍵條件則直接路由到數據所在的節點.對于不確定的分區鍵或無分區鍵條件的SQL則根據負載和就近計算原則進行節點選擇.

數據存儲使用了X-DB的數據引擎X-Engine.X-Engine包含了高效的內存索引結構，寫入異步流水線處理機制以及一系列與硬件結合加速引擎性能的技術(將在第3節詳細論述).同時，X-DB也可以使用計算存儲分離的方式，即無縫插拔阿里巴巴的分布式存儲系統PANGU.使用這種方式(計算存儲分離)解決了數據庫的快速彈性伸縮能力和存儲的可擴展能力.

2.2 系統模塊

本節我們介紹X-DB主要的系統模塊，包括存儲引擎、內存索引、并發控制和混合存儲格式.

2.2.1 存儲引擎

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

本質上來說，這種存儲結構是延遲了寫入刷盤的操作，把所有的隨機寫入轉換為順序追加操作，同時使用后臺任務批量將數據寫入磁盤，避免了傳統存儲引擎由于大量隨機寫頻繁刷臟頁帶來的寫入放大的問題.這種結構對大量寫入是非常友好的，使得我們在提升數據庫寫入吞吐上有機會做大量的優化，比起基于固定大小頁面的傳統存儲引擎來說，寫入速度有了量級的提升；但是伴隨而來的的代價是讀取路徑變長，以及比單純刷臟頁更重量級的合并操作.

由于數據量的不斷膨脹，很多應用每天新寫入的數據量以TB計，而數據的熱點非常明顯，使用同一種設備或是方法來存儲數據是一種浪費，而使用不同的存儲系統來存儲數據，又不得不面臨多份數據搬遷同步，應用面對異構系統的復雜性等額外問題；因此在一套系統中使用混合存儲成為一種必然.X-Engine的核心理念依然是根據數據的冷熱程度對數據分層，以最大程度的匹配當前多種不同的存儲介質，對不同熱度的數據使用不同的存儲方法，以求在存儲成本和性能之間取得平衡，獲取最大收益.

2.2.2 內存索引

內存表是數據寫入的第一落入點，也是元數據存儲結構，要求讀寫都有極高的并發吞吐，X-Engine采用了Lock-Free(無鎖)SkipList.SkipList相對于B-Tree來說，實現比較簡單，沒有B-Tree的節點分裂操作，容易實現為Lock-Free，缺點是因為數據是用鏈表鏈接起來，相鄰的數據沒有存儲在連續的內存中，因此CPU cache miss會比較高.我們比較過一些內存索引數據結構的性能: SkipList, B-Tree, MassTree[33],Bw-Tree[34]，目前的實現中MassTree性能最好，MassTree是一個B-Tree組成的前綴樹，使每個節點適配cache line，利用prefetch加速，獲得比較好的性能.但MassTree在穩定性上依然有問題，是我們下一步的優化實現的方向.

2.2.3 并發控制

目前主要的MVCC技術有2種:

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

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

X-DB同時支持2種并發控制技術，可以根據應用的特點進行選擇，在熱點沖突很少的應用場景，我們可以選用OCC，反之在熱點沖突明顯的場景，則適用基于鎖的并發控制.

2.2.4 混合存儲格式

互聯網龐大的數據量帶來高昂的存儲成本，因此對數據進行高效的壓縮，提升數據存儲密度成為一個重要議題；另外,數據庫需要在各種負載上運行，傳統的OLTPOLAP的界限不再清晰，用戶總是希望在一份數據上執行所有種類的請求，HTAP(hybrid transactionanalytical processing)應運而生.

X-DB面向的主要業務場景是OLTP，主要格式還是按行存儲，不過為了求取更好的壓縮比率，在局部使用了按列存儲的格式，在這個基礎上，X-DB使用了基于列編碼進行壓縮的方式替代通用壓縮算法進行壓縮，是因為通用壓縮算法并不關心數據的行列結構，一旦進行壓縮以后，原有的結構被完全破壞掉，無法在壓縮的數據上進行直接查詢.而X-DB的存儲引擎存儲了數據表的schema，可以按schema解釋數據的行列結構，識別每一列的數據類型和數據的特點尋求更合適的編碼方式進行壓縮，取得更好的壓縮比，更關鍵的是，進行壓縮編碼后的數據仍然是有結構的，無需解壓縮即可直接查詢.

3 軟硬一體設計

在本節中，我們詳細介紹X-DB中軟硬一體模塊的設計和實現.

3.1 基于FPGAQAT的數據compaction設計

X-DB的存儲結構都是基于Copy-On-Write實現的，所有的修改操作都是寫入新版本增量數據，所以無論是寫入數據還是修改元數據，都是可以在后臺進行的，對讀寫操作沒有影響.X-Engine會存儲數據的多個版本用于MVCC，在compaction過程中會對不再被事務所引用的舊數據版本進行回收.

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

為了減少compaction對系統性能的沖擊，X-DB從多個方面對其進行優化，其中很重要的一點是利用FPGAQAT對數據進行壓縮和解壓縮.

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

數據compaction的過程在本質上是一個多路歸并操作，X-DB將其抽象為一個多路datablocks按一定規則合并為一路datablocks的過程；FPGA內部的流水線可以將數據的讀取解碼合并編碼同時執行，可以提供單路處理達2 GBps的性能，遠優于CPU自己做compaction操作；同時可以將compaction中非常耗費CPU的通用壓縮操作也一并完成，最終CPU在這個階段只負責數據的IO.

Fig. 2 Data compaction in X-DB圖2 X-DB數據compaction

3.2 RDMA協同下的數據傳輸方案

X-DB擁有分布式強一致能力，內部通過Paxos算法實現多個數據庫副本之間的數據強一致.傳統的Paxos依賴于操作系統內核協議棧的套接字實現數據通信.在重負載情況下，多個副本之間的數據通信任務的并發和吞吐都非常大，不但占用了大量的系統資源，同時影響了數據庫的響應時間.

為了提升數據傳輸的性能，同時降低其對系統資源的消耗，X-DB從多個方面進行了優化，其中非常重要的一個方面是利用RDMA(remote direct memory access)優化了日志寫入和數據傳輸流程.RDMA是一種遠程數據直接存取技術，需要網絡適配器以及其他網絡基礎設施的支持.通過結合RDMA技術，數據庫可以像訪問本地內存一樣訪問遠程節點的內存，避免了數據拷貝和上下文切換，整個傳輸過程由硬件實現，不需要CPU和操作系統參與.

X-DB通過利用RDMA能大幅度降低系統資源消耗，同時降低了Paxos達成一致過程的時延，從而降低查詢響應時間.Paxos協議達成一致過程中的網路通信，可以抽象成將Proposer上的日志復制到法定多數派的節點上并持久化，同時將當前節點狀態匯報給Proposer.其中最主要日志的復制過程需要經過內存拷貝、內核態協議棧組裝發送等過程，是當前的主要瓶頸.RDMA的One-Side API中提供了Remote Write原語，可以不需要操作系統內核CPU的參與，將本地內存中的內容復制到遠程內存中.我們在X-DB中設計了高效的日志緩存數據結構，對RDMA支持友好；同時使用了Remote Write原語實現日志復制和消息匯報過程，不但降低了CPU負載，同時降低了時延，提升了數據庫的響應速度.

3.3 X-DB的存儲引擎重構

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

4 實驗與結果

Fig. 4 compaction performance of QAT and CPU圖4 QAT和CPU壓縮測試對比

在本節中，我們基于本文提出的設計和實現，給出了X-DB存儲引擎的測試結果；同時，我們也給出基于QAT的數據壓縮測試結果并加以分析.測試機型均為CPU:64core, DRAM:512 GB, Disk: NVME SSD 7T, NIC:10Gb.

4.1 X-DB存儲引擎

在本測試中，我們使用MySQL生態通用的測試集Sysbench[35].表數量設置為10，每個表包含20萬條記錄，并發連接數量為1 000，每個事務包含一條讀或寫操作.讀寫混合測試中，讀寫比為10∶4.

圖3給出了Sysbench在吞吐率上的測試結果.Read-only方面，X-DB存儲引擎對MySQL(InnoDB)有超過1倍的提升；Write-only上超過5倍的提升；讀寫混合下約有2.5倍的提升.相對于InnoDB，X-DB存儲引擎將更新寫入到高效內存索引中，沒有基于頁面的原地更新，只需要記錄Redo日志，而無需Undo日志，大大簡化了事務處理的邏輯；同時大部分熱數據是在內存中，使用是無鎖的數據結構，相對于頁面掃描提取數據來說，在熱點讀性能上更為高效.該項測試是使用CPU進行compaction，并沒有使用FPGA或QAT(QAT測試請見第4.2節).

Fig. 3 Performance on Sysbench圖3 Sysbench測試結果

4.2 X-DB數據壓縮

本節中我們使用X-DB存儲引擎對QAT進行了測試.QAT是Intel的數據壓縮技術，全稱為QuickAssist Technology.測試過程為隨機寫入的同時開啟數據壓縮，觀察硬件加速對數據壓縮的性能提升.

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

5 總 結

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

致謝感謝阿里巴巴集團張瑞和葉正盛對本文的指導!

[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