1. 前言

近年來，深度學(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)的近十個領(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)實際業(yè)務(wù)需求的圖數(shù)據(jù)庫產(chǎn)品，是建設(shè)圖存儲和圖學(xué)習(xí)平臺的基礎(chǔ)。我們結(jié)合業(yè)務(wù)現(xiàn)狀，制定了選型的基本條件：

開源項目，對商業(yè)應(yīng)用友好擁有對源代碼的控制力，才能保證數(shù)據(jù)安全和服務(wù)可用性。
支持集群模式，具備存儲和計算的橫向擴(kuò)展能力美團(tuán)圖譜業(yè)務(wù)數(shù)據(jù)量可以達(dá)到千億以上點邊總數(shù)，吞吐量可達(dá)到數(shù)萬 qps，單節(jié)點部署無法滿足存儲需求。
能夠服務(wù) OLTP 場景，具備毫秒級多跳查詢能力美團(tuán)搜索場景下，為確保用戶搜索體驗，各鏈路的超時時間具有嚴(yán)格限制，不能接受秒級以上的查詢響應(yīng)時間。
具備批量導(dǎo)入數(shù)據(jù)能力圖譜數(shù)據(jù)一般存儲在 Hive 等數(shù)據(jù)倉庫中。必須有快速將數(shù)據(jù)導(dǎo)入到圖存儲的手段，服務(wù)的時效性才能得到保證。

我們試用了 DB-Engines 網(wǎng)站上排名前 30 的圖數(shù)據(jù)庫產(chǎn)品，發(fā)現(xiàn)多數(shù)知名的圖數(shù)據(jù)庫開源版本只支持單節(jié)點，不能橫向擴(kuò)展存儲，無法滿足大規(guī)模圖譜數(shù)據(jù)的存儲需求，例如：Neo4j、ArangoDB、Virtuoso、TigerGraph、redisGraph。經(jīng)過調(diào)研比較，最終納入評測范圍的產(chǎn)品為：NebulaGraph（原阿里巴巴團(tuán)隊創(chuàng)業(yè)開發(fā)）、Dgraph（原 google 團(tuán)隊創(chuàng)業(yè)開發(fā)）、HugeGraph（百度團(tuán)隊開發(fā)）。

2. 測試概要

2.1 硬件配置

數(shù)據(jù)庫實例：運行在不同物理機(jī)上的 Docker 容器。
單實例資源：32 核心，64GB 內(nèi)存，1TB SSD 存儲。【Intel(R) Xeon(R) Gold 5218 CPU @ 2.30GHz】
實例數(shù)量：3

2.2 部署方案

Nebula v1.0.1

Metad 負(fù)責(zé)管理集群元數(shù)據(jù)，Graphd 負(fù)責(zé)執(zhí)行查詢，Storaged 負(fù)責(zé)數(shù)據(jù)分片存儲。存儲后端采用 RocksDB。

實例 1實例 2實例 3MetadMetadMetadGraphdGraphdGraphdStoraged[RocksDB]Storaged[RocksDB]Storaged[RocksDB]

Dgraph v20.07.0

Zero 負(fù)責(zé)管理集群元數(shù)據(jù)，Alpha 負(fù)責(zé)執(zhí)行查詢和存儲。存儲后端為 Dgraph 自有實現(xiàn)。

實例 1實例 2實例 3ZeroZeroZeroAlphaAlphaAlpha

HugeGraph v0.10.4

HugeServer 負(fù)責(zé)管理集群元數(shù)據(jù)和查詢。HugeGraph 雖然支持 RocksDB 后端，但不支持 RocksDB 后端的集群部署，因此存儲后端采用 HBase。

實例1實例2實例3HugeServer[HBase]HugeServer[HBase]HugeServer[HBase]JournalNodeJournalNodeJournalNodeDataNodeDataNodeDataNodeNodeManagerNodeManagerNodeManagerRegionServerRegionServerRegionServerZooKeeperZooKeeperZooKeeperNameNodeNameNode[Backup]--ResourceManagerResourceManager[Backup]HBase MasterHBase Master[Backup]-

3. 評測數(shù)據(jù)集

社交圖譜數(shù)據(jù)集：https://github.com/ldbc011生成參數(shù)：branch=stable, version=0.3.3, scale=1000實體情況：4 類實體，總數(shù) 26 億關(guān)系情況：19 類關(guān)系，總數(shù) 177 億數(shù)據(jù)格式：csvGZip 壓縮后大小：194 G

4. 測試結(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í)行 sst Ingest 操作插入數(shù)據(jù)。
Dgraph：執(zhí)行 Spark 任務(wù)，從數(shù)倉生成三元組 rdf 文件，然后執(zhí)行 bulk load 操作直接生成各節(jié)點的持久化文件。
HugeGraph：支持直接從數(shù)倉的 csv 文件導(dǎo)入數(shù)據(jù)，因此不需要數(shù)倉-中間文件的步驟。通過 loader 批量插入數(shù)據(jù)。

4.1.2 測試結(jié)果

4.1.3 數(shù)據(jù)分析

Nebula：數(shù)據(jù)存儲分布方式是主鍵哈希，各節(jié)點存儲分布基本均衡。導(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)系只能保存在一個數(shù)據(jù)節(jié)點上，導(dǎo)致存儲和計算嚴(yán)重偏斜。
HugeGraph：原始 194G 的數(shù)據(jù)執(zhí)行導(dǎo)入命令，寫滿了一個節(jié)點 1,000G 的磁盤，造成導(dǎo)入失敗，無法導(dǎo)入全量數(shù)據(jù)。存儲放大比最差，同時存在嚴(yán)重的數(shù)據(jù)偏斜。

4.2 實時數(shù)據(jù)寫入

4.2.1 測試說明

向圖數(shù)據(jù)庫插入點和邊，測試實時寫入和并發(fā)能力。響應(yīng)時間：固定的 50,000 條數(shù)據(jù)，以固定 qps 發(fā)出寫請求，全部發(fā)送完畢即結(jié)束。取客戶端從發(fā)出請求到收到響應(yīng)的 Avg、p99、p999 耗時。最大吞吐量：固定的 1,000,000 條數(shù)據(jù)，以遞增 qps 發(fā)出寫請求，Query 循環(huán)使用。取 1 分鐘內(nèi)成功請求的峰值 qps 為最大吞吐量。
插入點NebulaINSERT VERTEX t_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', '84.194.222.86', 'Firefox') Dgraph{ set { <${mid}> <creation_date> "2012-07-18T01:16:17.119+0000" . <${mid}> <first_name> "Rodrigo" . <${mid}> <last_name> "Silva" . <${mid}> <gender> "female" . <${mid}> <birthday> "1984-10-11" . <${mid}> <location_ip> "84.194.222.86" . <${mid}> <browser_used> "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", "84.194.222.86", "browser_used", "Firefox")
插入邊NebulaINSERT EDGE t_edge () VALUES ${mid1}->${mid2}:(); Dgraph{ set { <${mid1}> <link> <${mid2}> . } } HugeGraphg.V(${mid1}).as('src').V(${mid2}).addE('t_edge').from('src')

4.2.2 測試結(jié)果

實時寫入

4.2.3 數(shù)據(jù)分析

Nebula：如 4.1.3 節(jié)分析所述，Nebula 的寫入請求可以由多個存儲節(jié)點分擔(dān)，因此響應(yīng)時間和吞吐量均大幅領(lǐng)先。
Dgraph：如 4.1.3 節(jié)分析所述，同一種關(guān)系只能保存在一個數(shù)據(jù)節(jié)點上，吞吐量較差。
HugeGraph：由于存儲后端基于 HBase，實時并發(fā)讀寫能力低于 RocksDB（Nebula）和 BadgerDB（Dgraph），因此性能最差。

4.3 數(shù)據(jù)查詢

4.3.1 測試說明

以常見的 N 跳查詢返回 ID，N 跳查詢返回屬性，共同好友查詢請求測試圖數(shù)據(jù)庫的讀性能。響應(yīng)時間：固定的 50,000 條查詢，以固定 qps 發(fā)出讀請求，全部發(fā)送完畢即結(jié)束。取客戶端從發(fā)出請求到收到響應(yīng)的 Avg、p99、p999 耗時。60s 內(nèi)未返回結(jié)果為超時。最大吞吐量：固定的 1,000,000 條查詢，以遞增 qps 發(fā)出讀請求，Query 循環(huán)使用。取 1 分鐘內(nèi)成功請求的峰值 qps 為最大吞吐量。緩存配置：參與測試的圖數(shù)據(jù)庫都具備讀緩存機(jī)制，默認(rèn)打開。每次測試前均重啟服務(wù)清空緩存。
N 跳查詢返回 IDNebulaGO ${n} STEPS FROM ${mid} OVER person_knows_person Dgraph{ q(func:uid(${mid})) { uid person_knows_person { #${n}跳數(shù) = 嵌套層數(shù) uid } } } HugeGraphg.V(${mid}).out().id() #${n}跳數(shù) = out()鏈長度
N 跳查詢返回屬性NebulaGO ${n} STEPS FROM ${mid} OVER person_knows_person YIELDperson_knows_person.creation_date, $$.person.first_name, $$.person.last_name, $$.person.gender, $$.person.birthday, $$.person.location_ip, $$.person.browser_used Dgraph{ q(func:uid(${mid})) { uid first_name last_name gender birthday location_ip browser_used person_knows_person { #${n}跳數(shù) = 嵌套層數(shù) uid first_name last_name gender birthday location_ip browser_used } } } HugeGraphg.V(${mid}).out() #${n}跳數(shù) = out()鏈長度
共同好友查詢語句NebulaGO FROM ${mid1} OVER person_knows_person INTERSECT GO FROM ${mid2} OVER person_knows_person Dgraph{ var(func: uid(${mid1})) { person_knows_person { M1 as uid } } var(func: uid(${mid2})) { person_knows_person { M2 as uid } } 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 跳查詢返回 ID

N 跳查詢返回屬性

單個返回節(jié)點的屬性平均大小為 200 Bytes。

共同好友
本項未測試最大吞吐量。

4.3.3 數(shù)據(jù)分析

在 1 跳查詢返回 ID「響應(yīng)時間」實驗中，Nebula 和 DGraph 都只需要進(jìn)行一次出邊搜索。由于 DGraph 的存儲特性，相同關(guān)系存儲在單個節(jié)點，1 跳查詢不需要網(wǎng)絡(luò)通信。而 Nebula 的實體分布在多個節(jié)點中，因此在實驗中 DGraph 響應(yīng)時間表現(xiàn)略優(yōu)于 Nebula。
在 1 跳查詢返回 ID「最大吞吐量」實驗中，DGraph 集群節(jié)點的 CPU 負(fù)載主要落在存儲關(guān)系的單節(jié)點上，造成集群 CPU 利用率低下，因此最大吞吐量僅有 Nebula 的 11%。
在 2 跳查詢返回 ID「響應(yīng)時間」實驗中，由于上述原因，DGraph 在 qps=100 時已經(jīng)接近了集群負(fù)載能力上限，因此響應(yīng)時間大幅變慢，是 Nebula 的 3.9 倍。
在 1 跳查詢返回屬性實驗中，Nebula 由于將實體的所有屬性作為一個數(shù)據(jù)結(jié)構(gòu)存儲在單節(jié)點上，因此只需要進(jìn)行【出邊總數(shù) Y】次搜索。而 DGraph 將實體的所有屬性也視為出邊，并且分布在不同節(jié)點上，需要進(jìn)行【屬性數(shù)量 X * 出邊總數(shù) Y】次出邊搜索，因此查詢性能比 Nebula 差。多跳查詢同理。
在共同好友實驗中，由于此實驗基本等價于 2 次 1 跳查詢返回 ID，因此測試結(jié)果接近，不再詳述。
由于 HugeGraph 存儲后端基于 HBase，實時并發(fā)讀寫能力低于 RocksDB（Nebula）和 BadgerDB（Dgraph），因此在多項實驗中性能表現(xiàn)均落后于 Nebula 和 DGraph。