圖引擎底層存儲(chǔ)的設(shè)計(jì)與實(shí)現(xiàn)

馬洪賓,陳貴海

(上海交通大學(xué)計(jì)算機(jī)科學(xué)與工程系,上海200240)

圖引擎底層存儲(chǔ)的設(shè)計(jì)與實(shí)現(xiàn)

馬洪賓,陳貴海

(上海交通大學(xué)計(jì)算機(jī)科學(xué)與工程系,上海200240)

隨著社交網(wǎng)絡(luò)和語(yǔ)義Web等數(shù)據(jù)應(yīng)用的興起,催生了許多圖數(shù)據(jù)處理產(chǎn)品,包括Neo4j,HyperGraphDB等,然而這些產(chǎn)品在設(shè)計(jì)時(shí)并未充分考慮圖應(yīng)用對(duì)數(shù)據(jù)可用性和可擴(kuò)展性的更高要求。為此,提出一種基于分布式內(nèi)存云的圖引擎底層建模和存儲(chǔ)解決方案。在內(nèi)存云上搭建分布式鍵值引擎,進(jìn)而在鍵值存儲(chǔ)的基礎(chǔ)上對(duì)圖的數(shù)據(jù)進(jìn)行建模和讀寫(xiě)。在大規(guī)模數(shù)據(jù)集上的實(shí)驗(yàn)結(jié)果表明,該方案具有較好的圖隨機(jī)訪問(wèn)性能,并能夠高效地支持海量規(guī)模的圖數(shù)據(jù)應(yīng)用。

圖處理;云計(jì)算;分布式;數(shù)據(jù)建模;存儲(chǔ);數(shù)據(jù)結(jié)構(gòu)

1 概述

圖是最常見(jiàn)的數(shù)據(jù)結(jié)構(gòu)之一,與線性表和樹(shù)相比,它的結(jié)構(gòu)更加復(fù)雜,對(duì)數(shù)據(jù)的表現(xiàn)能力也更豐富。傳統(tǒng)的圖應(yīng)用包括道路分析［1］、論文引用分析［2］、網(wǎng)頁(yè)鏈接分析［3］等。 隨著社交網(wǎng)絡(luò)［4-5］、語(yǔ)義網(wǎng)絡(luò)［6］等研究領(lǐng)域的興起,由于圖在表示實(shí)體間關(guān)系方面的顯著優(yōu)勢(shì),因此越來(lái)越多的研究嘗試使用圖來(lái)存儲(chǔ)和挖掘數(shù)據(jù)。

學(xué)術(shù)界和工業(yè)界已有大量工作致力于圖的應(yīng)用和理論研究。截止目前,已有很多圖數(shù)據(jù)庫(kù)產(chǎn)品可供選擇。但是隨著數(shù)據(jù)規(guī)模的日益增長(zhǎng),圖的規(guī)模也隨之呈現(xiàn)爆發(fā)式增長(zhǎng)的趨勢(shì)。如何有效地存儲(chǔ)和使用海量規(guī)模的圖數(shù)據(jù)集,成為圖數(shù)據(jù)庫(kù)領(lǐng)域內(nèi)的一大難題。

本文結(jié)合圖數(shù)據(jù)應(yīng)用對(duì)可用性和可擴(kuò)展性的要求,提出一種基于分布式內(nèi)存Key-Value引擎的圖數(shù)據(jù)存儲(chǔ)和建模方案,介紹底層使用的分布式內(nèi)存云引擎,根據(jù)圖應(yīng)用對(duì)數(shù)據(jù)建模的需求分析建模技術(shù),并將已知的語(yǔ)義Web數(shù)據(jù)集導(dǎo)入到系統(tǒng)中,對(duì)系統(tǒng)性能進(jìn)行全面分析。

2 圖數(shù)據(jù)應(yīng)用及其挑戰(zhàn)

2.1 使用圖數(shù)據(jù)結(jié)構(gòu)進(jìn)行數(shù)據(jù)建模的優(yōu)勢(shì)

在已知的大數(shù)據(jù)問(wèn)題中,有很大一部分的問(wèn)題可以由圖進(jìn)行更為直觀的建模。而且這種直觀的建模方式可以帶來(lái)高效的數(shù)據(jù)讀寫(xiě)效率。以社交網(wǎng)絡(luò)為例,網(wǎng)絡(luò)中的兩大元素:人物與人物之間的關(guān)系,可以分別對(duì)應(yīng)到圖里面的頂點(diǎn)和邊。假設(shè)采用鄰接表的形式存儲(chǔ)圖的邊,那么所有的邊都可以保存在頂點(diǎn)上。人物的一些屬性,例如姓名、年齡等,可以作為頂點(diǎn)的屬性存放在頂點(diǎn)內(nèi)。與此相對(duì)地,也可以使用關(guān)系數(shù)據(jù)庫(kù)將數(shù)據(jù)建模成為一個(gè)人物表和一個(gè)朋友關(guān)系表。當(dāng)客戶(hù)端程序需要獲取某個(gè)特定人物的朋友列表時(shí),假設(shè)采用圖建模的方式,程序可以首先找到代表該人物的圖頂點(diǎn),然后通過(guò)一次頂點(diǎn)內(nèi)的訪問(wèn)獲得其所有鄰居。而在關(guān)系數(shù)據(jù)庫(kù)中,需要將朋友關(guān)系表與人物表進(jìn)行一次內(nèi)聯(lián)結(jié)才能達(dá)到相同目的。當(dāng)然,用戶(hù)可以選擇對(duì)朋友關(guān)系表中的外鍵來(lái)加速這一過(guò)程,但這又勢(shì)必會(huì)帶來(lái)了額外開(kāi)銷(xiāo)。

無(wú)論是在單機(jī)的多核計(jì)算處理器上,還是在分布式環(huán)境中的多機(jī)多處理器環(huán)境下,對(duì)并行計(jì)算是否友好都已經(jīng)成為衡量一個(gè)模型好壞的重要標(biāo)準(zhǔn)。在圖模型的領(lǐng)域,以頂點(diǎn)為中心的計(jì)算模型因?yàn)樗暮?jiǎn)單性、可擴(kuò)展性和靈活性而被廣泛地采用。在以頂點(diǎn)為中心的計(jì)算模型中,每個(gè)頂點(diǎn)都可以成為最細(xì)粒度的計(jì)算單元,一個(gè)或者多個(gè)頂點(diǎn)的計(jì)算工作可以由同一個(gè)操作系統(tǒng)線程或進(jìn)程負(fù)責(zé),以頂點(diǎn)為中心的計(jì)算模型可以將工作量自然地切割,并且適用于同步和異步、集中式和分布式的計(jì)算模型。

2.2 圖數(shù)據(jù)庫(kù)面臨的挑戰(zhàn)

傳統(tǒng)的圖數(shù)據(jù)庫(kù)面臨可用性與可擴(kuò)展性［7］之間的博弈。傳統(tǒng)圖數(shù)據(jù)庫(kù)可以粗略地分為以下3類(lèi):

(1)基于磁盤(pán)存儲(chǔ)的單機(jī)實(shí)現(xiàn)

已有的借助磁盤(pán)存儲(chǔ)空間的單機(jī)圖數(shù)據(jù)庫(kù),雖然能夠在假設(shè)磁盤(pán)空間沒(méi)有限制的前提下,克服數(shù)據(jù)的規(guī)模問(wèn)題。根據(jù)程序訪問(wèn)局部性原理,這類(lèi)圖數(shù)據(jù)庫(kù)也可以在內(nèi)存中緩存適量的緩存,以期減少數(shù)據(jù)訪問(wèn)的開(kāi)銷(xiāo)。然而,圖應(yīng)用的隨機(jī)訪問(wèn)性質(zhì)決定了程序在圖中對(duì)頂點(diǎn)的訪問(wèn)呈現(xiàn)隨機(jī)的特征,因此難以找到一種簡(jiǎn)單通用的緩存算法來(lái)加速數(shù)據(jù)訪問(wèn)。而大量的隨機(jī)讀寫(xiě)是對(duì)磁盤(pán)訪問(wèn)速度的災(zāi)難。因此,基于磁盤(pán)的解決方案會(huì)帶來(lái)不能接受的性能問(wèn)題。

(2)基于MapReduce/Hadoop的實(shí)現(xiàn)

這類(lèi)實(shí)現(xiàn)的典型代表為PEGASUS［8］,一個(gè)基于Hadoop的分布式圖信息挖掘系統(tǒng)。Hadoop對(duì)應(yīng)Google的分布式計(jì)算框架MapReduce［9］,它的文件系統(tǒng)HFS(Hadoop File System)對(duì)應(yīng)于MapReduce的GFS(Google File System)［10］。圖數(shù)據(jù)以文件的形式存放在HFS中。雖然這類(lèi)實(shí)現(xiàn)在可擴(kuò)展性和容錯(cuò)性方面得到了保證,但是Hadoop的計(jì)算模型與圖數(shù)據(jù)上的計(jì)算需求并不完全匹配。Hadoop的作業(yè)調(diào)度與任務(wù)分配要求對(duì)數(shù)據(jù)的反復(fù)讀寫(xiě),這造成了同樣的圖信息被反復(fù)地在磁盤(pán)中讀寫(xiě),增加了系統(tǒng)的 I/O開(kāi)銷(xiāo)。另外,為離線數(shù)據(jù)分析而設(shè)計(jì)的Hadoop也不能滿(mǎn)足對(duì)反應(yīng)時(shí)間具有更高要求的在線圖數(shù)據(jù)查詢(xún)需求。

(3)基于分布式和列式存儲(chǔ)的實(shí)現(xiàn)

在MapReduce后,Google相繼推出了基于GFS的列存儲(chǔ)引擎BigTable［11］以及Dremel［12］。這類(lèi)列式儲(chǔ)引擎將數(shù)據(jù)的不同維度(列)單獨(dú)存儲(chǔ),并且可以靈活地根據(jù)數(shù)據(jù)的使用頻率,將某些常用維度的數(shù)據(jù)配置在內(nèi)存中,以減少磁盤(pán)I/O,提高讀寫(xiě)性能。列式存儲(chǔ)需要對(duì)數(shù)據(jù)模型具有嚴(yán)格定義。在圖數(shù)據(jù)中,使用鄰接表來(lái)表示頂點(diǎn)間的關(guān)系。鄰接表的一個(gè)基本性質(zhì)是其長(zhǎng)度可變,而像BigTable這樣的列式存儲(chǔ)引擎對(duì)這一性質(zhì)并無(wú)很好的支持?？勺冮L(zhǎng)、可嵌套、可重復(fù)的列成員在Dremel中被引入,但是由于Dremel是一個(gè)只讀的交互式在線分析系統(tǒng),圖數(shù)據(jù)的頂點(diǎn)增加/刪除、關(guān)系的增加/刪除就無(wú)法被支持。

3 基于分布式內(nèi)存云的圖引擎存儲(chǔ)解決方案

3.1 分布式內(nèi)存云引擎——Trinity

Trinity是微軟亞洲研究院設(shè)計(jì)并實(shí)現(xiàn)的服務(wù)于云計(jì)算的一款輕量的高性能分布式內(nèi)存Key-Value存儲(chǔ)引擎［13］。在Trinity系統(tǒng)中,所有數(shù)據(jù)都被保存在內(nèi)存云中,因此能夠支撐每秒數(shù)百萬(wàn)次的隨機(jī)讀寫(xiě)。另外,Trinity支持通過(guò)配置服務(wù)器集群的方式,靈活地調(diào)整系統(tǒng)的服務(wù)能力［14］。Trinity向客戶(hù)端提供以下統(tǒng)一接口:

Trinity作為一個(gè)Key-Value存儲(chǔ)引擎,其中的Key僅限長(zhǎng)整數(shù)類(lèi)型,而Value則是一段不定長(zhǎng)的字節(jié)數(shù)組,稱(chēng)為BLOB。因此,Trinity可以看作是一個(gè)long-＞BLOB的Key-Value存儲(chǔ)引擎。

從單機(jī)角度觀察,Trinity在啟動(dòng)時(shí)向操作系統(tǒng)申請(qǐng)大塊的內(nèi)存,用以對(duì) BLOB進(jìn)行動(dòng)態(tài)儲(chǔ)存。Trinity封裝了高效的內(nèi)存管理模塊,可以進(jìn)行高效的垃圾收集和內(nèi)存清理。另外,Trinity提供細(xì)粒度的鎖機(jī)制,保證對(duì)于單個(gè)鍵值對(duì)的修改是原子的。從集群角度觀察,每個(gè)Trinity的服務(wù)器實(shí)例負(fù)責(zé)維護(hù)一批BLOB,Trinity系統(tǒng)通過(guò)對(duì)Key的哈希對(duì)不同BLOB進(jìn)行分割。各個(gè)實(shí)例之間由高速以太網(wǎng)互聯(lián)。

3.2 在BLOB上的圖頂點(diǎn)建模

Trinity中的每個(gè)BOLB都是獨(dú)立的個(gè)體,彼此之間互相獨(dú)立,且每個(gè)BLOB擁有全局唯一的長(zhǎng)整數(shù)標(biāo)識(shí)符。在BLOB的不同區(qū)間段內(nèi)存儲(chǔ)不同的信息,可以自然地將BLOB隱射成圖數(shù)據(jù)中的頂點(diǎn),如圖1所示。每個(gè)頂點(diǎn)中存儲(chǔ)的信息可以分為兩部分:屬性和邊。然而,BLOB只是簡(jiǎn)單的字節(jié)數(shù)組,無(wú)法為上層應(yīng)用提供更多數(shù)據(jù)格式的信息。因此,需要在BLOB上搭建數(shù)據(jù)訪問(wèn)層,以便上層圖處理程序能夠有效獲得感興趣的圖信息。

圖1 每個(gè)BLOB視作一個(gè)圖頂點(diǎn)的情況

圖的應(yīng)用千變?nèi)f化,對(duì)圖頂點(diǎn)和邊的定義也會(huì)存在巨大差異。例如,一個(gè)典型社交網(wǎng)絡(luò)可能需要定義人物這樣的圖頂點(diǎn),也需要把人物和人物之間的關(guān)系定義為圖中的邊。而在一個(gè)語(yǔ)義Web的圖應(yīng)用中,用戶(hù)可能更希望將任意的主語(yǔ)和賓語(yǔ)定義為圖頂點(diǎn),而將謂詞定義為圖中的關(guān)系?？偠灾?一個(gè)通用的圖引擎無(wú)法提前預(yù)知圖應(yīng)用所需的數(shù)據(jù)結(jié)構(gòu),因此允許用戶(hù)提前對(duì)圖的結(jié)構(gòu)進(jìn)行定義。例如,社交網(wǎng)絡(luò)中的人物頂點(diǎn)可以由以下語(yǔ)句定義:

根據(jù)定義,所有人物頂點(diǎn)的實(shí)例都由一個(gè)整數(shù)記錄其年齡,一個(gè)字符串記錄其姓名,還有一個(gè)可變長(zhǎng)的長(zhǎng)整數(shù)容器記錄其所有朋友的標(biāo)識(shí)符。對(duì)頂點(diǎn)的定義模仿了面向?qū)ο笳Z(yǔ)言(例如Java)中對(duì)類(lèi)的定義。然而,在實(shí)際存儲(chǔ)方式上卻完全不同。在面向?qū)ο笳Z(yǔ)言中,對(duì)象只保存各個(gè)非基本類(lèi)型成員的引用,成員具體的內(nèi)容保存在堆上,其物理地址并不一定相鄰。而在實(shí)現(xiàn)中,由于需要將圖頂點(diǎn)所有的信息保存到一段BLOB中,成員會(huì)按序依次排列,所有成員在存儲(chǔ)邏輯地址上是保證相鄰的,稱(chēng)為線性排列。

采用基于BLOB的線性排列,而不采用類(lèi)似于面向?qū)ο笳Z(yǔ)言基于堆的儲(chǔ)存方式的主要原因有以下2個(gè)方面:

(1)前者相對(duì)于后者更具空間優(yōu)勢(shì)。為了克服傳統(tǒng)圖數(shù)據(jù)庫(kù)在可用性上的瓶頸,達(dá)到最高效的訪問(wèn)速度來(lái)適應(yīng)圖的隨機(jī)訪問(wèn)性質(zhì),考慮將大部分的圖數(shù)據(jù)放入內(nèi)存中。盡管采用分布式的內(nèi)存云引擎作為底層存儲(chǔ),但是考慮到內(nèi)存云的代價(jià),更經(jīng)濟(jì)有效地利用內(nèi)存空間仍然具有重要的意義。以對(duì)象為單元存儲(chǔ)圖頂點(diǎn),涉及到引用類(lèi)型的開(kāi)銷(xiāo),以及對(duì)象本身的開(kāi)銷(xiāo)(例如對(duì)象上的鎖)等。事實(shí)上,在64 bit.NET平臺(tái)上,一個(gè)空對(duì)象也需要占據(jù)12 Byte的空間。因此,以BLOB的形式存儲(chǔ)圖頂點(diǎn)更具空間優(yōu)勢(shì)。

(2)以BLOB形式存儲(chǔ)的節(jié)點(diǎn)更有利于在分布式環(huán)境中分發(fā)傳送。在不同機(jī)器間傳送對(duì)象,需要首先在發(fā)送端將對(duì)象序列化成字節(jié)序列,然后通過(guò)網(wǎng)絡(luò)傳送至接收端,并由接收端負(fù)責(zé)將字節(jié)序列反序列化成對(duì)象,單個(gè)對(duì)象的序列化和反序列化的開(kāi)銷(xiāo)可能難以察覺(jué),但是在大型的圖應(yīng)用中,通常需要在不同機(jī)器間傳輸成千上萬(wàn)的圖頂點(diǎn)。在這種情況下,序列化和反序列化的代價(jià)就變得十分顯著。然而,基于BLOB的儲(chǔ)存形式無(wú)需經(jīng)歷序列化和反序列化的過(guò)程,BLOB本身就是字節(jié)數(shù)組,可以直接在網(wǎng)絡(luò)上傳輸。

3.3 具體實(shí)現(xiàn)

為了能夠用方便的接口讀寫(xiě)B(tài)LOB中的數(shù)據(jù),需要將用戶(hù)定義的圖頂點(diǎn)類(lèi)型編譯并生成相應(yīng)的訪問(wèn)器。

3.3.1 訪問(wèn)器類(lèi)的生成

對(duì)于每種類(lèi)型的圖頂點(diǎn),為它的每一個(gè)成員分配一個(gè)訪問(wèn)器。根據(jù)成員的長(zhǎng)度是否固定,訪問(wèn)器又可以細(xì)分為定長(zhǎng)訪問(wèn)器和變長(zhǎng)訪問(wèn)器。定長(zhǎng)訪問(wèn)器適用于對(duì)基本類(lèi)型成員的訪問(wèn),而可變長(zhǎng)的成員如字符串、線性容器等需要由變長(zhǎng)訪問(wèn)器來(lái)訪問(wèn)。例如人物頂點(diǎn)中,由于age成員占據(jù)固定4 Byte的空間,因此只需分配一個(gè)定長(zhǎng)訪問(wèn)器IntegerAccessor來(lái)訪問(wèn)它,而對(duì)于name成員來(lái)說(shuō),由于無(wú)法提前確定該字符串的長(zhǎng)度,使用變長(zhǎng)訪問(wèn)器StringAccessor訪問(wèn)它。同理,成員friends的類(lèi)型是長(zhǎng)整數(shù)線性表,也需要生成一個(gè)變長(zhǎng)訪問(wèn)器LongListAccessor才能訪問(wèn)它。

可以看到,對(duì)于每種成員類(lèi)型,需要為其生成對(duì)應(yīng)的訪問(wèn)器類(lèi)型。已知的最大規(guī)模圖應(yīng)用需要定義數(shù)千種頂點(diǎn)類(lèi)型,但是由于不同頂點(diǎn)類(lèi)型的成員類(lèi)型存在大量重復(fù),例如同樣的StringAccessor適用于任何擁有字符串成員的頂點(diǎn)類(lèi)型,因此訪問(wèn)器類(lèi)型的種類(lèi)數(shù)目反而不是很多。訪問(wèn)器訪問(wèn)BLOB內(nèi)數(shù)據(jù)的方式如圖2所示。

圖2 使用訪問(wèn)器的BLOB數(shù)據(jù)訪問(wèn)

在初始化訪問(wèn)器實(shí)例時(shí),傳入成員的指針,以便訪問(wèn)器知道成員從何開(kāi)始。對(duì)與定長(zhǎng)訪問(wèn)器而言,無(wú)需額外的信息,即可了解數(shù)據(jù)存放的格式。例如,如果在給定開(kāi)始指針之后,一個(gè)IntegerAccessor就明白在開(kāi)始指針之后的4 Byte就是需要訪問(wèn)的整數(shù)數(shù)據(jù)。而對(duì)于變長(zhǎng)訪問(wèn)器而言,需要借助一些輔助信息才能夠確定數(shù)據(jù)的格式。例如,對(duì)于所有簡(jiǎn)單數(shù)據(jù)類(lèi)型的線性表容器,如List＜long＞類(lèi)型,在成員的開(kāi)始用一個(gè)整數(shù)的空間存放該容器的大小,當(dāng)一個(gè)LongListAccessor訪問(wèn)這個(gè)成員時(shí),首先讀取首部4 Byte的容器大小信息,然后將指針向后偏移4 Byte,才開(kāi)始真正訪問(wèn)數(shù)據(jù)。

3.3.2 動(dòng)態(tài)容器擴(kuò)容的支持

圖應(yīng)用的數(shù)據(jù)處于經(jīng)常性的變化之中。社交網(wǎng)絡(luò)中的人物隨時(shí)會(huì)增加新的好友關(guān)系,同時(shí)也有可能解除原有的好友關(guān)系。因此,可支持動(dòng)態(tài)增減的容器類(lèi)型不可或缺。由于本文設(shè)計(jì)一個(gè)圖頂點(diǎn)所有的數(shù)據(jù)順序存放在一個(gè)固定大小的字節(jié)數(shù)組中,因此任何一個(gè)容器的擴(kuò)容都有可能導(dǎo)致空間不足?？梢杂^察到,在圖2中,BLOB的尾端有一部分不屬于任何成員的空間,稱(chēng)為緩沖區(qū)。當(dāng)任何一個(gè)容器試圖擴(kuò)容,請(qǐng)求更多的空間時(shí),如果緩沖區(qū)的大小足夠,那么該擴(kuò)容請(qǐng)求可以通過(guò)簡(jiǎn)單的向后生長(zhǎng)來(lái)實(shí)現(xiàn)。如圖3所示。如果緩沖區(qū)的大小不足以支持當(dāng)前的擴(kuò)容請(qǐng)求,那么需要向Trinity系統(tǒng)申請(qǐng)一塊更大的內(nèi)存區(qū)間來(lái)存放擴(kuò)容后的新數(shù)據(jù),同時(shí)把原有的內(nèi)存區(qū)間標(biāo)記為廢棄,以便Trinity內(nèi)置的內(nèi)存垃圾收集器能夠回收利用。

圖3 容器擴(kuò)容

3.3.3 嵌套支持

為向圖應(yīng)用提供更豐富的建模工具,允許用戶(hù)自行定義除了圖頂點(diǎn)之外的結(jié)構(gòu)體,并允許在圖頂點(diǎn)的定義中直接嵌套使用它。以社交網(wǎng)絡(luò)中的人物為例,如果對(duì)于每個(gè)好友,不僅希望保存他的標(biāo)識(shí)符,還希望保存對(duì)各個(gè)不同好友的備注簽名,那么可以將好友關(guān)系定義為一個(gè)特定結(jié)構(gòu)體,在這個(gè)結(jié)構(gòu)體中分別記錄好友的標(biāo)識(shí)符和對(duì)好友的備注簽名,這種情況下人物的朋友成員可以按以下方式定義:

在存儲(chǔ)上,結(jié)構(gòu)體會(huì)以和基本類(lèi)型相似的方式,順序保存在BLOB中。不同的是,系統(tǒng)會(huì)為每個(gè)結(jié)構(gòu)體生成特別的訪問(wèn)器,保證結(jié)構(gòu)體能被正確地讀寫(xiě)。另外,結(jié)構(gòu)體的引入增加了成員內(nèi)存管理的復(fù)雜度,為了支持嵌套成員的擴(kuò)容和縮減,每個(gè)成員都需要保存其上層成員的Resize函數(shù)指針,在需要擴(kuò)容或縮減時(shí),各個(gè)成員遞歸地調(diào)用Resize方法,直到傳遞到最終能夠處理該事件的圖頂點(diǎn)自身。對(duì)于好友關(guān)系中的備注簽名成員alias,如果希望將其修改成更長(zhǎng)的字符串,就需要向上遞歸地調(diào)用結(jié)構(gòu)體Friendship、容器FriendshipList以及圖頂點(diǎn)Person的Resize函數(shù)。該過(guò)程如圖4所示。

圖4 遞歸調(diào)用Resize方法

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

基于分布式內(nèi)存云的圖引擎存儲(chǔ)解決方案,首先借助內(nèi)存云的優(yōu)良擴(kuò)展性,解決了可擴(kuò)展性的問(wèn)題,能夠?qū)Ａ繄D數(shù)據(jù)的存儲(chǔ)和計(jì)算提供較好的支持。在實(shí)驗(yàn)中,將RDF(Resource Description Framework)數(shù)據(jù)集導(dǎo)入到圖引擎中。原數(shù)據(jù)集采用文本記錄,大小超過(guò)1 TB,擁有約110億條三元組,導(dǎo)入到圖引擎中共生成了30億個(gè)頂點(diǎn)、50億條邊。即使采用基于BLOB的緊湊內(nèi)存存儲(chǔ)結(jié)構(gòu),整個(gè)數(shù)據(jù)集仍然占用了480 GB左右的內(nèi)存。

基于內(nèi)存的底層存儲(chǔ)對(duì)圖的隨機(jī)訪問(wèn)具有較好的支撐,因此圖引擎在可用性上體現(xiàn)出較大優(yōu)勢(shì)。圖5是對(duì)17個(gè)不同類(lèi)型的圖頂點(diǎn)成員進(jìn)行隨機(jī)訪問(wèn)所花費(fèi)的時(shí)間。橫坐標(biāo)從P01至P17分別代表不同的17種查詢(xún),縱坐標(biāo)表示所花費(fèi)時(shí)間。

圖5 圖頂點(diǎn)成員隨機(jī)訪問(wèn)速度

借助于性能優(yōu)異的底層存儲(chǔ)引擎,上層的圖引擎應(yīng)用能夠表現(xiàn)出更優(yōu)異的性能。分別使用8臺(tái)96 GB DDR3內(nèi)存的服務(wù)器存儲(chǔ)上文提到的RDF數(shù)據(jù)集,并使用高速路由InfiniteBand對(duì)服務(wù)器進(jìn)行互聯(lián),并使用子圖匹配算法對(duì)圖數(shù)據(jù)進(jìn)行子圖搜索。圖6刻畫(huà)了若干查詢(xún)的響應(yīng)速度,橫坐標(biāo)從Q1至Q7分別代表7個(gè)不同的插敘,縱坐標(biāo)即完成查詢(xún)的時(shí)間。

圖6 圖查詢(xún)響應(yīng)速度

由圖5、圖6可以看出,分布式內(nèi)存云引擎可以為圖引擎提供穩(wěn)定高效的底層數(shù)據(jù)訪問(wèn)。在此之上,圖引擎可以向客戶(hù)端提供幾十毫秒內(nèi)的查詢(xún)響應(yīng)時(shí)間,有助于客戶(hù)端高效快速地完成查詢(xún)?nèi)蝿?wù)。

5 結(jié)束語(yǔ)

在大數(shù)據(jù)環(huán)境背景下,圖數(shù)據(jù)處理面對(duì)上億規(guī)模頂點(diǎn)的海量數(shù)據(jù)處理問(wèn)題。傳統(tǒng)的基于磁盤(pán)或者分布式文件系統(tǒng)的解決方案,在應(yīng)對(duì)圖應(yīng)用的大量隨機(jī)訪問(wèn)請(qǐng)求時(shí)存在性能瓶頸。本文基于分布式內(nèi)存云提出一種新穎的圖建模和存儲(chǔ)方案,可對(duì)上層圖應(yīng)用提供靈活高效的數(shù)據(jù)訪問(wèn)接口。實(shí)驗(yàn)結(jié)果表明,本文方案能夠?qū)崿F(xiàn)海量規(guī)模的圖數(shù)據(jù)處理。

［1］ Porta S,Crucitti P,Latora V.The Network Analysis of Urban Streets:A Dual Approach［J］.Physica A: Statistical Mechanics and Its Applications,2006, 369(2):853-866.

［2］ Narin F.Evaluative Bibliometrics:The Use of Publication and Citation Analysis in the Evaluation of Scientific Activity［M］.Cherry Hill,USA:Computer Horizons,1976.

［3］ Lawrence P.The PageRank Citation Ranking:Bringing Order to the Web［R］.Stanford University,Technical Report:SIDL-WP-1999-0120,1999.

［4］ Wasserman S.SocialNetwork Analysis:Methodsand Applications［M］.Cambridge,UK:Cambridge University Press,1994.

［5］ Mislove A.Measurement and Analysis of Online Social Networks［C］//Proceedings of the 7th ACM SIGCOMM Conference on Internet Measurement.New York,USA: ACM Press,2007:29-42.

［6］ Berners-Lee T,Hendler J,Lassila O.The Semantic Web［J］.Scientific American,2001,284(5):28-37.

［7］ Ramakrishnan R,Gehrke J.Database Management Systems［M］.［S.l.］:McGraw-Hill,2000.

［8］ Deelman E.Pegasus:A Framework for Mapping Complex Scientific Workflows onto Distributed Systems［J］.Scientific Programming Journal,2005,13(3):219-237.

［9］ Dean J,Sanjay G.MapReduce:Simplified Data Processing on Large Clusters［J］.Communications of the ACM,2008, 51(1):107-113.

［10］ Ghemawat S,Howard G,Leung Shun-Tak.The Google File System［J］.ACM SIGOPS Operating Systems Review,2003,37(5):29-43.

［11］ Chang F.Bigtable:A Distributed Storage System for Structured Data［J］.ACM Transactions on Computer Systems,2008,26(2):4-9.

［12］ Melnik S.Dremel:Interactive Analysis of Web-scale Datasets［J］.Proceedings of the VLDB Endowment, 2010,3(1/2):330-339.

［13］ Shao Bin,Wang Haixun,Li Yatao.Trinity:A Distributed Graph Engine on a Memory Cloud［C］//Proceedings of 2013 ACM SIGMOD International Conference on Management of Data.New York,USA:ACM Press,2013:505-516.

［14］ 于 戈,谷 峪,鮑玉斌,等.云計(jì)算環(huán)境下的大規(guī)模圖數(shù)據(jù)處理技術(shù)［J］.計(jì)算機(jī)學(xué)報(bào),2011,34(10): 1753-1768.

編輯 陸燕菲

Design and Implementation of Underlying Storage for Graph Engine

MA Hongbin,CHEN Guihai
(Department of Computer Science and Engineering,Shanghai Jiaotong University,Shanghai 200240,China)

Graph applications rise with the emerging of social network and semantic Web,and generate many graph data processing products,including Neo4j,HyperGraphDB,etc.However,current solutions fail to take into consideration graph applications'higher requirements on data availability and scalability.This paper proposes a modeling and storage solution based on distributed memory cloud.It takes advantage of the prior work to build a key-value system over the memory cloud,then builds data modeling and read-write based on it.Experimental results on large scaled datasets show that this solution has a good figure random access performance,and it can support massive graph applications efficiently.

graph processing;cloud computing;distributed;data modeling;storage;data structure

1000-3428(2014)11-0060-05

A

TP311

10.3969/j.issn.1000-3428.2014.11.012

馬洪賓(1989-),男,碩士研究生,主研方向:數(shù)據(jù)查詢(xún)處理,分布式系統(tǒng),云計(jì)算;陳貴海,教授、博士生導(dǎo)師。

2013-11-18

2013-12-17E-mail:790123072@qq.com

中文引用格式:馬洪賓,陳貴海.圖引擎底層存儲(chǔ)的設(shè)計(jì)與實(shí)現(xiàn)［J］.計(jì)算機(jī)工程,2014,40(11):60-64.

英文引用格式:Ma Hongbin,Chen Guihai.Design and Implementation of Underlying Storage for Graph Engine［J］.Computer Engineering,2014,40(11):60-64.