主流開源分布式圖數(shù)據(jù)庫-Benchmark

主流開源分布式圖數(shù)據(jù)庫Benchmark

本文由美團(tuán)NLP團(tuán)隊(duì)高辰、趙登昌撰寫首發(fā)于NebulaGraph官方論壇：/t/topic/1377image1.前言近年來，深度學(xué)習(xí)和知識圖譜技術(shù)發(fā)展迅速，相比于深度學(xué)習(xí)的“黑盒子”，知識圖譜具有很強(qiáng)的可解釋性，在搜索推薦、智能助理、金融風(fēng)控等場景中有著廣泛的應(yīng)用。美團(tuán)基于積累的海量業(yè)務(wù)數(shù)據(jù)，結(jié)合使用場景進(jìn)行充分地挖掘關(guān)聯(lián)，逐步建立起包括美食圖譜、旅游圖譜、商品圖譜在內(nèi)的近十個(gè)領(lǐng)域知識圖譜，并在多業(yè)務(wù)場景落地，助力本地生活服務(wù)的智能化。為了高效存儲并檢索圖譜數(shù)據(jù)，相比傳統(tǒng)關(guān)系型數(shù)據(jù)庫，選擇圖數(shù)據(jù)庫作為存儲引擎，在多跳查詢上具有明顯的性能優(yōu)勢。當(dāng)前業(yè)界知名的圖數(shù)據(jù)庫產(chǎn)品有數(shù)十款，選型一款能夠滿足美團(tuán)實(shí)際業(yè)務(wù)需求的圖數(shù)據(jù)庫產(chǎn)品，是建設(shè)圖存儲和圖學(xué)習(xí)平臺的基礎(chǔ)。我們結(jié)合業(yè)務(wù)現(xiàn)狀，制定了選型的基本條件：開源項(xiàng)目，對商業(yè)應(yīng)用友好擁有對源代碼的控制力，才能保證數(shù)據(jù)安全和服務(wù)可用性。支持集群模式，具備存儲和計(jì)算的橫向擴(kuò)展能力美團(tuán)圖譜業(yè)務(wù)數(shù)據(jù)量可以達(dá)到千億以上點(diǎn)邊總數(shù)，吞吐量可達(dá)到數(shù)萬qps，單節(jié)點(diǎn)部署無法滿足存儲需求。能夠服務(wù)OLTP場景，具備毫秒級多跳查詢能力美團(tuán)搜索場景下，為確保用戶搜索體驗(yàn)，各鏈路的超時(shí)時(shí)間具有嚴(yán)格限制，不能接受秒級以上的查詢響應(yīng)時(shí)間。具備批量導(dǎo)入數(shù)據(jù)能力圖譜數(shù)據(jù)一般存儲在Hive等數(shù)據(jù)倉庫中。必須有快速將數(shù)據(jù)導(dǎo)入到圖存儲的手段，服務(wù)的時(shí)效性才能得到保證。我們試用了DB-Engines網(wǎng)站上排名前30的圖數(shù)據(jù)庫產(chǎn)品，發(fā)現(xiàn)多數(shù)知名的圖數(shù)據(jù)庫開源版本只支持單節(jié)點(diǎn)，不能橫向擴(kuò)展存儲，無法滿足大規(guī)模圖譜數(shù)據(jù)的存儲需求，例如：Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。經(jīng)過調(diào)研比較，最終納入評測范圍的產(chǎn)品為：NebulaGraph（原阿里巴巴團(tuán)隊(duì)創(chuàng)業(yè)開發(fā)）、Dgraph（原Google團(tuán)隊(duì)創(chuàng)業(yè)開發(fā)）、HugeGraph（百度團(tuán)隊(duì)開發(fā)）。2.測試概要2.1硬件配置數(shù)據(jù)庫實(shí)例：運(yùn)行在不同物理機(jī)上的Docker容器。單實(shí)例資源：32核心，64GB內(nèi)存，1TBSSD存儲?！綢ntel(R)Xeon(R)Gold5218CPU@2.30GHz】實(shí)例數(shù)量：32.2部署方案Nebulav1.0.1Metad負(fù)責(zé)管理集群元數(shù)據(jù)，Graphd負(fù)責(zé)執(zhí)行查詢，Storaged負(fù)責(zé)數(shù)據(jù)分片存儲。存儲后端采用RocksDB。實(shí)例

1實(shí)例2實(shí)例3MetadMetadMetadGraphdGraphdGraphdStoraged[RocksDB]Storaged[RocksDB]Storaged[RocksDB]Dgraphv20.07.0Zero負(fù)責(zé)管理集群元數(shù)據(jù)，Alpha負(fù)責(zé)執(zhí)行查詢和存儲。存儲后端為Dgraph自有實(shí)現(xiàn)。實(shí)例1實(shí)例2實(shí)例3ZeroZeroZeroAlphaAlphaAlphaHugeGraphv0.10.4HugeServer負(fù)責(zé)管理集群元數(shù)據(jù)和查詢。HugeGraph雖然支持RocksDB后端，但不支持RocksDB后端的集群部署，因此存儲后端采用HBase。實(shí)例1實(shí)例2實(shí)例3HugeServer[HBase]HugeServer[HBase]HugeServer[HBase]JournalNodeJournalNodeJournalNodeDataNodeDataNodeDataNodeNodeManagerNodeManagerNodeManagerRegionServerRegionServerRegionServerZooKeeperZooKeeperZooKeeperNameNodeNameNode[Backup]--ResourceManagerResourceManager[Backup]HBaseMasterHBaseMaster[Backup]-3.評測數(shù)據(jù)集image社交圖譜數(shù)據(jù)集：/ldbc011生成參數(shù)：branch=stable,version=0.3.3,scale=1000實(shí)體情況：4類實(shí)體，總數(shù)26億關(guān)系情況：19類關(guān)系，總數(shù)177億數(shù)據(jù)格式：csvGZip壓縮后大小：194G4.測試結(jié)果4.1批量數(shù)據(jù)導(dǎo)入4.1.1測試說明批量導(dǎo)入的步驟為：Hive倉庫底層csv文件->圖數(shù)據(jù)庫支持的中間文件->圖數(shù)據(jù)庫。各圖數(shù)據(jù)庫具體導(dǎo)入方式如下：Nebula：執(zhí)行Spark任務(wù)，從數(shù)倉生成RocksDB的底層存儲sst文件，然后執(zhí)行sstIngest操作插入數(shù)據(jù)。Dgraph：執(zhí)行Spark任務(wù)，從數(shù)倉生成三元組rdf文件，然后執(zhí)行bulkload操作直接生成各節(jié)點(diǎn)的持久化文件。HugeGraph：支持直接從數(shù)倉的csv文件導(dǎo)入數(shù)據(jù)，因此不需要數(shù)倉-中間文件的步驟。通過loader批量插入數(shù)據(jù)。4.1.2測試結(jié)果image4.1.3數(shù)據(jù)分析Nebula：數(shù)據(jù)存儲分布方式是主鍵哈希，各節(jié)點(diǎn)存儲分布基本均衡。導(dǎo)入速度最快，存儲放大比最優(yōu)。Dgraph：原始194G數(shù)據(jù)在內(nèi)存392G的機(jī)器上執(zhí)行導(dǎo)入命令，8.7h后OOM退出，無法導(dǎo)入全量數(shù)據(jù)。數(shù)據(jù)存儲分布方式是三元組謂詞，同一種關(guān)系只能保存在一個(gè)數(shù)據(jù)節(jié)點(diǎn)上，導(dǎo)致存儲和計(jì)算嚴(yán)重偏斜。HugeGraph：原始194G的數(shù)據(jù)執(zhí)行導(dǎo)入命令，寫滿了一個(gè)節(jié)點(diǎn)1,000G的磁盤，造成導(dǎo)入失敗，無法導(dǎo)入全量數(shù)據(jù)。存儲放大比最差，同時(shí)存在嚴(yán)重的數(shù)據(jù)偏斜。4.2實(shí)時(shí)數(shù)據(jù)寫入4.2.1測試說明向圖數(shù)據(jù)庫插入點(diǎn)和邊，測試實(shí)時(shí)寫入和并發(fā)能力。響應(yīng)時(shí)間：固定的50,000條數(shù)據(jù)，以固定qps發(fā)出寫請求，全部發(fā)送完畢即結(jié)束。取客戶端從發(fā)出請求到收到響應(yīng)的Avg、p99、p999耗時(shí)。最大吞吐量：固定的1,000,000條數(shù)據(jù)，以遞增qps發(fā)出寫請求，Query循環(huán)使用。取1分鐘內(nèi)成功請求的峰值qps為最大吞吐量。插入點(diǎn)NebulaINSERTVERTEXt_rich_node(creation_date,first_name,last_name,gender,birthday,location_ip,browser_used)VALUES${mid}:('2012-07-18T01:16:17.119+0000','Rodrigo','Silva','female','1984-10-11','6','Firefox')Dgraph{

set{

<${mid}>"2012-07-18T01:16:17.119+0000".

<${mid}>"Rodrigo".

<${mid}>"Silva".

<${mid}>"female".

<${mid}>"1984-10-11".

<${mid}>"6".

<${mid}>"Firefox".

}

}HugeGraphg.addVertex(T.label,"t_rich_node",T.id,${mid},"creation_date","2012-07-18T01:16:17.119+0000","first_name","Rodrigo","last_name","Silva","gender","female","birthday","1984-10-11","location_ip","6","browser_used","Firefox")插入邊NebulaINSERTEDGEt_edge()VALUES${mid1}->${mid2}:();Dgraph{

set{

<${mid1}><${mid2}>.

}

}HugeGraphg.V(${mid1}).as('src').V(${mid2}).addE('t_edge').from('src')4.2.2測試結(jié)果實(shí)時(shí)寫入imageimage4.2.3數(shù)據(jù)分析Nebula：如4.1.3節(jié)分析所述，Nebula的寫入請求可以由多個(gè)存儲節(jié)點(diǎn)分擔(dān)，因此響應(yīng)時(shí)間和吞吐量均大幅領(lǐng)先。Dgraph：如4.1.3節(jié)分析所述，同一種關(guān)系只能保存在一個(gè)數(shù)據(jù)節(jié)點(diǎn)上，吞吐量較差。HugeGraph：由于存儲后端基于HBase，實(shí)時(shí)并發(fā)讀寫能力低于RocksDB（Nebula）和BadgerDB（Dgraph），因此性能最差。4.3數(shù)據(jù)查詢4.3.1測試說明以常見的N跳查詢返回ID，N跳查詢返回屬性，共同好友查詢請求測試圖數(shù)據(jù)庫的讀性能。響應(yīng)時(shí)間：固定的50,000條查詢，以固定qps發(fā)出讀請求，全部發(fā)送完畢即結(jié)束。取客戶端從發(fā)出請求到收到響應(yīng)的Avg、p99、p999耗時(shí)。60s內(nèi)未返回結(jié)果為超時(shí)。最大吞吐量：固定的1,000,000條查詢，以遞增qps發(fā)出讀請求，Query循環(huán)使用。取1分鐘內(nèi)成功請求的峰值qps為最大吞吐量。緩存配置：參與測試的圖數(shù)據(jù)庫都具備讀緩存機(jī)制，默認(rèn)打開。每次測試前均重啟服務(wù)清空緩存。N跳查詢返回IDNebulaGO${n}STEPSFROM${mid}OVERperson_knows_personDgraph{

q(func:uid(${mid})){

uid

person_knows_person{#${n}跳數(shù)=嵌套層數(shù)

uid

}

}

}HugeGraphg.V(${mid}).out().id()#${n}跳數(shù)=out()鏈長度N跳查詢返回屬性NebulaGO${n}STEPSFROM${mid}OVERperson_knows_personYIELDperson_knows_person.creation_date,$$.person.first_name,$$.person.last_name,$$.person.gender,$$.person.birthday,$$.person.location_ip,$$.person.browser_usedDgraph{

q(func:uid(${mid})){

uidfirst_namelast_namegenderbirthdaylocation_ipbrowser_used

person_knows_person{#${n}跳數(shù)=嵌套層數(shù)

uidfirst_namelast_namegenderbirthdaylocation_ipbrowser_used

}

}

}HugeGraphg.V(${mid}).out()#${n}跳數(shù)=out()鏈長度共同好友查詢語句NebulaGOFROM${mid1}OVERperson_knows_personINTERSECTGOFROM${mid2}OVERperson_knows_personDgraph{

var(func:uid(${mid1})){

person_knows_person{

M1asuid

}

}

var(func:uid(${mid2})){

person_knows_person{

M2asuid

}

}

in_common(func:uid(M1))@filter(uid(M2)){

uid

}

}HugeGraphg.V(${mid1}).out().id().aggregate('x').V(${mid2}).out().id().where(within('x')).dedup()4.3.2測試結(jié)果N跳查詢返回IDimageimageN跳查詢返回屬性單個(gè)返回節(jié)點(diǎn)的屬性平均大小為200Bytes。imageimage共同好友本項(xiàng)未測試最大吞吐量。image4.3.3數(shù)據(jù)分析在1跳查詢返回ID「響應(yīng)時(shí)間」實(shí)驗(yàn)中，Nebula和DGraph都只需要進(jìn)行一次出邊搜索。由于DGraph的存儲特性，相同關(guān)系存儲在單個(gè)節(jié)點(diǎn)，1跳查詢不需要網(wǎng)絡(luò)通信。而Nebula的實(shí)體分布在多個(gè)節(jié)點(diǎn)中，因此在實(shí)驗(yàn)中DGraph響應(yīng)時(shí)間表現(xiàn)略優(yōu)于Nebula。在1跳查詢返回ID「最大吞吐量」實(shí)驗(yàn)中，DGraph集群節(jié)點(diǎn)的CPU負(fù)載主要落在存儲關(guān)系的單節(jié)點(diǎn)上，造成集群CPU利用率低下，因此最大吞吐量僅有Nebula的11%。在2跳查詢返回ID「響應(yīng)時(shí)間」實(shí)驗(yàn)中，由于上述原因，DGraph在qps=100時(shí)已經(jīng)接近了集群負(fù)載能力上限，因此響應(yīng)時(shí)間大幅變慢，是Nebula的3.9倍。在1跳查詢返回屬性實(shí)驗(yàn)中，Nebula由于將實(shí)體的所有屬性作為一個(gè)數(shù)據(jù)結(jié)構(gòu)存儲在單節(jié)點(diǎn)上，因此只需要進(jìn)行【出邊總數(shù)Y】次搜索。而DGraph將實(shí)體的所有屬性也視為出邊，并且分布在不同節(jié)點(diǎn)上，需要進(jìn)行【屬性數(shù)量X*出邊總數(shù)Y】次出邊搜索，因此查詢性能比Nebula差。多跳查詢同理。在共同好友實(shí)驗(yàn)中，由于此實(shí)驗(yàn)基本等價(jià)于2次1跳查詢返回