主流開源分布式圖數據庫 Benchmark

本文轉載自查看原文 2020-10-21 10:31 3369 技術長文

本文由美團 NLP 團隊高辰、趙登昌撰寫
首發於 Nebula Graph 官方論壇：https://discuss.nebula-graph.com.cn/t/topic/1377

1. 前言

近年來，深度學習和知識圖譜技術發展迅速，相比於深度學習的“黑盒子”，知識圖譜具有很強的可解釋性，在搜索推薦、智能助理、金融風控等場景中有着廣泛的應用。美團基於積累的海量業務數據，結合使用場景進行充分地挖掘關聯，逐步建立起包括美食圖譜、旅游圖譜、商品圖譜在內的近十個領域知識圖譜，並在多業務場景落地，助力本地生活服務的智能化。

為了高效存儲並檢索圖譜數據，相比傳統關系型數據庫，選擇圖數據庫作為存儲引擎，在多跳查詢上具有明顯的性能優勢。當前業界知名的圖數據庫產品有數十款，選型一款能夠滿足美團實際業務需求的圖數據庫產品，是建設圖存儲和圖學習平台的基礎。我們結合業務現狀，制定了選型的基本條件：

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

我們試用了 DB-Engines 網站上排名前 30 的圖數據庫產品，發現多數知名的圖數據庫開源版本只支持單節點，不能橫向擴展存儲，無法滿足大規模圖譜數據的存儲需求，例如：Neo4j、ArangoDB、Virtuoso、TigerGraph、RedisGraph。經過調研比較，最終納入評測范圍的產品為：NebulaGraph（原阿里巴巴團隊創業開發）、Dgraph（原 Google 團隊創業開發）、HugeGraph（百度團隊開發）。

2. 測試概要

2.1 硬件配置

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

2.2 部署方案

Nebula v1.0.1

Metad 負責管理集群元數據，Graphd 負責執行查詢，Storaged 負責數據分片存儲。存儲后端采用 RocksDB。

實例 1	實例 2	實例 3
Metad	Metad	Metad
Graphd	Graphd	Graphd
Storaged[RocksDB]	Storaged[RocksDB]	Storaged[RocksDB]

Dgraph v20.07.0

Zero 負責管理集群元數據，Alpha 負責執行查詢和存儲。存儲后端為 Dgraph 自有實現。

實例 1	實例 2	實例 3
Zero	Zero	Zero
Alpha	Alpha	Alpha

HugeGraph v0.10.4

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

實例1	實例2	實例3
HugeServer[HBase]	HugeServer[HBase]	HugeServer[HBase]
JournalNode	JournalNode	JournalNode
DataNode	DataNode	DataNode
NodeManager	NodeManager	NodeManager
RegionServer	RegionServer	RegionServer
ZooKeeper	ZooKeeper	ZooKeeper
NameNode	NameNode[Backup]	-
-	ResourceManager	ResourceManager[Backup]
HBase Master	HBase Master[Backup]	-

3. 評測數據集

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

4. 測試結果

4.1 批量數據導入

4.1.1 測試說明

批量導入的步驟為：Hive 倉庫底層 csv 文件 -> 圖數據庫支持的中間文件 -> 圖數據庫。各圖數據庫具體導入方式如下：

Nebula：執行 Spark 任務，從數倉生成 RocksDB 的底層存儲 sst 文件，然后執行 sst Ingest 操作插入數據。
Dgraph：執行 Spark 任務，從數倉生成三元組 rdf 文件，然后執行 bulk load 操作直接生成各節點的持久化文件。
HugeGraph：支持直接從數倉的 csv 文件導入數據，因此不需要數倉-中間文件的步驟。通過 loader 批量插入數據。

4.1.2 測試結果

4.1.3 數據分析

Nebula：數據存儲分布方式是主鍵哈希，各節點存儲分布基本均衡。導入速度最快，存儲放大比最優。
Dgraph：原始 194G 數據在內存 392G 的機器上執行導入命令，8.7h 后 OOM 退出，無法導入全量數據。數據存儲分布方式是三元組謂詞，同一種關系只能保存在一個數據節點上，導致存儲和計算嚴重偏斜。
HugeGraph：原始 194G 的數據執行導入命令，寫滿了一個節點 1,000G 的磁盤，造成導入失敗，無法導入全量數據。存儲放大比最差，同時存在嚴重的數據偏斜。

4.2 實時數據寫入

4.2.1 測試說明

向圖數據庫插入點和邊，測試實時寫入和並發能力。
- 響應時間：固定的 50,000 條數據，以固定 qps 發出寫請求，全部發送完畢即結束。取客戶端從發出請求到收到響應的 Avg、p99、p999 耗時。
- 最大吞吐量：固定的 1,000,000 條數據，以遞增 qps 發出寫請求，Query 循環使用。取 1 分鍾內成功請求的峰值 qps 為最大吞吐量。

插入點

Nebula

INSERT 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" .
    }
}

HugeGraph

g.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")

插入邊

Nebula

INSERT EDGE t_edge () VALUES ${mid1}->${mid2}:();

Dgraph

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

HugeGraph

g.V(${mid1}).as('src').V(${mid2}).addE('t_edge').from('src')

4.2.2 測試結果

實時寫入

4.2.3 數據分析

Nebula：如 4.1.3 節分析所述，Nebula 的寫入請求可以由多個存儲節點分擔，因此響應時間和吞吐量均大幅領先。
Dgraph：如 4.1.3 節分析所述，同一種關系只能保存在一個數據節點上，吞吐量較差。
HugeGraph：由於存儲后端基於 HBase，實時並發讀寫能力低於 RocksDB（Nebula）和 BadgerDB（Dgraph），因此性能最差。

4.3 數據查詢

4.3.1 測試說明

以常見的 N 跳查詢返回 ID，N 跳查詢返回屬性，共同好友查詢請求測試圖數據庫的讀性能。
- 響應時間：固定的 50,000 條查詢，以固定 qps 發出讀請求，全部發送完畢即結束。取客戶端從發出請求到收到響應的 Avg、p99、p999 耗時。
  - 60s 內未返回結果為超時。
- 最大吞吐量：固定的 1,000,000 條查詢，以遞增 qps 發出讀請求，Query 循環使用。取 1 分鍾內成功請求的峰值 qps 為最大吞吐量。
- 緩存配置：參與測試的圖數據庫都具備讀緩存機制，默認打開。每次測試前均重啟服務清空緩存。

N 跳查詢返回 ID

Nebula

GO ${n} STEPS FROM ${mid} OVER person_knows_person

Dgraph

{
 q(func:uid(${mid})) {
   uid
   person_knows_person { #${n}跳數 = 嵌套層數
     uid
   }
 }
}

HugeGraph

g.V(${mid}).out().id() #${n}跳數 = out()鏈長度

N 跳查詢返回屬性

Nebula

GO ${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}跳數 = 嵌套層數
      uid first_name last_name gender birthday location_ip browser_used
    }
  }
}

HugeGraph

g.V(${mid}).out()  #${n}跳數 = out()鏈長度

共同好友查詢語句

Nebula

GO 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
  }
}

HugeGraph

g.V(${mid1}).out().id().aggregate('x').V(${mid2}).out().id().where(within('x')).dedup()

4.3.2 測試結果

N 跳查詢返回 ID

N 跳查詢返回屬性

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

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

4.3.3 數據分析

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

5. 結論

參與測試的圖數據庫中，Nebula 的批量導入可用性、導入速度、實時數據寫入性能、數據多跳查詢性能均優於競品，因此我們最終選擇了 Nebula 作為圖存儲引擎。

6. 參考資料

NebulaGraph Benchmark：https://discuss.nebula-graph.com.cn/t/topic/782
NebulaGraph Benchmark 微信團隊：https://discuss.nebula-graph.com.cn/t/topic/1013
DGraph Benchmark：https://dgraph.io/blog/tags/benchmark/
HugeGraph Benchmark：https://hugegraph.github.io/hugegraph-doc/performance/hugegraph-benchmark-0.5.6.html
TigerGraph Benchmark：https://www.tigergraph.com/benchmark/
RedisGraph Benchmark：https://redislabs.com/blog/new-redisgraph-1-0-achieves-600x-faster-performance-graph-databases/

本次性能測試系美團 NLP 團隊高辰、趙登昌撰寫，如果你對本文有任意疑問，歡迎來原貼和作者交流：https://discuss.nebula-graph.com.cn/t/topic/1377

免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。

猜您在找 目前主流的分布式數據庫 TiDB 開源分布式關系型數據庫分布式數據庫當數據庫遇到分布式分布式數據庫華為雲分布式數據庫中間件DDM和開源MyCAT對比敢啃“硬骨頭”，開源分布式數據庫TiDB如何煉成？ InfluxDB 開源分布式時序、事件和指標數據庫小試國產開源HTAP分布式NewSQL數據庫TiDB-v5.3.0 開源分布式數據庫中間件MyCat源碼分析系列