摘要：在本文中 360 數科的周鵬詳細講解了業務從 JanusGraph 遷移到 Nebula Graph 帶來的效能提升，在機器資源不到之前 JanusGraph 配置三分之一的情況下，業務效能提升至少 20 倍。

![360 遷移](https://www-cdn.nebula-graph.com.cn/nebula-blog/360-migrate.png)

> 本文作者系 360 數科開發工程師：周鵬

## 遷移背景

我們之前圖資料用的是單機版的 [AgensGraph](https://github.com/bitnine-oss/agensgraph), 後面因為單機帶來的效能限制問題，遷移到了分散式資料庫 [JanusGraph](https://github.com/JanusGraph/janusgraph)，詳細的遷移資訊可以看我之前的一篇文章[《百億級圖資料JanusGraph遷移之旅》](https://www.jianshu.com/p/f372f0ef6c42)。但是隨著資料量和業務呼叫量的增加，新的問題又出現了——單次查詢的耗時很高個別業務場景已經到了 10s，資料量稍微多點，邏輯複雜點的查詢耗時也在 2~3s 左右，這嚴重影響了整個業務流程的效能和相關業務的發展。

JanusGraph 的架構決定了單次耗時高，核心的原因在於它的儲存依賴外部，自身不能很好地控制外部儲存，我們生產環境用的便是 [HBase](https://hbase.apache.org/) 叢集，這導致所有的查詢沒法下推到儲存層進行處理，只能把資料從 HBase 查詢到 JanusGraph Server 記憶體再做相應的過濾。

舉個例子，查詢一層關聯關係年齡大於 50 歲的使用者，如果一層關聯有 1,000 人，年齡大於 50 歲的只有 2 個人。介於 JanusGraph 查詢請求傳送到 HBase 時做不了一層關聯頂點屬性的過濾，我們不得不透過併發請求去查詢 HBase 獲取這 1,000 人的頂點屬性，再在 JanusGraph Server 的記憶體做過濾，最後返回給客戶端滿足條件的 2 個使用者。

這樣做的問題就是磁碟 IO、網路 IO 浪費很大，而且查詢返回的大多資料在而後查的查詢並未用到。我們生產環境用的 HBase 為 19 臺高配 SSD 伺服器的，具體的網路 IO、磁碟 IO 使用情況如下圖：

![Hbase 網路IO](https://www-cdn.nebula-graph.com.cn/nebula-blog/hbase-network-io.jpg)

![Hbase 磁碟IO](https://www-cdn.nebula-graph.com.cn/nebula-blog/hbase-hardware-io.jpeg)

我們對比相同的業務場景，但是隻有 6 臺相同配置的 SSD 伺服器 [Nebua Graph](https://0x7.me/3602github) 的磁碟 IO 和網路 IO 情況如下：

![NebulaGraph 網路IO](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-network-io.jpg)

![NebulaGraph 磁碟IO](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-hardware-io.jpg)

Nebula Graph 效能確實優秀太多，而且是在機器資源只有之前 Hbase 叢集 30% 的情況下。我們再來看下業務場景下的耗時情況，之前業務場景中查詢耗時需要 2~3s 情況的在 Nebula Graph 這邊 100ms 左右返回了，之前需要 10~20s 情況的業務場景現在也基本在 2s 就能返回，並且平均耗時也基本在 500ms 左右就能搞定，效能提升至少 20 倍以上 :)

![cat 耗時監控](https://www-cdn.nebula-graph.com.cn/nebula-blog/cat-detective.jpg)

就衝上面的這些資料，如果你還在用 JanusGraph，就應該立馬把這篇文章轉發給你的領導，並立個項開始遷移到 [Nebua Graph](https://github.com/vesoft-inc/nebula) ?

## 歷史資料遷移

資料遷移這塊，因為我們的資料量比較大，20 億左右的頂點，200 億左右的邊，好在 Nebula Graph 提供 Spark 匯入工具——[Spark Writer](https://github.com/vesoft-inc/nebula-java/tree/master/tools/exchange)，整個資料匯入過程還算比較流暢。這裡有個可分享經驗，當時使用 Spark 匯入工具採用非同步方式匯入導致了不少 error，稍微改下匯入方式換成同步寫入就沒問題了。另外一個經驗是關於 Spark 的，如果匯入的資料量比較大，對應的 partitions 需要設定大一點，我們就設定過 8w 個 patitions。如果你設定的 partitions 比較小，單個 partition 的資料量便會比較大，容易導致 Spark 任務 OOM Fail。

## 查詢調優

我們現在生產環境 Nebula Graph 用的是 [1.0 的版本](https://github.com/vesoft-inc/nebula/releases/tag/v1.0.0)，生產環境上 ID 生產我們用的是 hash 函式， uuid 匯入資料會很慢，後面官方也不會再支援 uuid。

在我們的生產環境主要引數調優配置如下，主要是 nebula-storage 需要調優

```
# The default reserved bytes for one batch operation
--rocksdb_batch_size=4096
# The default block cache size used in BlockBasedTable.
# The unit is MB. 我們生產伺服器記憶體為128G
--rocksdb_block_cache=44024

############## rocksdb Options ##############
--rocksdb_disable_wal=true
# rocksdb DBOptions in json, each name and value of option is a string, given as "option_name":"option_value" separated by comma
--rocksdb_db_options={"max_subcompactions":"3","max_background_jobs":"3"}
# rocksdb ColumnFamilyOptions in json, each name and value of option is string, given as "option_name":"option_value" separated by comma
--rocksdb_column_family_options={"disable_auto_compactions":"false","write_buffer_size":"67108864","max_write_buffer_number":"4","max_bytes_for_level_base":"268435456"}
# rocksdb BlockBasedTableOptions in json, each name and value of option is string, given as "option_name":"option_value" separated by comma
--rocksdb_block_based_table_options={"block_size":"8192"}

--max_handlers_per_req=10
--heartbeat_interval_secs=10

# 新新增引數
--raft_rpc_timeout_ms=5000
--raft_heartbeat_interval_secs=10
--wal_ttl=14400
--max_batch_size=512
# 引數配置減小記憶體使用
--enable_partitioned_index_filter=true
--max_edge_returned_per_vertex=10000
```

Linux 機器的調優主要就是把服務的 swap 關閉掉，開啟後會因為磁碟 IO 影響查詢效能。另外關於 minor compact 和 major compact 調優，我們生產環境是開啟 minor compact 關閉 major compact。關閉 major compact 主要是因為這個操作很佔磁碟 IO，並且很難透過執行緒數（`--rocksdb_db_options={"max_subcompactions":"3","max_background_jobs":"3"`}）控制，後續 Nebula Graph 官方有計劃最佳化這塊。

最後，來重點提下 `max_edge_returned_per_vertex` 這個引數，能想到這個引數 Nebula Graph 不愧是圖資料行業的老司機——我們之前的圖查詢一直受到超級節點的困擾，線上環境如果查詢遇到這種關聯幾百萬資料的超級節點能直接把 JanusGraph 的 HBase 叢集查崩掉（我們生產環境出現過幾次）。之前在查詢 JanusGraph 的 Gremlin 語句上加各種 limit 限制都沒能很好的解決這個問題，在 Nebula Graph 有了這個 `max_edge_returned_per_vertex` 引數，資料在最底層儲存層直接做了過濾，生產環境就不會再有這種超級節點的困擾，就這一點就應該給 NebulaGraph 一個 FIVE STAR ！

**本文首發於** [Nebula Graph 論壇](https://discuss.nebula-graph.com.cn/)，**閱讀本文的你有任何疑問，歡迎前往論壇和作者進行討論，原帖傳送門**：[https://discuss.nebula-graph.com.cn/t/topic/1172](https://discuss.nebula-graph.com.cn/t/topic/1172)

360 數科實踐：JanusGraph 到 NebulaGraph 遷移

相關文章