詳解 nebula 2.0 性能測試和 nebula-importer 數據導入調優

這是由社區用戶——繁凡撰寫的一篇他的實踐分享，主要講解如何進行 Nebula 性能測試以及數據導入部分的性能調優。下文中出現的「我」代指用戶繁凡。

0. 概要

以前在作 Nebula 的調研工做，而後又針對使用上作了性能測試，期間屢次請教了 Nebula 的官方人員，在這裏對官方人員表示感謝，大佬辛苦了！

我把本身測試的過程整理一下，但願對你們有一點啓發，若是你們有更好的意見，請不吝賜教！

1.部署 Nebula 集羣

首先準備了 4 臺實體機：一、二、三、4，每臺配置，CPU：96C，內存：512G， 磁盤：SSD。機子分配：

• 1：meta，storage
• 2：storage
• 3：storage
• 4：graphd

安裝過程就再也不詳述了，使用的是 rpm 的方式。其餘插件：nebula-import-2.0，nebula-bench-2.0，下載源碼編譯便可，安裝在 4 節點。

2.導入數據

本次導入的數據數據結構爲 7 種點類型、15 種邊類型，數據量並不大，結構也很簡單，數據量總計 3400w，不過要提早處理成這麼多個點邊表。

先建立 space，設置 vid=100 ，replica_factor=3，partition_num=100。

nebula-importer 數據導入優化

使用 nebula-importer 進行導入，直接開幹，速度只有 3w/s 的樣子，這也太慢了吧。查看import的文檔，整個使用的參數也就只有concurrency，channelBufferSize ，batchsize

先調整一下試試吧，隨便改了改，效果並不明顯, 發帖請教大佬了。詳見論壇帖子 nebula-import 2.0 導入速度太慢，請教完以後，收穫很大，先改 yaml 參數

concurrency：96 # cpu核數
channelBufferSize：20000
batchsize：2500

複製代碼

速度差很少 7-8w 了，嗯，看起來確實快了不少，再搞大點，graphd 直接崩掉了，看來仍是不能過大，因此這幾個參數要儘可能大可是不能過大。

而後再確認下磁盤和網絡，居然用的是機械磁盤和千 M 網絡。。。改爲SSD的，而後再切換成萬 M 網絡，速度直接再提高一倍多，大概 17w/s，看起來硬件仍是很重要。

而後我再想會不會跟數據有關係，注意到 vid 和partition_num，vid 挺長的想着設置短一點可是沒辦法改，由於確實有這麼長的，而後是 partition_num，看了下官方說明，磁盤的 2-10 倍，改成了 15，確實有影響，速度達到了 25w/s。到這裏也算比較滿意了，可能再修改還會有提高，不過已經知足要求了先告一段落吧。

小結

• concurrency 設置爲 CPU 核數，channelBufferSize 和 batchsize 儘量大，可是不能超過集羣的負載。
• 硬件要用 SSD 和萬 M 網絡
• space 的分區 partition_num 要合理，不能太多
• 猜想 vid 長度，屬性數量，graphd 的個數都有影響，但還何嘗試

3.壓力測試

根據業務上使用的指標，選取了一個進行測試。 指標以下：

match (v:email)-[:emailid]->(mid:id)<-[:phoneid]-(phone:phone)-[:phoneid]->(ids:id) where id(v)=="replace" with v, count(distinct phone) as pnum,count(distinct mid) as midnum,count(distinct ids) as idsnum , sum(ids.isblack) as black  where pnum > 2 and midnum>5 and midnum < 100 and idsnum > 5 and idsnum < 300 and black > 0 return v.value1, true as result
複製代碼

該語句爲一個三度擴散 + 條件判斷，集中數據涉及點的數量大概在 200-400 之間。

官方的 nebula-bench 須要作一點修改，打開 jmter 的 go_step.jmx 配置文件，修改ThreadGroup.num_threads爲 CPU 核數，而後是其餘的參數，如 loop，ngql 根據實際狀況設置，ngql 裏邊的變量要用 replace 代替。

因爲測試數據爲較爲集中的數據，該部分測試結果爲 700/s,將數據擴大至所有節點，則達到 6000+/s。併發看起來仍是能夠的，查詢速度也 ok，最高 300ms。

由於我這裏是單節點，因此想增長 1 臺 graphd 進行測試，看併發是否提升，而後直接啓動了一個graphd進程，再測試結果發現沒有提升。

而後恰好看到發佈了2.0.1，因此從新搭建了集羣，從新導入數據，使用 3 臺 graphd，性能直接翻三倍，集中數據達到2100+/s，所有節點則達到將近 2w。因此很奇怪，詳見論壇帖子nebula-bench 2.0 增長graph節點，併發上不去 。

猜想多是因爲增長 graphd 以後沒有 blance 或者 compact，有空能夠嘗試一下。

另外因爲沒有使用一些監控組件，只用了 Linux 的命令查看，因此也沒有獲得太確切的機器狀態信息。

小結

• 測試以前，保證集羣的負載平衡，作好 compact
• 適當調整 storage 的配置，增大可用線程數以及緩存的內存大小
• 併發跟數據有很大關係的，單純多少沒有意義，須要結合本身的數據分佈狀況來看。

4.配置

下邊直接貼一下我修改的參數，meta，graphd 都採用默認配置，也沒有特別要修改的，只貼一下 storage，並進行說明。

rocksdb_block_cache=102400  # 官方建議 1/3 內存，我這裏設置 100G
num_io_threads=48 # 可用線程數，設置爲 cpu 核數一半
min_vertices_per_bucket=100 # 一個桶最小的點數量
vertex_cache_bucket_exp=8 # 桶的總數是 2 的 8 次方
wal_buffer_size=16777216  # 16 M

write_buffer_size:268435456   # 256 M
複製代碼

這裏的參數是根據瀏覽各個貼子以及去官方代碼查找的，並不必定特別準確，也是摸索來的，其餘的參數沒有特別修改。有不少的參數沒有暴露出來，官方不建議隨便修改，因此須要瞭解的話要去 GitHub 的源碼裏邊查看。

結尾

整體來講，本次測試算不上特別專業，可是針對具體業務場景的測試，Nebula 也表現了很好的結果。具體參數的調整，也沒有研究特別透徹，須要以後在使用中研究，若是你們有調優的好想法還請暢所欲言。

交流圖數據庫技術？報名參與 Nebula 交流會，NUC·2021 報名傳送門，咱們在北京等你來交流~~