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

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

遷移背景

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

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

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

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

我們對比相同的業務場景，但是隻有 6 臺相同配置的 SSD 伺服器 Nebua Graph 的磁碟 IO 和網路 IO 情況如下：

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