翟社平　高　山　郭　琳　李兆兆

(西安郵電大學(xué)計(jì)算機(jī)學(xué)院　陜西 西安 710121)

0　引　言

語義Web核心思想[1]是通過語義信息的分享，實(shí)現(xiàn)網(wǎng)絡(luò)信息服務(wù)的智能化、自動(dòng)化，從而促使互聯(lián)網(wǎng)成為信息交換的通用媒介。

隨著人工智能的發(fā)展和計(jì)算機(jī)應(yīng)用需求的不斷增強(qiáng)，語義Web技術(shù)已經(jīng)深入到社會(huì)生活的各個(gè)領(lǐng)域，如輿情監(jiān)控、知識(shí)圖譜、穿戴計(jì)算、智能家居、智慧校園等。語義Web是萬維網(wǎng)的一個(gè)擴(kuò)展，其影響范圍和應(yīng)用范圍在不斷地?cái)U(kuò)大，越來越多的研究者開始高度關(guān)注和重視到語義Web技術(shù)的應(yīng)用。

為了對(duì)Web資源及其屬性進(jìn)行規(guī)范化描述，W3C組織提出了一個(gè)Web資源之間語義關(guān)系的開放元數(shù)據(jù)框架RDF[2]。RDF是語義Web建立的重要基礎(chǔ)，通常以三元組(RDF Triple)數(shù)據(jù)模型(主語、謂語、賓語)描述Web資源之間存在的特定關(guān)系。簡單而言，一個(gè)RDF語句是由資源、屬性類型、屬性值構(gòu)成的三元組?；谡Z義Web的RDF三元組標(biāo)簽可以構(gòu)造信息間邏輯推理關(guān)系的本體模型，進(jìn)而使人與機(jī)器間、機(jī)器與機(jī)器間的交流變得像人與人之間交流一樣輕松。

隨著語義Web的迅猛發(fā)展，越來越多的互聯(lián)網(wǎng)數(shù)據(jù)以RDF的形式發(fā)布出來。自2007年第一代關(guān)聯(lián)數(shù)據(jù)發(fā)布至今，RDF數(shù)據(jù)增長速度不斷加快。據(jù)關(guān)聯(lián)開放數(shù)據(jù)LOD(Link Open Data)統(tǒng)計(jì)，2012年關(guān)聯(lián)數(shù)據(jù)云中已經(jīng)包括295個(gè)數(shù)據(jù)集、316億個(gè)RDF三元組以及5.04億個(gè)RDF鏈接。截止2017年1月，關(guān)聯(lián)數(shù)據(jù)云中的數(shù)據(jù)集已經(jīng)達(dá)到1 146個(gè)[3]，約是2012年的4倍。如此大規(guī)模的RDF數(shù)據(jù)就為語義Web技術(shù)的發(fā)展提出了新的挑戰(zhàn)。

現(xiàn)在的互聯(lián)網(wǎng)正處在語義化蛻變過程中，智能化語義Web在理解人類語言的基礎(chǔ)上逐漸實(shí)現(xiàn)了人機(jī)交互的網(wǎng)絡(luò)訪問。如何高效地管理大規(guī)模RDF數(shù)據(jù)已經(jīng)成為推動(dòng)語義Web技術(shù)發(fā)展亟待解決的重要問題。目前，RDF數(shù)據(jù)存儲(chǔ)需要解決以下兩個(gè)關(guān)鍵問題：

1) 如何建表才能在RDF數(shù)據(jù)存儲(chǔ)空間開銷和查詢性能之間找到平衡點(diǎn)；

2) 如何建立簡單、有效索引才能將RDF數(shù)據(jù)的查詢化繁為簡。

針對(duì)傳統(tǒng)的RDF數(shù)據(jù)存儲(chǔ)在大數(shù)據(jù)集下表現(xiàn)不盡人意的現(xiàn)狀，本文從用戶行為習(xí)慣的角度出發(fā)，統(tǒng)計(jì)發(fā)現(xiàn)90%以上的查詢都包含被約束的謂語值。通過分析現(xiàn)有的存儲(chǔ)模式，充分結(jié)合語義數(shù)據(jù)查詢特征，本文提出了一種基于分布式數(shù)據(jù)庫HBase的RDF數(shù)據(jù)存儲(chǔ)模型。將RDF數(shù)據(jù)存儲(chǔ)到HBase表中以實(shí)現(xiàn)海量語義數(shù)據(jù)的分布式存儲(chǔ)，并通過自定義的Bulk Loading數(shù)據(jù)加載方式完成數(shù)據(jù)上傳，進(jìn)而解決數(shù)據(jù)初始導(dǎo)入效率低的問題，同時(shí)實(shí)現(xiàn)RDF數(shù)據(jù)的高效查詢。

1　相關(guān)研究工作

傳統(tǒng)集中式的RDF數(shù)據(jù)管理大都采用關(guān)系型數(shù)據(jù)庫管理系統(tǒng)RDBMS(Relational Database Management System)來存儲(chǔ)RDF數(shù)據(jù)。RDBMS是一個(gè)二維映射的集中式存儲(chǔ)數(shù)據(jù)庫系統(tǒng)，表中每一列需預(yù)定義數(shù)據(jù)類型和長度，且表中的列數(shù)存在限制。目前基于關(guān)系型數(shù)據(jù)庫的語義數(shù)據(jù)存儲(chǔ)方案有三元組表存儲(chǔ)、垂直存儲(chǔ)、水平存儲(chǔ)和模式生成存儲(chǔ)等。

三元組表存儲(chǔ)是最為簡潔的一種RDF數(shù)據(jù)存儲(chǔ)方式，其核心思想是每條三元組對(duì)應(yīng)一條數(shù)據(jù)記錄。垂直存儲(chǔ)的核心思想是將同一謂語的三元組存到同一張表中，由于數(shù)據(jù)表本身已經(jīng)將RDF的謂語屬性值隱藏，因此數(shù)據(jù)表只保存主語和賓語兩列數(shù)據(jù)值。水平存儲(chǔ)的核心思想是將所有謂語作為列名存儲(chǔ)在一張表中，通過一張表即可存儲(chǔ)所有RDF數(shù)據(jù)。模式生成存儲(chǔ)的核心思想是根據(jù)空值分布對(duì)表做垂直和水平切分，混合切分后的數(shù)據(jù)表會(huì)在很大程度上減少表中存儲(chǔ)的空值數(shù)量。

表1從優(yōu)勢、劣勢兩個(gè)方面對(duì)以上四種存儲(chǔ)方案進(jìn)行簡單總結(jié)。

表1　基于關(guān)系型數(shù)據(jù)庫的存儲(chǔ)方案總結(jié)

面對(duì)RDF數(shù)據(jù)的急劇增長，傳統(tǒng)關(guān)系型數(shù)據(jù)庫已無法高效地對(duì)其進(jìn)行管理，越來越多的研究者使用分布式系統(tǒng)和并行計(jì)算技術(shù)來管理大規(guī)模RDF數(shù)據(jù)。這類系統(tǒng)采用傳統(tǒng)的分布式計(jì)算架構(gòu)，并對(duì)RDF數(shù)據(jù)存儲(chǔ)和查詢進(jìn)行優(yōu)化。

其中，研究者曾提出一個(gè)分布式RDF數(shù)據(jù)查詢框架SPARQL ENGINE[8]，該系統(tǒng)架構(gòu)實(shí)現(xiàn)了大數(shù)據(jù)環(huán)境下RDF數(shù)據(jù)的分布式查詢機(jī)制。但是，該框架并沒有對(duì)RDF數(shù)據(jù)在分布式數(shù)據(jù)庫中的存儲(chǔ)策略進(jìn)行研究。Bigdata是另一種分布式存儲(chǔ)系統(tǒng)，在存儲(chǔ)上，其采用分區(qū)存儲(chǔ)，利用key-range劃分的B+樹索引來分布式訪問集群資源，而且這種劃分是動(dòng)態(tài)進(jìn)行的[9]。但是該系統(tǒng)也存在著通信開銷大、數(shù)據(jù)存取結(jié)構(gòu)和安全性難以控制的缺點(diǎn)。

除此之外，在RDF數(shù)據(jù)存儲(chǔ)領(lǐng)域已經(jīng)有研究人員將RDF與Hadoop相結(jié)合，目前這方面的研究工作主要集中在Hadoop的存儲(chǔ)設(shè)計(jì)以及基于存儲(chǔ)模式的數(shù)據(jù)查詢處理上。Hadoop是Apache公司效仿Google云設(shè)計(jì)的開源平臺(tái)，其具有可擴(kuò)展、經(jīng)濟(jì)、高效、可靠等諸多優(yōu)點(diǎn)，適合于對(duì)海量數(shù)據(jù)進(jìn)行存儲(chǔ)、搜索、挖掘和分析。研究學(xué)者提出了一種基于Hadoop的RDF數(shù)據(jù)編碼模型，詳細(xì)介紹了詞典構(gòu)建的方法，通過構(gòu)建好的數(shù)據(jù)詞典實(shí)現(xiàn)RDF三元組的編解碼操作，該方法在減少存儲(chǔ)容量占用的同時(shí)保證了數(shù)據(jù)的安全性[10]。但是，該存儲(chǔ)模型仍然采用S_PO、P_OS、O_SP、PS_O、SO_P和PO_S六張索引表進(jìn)行存儲(chǔ)，在數(shù)據(jù)存儲(chǔ)設(shè)計(jì)方面并沒有給出存儲(chǔ)模式的優(yōu)化方案。

2　基于HBase的RDF數(shù)據(jù)存儲(chǔ)

2.1　存儲(chǔ)分析

HBase是一個(gè)高可靠性、高性能、列存儲(chǔ)、可伸縮、支持實(shí)時(shí)讀寫的數(shù)據(jù)庫系統(tǒng)，底層的Hadoop分布式文件系統(tǒng)HDFS(Hadoop Distributed File System)具有高容錯(cuò)性且可以被部署在低價(jià)的硬件設(shè)備之上[11]。HBase是一個(gè)多維映射的數(shù)據(jù)存儲(chǔ)表，其數(shù)據(jù)存儲(chǔ)模型為Key-Value類型：

(Row-Key，Column Family，Timestamp)->Value

Row-Key為表中唯一的行標(biāo)識(shí)，動(dòng)態(tài)擴(kuò)展的多個(gè)列合并為一個(gè)列族(Column Family)，時(shí)間戳用來區(qū)分所存數(shù)據(jù)的不同版本，進(jìn)而唯一確定數(shù)據(jù)單元值Value。

表2描述了百度網(wǎng)站分頻道(百科、文庫、貼吧等)關(guān)系數(shù)據(jù)在HBase表中的S_PO存儲(chǔ)結(jié)構(gòu)。該表以主語www.baidu.com為Row-key，謂語Anchor:channel對(duì)應(yīng)三個(gè)賓語值，Timestamp表示時(shí)間戳。

表2　表S_PO在HBase中的存儲(chǔ)結(jié)構(gòu)

基于HBase的數(shù)據(jù)存儲(chǔ)方案不對(duì)空值做存放操作，邏輯上為空的單元值并不占用實(shí)際的存儲(chǔ)空間，所以HBase的稀疏特性非常適合存儲(chǔ)RDF數(shù)據(jù)。

將RDF三元組<主語(Subject)、謂語(Predicate)、賓語(Object)>中不同的元素和元素組合作為Row-Key索引，需要設(shè)計(jì)S_PO、P_OS、O_SP、PS_O、SO_P和PO_S六張HBase索引表來對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)。實(shí)際上，S_PO、P_OS、O_SP三種數(shù)據(jù)屬性排列方式足以能夠?yàn)樗械娜M查詢模式提供索引服務(wù)。S_PO、P_OS、O_SP分別表示以S、P、O為Row-Key，其查詢組合對(duì)應(yīng)的索引如表3所示。

表3　查詢組合索引表

注：“?”表示在三元組的位置存在一個(gè)未知值，“--”表示該值被約束(即，固定)

2.2　存儲(chǔ)改進(jìn)策略

RDF數(shù)據(jù)存儲(chǔ)模型的目標(biāo)是高效地執(zhí)行各種查詢操作，現(xiàn)有的RDF存儲(chǔ)系統(tǒng)為了實(shí)現(xiàn)這一目標(biāo)大都從數(shù)據(jù)源本身出發(fā)，對(duì)如何合理地拆分三元組數(shù)據(jù)集進(jìn)行研究。但是，從數(shù)據(jù)查詢的角度來講，已有的存儲(chǔ)方式忽略了用戶查詢習(xí)慣本身所帶來的應(yīng)用價(jià)值。

本文通過對(duì)里海大學(xué)基準(zhǔn)LUBM(Lehigh University Benchmark)測試基準(zhǔn)中的查詢記錄進(jìn)行統(tǒng)計(jì)分析，發(fā)現(xiàn)SP?、?PO、?P?三種約束謂語的查詢模式最符合日常查詢習(xí)慣，其查詢請(qǐng)求數(shù)量約占查詢總數(shù)的90%。由此可見，謂語在大多數(shù)情況下是作為約束對(duì)象出現(xiàn)在查詢語句中。但是在實(shí)際的RDF數(shù)據(jù)集中，謂語的數(shù)量通常在數(shù)十至數(shù)百范圍內(nèi)，遠(yuǎn)遠(yuǎn)少于主語和賓語數(shù)量，因此當(dāng)謂語作為行鍵索引(Row-Key)時(shí)會(huì)使系統(tǒng)負(fù)載增大，查詢效率降低。

為了適應(yīng)謂語在查詢中出現(xiàn)的高頻特性，本文在S_PO、O_SP索引表不做處理的基礎(chǔ)上，對(duì)P_OS索引表給出改進(jìn)策略。將基于謂語索引的存儲(chǔ)表細(xì)分為P_OS、P_SO兩大類，實(shí)現(xiàn)謂語約束下主語或賓語查詢的兩種不同組合。具體實(shí)現(xiàn)形式表示如下：

P_OS：

Row Key：Predicate URI{

Column Family:Object{

Column:(Subject)

}

}

P_SO：

Row Key：Predicate URI{

Column Family: Subject {

Column:(Object)

}

}

2.3　模型設(shè)計(jì)

本文設(shè)計(jì)如圖1所示的RDF三元組數(shù)據(jù)存儲(chǔ)模型，該模型在S_PO和O_SP索引表不做修改的基礎(chǔ)上對(duì)P_OS索引表進(jìn)行改進(jìn)。每條謂語分別對(duì)應(yīng)P_OS、P_SO兩類索引表，將每一謂語值作為熱數(shù)據(jù)進(jìn)行索引存儲(chǔ)。完成以謂語為索引的RDF數(shù)據(jù)存儲(chǔ)模型后，謂語確定的RDF數(shù)據(jù)查詢會(huì)變得十分高效。由于謂語在整個(gè)RDF數(shù)據(jù)集中數(shù)量級(jí)極小，所以以謂語為索引的RDF數(shù)據(jù)存儲(chǔ)表可以快速鎖定數(shù)據(jù)，再加上原有S_PO和O_SP的RDF數(shù)據(jù)存儲(chǔ)模型，整個(gè)存儲(chǔ)系統(tǒng)就會(huì)變得很完善。從用戶查詢的角度講，也能滿足絕大多數(shù)數(shù)據(jù)的高效查詢。

圖1　RDF三元組存儲(chǔ)模型

以謂語為索引的RDF數(shù)據(jù)存儲(chǔ)模型旨在優(yōu)化以謂語為約束條件的RDF數(shù)據(jù)查詢。對(duì)照表3所示的查詢組合索引，該存儲(chǔ)模型針對(duì)不同查詢索引做出改進(jìn)，具體方案如下：

1) 為每種查詢組合指定唯一確定的索引表；

2) 針對(duì)SP？高頻查詢組合，將優(yōu)化前的S_PO索引表替換為P_SO索引表。

該存儲(chǔ)模型充分考慮RDF三元組合的謂語特征，在實(shí)現(xiàn)系統(tǒng)負(fù)載均衡的同時(shí)能夠提升數(shù)據(jù)的查詢效率。表4介紹了改進(jìn)后的RDF數(shù)據(jù)查詢索引情況。

表4　查詢索引表(改進(jìn)后)

2.4　查找索引算法

查找索引算法的目標(biāo)是找出與查詢請(qǐng)求相對(duì)應(yīng)的索引類型。結(jié)合表4的查詢組合索引，給出該存儲(chǔ)模型的查詢索引算法，如算法1所示。

算法1查詢索引

輸入：查詢語句

輸出：索引類型

開始

//若謂語被約束

if(predicate is constrained)

{

//且主語被約束

if (subject is constrained)

return P_SO

else

return P_OS

}

else

{

//賓語被約束

if (object is constrained)

return O_SP

else

return S_PO

}

結(jié)束

該算法給出了查詢索引的詳細(xì)過程。根據(jù)查詢語句做出判斷，若謂語被約束，可以通過判斷主語是否被約束來確定相對(duì)應(yīng)的索引類型；反之，可以通過判斷賓語是否被約束來確定相對(duì)應(yīng)的索引類型。該算法的核心思想是根據(jù)用戶查詢請(qǐng)求模型，優(yōu)先匹配被約束的元素，進(jìn)而快速?zèng)Q定使用何種對(duì)應(yīng)索引。

2.5　Bulk Loading數(shù)據(jù)加載

完成數(shù)據(jù)存儲(chǔ)模型的設(shè)計(jì)后，接下來就要實(shí)現(xiàn)將RDF數(shù)據(jù)按照S_PO，P_SO，P_OS，O_SP模型加載到HBase中。HBase數(shù)據(jù)加載有兩種通用方法：一是通過MapReduce調(diào)用TableOutpu-tFormat；二是在client上調(diào)用API寫入數(shù)據(jù)。但是這兩種方式都需要頻繁地通過遠(yuǎn)程過程調(diào)用協(xié)議RPC(Remote Procedure Call Protocol)方式與HRegion服務(wù)器進(jìn)行通信，當(dāng)一次性寫入大量數(shù)據(jù)時(shí)會(huì)造成額外的資源開銷。針對(duì)海量語義數(shù)據(jù)的存儲(chǔ)，這兩種方式顯然不是最有效的。

HBase可通過自帶的用戶自定義程序向HBase中加載數(shù)據(jù)。針對(duì)改進(jìn)后的數(shù)據(jù)存儲(chǔ)模型，本文在HBase自帶數(shù)據(jù)加載方法的基礎(chǔ)上，自定義了Bulk Loading數(shù)據(jù)加載程序。數(shù)據(jù)加載具體步驟如下：

1) HDFS不適合存放大量小文件，所以要先把RDF數(shù)據(jù)處理成為與S_PO，P_SO，P_OS,O_SP模型對(duì)應(yīng)的結(jié)構(gòu)。

2) 在Hadoop的分布式文件系統(tǒng)HDFS上為RDF數(shù)據(jù)創(chuàng)建一個(gè)專門的存儲(chǔ)目錄，然后調(diào)用Hadoop的Put接口進(jìn)一步將數(shù)據(jù)導(dǎo)入到HDFS分布式文件系統(tǒng)的RDF數(shù)據(jù)存儲(chǔ)目錄下。

3) 在HBase中建立空的S_PO，P_SO，P_OS，O_SP表結(jié)構(gòu)，并指定它們的列族。

4) 執(zhí)行一個(gè)MapReduce任務(wù)，并行加載RDF數(shù)據(jù)到HBase，任務(wù)的輸入是存放RDF數(shù)據(jù)的文件，輸出是HBase文件。

5) 查看HBase中對(duì)應(yīng)的表結(jié)構(gòu)下是否存入了RDF數(shù)據(jù)。

對(duì)Bulk Loading數(shù)據(jù)加載核心部分的代碼進(jìn)行描述(向新增的P_SO表加載數(shù)據(jù))：

Method Map(Text value, Context context)

String[]textStrSplit=text.toString().split(″ ″);

//將謂語作為Row key

String hkey=textStrSplit[1];

String column=textStrSplit[0];

String hvalue=textStrSplit[2];

rowKey=Bytes.toBytes(hkey);

//謂語值存在

while(hkey==ture)

//創(chuàng)建Put對(duì)象用于存放Put實(shí)例

Put HPut=new Put(rowKey);

byte[ ] cell=Bytes.toBytes(hvalue);

//向Put對(duì)象中添加單元數(shù)據(jù)

HPut.add(Bytes.toBytes(column), cell);

context.write(HKey, HPut);

該數(shù)據(jù)加載算法主要包括數(shù)據(jù)分割、加載三元組和寫入數(shù)據(jù)三部分?；谥^語的數(shù)據(jù)索引，需要將數(shù)據(jù)按照P_SO和P_OS模式分別完成加載。同時(shí)，對(duì)每一謂語值是否為空預(yù)先做出判斷，若謂語值不存在，則不將該記錄存入以謂語為索引的存儲(chǔ)表中；反之，直接將數(shù)據(jù)寫入對(duì)應(yīng)的數(shù)據(jù)索引表中。S_PO和O_SP存儲(chǔ)表本文不做詳細(xì)說明。

3　系統(tǒng)測試與分析

3.1　實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)搭建了具有5個(gè)節(jié)點(diǎn)的Hadoop集群，每個(gè)節(jié)點(diǎn)硬件配置如表5所示。存儲(chǔ)結(jié)構(gòu)設(shè)計(jì)是將RDF數(shù)據(jù)存儲(chǔ)在HBase集群中，HBase構(gòu)建在HDFS之上，HRegionServer(域服務(wù)器)作為HBase的集群節(jié)點(diǎn)維護(hù)存儲(chǔ)RDF數(shù)據(jù)的域(region)，RDF數(shù)據(jù)均衡分布在集群各節(jié)點(diǎn)中。實(shí)驗(yàn)采用LUBM測試集進(jìn)行測試，LUBM[12]是當(dāng)前使用最廣泛的測試樣例，該測試集可以根據(jù)指定的參數(shù)生成相應(yīng)規(guī)模的數(shù)據(jù)集。例如LUMB(10)，參數(shù)10表示生成具有10個(gè)大學(xué)的語義數(shù)據(jù)集，其中指定參數(shù)越大數(shù)據(jù)集規(guī)模越大。

表5　硬件配置

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

實(shí)驗(yàn)采用UBA[13](數(shù)據(jù)發(fā)生器)生成三組不同大小的RDF數(shù)據(jù)集進(jìn)行測試，數(shù)據(jù)集大小如表6所示。

表6　測試數(shù)據(jù)集

數(shù)據(jù)加載性能是評(píng)價(jià)該存儲(chǔ)模型的一個(gè)重要指標(biāo)，本文基于MapReduce編程模型實(shí)現(xiàn)了大規(guī)模RDF數(shù)據(jù)的并行加載功能。表7給出了串行加載算法和MapReduce并行加載算法加載三組不同規(guī)模RDF數(shù)據(jù)所需的時(shí)間。

表7　數(shù)據(jù)加載消耗時(shí)間

實(shí)驗(yàn)加速比可由式(1)得出：

(1)

式中：T(1)表示串行加載運(yùn)行時(shí)間，T(N)表示并行加載運(yùn)行時(shí)間。

由表7可以看出，對(duì)比串行方法，Bulk loading并行數(shù)據(jù)加載算法在數(shù)據(jù)規(guī)模較小時(shí)優(yōu)勢并不明顯，原因是當(dāng)數(shù)據(jù)規(guī)模小時(shí)Map任務(wù)個(gè)數(shù)也較少，不能有效利用MapReduce的并行機(jī)制。隨著數(shù)據(jù)規(guī)模的增大，實(shí)驗(yàn)表明該加載算法能夠高效地完成海量RDF三元組數(shù)據(jù)的加載操作。

本文數(shù)據(jù)查詢測試主要目的是驗(yàn)證謂語索引表P_SO的高效性，設(shè)計(jì)謂語綁定，主語已知，賓語未知的查詢用例:

SELECT ?Y

WHERE

{

ub:subOrganizationOf ?Y

}

將該查詢用例分別在S_PO和P_SO存儲(chǔ)模式上進(jìn)行測試，三組不同規(guī)模RDF數(shù)據(jù)所需的查詢的響應(yīng)時(shí)間如表8和圖2所示。

表8　SP?查詢響應(yīng)時(shí)間

圖2　SP?查詢響應(yīng)時(shí)間

由統(tǒng)計(jì)分析得出，基于謂語約束的查詢請(qǐng)求數(shù)量約占整個(gè)系統(tǒng)查詢總數(shù)的90%。改進(jìn)后整個(gè)系統(tǒng)的查詢加速比(表8)可由Amdahl定律得出：

(2)

本實(shí)驗(yàn)Fe=0.9，F(xiàn)e是執(zhí)行某個(gè)任務(wù)的總時(shí)間中可被改進(jìn)部分的時(shí)間所占的百分比，Se是改進(jìn)部分采用改進(jìn)措施后比沒有采用改進(jìn)措施前性能提高倍數(shù)。

對(duì)比優(yōu)化前的S_PO查詢索引，P_SO在查詢時(shí)能夠快速確定Row-Key范圍，原因是數(shù)據(jù)源本身具有謂語數(shù)量級(jí)小的特點(diǎn)，根據(jù)Row-Key檢索所有包含謂語P的三元組，然后根據(jù)主語S進(jìn)行過濾操作，最終得出查詢結(jié)果。隨著數(shù)據(jù)規(guī)模的增長，謂語P確定的Row-Key范圍也逐漸變大，因此查詢時(shí)間遞增。同時(shí)，MapReduce并行機(jī)制進(jìn)一步提升查詢效率，查詢加速比逐漸增大。

4　結(jié)　語

針對(duì)海量語義數(shù)據(jù)的管理問題，本文提出了一種基于分布式數(shù)據(jù)庫HBase的RDF數(shù)據(jù)存儲(chǔ)模型。相較于傳統(tǒng)的三元組存儲(chǔ)方法，該模型可以直接根據(jù)謂語的索引更加快速地查詢到相應(yīng)的關(guān)聯(lián)數(shù)據(jù)值。在保證查詢性能的同時(shí)有效地減少了存儲(chǔ)開銷，為實(shí)現(xiàn)大規(guī)模語義數(shù)據(jù)的高效查詢和推理奠定了理論和應(yīng)用基礎(chǔ)。

本文在RDF數(shù)據(jù)的查詢處理問題上沒有做針對(duì)性的研究，接下來的工作是要對(duì)該模型上的查詢算法進(jìn)行優(yōu)化，進(jìn)一步提升數(shù)據(jù)的查詢效率。

[1] 常亮,劉進(jìn),古天龍,等.基于動(dòng)態(tài)描述邏輯的語義Web服務(wù)組合[J].計(jì)算機(jī)學(xué)報(bào),2013,36(12):2468-2478.

[2] 杜方,陳躍國,杜小勇.RDF數(shù)據(jù)查詢處理技術(shù)綜述[J].軟件學(xué)報(bào),2013(06):1222-1242.

[3] Bizer C,Jentzsch A,Cyganiak R.State of the LOD Cloud[EB/OL].http://lod-cloud.net/.

[4] Kaoudi Z,Manolescu I.RDF in the clouds:a survey[J].Vldb Journal,2015,24(1):67-91.

[5] Harris S,Lamb N,Shadbolt N,et al.4store:The design and implementation of a clustered rdf store[J].Scalable Semantic Web Knowledge Base Systems,2009,4:94-109.

[6] 杜小勇,王琰,呂彬.語義Web數(shù)據(jù)管理研究進(jìn)展[J].軟件學(xué)報(bào),2009,20(11):2950-2964.

[7] Zhou Q,Hall W,Roure D D.Building a Distributed Infrastructure for Scalable Triple Stores[J].Journal of Computer Science & Technology,2009,24(3):447-462.

[8] Rajapoornima M,Tamilselvan L,Priyadarshini R.Personalized semantic retrieval of information from large scale blog data[C]//IEEE International Conference on Recent Trends in Electronics,Information & Communication Technology.IEEE,2017:1055-1059.

[9] Owens A,Seaborne A,Gibbins N,et al.Clustered TDB:A Clustered Triple store for Jena[C]//Proceedings of 18th Internation Conference on World Wide Web,2009.

[10] Abiri F,Kahani M,Zarinkalam F.An entity based RDF indexing schema using Hadoop and HBase[C]//International Econference on Computer and Knowledge Engineering.IEEE,2014:68-73.

[11] 徐德智,劉揚(yáng),Sarfraz Ahmed.基于Hadoop的RDF數(shù)據(jù)存儲(chǔ)及查詢優(yōu)化[J].計(jì)算機(jī)應(yīng)用研究,2017,34(2):477-480,486.

[12] Guo Y,Pan Z,Heflin J.LUBM:A benchmark for OWL knowledge base systems[J].Web Semantics Science Services & Agents on the World Wide Web,2005,3(2-3):158-182.

[13] Helflin J,Stuckenschmidt H.Editorial:Web-scale semantic information preprocess[J].Web Semantic:Science,Services and Agents on the World Wide Web,2012(10):121-132.