余楷,李志方,周敏奇,周傲英

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

非阻塞事務(wù)型實時數(shù)據(jù)注入技術(shù)研究與實現(xiàn)

余楷,李志方,周敏奇,周傲英

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

伴隨著大數(shù)據(jù)時代來臨,傳統(tǒng)數(shù)據(jù)庫系統(tǒng)已逐漸無法應(yīng)對海量數(shù)據(jù)處理帶來的挑戰(zhàn),而分布式數(shù)據(jù)庫系統(tǒng)得到了越來越多的部署和應(yīng)用.分布式數(shù)據(jù)庫系統(tǒng)部署數(shù)據(jù)于多臺機器上,利用大規(guī)模并行計算技術(shù)實現(xiàn)了對海量數(shù)據(jù)的存儲、管理和分析.但針對金融領(lǐng)域嚴苛的事務(wù)型實時數(shù)據(jù)注入需求,現(xiàn)有分布式數(shù)據(jù)庫系統(tǒng)對其支持有限,其主要原因在于利用鎖和兩階段提交等方式實現(xiàn)分布式事務(wù)處理,無法做到非阻塞式數(shù)據(jù)注入,極大地影響了數(shù)據(jù)注入的性能.華東師范大學數(shù)據(jù)科學與工程研究院自主研發(fā)的分布式內(nèi)存數(shù)據(jù)庫系統(tǒng)—-CLAIMS,已能提供面向關(guān)系型數(shù)據(jù)集的實時數(shù)據(jù)分析服務(wù),但尚不能支持實時數(shù)據(jù)注入.針對上述實時數(shù)據(jù)注入的問題,本文重點分析了現(xiàn)有數(shù)據(jù)注入技術(shù)和基于分布式事務(wù)處理的實現(xiàn)方式,設(shè)計了面向元數(shù)據(jù)的集中式事務(wù)處理策略,利用無鎖編程技術(shù),實現(xiàn)了支持分布式事務(wù)的高性能實時數(shù)據(jù)注入框架,并通過熱備機制實現(xiàn)系統(tǒng)的高可用性.上述框架在CLAIMS系統(tǒng)中的實現(xiàn),經(jīng)充分實驗表明:該框架能夠?qū)崿F(xiàn)高通量的事務(wù)型實時數(shù)據(jù)注入,同時支持低延時的實時數(shù)據(jù)查詢.

分布式數(shù)據(jù)庫;實時數(shù)據(jù)注入;事務(wù);CLAIMS

0 引言

隨著信息技術(shù)的快速成熟和互聯(lián)網(wǎng)的高速發(fā)展,傳統(tǒng)行業(yè)加速信息化.大型企業(yè)的數(shù)據(jù)規(guī)模普遍已經(jīng)達到TB級,甚至PB級,同時每天仍以TB的量級不斷增加.應(yīng)對海量數(shù)據(jù)對數(shù)據(jù)存儲和數(shù)據(jù)分析帶來的巨大挑戰(zhàn),目前業(yè)界使用的解決方案是基于MapReduce框架[1]的HADOOP和SPARK[2].兩者構(gòu)建在分布式文件系統(tǒng)HDFS上,由其負責將巨大的數(shù)據(jù)集分派到集群中的多個節(jié)點進行存儲,同時提供良好的容錯性[3],實現(xiàn)數(shù)據(jù)的多備份策略. HADOOP使用MapReduce模式實現(xiàn)并行計算,具有天然的容錯能力;后者主要在內(nèi)存中處理和分析所有數(shù)據(jù),不寫回中間結(jié)果到磁盤,極大地提高性能.同樣地,內(nèi)存數(shù)據(jù)庫將數(shù)據(jù)全部存放于內(nèi)存,使數(shù)據(jù)的查詢分析性能提升一個數(shù)量級.SAP HANA[4-5]和Exalytics[6]作為內(nèi)存數(shù)據(jù)庫的代表,提供數(shù)據(jù)的實時查詢分析,達到秒級的響應(yīng)速度.

數(shù)據(jù)從事件發(fā)生到支持決策經(jīng)歷多次延遲:數(shù)據(jù)注入延遲、分析延遲、決策延遲,實時數(shù)據(jù)的價值依次遞減.為了減少企業(yè)因數(shù)據(jù)延遲帶來的經(jīng)濟損失,數(shù)據(jù)需要在實際產(chǎn)生后立刻實時注入數(shù)據(jù)庫系統(tǒng)中,同時立即提供實時的查詢和數(shù)據(jù)分析,以同時降低注入延遲和分析延遲.而數(shù)據(jù)的實時存儲和分析都基于實時數(shù)據(jù)注入的基礎(chǔ)上,因此數(shù)據(jù)注入延遲更顯重要.大數(shù)據(jù)環(huán)境下的數(shù)據(jù)注入不僅注入數(shù)據(jù)量非常巨大,同時數(shù)據(jù)注入的速度要求極高.實際需求中,實時注入和實時分析同時執(zhí)行,并按需實現(xiàn)兩者隔離(如實現(xiàn)read committed等隔離級別).在更加嚴格的金融領(lǐng)域,數(shù)據(jù)注入必須支持事務(wù),保證數(shù)據(jù)的持久性和一致性.以上現(xiàn)實需求對數(shù)據(jù)注入提出以下要求:

1.實現(xiàn)較高性能的數(shù)據(jù)注入,壓縮注入延遲在毫秒量級,實現(xiàn)數(shù)據(jù)注入的實時性;

2.通過事務(wù)處理的方式保證實時數(shù)據(jù)注入過程中數(shù)據(jù)的完整性和一致性;

3.對數(shù)據(jù)注入和數(shù)據(jù)分析進行必要的隔離,以保證數(shù)據(jù)實時注入不影響實時數(shù)據(jù)查詢、分析執(zhí)行及其正確性.

面對大數(shù)據(jù)時代對海量數(shù)據(jù)存儲管理和實時分析的需求,華東師范大學數(shù)據(jù)科學與工程研究院自主研發(fā)了支持高性能數(shù)據(jù)查詢的集群感知分布式內(nèi)存數(shù)據(jù)庫--CLAIMS(Cluster Aware In-Memory SQL engine).CLAIMS系統(tǒng)基于Master-Slave的Shared-Nothing架構(gòu),利用大規(guī)模并行計算提供基于關(guān)系型數(shù)據(jù)集的高性能實時數(shù)據(jù)分析[7],并極大降低分析延遲.然而,針對注入延遲問題,CLAIMS暫時不能提供高效的解決方案.

針對CLAIMS的數(shù)據(jù)注入框架無法實現(xiàn)實時數(shù)據(jù)注入并實現(xiàn)系統(tǒng)容錯等問題,本文摒棄傳統(tǒng)基于分布式事務(wù)處理的實現(xiàn)方式,廣泛使用無鎖結(jié)構(gòu)與算法,以等價的面向元數(shù)據(jù)的集中式事務(wù)處理方式替代傳統(tǒng)的分布式事務(wù)型實時數(shù)據(jù)注入方式.主要貢獻如下:

1.擴展傳統(tǒng)的單機數(shù)據(jù)注入為面向分布式系統(tǒng)的數(shù)據(jù)注入,充分利用集群多臺機器的資源,避免由于單機資源耗盡導致的性能瓶頸.

2.結(jié)合HDFS系統(tǒng)中文件只能截斷,無法被修改的特性,設(shè)計實現(xiàn)面向服務(wù)的分布式并發(fā)控制機制.該系統(tǒng)基于無鎖思想,利用事務(wù)快照實現(xiàn)“讀寫分離”,預(yù)分配分布式節(jié)點內(nèi)存來實現(xiàn)“寫寫分離”,大幅度提升數(shù)據(jù)注入和查詢的性能,實現(xiàn)非阻塞實時數(shù)據(jù)注入.

3.在實時數(shù)據(jù)注入的同時,對外提供強一致性的實時數(shù)據(jù)查詢分析,并實現(xiàn)數(shù)據(jù)的快照隔離級別.

4.實驗證明本文所提出的分布式實時數(shù)據(jù)注入框架具有較高的數(shù)據(jù)注入性能、較低的數(shù)據(jù)注入延遲與較高的事務(wù)型數(shù)據(jù)注入吞吐量,滿足大多數(shù)實時注入的需求,并提供數(shù)據(jù)的完整性保證.

本文第1節(jié)介紹數(shù)據(jù)實時注入實現(xiàn)技術(shù)和分布式事務(wù)處理的方式,以及本文實驗基于的CLAIMS系統(tǒng)的架構(gòu);第2節(jié)闡述分布式數(shù)據(jù)注入的設(shè)計、分布式事務(wù)管理的設(shè)計實現(xiàn)等;第3節(jié)對實現(xiàn)的框架進行測試和對比實驗;最后一節(jié)是本文的總結(jié).

1 相關(guān)工作

實時數(shù)據(jù)注入是指數(shù)據(jù)從消息隊列系統(tǒng)注入到數(shù)據(jù)庫系統(tǒng)的延時較低(通常在毫秒級別),并實現(xiàn)對數(shù)據(jù)庫系統(tǒng)中的數(shù)據(jù)實時更新,是大幅提升數(shù)據(jù)的處理價值的必要前提.對實時數(shù)據(jù)的實時分析,包括數(shù)據(jù)注入的實時性和數(shù)據(jù)分析的實時性,并通過隔離數(shù)據(jù)注入和數(shù)據(jù)分析實現(xiàn)數(shù)據(jù)分析的一致性.本文工作主要面向CLAIMS系統(tǒng)的分布式系統(tǒng)環(huán)境,實現(xiàn)事務(wù)型實時數(shù)據(jù)注入.下面從分布式實時注入、分布式系統(tǒng)的事務(wù)處理、CLAIMS系統(tǒng)三個方面來介紹本文的相關(guān)工作.

1.1 分布式數(shù)據(jù)實時注入

目前流行的大數(shù)據(jù)分析工具對數(shù)據(jù)實時注入支持較不完善,例如Facebook開源的分布式SQL查詢引擎Presto和SPARKSQL都針對于分布式查詢問題,在海量數(shù)據(jù)上提供分布式的SQL查詢能力,但無法保證實時的數(shù)據(jù)加載[8-9].Druid是一個列存儲的分布式數(shù)據(jù)存儲[10],專門為了快速導入海量數(shù)據(jù)并立即對外提供查詢而設(shè)計,但是它查詢上不支持SQL,使其在電信、金融服務(wù)等依賴SQL的行業(yè)無法廣泛使用.不同于Druid,Pinot同時支持實時數(shù)據(jù)注入和SQL語句查詢.Pinot[12]劃分數(shù)據(jù)為兩類,離線數(shù)據(jù)(存于HADOOP等)和在線的準實時數(shù)據(jù)(存于Kafka).然而Pinot不支持SQL中極為重要的JOIN語義,因此無法滿足現(xiàn)實的需求.同時其受限于Kafka支持的“At Least Once”消息消費模型[13],可能出現(xiàn)重復冗余的消息,應(yīng)用場景有限.因此實時數(shù)據(jù)注入需要支持事務(wù)的四個特性:ACID[11](原子性、一致性、隔離性、持久性).Vertica[14]、HAWQ[15]作為支持批量數(shù)據(jù)事務(wù)型注入功能的系統(tǒng)代表,不能將最新插入的數(shù)據(jù)反映在查詢中,無法滿足實時查詢的需求.目前支持事務(wù)型分布式數(shù)據(jù)實時注入和數(shù)據(jù)實時查詢的系統(tǒng)只有VoltDB,因此該系統(tǒng)是本文的實驗對照對象.

1.2 分布式系統(tǒng)的事務(wù)處理

分布式系統(tǒng)中數(shù)據(jù)處于不同的機器節(jié)點,需要事務(wù)支持來保證數(shù)據(jù)的ACID特性.

1.2.1 兩階段提交

分布式事務(wù)一般通過鎖和兩階段提交協(xié)議(Two-phase Commit,2PC)來實現(xiàn)[23],分為一個協(xié)調(diào)者和多個資源管理者角色.該協(xié)議將分布式事務(wù)劃分為兩個階段:預(yù)提交階段和提交階段.協(xié)議的執(zhí)行通過阻塞操作完成,大幅影響計算資源的使用率和事務(wù)性能,兩階段提交涉及多次節(jié)點間的網(wǎng)絡(luò)通信,通信時間大大延長.由于鎖的阻塞,資源的等待時間大量增加.其核心問題是如果協(xié)調(diào)者宕機,整個系統(tǒng)將處于不可用狀態(tài).針對2PC的缺點,三階段提交協(xié)議被提出[25],但其網(wǎng)絡(luò)延遲再次增大,無法作為有效的解決方案.

1.2.2 多版本事務(wù)處理

除了基于鎖的事務(wù)并發(fā)控制,多版本事務(wù)并發(fā)控制得到廣泛的使用.每個數(shù)據(jù)項對應(yīng)于多個副本,更一般的情況是,不同事務(wù)可以對相同數(shù)據(jù)項的不同版本進行讀和寫[20].基于多版本的并發(fā)控制方法可以實現(xiàn)寫寫分離和讀寫分離以避免事務(wù)執(zhí)行過程中的阻塞.SQL Server 2014中的Hekaton內(nèi)存計算框架就是基于多版本并發(fā)控制實現(xiàn)[21].表中的每個元組均保存有多個不同版本的副本(基于時間戳),刪除和修改元組時創(chuàng)建新的版本.讀取數(shù)據(jù)的時候根據(jù)時間戳只讀取定版本的數(shù)據(jù).由于Hekaton系統(tǒng)是集中式數(shù)據(jù)庫,對使用的單臺機器性能有較高要求,因此在可拓展性和成本方面有較多要求,嚴重地限制其應(yīng)用場景.

1.2.3 基于單線程的事務(wù)處理

多線程并發(fā)的事務(wù)處理有許多限制和要求,甚至反而降低性能,因此單線程的事務(wù)并發(fā)處理框架被提出.該框架將數(shù)據(jù)進行切分,在每個數(shù)據(jù)分區(qū)上僅有單個線程進行讀寫,避免事務(wù)執(zhí)行的沖突,從而完全避免鎖的開銷和其他多線程并發(fā)控制的開銷.Micheal Stonebraker主導的H-Store/VoltDB分布式內(nèi)存數(shù)據(jù)庫就基于單線程的事務(wù)處理,簡化并發(fā)控制的機制[16].通過在集群中簡單增加節(jié)點的方式VoltDB可實現(xiàn)性能的線性增加,因此目前的分布式事務(wù)處理系統(tǒng)中VoltDB擁有幾乎最高的性能.

1.3 CLAIMS系統(tǒng)

CLAIMS系統(tǒng)作為分布式內(nèi)存計算系統(tǒng),提供高性能的實時交互式數(shù)據(jù)分析與處理.不同于NOSQL[26],CLAIMS支持SQL92,兼容金融等領(lǐng)域的歷史上層應(yīng)用.

圖1 CLAIMS系統(tǒng)架構(gòu)圖Fig.1System architecture of CLAIMS

CLAIMS系統(tǒng)采用經(jīng)典的主從架構(gòu)(Master-Slave),集群包括一個主節(jié)點和若干個從節(jié)點,如圖1所示.主節(jié)點接收SQL語句并解析,生成查詢計劃分發(fā)給從節(jié)點,最后匯總結(jié)果集,管理和調(diào)度每臺機器上的計算資源和查詢執(zhí)行過程.主節(jié)點包括SQL解析器、查詢優(yōu)化器、數(shù)據(jù)字典管理器、集群資源管理器、全局調(diào)度器、協(xié)調(diào)器六個組件.從節(jié)點主要負責在內(nèi)存實際存取數(shù)據(jù)和接收并執(zhí)行查詢計劃,由執(zhí)行器、資源管理器、單機調(diào)度器、存儲管理器四個組件組成.

2 實時數(shù)據(jù)注入框架的設(shè)計實現(xiàn)

為了實現(xiàn)面向CLAIMS的事務(wù)型實時數(shù)據(jù)注入框架,在深刻理解CLAIMS系統(tǒng)架構(gòu)的基礎(chǔ)上,參考各類分布式事務(wù)處理系統(tǒng)的設(shè)計經(jīng)驗,本文提出新型的事務(wù)處理控制方式,設(shè)計并實現(xiàn)以下的一系列功能:

1.針對實時數(shù)據(jù)注入對應(yīng)的追加型事務(wù),采用面向元數(shù)據(jù)的集中式事務(wù)處理的策略,實現(xiàn)事務(wù)性數(shù)據(jù)注入,以避免直接對分布式數(shù)據(jù)注入操作實現(xiàn)事務(wù)性管理.

2.非阻塞式分布式數(shù)據(jù)注入框架,將傳統(tǒng)的集中式單機數(shù)據(jù)注入轉(zhuǎn)變?yōu)榉植际綌?shù)據(jù)注入,充分利用多臺機器的性能,避免性能受限于單機的處理瓶頸.

3.提供強一致性的數(shù)據(jù)查詢模型,實時注入的數(shù)據(jù)在后續(xù)的實時查詢中即時可見,支持在實時注入更新的數(shù)據(jù)集上實時查詢.

4.使用log-shipping技術(shù)實現(xiàn)數(shù)據(jù)熱備,面對服務(wù)機器宕機支持快速切換,對外提供高可用性的服務(wù),滿足金融領(lǐng)域的可用性要求.

在當前的CLAIMS的系統(tǒng)架構(gòu)基礎(chǔ)下,本文設(shè)計如圖2的系統(tǒng)架構(gòu),并實現(xiàn)并行的實時數(shù)據(jù)注入框架和原有的實時數(shù)據(jù)分析框架,兩者之間互不阻塞.

圖2 CLAIMS數(shù)據(jù)注入框架Fig.2Framework of data ingestion in CLAIMS

2.1 框架總體設(shè)計

如圖2所示,實時數(shù)據(jù)注入框架主要分為數(shù)據(jù)實時注入器以及事務(wù)管理器(TM)、HDFS持久存儲層.數(shù)據(jù)注入器主要分為主注入器(下稱Coordinator)和從注入器(下稱Worker).完整的數(shù)據(jù)注入框架包括一個事務(wù)管理器、多個Coordinator、多個Worker和持久存儲層HDFS.其中Coordinator和Worker可共存于同一機器節(jié)點.

數(shù)據(jù)注入引擎中各組件功能如下所示:

·TM:管理所有事務(wù)相關(guān)的數(shù)據(jù)并維護事務(wù)狀態(tài),向其他節(jié)點提供事務(wù)管理服務(wù).

·Coordinator:多個Coordinator獨立提供服務(wù).每個Coordinator從MQ拉取數(shù)據(jù)注入請求,對數(shù)據(jù)進行合法性等檢查,向TM申請事務(wù)的支持,獲得該事務(wù)預(yù)分配的注入地址后,將注入任務(wù)切分為多個Worker上的子任務(wù)并分發(fā)給對應(yīng)的Worker.在Worker完成(commit或者abort)事務(wù)后收集反饋,提交給TM.接收反饋超時則采取重試一次的策略,再失敗則認定事務(wù)失敗,并提交給TM.

·Worker:每個Worker負責該節(jié)點上綁定的所有數(shù)據(jù)分區(qū)的讀寫操作.其接收從Coordinator發(fā)送的注入任務(wù),并在對應(yīng)數(shù)據(jù)分區(qū)上實際執(zhí)行.所注入的數(shù)據(jù)被保存Worker節(jié)點的內(nèi)存中,提供快速查詢與訪問.

·持久存儲層:CLAIMS系統(tǒng)采用HDFS作為Worker內(nèi)存中已提交的歷史數(shù)據(jù)持久化的介質(zhì).一旦寫入HDFS中,則由HDFS保證數(shù)據(jù)不會丟失.

Coordinator同Worker共用機器以充分利用每個節(jié)點的性能.一般情況可選用單Coordinator多Worker的架構(gòu),實現(xiàn)難度較低,對性能要求較高時可采用多Coordinator多Worker架構(gòu)來提高系統(tǒng)的吞吐率,防止單一的Coordinator成為系統(tǒng)的瓶頸.理論上可通過增大Coordinator和Worker節(jié)點的數(shù)量達到近線性橫向拓展CLAIMS的數(shù)據(jù)注入處理能力. 2.2事務(wù)并發(fā)控制

2.2.1 事務(wù)對象模型

傳統(tǒng)數(shù)據(jù)采用頁模型和對象模型[20],其任何對數(shù)據(jù)的高層操作最終都要映射為一組對磁盤頁的Read/Write動作.內(nèi)存數(shù)據(jù)庫將表存放在內(nèi)存中,直接進行隨機讀寫操作,相比傳統(tǒng)數(shù)據(jù)庫減少很多限制.本文采用內(nèi)存條帶的概念描述事務(wù)執(zhí)行的對象,并以如下的三元組的形式描述內(nèi)存條帶s的概念:

s表示在分區(qū)part上,以該分區(qū)的起始地址記為0地址,在［pos,pos+length)之間的連續(xù)內(nèi)存空間.對于任意二個內(nèi)存條帶si和sj,如果滿足下面的條件,則稱si和sj是重疊的,表示為si∩sj=?;否則為不重疊,表示為si∩sj?.

類似頁模型,在內(nèi)存條帶s上,本文定義Read和Write二種基本操作,它們表示的含義如下所示:

Read(t,s):掃描分區(qū)s.part中［pos,pos+length)范圍內(nèi)的數(shù)據(jù);

Write(t,s,d):將分區(qū)s.part中［pos,pos+length)范圍內(nèi)的數(shù)據(jù)寫為d,其中t表示某一個事務(wù).

在分布式事務(wù)t的執(zhí)行中,需要對多個內(nèi)存條帶同時進行讀寫操作,所以本文稱一組內(nèi)存條帶的集合為內(nèi)存向量,如下所示:

在內(nèi)存向量上本文拓展了Map,Merge以及Filter三種輔助操作,如下所示:

·Map:該函數(shù)將單個內(nèi)存向量劃分成多個內(nèi)存向量的集合.

其中λ為劃分函數(shù),Map操作將所有λ函數(shù)值相同的內(nèi)存條帶劃分到同一個內(nèi)存向量.在本框架具體實現(xiàn)中,λ函數(shù)按part值進行劃分,每個part對應(yīng)一個內(nèi)存向量.

·Merge:該函數(shù)將內(nèi)存向量內(nèi)相鄰的內(nèi)存條帶進行合并,如下所示:

通過合并相鄰內(nèi)存條帶,多次的讀寫簡化為單次讀寫,有效地降低讀寫IO次數(shù),提高系統(tǒng)性能.

·Filter:該函數(shù)對內(nèi)存向量進行過濾,去除所包含的不滿足條件的內(nèi)存條帶.

其中f為過濾函數(shù),Filter函數(shù)將f函數(shù)值為false的內(nèi)存條帶過濾掉,僅保留結(jié)果為true的內(nèi)存條帶集.

通過引入內(nèi)存條帶上的Read/Write操作,以及內(nèi)存向量上的Map,Merge和Filter輔助操作,本文將復雜的分布式事務(wù)的執(zhí)行過程抽象成上述簡單操作的組合.

2.2.2 事務(wù)處理模型

在CLAIMS的數(shù)據(jù)注入框架中包括消息隊列MQ,1個用于集群資源管理的節(jié)點M,1個用于分布式事務(wù)管理的節(jié)點TM,n個用于執(zhí)行查詢和注入任務(wù)的工作節(jié)點,組成的集合為S.系統(tǒng)中每個節(jié)點i的機器都有m個可利用的處理器核心,組成的集合為Corei.CLAIMS集群中所有被創(chuàng)建的表的集合為T,并且每個表Ti對應(yīng)的分區(qū)的集合為PTi.為了簡化問題,本文統(tǒng)一地將所有表中的所有分區(qū)的集合定義為P.

數(shù)據(jù)注入過程中,交易系統(tǒng)將不斷產(chǎn)生的交易流水實時地不間斷地分批發(fā)送到作為中間件的消息隊列MQ中,并隨后被注入到CLAIMS中.對于某批次b中這些元組所對應(yīng)的分區(qū)的集合為Pb.對于某個分布式注入事務(wù)t,本文定義分區(qū)pi上的注入數(shù)據(jù)d的動作為Write(t,si,d),其中si是TM在pi上分配的內(nèi)存條帶,滿足si.part=pi∧pi∈Pb.當P′中所有分區(qū)上的操作都成功時,使用操作Commit(t)使注入的t所注入的數(shù)據(jù)對其他事務(wù)可見;否則調(diào)用Abort(t)撤銷t進行的所有修改.

在數(shù)據(jù)被實時地注入CLAIMS系統(tǒng)的同時,企業(yè)的分析用戶通過M節(jié)點向CLAIMS集群發(fā)送所要執(zhí)行的SQL查詢語句q.本文假設(shè)q執(zhí)行過程中所要掃描的分區(qū)的集合為Pq, Pq中每個分區(qū)上已提交的內(nèi)存條帶組成的集合記為sq.q在執(zhí)行過程中依次對sq中的每個內(nèi)存條帶都執(zhí)行Read操作,即可獲取查詢q所需數(shù)據(jù).

在數(shù)據(jù)庫的研究領(lǐng)域中,沖突可串行化提供了事務(wù)執(zhí)行所必需的隔離性,在商用系統(tǒng)中具有重要的應(yīng)用價值,通常被商用數(shù)據(jù)庫強制滿足并執(zhí)行.CLAIMS的實時注入引擎和查詢引擎所產(chǎn)生的調(diào)度利用寫寫分離策略保證寫事務(wù)之間的無沖突,利用多版本快照策略來保證讀寫分離,從而保證讀寫事務(wù)并發(fā)控制調(diào)度沖突可串行.

2.2.3 事務(wù)管理器

在分布式實時數(shù)據(jù)注入框架中,事務(wù)管理器(TM)主要對外提供三種服務(wù):第一是原子性分配注入事務(wù)所需的資源并維護事務(wù)在整個生命周期內(nèi)的狀態(tài)信息;第二是基于事務(wù)的狀態(tài)信息生成查詢事務(wù)所需要的事務(wù)快照,實現(xiàn)讀寫分離;第三是周期性地合并連續(xù)內(nèi)存上的連續(xù)事務(wù),依據(jù)合并的事務(wù)信息,幫助各個Worker節(jié)點發(fā)起數(shù)據(jù)持久化.

為了提供上述服務(wù)功能,TM節(jié)點在內(nèi)存中維護事務(wù)狀態(tài)表和內(nèi)存分配表.事務(wù)狀態(tài)表記錄并維護已創(chuàng)建事務(wù)的編號、事務(wù)提交狀態(tài)和分配內(nèi)存向量等信息.內(nèi)存分配表記錄每個數(shù)據(jù)分區(qū)的末尾地址,記錄下次分配內(nèi)存的起始地址.

考慮現(xiàn)代機器基本是多核多CPU,為了充分利用機器各CPU的性能,TM設(shè)計成多線程并發(fā)控制結(jié)構(gòu).對于TM所需要維護的兩個結(jié)構(gòu):事務(wù)狀態(tài)表和內(nèi)存分配記錄表,本文摒棄基于鎖的阻塞式策略,采用不同的多線程并發(fā)結(jié)構(gòu)實現(xiàn)非阻塞式的并發(fā)操作.

現(xiàn)代多級存儲器體系中,處理器和內(nèi)存之間通常有三級緩存(cache),緩存的訪問速度遠大于內(nèi)存.由于緩存大小有限,一般使用LRU算法[26]保存最近頻繁訪問的內(nèi)存,因此滿足“局部性”的程序可充分利用cache顯著提高程序運行速率.同時每個核有獨立的L1緩存,由硬件保障其一致性.某個緩存數(shù)據(jù)的修改會導致其他核的緩存無效,導致重新載入.

基于上述兩個cache特性,事務(wù)狀態(tài)表拋棄傳統(tǒng)的由多線程全局共享的方式,切分為多個線程局部的事務(wù)狀態(tài)子表,如圖3所示.每個事務(wù)子表由其獨占的線程負責讀、寫、回收等操作.基于線程局部的事務(wù)表切分方式避免多線程并發(fā)操作的沖突,并在一定程度上維持事務(wù)的多線程的性能加速,同時此方式將事務(wù)子表長久地保存于L1緩存中,免于緩存不命中,同時每個CPU只保存一部分的子表,相互間沒有交疊,避免出現(xiàn)緩存失效,減少因為子表頻繁換入換出緩存帶來的額外性能開銷.

當創(chuàng)建注入事務(wù),本文通過特定的策略確定其所在的事務(wù)狀態(tài)子表,并轉(zhuǎn)發(fā)任務(wù)給對應(yīng)工作線程.當讀事務(wù)獲取快照時,基于流水線執(zhí)行方式,對所有事務(wù)狀態(tài)表的工作線程發(fā)送創(chuàng)建快照的任務(wù),最后合并所有的子快照,得到最終的快照.具體步驟見章節(jié)2.3與2.4.

圖3 事務(wù)狀態(tài)表結(jié)構(gòu)Fig.3Transaction state table structure

內(nèi)存分配狀態(tài)表只有各自數(shù)據(jù)分區(qū)的尾部地址信息,所有對該表操作的沖突均來自對尾部地址的并發(fā)讀和寫,本文利用無鎖編程技術(shù),采用原子性操作來操作各自分區(qū)的尾部地址,實現(xiàn)非阻塞事務(wù)創(chuàng)建和事務(wù)資源無沖突的分配.每個注入事務(wù)在創(chuàng)建事務(wù)之前獲得其所需要的內(nèi)存空間大小,原子性地修改尾部地址,達到預(yù)分配內(nèi)存的目的,每個事務(wù)之間申請的資源沒有重疊,從而天然地支持無沖突事務(wù)并發(fā).

2.3 數(shù)據(jù)注入

CLAIMS系統(tǒng)底層以HDFS為文件存儲系統(tǒng),由于HDFS只支持數(shù)據(jù)追加到文件末尾而不支持原地修改,CLAIMS采用日志式存儲,注入的數(shù)據(jù)均以追加的模式添加到對應(yīng)分區(qū)的末尾.針對傳統(tǒng)數(shù)據(jù)庫支持的UPDATE操作,本文將其分解為兩個INSERT操作,分別在原表和隱藏的deleted表中各插入一條數(shù)據(jù),注入新值到原表之中,插入舊值到deleted表.查詢同時查詢兩張表,增加JOIN操作過濾舊值保留新值,等價于UPDATE操作.

TM節(jié)點對每個分布式注入事務(wù)分配互不重疊的內(nèi)存條帶,如圖4所示.因此CLAIMS系統(tǒng)在處理數(shù)據(jù)注入的過程中,對每個事務(wù)訪問的資源進行隔離,事務(wù)實現(xiàn)寫寫分離.得益于此,不同的注入事務(wù)可實現(xiàn)完全的并行執(zhí)行,同時事務(wù)不會因為相互沖突而中止,大幅減少事務(wù)的失敗率.只有事務(wù)涉及的每個內(nèi)存條帶上的注入都成功執(zhí)行,提交事務(wù),之后注入的數(shù)據(jù)即時可見.

圖4 事務(wù)內(nèi)存分配圖Fig.4Memory allocation for transaction

注入事務(wù)的完整執(zhí)行過程分為如下步驟,如圖5所示.

1.數(shù)據(jù)到達:Coordinator節(jié)點從MQ中讀取最新的數(shù)據(jù)包,開始執(zhí)行數(shù)據(jù)注入過程.

2.創(chuàng)建事務(wù):Coordinator節(jié)點解析獲得注入的若干條元組,并按照每個元組對應(yīng)的分區(qū)進行劃分.計算該事務(wù)在每個分區(qū)上的內(nèi)存需求量后,Coordinator向TM發(fā)起創(chuàng)建注入事務(wù)t的請求.TM節(jié)點分配t執(zhí)行所需資源,例如事務(wù)ID,所注入的內(nèi)存條帶等,并返回申請者.這些操作同步地追加到磁盤中的日志文件,用于故障后恢復TM.發(fā)起事務(wù)后給消息隊列MQ發(fā)送確認信息.

3.數(shù)據(jù)注入:Coordinator創(chuàng)建事務(wù)成功后,按照分區(qū)的劃分將元組進行打包,生成數(shù)據(jù)日志,并發(fā)送到對應(yīng)分區(qū)所在的Worker節(jié)點上.數(shù)據(jù)日志中包含對應(yīng)的內(nèi)存條帶以及所要注入的數(shù)據(jù).Worker節(jié)點收到數(shù)據(jù)日志,按照日志的內(nèi)容將數(shù)據(jù)注入對應(yīng)的內(nèi)存條帶中,并反饋結(jié)果給Coordinator.

4.日志遷移:Worker節(jié)點完成注入操作后,轉(zhuǎn)發(fā)數(shù)據(jù)日志到其他Worker節(jié)點上進行備份,最后給Coordinator發(fā)送確認信息.

5.提交事務(wù):Coordinator完成分布式數(shù)據(jù)注入后根據(jù)各Worker節(jié)點的反饋向TM節(jié)點請求提交事務(wù)或者撤銷事務(wù).TM將事務(wù)的提交或撤銷記錄在磁盤的日志文件中.

6.數(shù)據(jù)持久化:Worker節(jié)點周期性將各個分區(qū)在內(nèi)存中已提交的數(shù)據(jù)整理并寫入HDFS中,將注入CLAIMS的數(shù)據(jù)持久化.一旦寫入HDFS成功,即認為數(shù)據(jù)不會丟失.

圖5 數(shù)據(jù)注入流程圖Fig.5Data ingestion flow chart

2.4 數(shù)據(jù)查詢分析

為了保證實時查詢結(jié)果的一致性,本文支持事務(wù)執(zhí)行的隔離性,并提供已提交讀,可重復讀,沖突可串行化等隔離級別[11].CLAIMS系統(tǒng)中使用多版本并發(fā)控制,對每個讀事務(wù)都創(chuàng)建事務(wù)快照,實現(xiàn)快照隔離級別,保證事務(wù)之間的隔離性.本框架對TM節(jié)點管理的元數(shù)據(jù)進行多版本控制而不是數(shù)據(jù)本身的多版本控制.

本文引入“快照”的概念來描述數(shù)據(jù)庫某個一致性版本的子集.本文定義分區(qū)集合P上已提交的內(nèi)存條帶的集合為快照SP,如下所示:

其中t.v為事務(wù)t所申請的內(nèi)存向量,t.commit為事務(wù)t的提交狀態(tài).當獲取到SP后,本文通過遍歷SP所包含的內(nèi)存條帶,并依次調(diào)用Read來讀取P分區(qū)集合上的數(shù)據(jù).為了減少Read操作執(zhí)行的次數(shù),以降低開銷,本文利用定義的Map和Merge函數(shù)對快照SP進行化簡.首先將SP利用Map函數(shù)按照分區(qū)進行劃分,得到每個分區(qū)的快照的集合ΠP,如下所示:

對ΠP中每個快照使用Merge函數(shù)合并相鄰的內(nèi)存條帶,得到簡化后的Π′P:

Coordinator接受用戶的SQL查詢,通過數(shù)據(jù)字典管理器獲取要查詢的表,進而確定需要進行掃描的分區(qū)集合P,向TM節(jié)點申請獲取在P上的最簡化的內(nèi)存快照.編譯后的查詢計劃中的Scan算子通過對所有內(nèi)存中的數(shù)據(jù)進行過濾,只讀取在中的數(shù)據(jù).通過每個Core獲取快照方式是基于流水線方式,如圖6所示.從第一個Core向其加入本地的已提交事務(wù)立即轉(zhuǎn)發(fā)給下一個Core,同時處理下一個讀事務(wù)的請求.基于Pipeline的處理方式最大程度地提高每個核的利用率,增加事務(wù)的吞吐量,在事務(wù)足夠多的理想情況下,雖然每個Core都是單線程,實現(xiàn)的性能接近多線程并行的性能.本框架的事務(wù)管理器避免因多線程處理之間并發(fā)操作帶來的鎖或其他控制結(jié)構(gòu)的額外開銷,且基本達到多線程處理的性能,實現(xiàn)非阻塞式事務(wù)處理,具有較高的工程創(chuàng)新意義.

上述可得,本文設(shè)計的事務(wù)管理器支持事務(wù)的強一致性.一旦事務(wù)提交,后續(xù)的讀事務(wù)都能立刻訪問這個提交事務(wù)的元數(shù)據(jù)快照,已提交事務(wù)的結(jié)果能即時訪問.

2.5 高可用方案

在金融領(lǐng)域,用戶需要實時地訪問、分析、修改金融交易數(shù)據(jù),而且服務(wù)方不能中斷或停機,一旦無法提供服務(wù),會給企業(yè)造成無法估算的損失.尤其是數(shù)據(jù)庫系統(tǒng)需要保證提供不間斷的數(shù)據(jù)服務(wù),盡量減少系統(tǒng)處于不可用狀態(tài)的時間,做到數(shù)據(jù)庫的高可用性.

圖6 實時數(shù)據(jù)查詢流程圖Fig.6Real-time data query flow chart

本文設(shè)計的數(shù)據(jù)注入框架考慮到滿足系統(tǒng)的高可用性,采用雙機熱備等方案.CLAIMS是基于內(nèi)存的數(shù)據(jù)庫,相對于傳統(tǒng)的磁盤數(shù)據(jù)庫,出錯率相對較低,在兩臺機器上備份數(shù)據(jù)在絕大部分情況下可滿足需求.如圖5所示,Worker在接收到Coordinator節(jié)點發(fā)送過來的子事務(wù)請求后,一方面將該日志格式的數(shù)據(jù)轉(zhuǎn)發(fā)給綁定的另一臺熱備機器上,另一方面將數(shù)據(jù)切實地寫入到本機的內(nèi)存中,兩者并行,可壓縮Worker工作的時間.兩個操作均完成后,給Coordinator發(fā)送反饋.熱備機器收到日志后,在本機回放日志,再發(fā)送確認消息給Worker,保證Worker與熱備機器維護有相同的數(shù)據(jù),一旦原Worker出錯或者宕機,系統(tǒng)快速將請求轉(zhuǎn)發(fā)給熱備機器,理論上系統(tǒng)的不可用時間僅相當于請求切換時間,保證極高的可用性.

同樣地,事務(wù)管理器全局唯一,有宕機后導致整個系統(tǒng)不可用的風險.事務(wù)管理器同樣支持熱備,實時地將事務(wù)日志發(fā)送給備機,同時備機在本機上重做所有事務(wù)日志.

3 實驗

前文已經(jīng)提及,在分布式工具中,只有VoltDB支持事務(wù)型的數(shù)據(jù)實時注入和數(shù)據(jù)實時查詢,因此將其作為本文的實驗對比對象.對于CLAIMS,由TM獨占一臺機器,設(shè)置12個線程運行,另一臺機器負責發(fā)起注入事務(wù);對于VoltDB,一臺機器作為其master,設(shè)置注入器sites為12,另一臺機器負責發(fā)起注入事務(wù).測試服務(wù)器基于CentOS release 6.5(Final)系統(tǒng),CPU型號為Intel(R)Xeon(R)CPU E5-2620 0@2.00 GHz,雙路,共12核,可超線程到24核,機器擁有165 G內(nèi)存和100 G以上大小的硬盤以及千兆網(wǎng)卡.本文采用TPC-H基準測試集的LINEITEM表作為數(shù)據(jù)注入的實驗數(shù)據(jù)集.本文假設(shè)每個批次的注入事務(wù)包括150個元組,每個元組大小為200字節(jié),數(shù)據(jù)由TPC-H數(shù)據(jù)生成器生成.

實驗1測試4臺機器,在每個機器分布一個partition的環(huán)境下,不同注入線程數(shù)下CLAIMS與VoltDB的吞吐量及其單個注入時延,結(jié)果如圖7所示.實驗結(jié)果顯示:在不同線程數(shù)下,CLAIMS系統(tǒng)的注入引擎的事務(wù)吞吐量均遠大于VoltDB.隨著注入線程數(shù)不斷增大,在不超過機器物理核數(shù)量時,CLAIMS的吞吐量大幅增加,時延基本穩(wěn)定在10 ms之內(nèi),直到線程數(shù)約等于機器物理核數(shù)量時,其吞吐量達到上限,穩(wěn)定在1300TPS左右.線程數(shù)繼續(xù)增大到16線程,由于各注入線程競爭CPU,導致其吞吐量開始大幅下降,同時事務(wù)時延急劇增加.VoltDB在線程數(shù)為3時達到其吞吐量的峰值,其后略降,穩(wěn)定在60TPS,其事務(wù)時延隨著注入線程數(shù)量增長呈線性遞增趨勢.實驗說明CLAIMS在不超過物理核數(shù)的線程數(shù)下能提供極高的事務(wù)吞吐量和極低的時延,完全滿足大量實時注入任務(wù)的需求,同時充分利用機器的性能,對比VoltDB具有較大的性能優(yōu)勢.

圖7 實驗1測試結(jié)果Fig.7Result of experiment 1

實驗2測試4臺機器,在采用12個注入線程的環(huán)境下,不同partition(均勻分布在4臺機器上)下兩個系統(tǒng)的吞吐量和時延,實驗結(jié)果如圖8所示.實驗表明,在不同partition數(shù)量下,CLAIMS仍提供較高的注入事務(wù)吞吐量,遠大于VoltDB的性能.兩者的吞吐量都隨著partition數(shù)量的增大而下降,主要因為單個事務(wù)被分解為更多的子事務(wù)處理(每個partition作為一個子事務(wù)).在單次注入平均時延方面,CLAIMS在partition較少時延遲遠低于VoltDB,在partitions per machine=3左右,急劇增長,因為當前版本的CLAIMS在Worker上僅實現(xiàn)了單線程處理,因此在達到單線程處理極限后延遲大幅增加,在partition數(shù)量較大時,增速放緩.Worker上的優(yōu)化將作為后續(xù)工作進行.VoltDB的單次事務(wù)延時隨partition數(shù)量增加呈現(xiàn)線性增長趨勢,在partition數(shù)量較大時相比CLAIMS具有一定優(yōu)勢.

圖8 實驗2測試結(jié)果Fig.8Result of experiment 2

實驗3測試基于TPC-H數(shù)據(jù)集在4臺機器各分布1個partition的環(huán)境下,實時注入時實時SQL查詢的延時情況,并進行對比,結(jié)果如表1所示.實驗結(jié)果顯示,實時注入對大部分實時查詢的性能影響較小,基本延時增長在10%以內(nèi),查詢達到秒級響應(yīng),但對于長查詢,影響稍大,達到12%,仍處于可接受范圍之內(nèi).總體來看,實時注入框架能保證數(shù)據(jù)的實時查詢不受較大影響.

表1 實驗3測試結(jié)果Tab.1Result of experiment 3

4 總結(jié)

分布式環(huán)境下,事務(wù)型實時數(shù)據(jù)注入在電信、金融和電子商務(wù)等領(lǐng)域有著巨大的需求和廣泛的應(yīng)用前景.本文介紹了目前分布式數(shù)據(jù)實時注入的研究現(xiàn)狀,闡述事務(wù)并發(fā)控制的幾種方式,面向自主研發(fā)的分布式內(nèi)存數(shù)據(jù)庫CLAIMS,設(shè)計了一套高可用、高性能、高通量的分布式數(shù)據(jù)實時注入框架,保證了數(shù)據(jù)的實時注入,同時結(jié)合CLAIMS的執(zhí)行引擎提供實時的數(shù)據(jù)分析查詢,詳細說明了數(shù)據(jù)注入和數(shù)據(jù)查詢的整個流程.經(jīng)試驗證明,本文所提出的實時數(shù)據(jù)注入框架具有良好的性能,并能提供實時的數(shù)據(jù)注入服務(wù)和實時數(shù)據(jù)分析服務(wù),能夠較好滿足金融等領(lǐng)域的實際需求.

［1］DEAN J,GHEMAWAT S.MapReduce:Simplified data processing on large clusters[J].Communications of the ACM,2008,51(1):107-113.

［2］ZAHARIA M,CHOWDHURY M,FRANKLIN M J,et al.Spark:Cluster computing with working sets [C]//Proceedings of the 2nd USENIX Conference on Hot Topics in Cloud Computing.Berkeley:USENIX Association,2010:10.

［3］SHVACHKO K,KUANG H,RADIA S,et al.The hadoop distributed file system[C]//Proceedings of IEEE Conference on MSST.2010:1-10.

［4］胡健,和軼東.SAP內(nèi)存計算--HANA[M].北京:清華大學出版社,2013.

［5］F?RBER F,CHA S K,PRIMSCH J,et al.SAP HANA database:Data management for modern business applications[J].ACM Sigmod Record,2012,40(4):45-51.

［6］GLIGOR G,TEODORU S.Oracle exalytics:Engineered for speed-of-thought analytics[J].Database Systems Journal,2011,2(4):3-8.

［7］WANG L,ZHOU M Q,ZHANG Z J,et al.Elastic pipelining in in-memory DataBase cluster[R].2016.

［8］TRAVERSO M.Presto:Interacting with petabytes of data at Facebook[EB/OL].(2013-11-07)[2016-06-10]. http://www.facebook.com/notes/facebook-engineering/presto-interacting-with-petabytes-of-data-at-facebook/ 10151786197628920.

［9］ARMBRUST M,XIN R S,LIAN C,et al.Spark SQL:Relational data processing in spark[C]//Proceedings of the 2015 ACM SIGMOD International Conference on Management of Data.ACM,2015:1383-1394.

［10］YANG F,TSCHETTER E,LéAUTé X,et al.Druid:A real-time analytical data store[C]//Proceedings of the 2014 ACM SIGMOD International Conference on Management of Data.2014.

［11］GARCIA-MOLINA H,ULLMAN J D,WIDOM J.Database System Implementation[M].Upper Saddle River, NJ:Prentice Hall,2000.

［12］NAGA P N.Real-time Analytics at Massive Scale with Pinot[EB/OL].[2016-06-10].https://engineering. linkedin.com/analytics/real-time-analytics-massive-scale-pinot.

［13］KREPS J,NARKHEDE N,RAO J,et al.Kafka:A distributed messaging system for log processing [C]//Proceedings of the NetDB.2011:1-7.［14］LAMB A,FULLER M,VARADARAJAN R,et al.The vertica analytic database:C-store 7 years later [C]//Proceedings of the VLDB Endowment.2012:1790-1801.

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

［16］STONEBRAKER M,WEISBERG A.The VoltDB main memory DBMS[J].IEEE Data Eng Bull,2013:21-27.

［17］BRYANT R E,O′HALLARON D R.深入理解計算機系統(tǒng)[M].北京:機械工業(yè)出版社,2013.

［18］ESWARAN K P,GRAY J N,LORIE R A,et al.The notions of consistency and predicate locks in a database system[J].Communications of the ACM,1976,19(11):624-633.

［19］STONEBRAKER M.One Size Fits None-(Everything You Learned in Your DBMS Class is Wrong)[R/OL]. (2013-05-30)[2016-07-01].http://slideshot.epfl.ch/talks/166.

［20］WEIKUM G,VOSSEN G.Transactional Information Systems:Theory,Algorithms,and the Practice of Concurrency Control and Recovery[M].San Francisco:Morgan Kaufmann Publishers,2002.

［21］DIACONU C,FREEDMAN C,ISMERT E,et al.Hekaton:SQL server’s memory-optimized OLTP engine [C]//Proceedings of the 2013 ACM SIGMOD International Conference on Management of Data.2013.

［22］MICHAEL M M.High performance dynamic lock-free hash tables and list-based sets[C]//Proceedings of the 14th Annual ACM Symposium on Parallel Algorithms and Architectures.2002:73-82.

［23］LAMPSON B W,STURGIS H E.Crash Recovery in a Distributed Data Storage System[R].Palo Alto,California: Xerox Palo Alto Research Center,1979.

［24］SKEEN D.Nonblocking commit protocols[C]//Proceedings of the 1981 ACM SIGMOD International Conference on Management of Data.1981.

［25］HAN J,HAIHONG E,LE G,et al.Survey on NoSQL database[C]//Proceedings of the 2011 6th International Conference on Pervasive Computing and Applications.2011:363-366.

［26］O’NEIL E J,O’NEIL P E,WEIKUM G.The LRU-K page replacement algorithm for database disk buffering [C]//Proceedings of the ACM SIGMOD International Conference on Management of Data.1993:297-306.

(責任編輯:林磊)

Research and implementation of transactional real-time data ingestion technology without blocking

YU Kai,LI Zhi-fang,ZHOU Min-qi,ZHOU Ao-ying
(Institue for Data Science and Engineering,East China Normal University, Shanghai200062,China)

With the advent of big data era,traditional database systems are facing difficulties in satisfying the new challenges brought by massive data processing,while distributed database systems have been deployed widely in real applications.Distributed database systems partitioned and the dispatched the data across machines under a designed scheme and analyzed all the massive data in massive parallel manner.In facing of the requirements of the transactional real-time data ingestion from financial field, distributed database systems are ineffective and inefficient due to their implementation ofthe distributed transaction processing based on the lock and two-phase commit,which lead to the impossibility of non-blocking data ingestion.CLAIMS is a distributed in-memory database system designed and implemented by Institute for Data Science and Engineering of ECNU.It supports real-time data analysis towards relational data set but is incapable of real-time data ingestion.To address these problems,we analyzed data ingestion technology and distributed transaction processing algorithms first,and proposed to mimic the transactional data ingestion in the distributed environment with the centralized transaction processing based on meta data,and eventually achieved the real-time data ingestion with high availability and without blocking.The experiment results with the implementation of the proposed algorithms in CLAIMS proved that the proposed framework could achieve high throughput transactional real-time data ingestion as well as low latency real-time query processing.

distributed database system;real-time data ingestion;transaction processing;CLAIMS

TP392

A

10.3969/j.issn.1000-5641.2016.05.015

1000-5641(2016)05-0131-13

2016-05

國家自然科學基金重點項目(61332006),上海市基金(13ZR1413200)

余楷,男,碩士研究生.研究方向為內(nèi)存數(shù)據(jù)庫系統(tǒng).E-mail:yukai@gmail.com.

周敏奇,男,副教授.研究方向為對等計算、云計算、分布式數(shù)據(jù)管理、內(nèi)存數(shù)據(jù)管理系統(tǒng). E-mail:mqzhou@sei.ecnu.edu.cn.