可擴展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡請求服務機制

肖冰,郭進偉,錢衛(wèi)寧

(華東師范大學數(shù)據(jù)科學與工程研究院,上海200062)

可擴展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡請求服務機制

肖冰,郭進偉,錢衛(wèi)寧

(華東師范大學數(shù)據(jù)科學與工程研究院,上海200062)

請求服務機制涉及請求的傳輸和處理,是分布式數(shù)據(jù)管理系統(tǒng)中各組件交互并完成任務的重要前提.本文以可擴展數(shù)據(jù)管理系統(tǒng)為背景,抽象系統(tǒng)中的網(wǎng)絡服務模型,介紹系統(tǒng)中的網(wǎng)絡請求服務機制.從數(shù)據(jù)庫的主要實現(xiàn)出發(fā),分析不同類型的請求在傳輸以及處理上的不同要求.以OceanBase為例,統(tǒng)計各機制在一個可擴展數(shù)據(jù)管理系統(tǒng)中的服務比重,并進行相關的分析.

可擴展數(shù)據(jù)管理系統(tǒng);網(wǎng)絡請求;OceanBase

0 引言

傳統(tǒng)單機模式數(shù)據(jù)庫有限的存儲能力及其縱向擴展方式已經不適合互聯(lián)網(wǎng)應用對海量數(shù)據(jù)的存儲和處理所帶來的需求.隨著計算機網(wǎng)絡與通信技術的發(fā)展,越來越多的分布式數(shù)據(jù)庫系統(tǒng)應運而生,如Megastore[1],Cassandra[2]等.這些分布式數(shù)據(jù)管理系統(tǒng)采用橫向擴展的方式,通過向系統(tǒng)中添加機器,來達到系統(tǒng)支持更高并發(fā)服務的目的[3].與集中式數(shù)據(jù)庫相比,分布式數(shù)據(jù)庫系統(tǒng)包含多個在地理上分離而在邏輯上集中的節(jié)點,通過網(wǎng)絡互連通信.每個節(jié)點在網(wǎng)絡上都是獨立的服務器(也可以引申為數(shù)據(jù)庫進程),能夠自主存儲并管理本地數(shù)據(jù),但同時所有節(jié)點通過系統(tǒng)能夠作為整體對外服務[4].

在互聯(lián)網(wǎng)高速發(fā)展的今天,數(shù)據(jù)量呈指數(shù)增長,數(shù)據(jù)類型也展現(xiàn)出多樣性,大量結構化和非結構化數(shù)據(jù)需要更加高效地存儲和處理[5].這不僅使得集中式數(shù)據(jù)庫系統(tǒng)愈加難以滿足需求,甚至傳統(tǒng)架構的分布式數(shù)據(jù)庫也不再適應.為了應對這些挑戰(zhàn),很多企業(yè),特別是互聯(lián)網(wǎng)企業(yè)開始尋求新的解決方案,提出新的分布式存儲架構和管理方式,并實現(xiàn)了成熟的、適應海量數(shù)據(jù)應用需求的分布式數(shù)據(jù)庫[6].新型分布式數(shù)據(jù)庫是一種集群式架構的系統(tǒng),內部通過高速網(wǎng)絡互連,數(shù)據(jù)以多副本形式分布存儲于部分節(jié)點中,其最重要的特征是高可擴展性,因此又被稱為可擴展數(shù)據(jù)管理系統(tǒng),如HBase[7],Spanner[8],OceanBase[9-10]等.

而對于這樣的可擴展數(shù)據(jù)管理系統(tǒng)而言,請求服務機制真正將系統(tǒng)中的各個功能節(jié)點聯(lián)系起來形成一個整體對外服務,是系統(tǒng)功能的前提和性能的保證.圖1所示為一個可擴展數(shù)據(jù)管理系統(tǒng)中的各功能節(jié)點,其中,主控節(jié)點MNode(Master-Node)負責管理集群內所有節(jié)點的狀態(tài)信息,幫助各個節(jié)點協(xié)同工作,管理集群、數(shù)據(jù)分布以及副本;事務處理節(jié)點TNode(Transaction-Node)負責處理寫事務,并存儲增量更新的數(shù)據(jù),是數(shù)據(jù)庫集群中負載較高的節(jié)點之一;基線數(shù)據(jù)存儲節(jié)點SNode(Storage-Node)存儲大部分的用戶數(shù)據(jù),提供對數(shù)據(jù)的讀訪問支持,能夠自動合并基線數(shù)據(jù)和事務處理節(jié)點上的增量數(shù)據(jù)返回給用戶;客戶端管理器CMgr(Client-Manager)用來管理客戶端通信,對外提供服務接口(此處的客戶端指系統(tǒng)用戶,不同于后文中提到的網(wǎng)絡模型中的客戶端).

圖1 可擴展數(shù)據(jù)管理系統(tǒng)架構圖Fig.1Architecture of a scalable database management system

為了更好地理解可擴展數(shù)據(jù)管理系統(tǒng)中的請求服務機制,本文基于系統(tǒng)架構,抽象了系統(tǒng)中網(wǎng)絡請求服務的Client/Server模型,并基于該模型概括了3種請求傳輸機制和4種請求處理機制.以OceanBase為例統(tǒng)計分析了TPC-C各類型事務負載下各機制所占的比重,并總結了不同的請求類型對系統(tǒng)的不同要求.

本文的后續(xù)內容組織如下:第1節(jié)介紹網(wǎng)絡請求服務基礎,以及可擴展數(shù)據(jù)管理系統(tǒng)在經典的Client/Server模型下包含的幾種請求的傳輸和處理機制;第2節(jié)在TPC-C多類型的事務負載下,以OceanBase為例,統(tǒng)計可擴展數(shù)據(jù)管理系統(tǒng)中各機制處理的請求占整個系統(tǒng)的比重,分析其與系統(tǒng)架構的關系;最后,第3節(jié)總結全文.

1 網(wǎng)絡請求服務基礎

1.1 網(wǎng)絡請求服務模型

最原始的網(wǎng)絡請求服務使用的是阻塞型接口,需要等待調用結果的返回,這樣的模型一次只能響應一個客戶端請求,無法滿足多客戶端的應用帶來的網(wǎng)絡要求.對此最簡單的解決方式是在服務端使用多線程,讓每一個連接都有獨立的線程,這樣任何一個連接的阻塞都不會影響到其他的連接.但是多線程模型會嚴重占用系統(tǒng)資源,降低系統(tǒng)對外界的響應效率.也就是說,多線程模型中每個線程依然只能處理一路I/O,適合處理短連接,而且是連接的打開關4非常頻繁的情形,并不適合處理長連接.因為過多的線程依然會使服務器的性能下降.一般系統(tǒng)的底層網(wǎng)絡服務選用Linux select或epoll等I/O多路復用接口[11],使用句柄操作,可以同時從多個客戶端接收數(shù)據(jù),同時對多個句柄進行讀、寫和異常狀態(tài)的檢測,保證并發(fā).這個環(huán)節(jié)只管收,不處理任務,把句柄放到一個緩沖區(qū)里面,然后業(yè)務處理模型對接線程池,可以使復雜業(yè)務處理上的負擔被分擔.但當句柄值較大時,接口本身需要消耗大量時間去輪詢各個句柄.

如果選擇異步的方式,需要在業(yè)務處理里使用完全的異步API(Application Programming Interface),如OceanBase底層使用了開源的事件驅動庫libev[12].很多業(yè)務要保障流程的正確是需要同步操作的.異步回調和4包在編程實現(xiàn)上帶來了一定的復雜度和風險. UNIX平臺下多進程模型擅長處理并發(fā)長連接,但不適用于連接頻繁產生和關4的情形.最高效的模型是異步非阻塞I/O,而且不用select/epoll接口,因為這兩個接口都有著O(n)的時間復雜度[11].異步非阻塞I/O模型下的編程是有一定難度的,由于I/O操作不再阻塞,需要親自管理維護每個連接的狀態(tài).為了充分利用CPU,還應結合線程池,避免在輪詢線程中處理業(yè)務邏輯.

圖2 可擴展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡服務模型圖Fig.2Network server model of a scalable database management system

圖2抽象了可擴展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡服務模型,我們說當一臺服務機S1向另外一臺服務機S2請求服務時,S1就被稱為客戶端,S2被稱為服務端.服務端接收客戶端發(fā)送的網(wǎng)絡包,通常會將網(wǎng)絡包加入到任務隊列中[13].接著,工作線程會從任務隊列中不斷獲取網(wǎng)絡包進行處理,處理完成后應答客戶端.而系統(tǒng)中一臺服務機在不同的任務當中往往會充當不同的角色.系統(tǒng)中的各個節(jié)點往往會同時封裝客戶端和服務端,在不同的處理流程中,節(jié)點會首先定位自己的角色然后調用相關的處理方法.

1.2 可擴展數(shù)據(jù)管理系統(tǒng)中的請求服務機制

可擴展數(shù)據(jù)管理系統(tǒng)中的請求傳輸機制主要分為兩種:一種是客戶端發(fā)送請求并需要服務端回復請求,如查詢內存表;另一種是客戶端發(fā)送消息不需要服務端回復,如異步日志回放.如圖3,我們將只響應不回復的服務端稱為響應端.其中,需要回復的請求又分為同步請求和異步請求.同步請求需等待服務端返回響應,如獲取元數(shù)據(jù)[14],而異步請求則不需要,如心跳.異步請求時,客戶端將請求包加入到網(wǎng)絡發(fā)送隊列后立即返回,不等待應答.同步請求時,客戶端將請求包加入到網(wǎng)絡發(fā)送隊列后開始阻塞等待,直到網(wǎng)絡線程接收到服務端的應答后才喚醒客戶端,從而執(zhí)行后續(xù)處理邏輯.而不需要回復的請求表現(xiàn)為單向通信,對方接到消息后立即執(zhí)行處理邏輯,請求的發(fā)送即為請求的結束.

圖3 請求的傳輸機制Fig.3Request transmitting mechanism

在生產者/消費者模型中,往往有一個全局任務隊列,生產者將任務加入到任務隊列,消費者從任務隊列中取出任務進行處理[6].圖4展示了請求處理機制對于不同的任務有不同的處理[15].對于處理時間比較短的任務,采用I/O線程直接處理的方式,可以減少上下文切換.基于事件循環(huán)的多I/O線程能夠增加網(wǎng)絡的收發(fā)能力[16].將處理時間比較長的任務加入隊列,工作線程不斷地從任務隊列取出任務進行處理.所有的網(wǎng)絡I/O線程和工作線程操作全局任務隊列都需要首先獲取獨占鎖,這種方式的鎖沖突嚴重,將導致大量操作系統(tǒng)上下文切換.為了解決這個問題,給每個工作線程分配一個任務隊列,網(wǎng)絡I/O線程按照一定的策略選擇一個任務隊列并加入任務.選擇策略如隨機選擇,通過全局任務計數(shù)計算出任務所屬的任務隊列,或者選擇一個任務個數(shù)最少的任務隊列.如果某個任務的處理時間很長,就有可能出現(xiàn)任務不均衡的情況,即某個線程的任務隊列中還有很多任務未被處理,其他線程卻處于空閑狀態(tài).可以采取一個很簡單的策略應對這種情況:每個工作線程首先嘗試從對應的任務隊列中獲取任務,如果由于隊列為空獲取任務失敗,則遍歷所有工作線程的任務隊列,直到獲取任務成功或者遍歷完所有的任務隊列為止.

圖4 請求的處理機制Fig.4Request processing mechanism

這樣的任務隊列在后文歸類中我們稱之為普通隊列.

2 OceanBase的請求服務統(tǒng)計分析

本節(jié)以第1節(jié)中抽象的可擴展數(shù)據(jù)管理系統(tǒng)中的網(wǎng)絡請求服務模型為基礎,在TPC-C不同類型的事務負載下分析請求類型和服務機制,總結不同請求類型對應的傳輸機制和處理機制,探索它們之間的關系.

2.1 傳輸機制與請求類型

表1列出了系統(tǒng)中的傳輸機制與請求類型的對應關系.首先,系統(tǒng)中每個節(jié)點通過心跳檢測其他節(jié)點是否存活,心跳發(fā)出后不必阻塞等待節(jié)點的回復,心跳響應會以不需要回復的方式返回給請求節(jié)點.如MNode向TNode發(fā)送一個心跳請求以確認該事務處理節(jié)點仍然存活,請求發(fā)送后立即返回,TNode隨后會向MNode發(fā)送一個心跳響應的信號,來告訴MNode自己仍然存活.這一類用來維護節(jié)點間關系的請求,通常是通過異步的方式來發(fā)送.

在集群啟動時,其他節(jié)點需要向主控節(jié)點注冊自己的角色,這樣的注冊請求需要阻塞等待回復方可進行后續(xù)的操作.當節(jié)點需要獲取描述系統(tǒng)或系統(tǒng)中用戶對象的元數(shù)據(jù)時,也需要同步等待數(shù)據(jù)的返回結果加入輸出緩沖區(qū).如MNode獲取SNode成員鏈表時,主控節(jié)點的客戶端管理器會向其服務端管理器發(fā)送請求,服務端管理器接到請求后立即進行相關的處理,將SNode成員鏈表信息加入輸出緩沖區(qū),隨后立即喚醒I/O線程響應客戶端管理器.又如SNode向MNode獲取模式信息時,SNode的客戶端管理器向MNode的服務端管理器發(fā)送獲取模式信息的請求,MNode接受該類型的請求后立即處理,將相關模式信息加入輸出緩沖區(qū)后喚醒I/O線程響應SNode.同樣的同步傳輸機制還應用于操作SQL、獲取版本、執(zhí)行事務、處理觸發(fā)事件等.

表1 客戶端傳輸機制及請求類型Tab.1Transmitting mechanisms and request types in client

還有一類請求是不需要回復的,客戶端發(fā)出后即結束,服務端接收到請求后進行響應即可.這里我們稱服務端為響應端.通常情況下這一類的請求是不帶數(shù)據(jù)的請求,而且請求包傳輸?shù)巾憫撕笊芷诹⒓唇K止,響應端的后續(xù)處理由此觸發(fā)但并不會延續(xù)請求的生命周期.如事務處理節(jié)點TNode在啟動時需要異步回放提交日志,此時TNode客戶端管理器會向其服務端管理器發(fā)送不帶輸入輸出緩沖區(qū)的空請求,服務端管理器接到請求后立即回放日志,響應過程結束.這一個過程與異步傳輸機制中的服務端向客戶端返回結果十分類似,但是場景不同,因而這里做一個區(qū)分,并將只處理不回復的服務端稱為響應端.

2.2 處理機制與請求類型

服務端接受一個請求后就要進行相應的處理或者響應,在不同的服務端對應不同類型的請求有不同的請求處理機制.系統(tǒng)常常使用隊列作為客戶端和服務器之間的請求和應答的緩沖區(qū)[17].在一個可擴展的數(shù)據(jù)管理系統(tǒng)中,事務處理節(jié)點往往處理較核心的業(yè)務任務,也承擔著一定比重的負載,因此TNode上的處理機制有多種,而SNode不需要維護隊列來管理請求, MNode只需要簡單的隊列來管理請求.

對于SNode而言,不管是異步的心跳請求,同步的獲取元數(shù)據(jù)的請求,還是建表的請求都直接在I/O線程就地處理,因為這些請求往往不帶數(shù)據(jù)只帶報頭,處理時間通常在幾十微秒的數(shù)量級,結束后B將結果返回給客戶端.而MNode作為主控節(jié)點管理元數(shù)據(jù),會區(qū)分請求的類型用不同的隊列進行管理,如數(shù)據(jù)讀取類請求歸讀隊列管理,數(shù)據(jù)修改類請求歸寫隊列管理,節(jié)點間協(xié)調關系類請求歸租約隊列來管理.由于這些請求在MNode上的到達和處理順序隨機,所以這里的隊列類型均為普通隊列.然而對于事務處理節(jié)點TNode而言,復雜的事務處理和較高的任務負載決定該節(jié)點的請求處理機制不僅僅是I/O線程就地處理和普通隊列+工作線程的方式就能很好地應對的.OceanBase的TNode為了保證事務的提交順序,采用FIFO(First-In-First-Out)的隊列來處理事務提交的請求,而在事務的執(zhí)行上采用優(yōu)先級隊列的方式,因為普通隊列和FIFO隊列都不能滿足事務并發(fā)控制可能帶來的優(yōu)先級要求.而對于短任務比如異常狀態(tài)下請求的直接退出、提交異步任務時的日志回訪請求,TNode都會在I/O線程直接處理,不會排隊.對于節(jié)點間協(xié)調關系類的請求如心跳,TNode會同MNode一樣采用普通隊列來構建租約隊列進行管理.我們將服務端的請求處理機制與請求類型歸納總結為表2.

表2 服務端處理機制及請求類型Tab.2Processing mechanisms and request types in server

可以看出,對于請求的處理機制,首要的區(qū)別是請求是否需要排隊,其次是對于需要排隊的請求,針對不同的請求類型和節(jié)點處理的特點,選擇不同類型的隊列.

2.3 ?類型事務下的請求服務統(tǒng)計分析

TPC-C是數(shù)據(jù)庫管理系統(tǒng)在線事務處理(OLTP)性能測試的國際標準[18],已得到廣泛認可.為了在一定程度上反應可擴展數(shù)據(jù)管理系統(tǒng)中各個請求服務機制的分布情況,本小節(jié)統(tǒng)計了TPC-C多類型事務下各機制服務的請求占比.并進行相關的簡要分析.

圖5 2種傳輸機制的比例分布情況Fig.5Proportional distribution of the two transmitting mechanisms

圖5所示為同步和異步兩種請求傳輸機制的占比情況,這里沒有考慮無回復的請求,因為大部分這一類的請求均表現(xiàn)為節(jié)點內部的信號,很大程度上不構成網(wǎng)絡I/O的開銷.從圖5可以看出,在TPC-C所有的5種事務類型中,同步傳輸機制所服務的請求要比異步傳輸機制服務的請求量高出1.5倍到4倍.其中,對于Delivery的事務類型,同步傳輸機制服務的請求比重在所有的TPC-C事務類型中為最高,這跟該類型負載中大量的批處理直接相關.而OrderStatus更多的是處理用戶的查詢,所以異步傳輸機制服務的請求量相對較高.

可以看出,對于可擴展的數(shù)據(jù)管理系統(tǒng)而言,同步機制是網(wǎng)絡請求傳輸?shù)闹饕绞?

由于OceanBase底層使用了libev事件驅動庫,所以它的同步處理機制是基于底層的異步I/O實現(xiàn)的,這在一定程度上也優(yōu)化了系統(tǒng)同步機制的發(fā)送性能.

而對于網(wǎng)絡請求的處理機制而言,如圖6所示,我們可以看到,FIFO的隊列管理方式在一個數(shù)據(jù)庫管理系統(tǒng)中不可或缺[19],但是在一個可擴展數(shù)據(jù)管理系統(tǒng)中所能處理的請求已經不再占有較大的比重.取而代之的是優(yōu)先級隊列.對于一些對執(zhí)行順序不敏感的請求,系統(tǒng)還采用了隨機出入隊的普通隊列,進而降低一部分維護成本.系統(tǒng)中還有大量的短任務可以在I/O線程就地處理,主要表現(xiàn)在SNode對請求的轉發(fā)和系統(tǒng)內各節(jié)點的心跳信號.

圖6 4種處理機制的比例分布情況Fig.6Proportional distribution of the four processing mechanisms

如果將TNode節(jié)點視為一個內存數(shù)據(jù)庫,當所有的讀寫操作都可以在內存上直接進行時,不阻塞的事務讀取請求可以在I/O線程就地處理,這將提升數(shù)據(jù)庫的請求服務性能.

3 結論

網(wǎng)絡請求服務機制是可擴展數(shù)據(jù)管理系統(tǒng)底層支持的重要部分.本文從系統(tǒng)的架構出發(fā),抽象網(wǎng)絡服務的Client/Server模型,分別以客戶端和服務端的角度總結概括了模型中網(wǎng)絡請求的傳輸機制和處理機制,并將請求傳輸機制分為3種,將請求處理機制分為4種,關聯(lián)不同的請求類型進行具體介紹.以OceanBase為例,文章在TPC-C不同類型的事務負載下統(tǒng)計了各機制所處理的請求占系統(tǒng)所有請求的比重,并分析了不同的請求類型對系統(tǒng)帶來的不同要求,及其與服務機制的關系.

可擴展數(shù)據(jù)管理系統(tǒng)除了實現(xiàn)集群規(guī)模的伸縮性,也需要提供高性能事務.為事務類型的請求進行恰當?shù)姆諜C制的選擇是事務處理性能得以保證的前提.網(wǎng)絡請求的發(fā)送機制主要分為同步機制和異步機制.對于數(shù)據(jù)庫而言,大部分事務相關或者寫任務相關的請求都需要采用同步機制.網(wǎng)絡請求處理機制的多樣性主要體現(xiàn)在系統(tǒng)的事務處理節(jié)點.傳統(tǒng)的先入先出服務類型已經無法滿足可擴展架構下的事務請求,因此,多種隊列各自配合工作線程的服務模型被應用到可擴展數(shù)據(jù)管理系統(tǒng)中.

［1］BAKER J,BOND C,CORBETT J.C,et al.Megastore:Providing scalable,highly available storage for interactive services[C]//Proceedings of CIDR.2011,11:223-234.

［2］LAKSHMAN A,MALIK P.Cassandra:A decentralized structured storage system[J].Operating Systems Review, 2010,44(2):35-40.

［3］COULOURIS G,DOLLIMORE J,KINDBERG T,et al.Distributed Systems:Concept and Design[M].Addison-Wesley,2012.

［4］?ZSU M T,VALDURIEZ P.Principles of Distributed Database Systems[M].New York:Springer-Verlag,2011.

［5］MARYANSKI F J.A survey of developments in distributed data base management systems[J].IEEE Computer, 1978,11(2):28-38.

［6］楊傳輝.大規(guī)模分布式是存儲系統(tǒng):原理解析與架構實戰(zhàn)[M].北京:機械工業(yè)出版社,2013.

［7］Apache.Apache HBase[EB/OL].[2016-06-10].https://hbase.apache.org.

［8］CORBETT J C,DEAN J,EPSTEIN M,et al.Spanner:Google’s globally distributed database[J].ACM Trans Comput Syst,2013,31(3):8.

［9］陽振坤.Oceanbase關系數(shù)據(jù)庫架構[J].華東師范大學學報(自然科學版),2014,6(5):141-148.

［10］OceanBase[EB/OL].[2016-06-10].https://github.com/alibaba/oceanbase.

［11］STEVENS W R,FENNER B,RUDOFF A M.UNIX Network Programming,Volume 1:The Sockets Networking API[M].Addison-Wesley Professional.2003.

［12］Libev[EB/OL].[2016-06-10].http://software.schmorp.de/pkg/libev.html.

［13］GARCIS-MOLINA H,ULLMAN J D,WIDOM J.Database System Implementation[M].New Jersey Prentice Hall,2009.

［14］CHANG L,WANG Z,MA T,et al.A massively parallel processing SQL engine in hadoop[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data.New York:ACM,2014.

［15］STONEBRAKER M.Technical perspective-one size fits all:An idea whose time has come and gone[J].Commun ACM,2008,51(12):76.

［16］JOHNSON R,PANDIS I,AILAMAKI A.Eliminating unscalable communication in transaction processing[J]. VLDB Journal,2014,23(1):1-23.

［17］BERNSTEIN P A,NEWCOMER E.Principles of Transaction Processing[M].Morgan Kaufmann,2009.

［18］Transaction Processing Performance Council(TPC).TPC Benchmark C:Standard Specification[EB/OL].[2016-06-10].http://www.tpc.org/tpcc/.

［19］HELLERSTEIN J M,STONEBRAKER M,HAMILTON J.Architecture of a Database System[M].Hanover: Now Publishers Inc,2007.

(責任編輯:林磊)

Network request service mechanisms in a scalable database management system

XIAO Bing,GUO Jin-wei,QIAN Wei-ning
(Institute for Data Science and Engineering,East China Normal University,Shanghai200062,China)

Network request service mechanism involves the transmitting and processing of the requests.It plays an important role for interactive components to cooperate in a distributed database management system.Taking scalable database management systems as background,this paper introduces the inside network service model and the network request service mechanisms.On the basis of the primary implementation in database systems,we analyze different demands from different requests in terms of transmitting and processing.The service distribution of each mechanism and associative analysis are presented based on OceanBase.

scalable database management system;network request;OceanBase

TP391

A

10.3969/j.issn.1000-5641.2016.05.018

1000-5641(2016)05-0165-08

2016-05

國家863計劃項目(2015AA015307);國家自然科學基金(61432006)

肖冰,女,碩士研究生,研究方向為分布式數(shù)據(jù)庫.E-mail:bingxiao@stu.ecnu.edu.cn.

錢衛(wèi)寧,男,教授,研究方向為可擴展事務處理和海量數(shù)據(jù)管理與分析. E-mail:wnqian@sei.ecnu.edu.cn.