「實操」適配 NebulaGraph 新版本與壓測實踐

NebulaGraph發表於2022-12-22
本文來自邦盛科技-知識圖譜團隊-繁凡，本文以 NebulaGraph v3.1.0 為例。

前言

NebulaGraph v3.1 版本已經發布有一段時間了，但是我們的專案之前是基於 v2.6.1 版本開發的，由於一直在做功能相關的工作，所以一直沒有對相簿進行升級。

最近，剛好完成了 NebulaGraph v3.1 版本的升級，並做了一些測試工作，這期間的一些問題總結，在這裡分享一下，都是實踐中踩過的坑，文中的一些問題可能也是 NebulaGraph 相關的 bug。

升級事項

v2.6.1 版本到 v3.1.0 版本是一個較大版本，從不支援直接升級來看，改動的東西還是蠻多的，那麼專案中需要改造的地方應該也是比較多的。下邊是我們在升級過程中的一些總結。

語法改動

  1. 首先是 MATCH 查詢的調整，最佳化了 MATCH 的查詢效能，並且支援多 MATCH 的子句，這個確實極大地提高了 MATCH 查詢的表達能力，但是實測當中，複雜的查詢效能並不會太高，用於不需要毫秒級響應的查詢分析還是很方便的。
  2. MATCH 查詢屬性需要指定 Tag，這個一定程度上解決了同名屬性的問題，順帶提一下在 GO 語句中，同名屬性尚未解決，用的時候需要注意。
  3. match (v) return v 這個實在是太有用了，之前必須要指定 vid，但是很多時候匯入了資料不知道 vid，只想大致看一下，還要去翻一下資料很麻煩。
  4. GO 等語句必須要帶 YIELD 返回了，之前專案中所有用到的地方都要做修改，這個要注意。
  5. GO、FETCH 等可以返回 vertex 和 edge 了，這個也解決了一大痛點，由於 API 查詢需要返回 path 或者 vertex 和 edge，用於渲染圖，但是 v2.6 中 MATCH 的查詢太慢了，只好使用 GO 查詢。於是，就要把點邊的所有資訊都 YIELD 出來，造成特殊化的返回，需要專門寫程式碼解析。現在可以直接一次返回 vertex 和 edge，使用通用的解析方法很 easy 了。
  6. SHOW ALL QUERIES 變化了，專案中有用到超時 kill 的機制，需要 kill 掉慢查詢，現在要改成 show local queries，拿到 sessionId（ps：這個 sessionId 私有了，要不就不用查了...），再使用 SHOW QUERIES 查詢到對應的 planId 執行 kill 命令。
  7. Console 的查詢資料匯出已經不可用了，有用到的需要注意。

新增部分

  1. KV 分離是一個很大的改變了，不過目前沒有對這個功能進行測試，有實踐過的可以談談未分離的差異。
  2. 增加了限制一個使用者和機器的 session 個數，這個不注意的話在併發的情況下很容易超出限制。
  3. 支援了 CLEAR SPACE，清除圖空間語句，這個非常好用，在測試時經常要清空相簿，以前只能刪除重建。不過實測中資料量較多會有一定耗時，需要謹慎使用。
  4. BALANCE DATA 這個命令不直接可用了，論壇問了一下需要開啟實驗性功能。因為開啟了實驗性功能，所以間接開啟了 v2.6.0 開始支援的 TOSS 這個功能，強制保證資料一致性，導致資料寫入緩慢，於是就又關掉了。所以目前 BALANCE DATA 不太方便，可能後續會有一些調整吧。

改動部分

  1. 刪除點只會刪掉點了，之前是連帶點的邊都會刪除，這裡使用一定要注意懸掛邊導致的資料一致性的問題。
  2. 支援不帶 Tag 的點，就是允許只有一個 vid 存在。這個似乎引起一個 bug，只有一個 tag 的點在 TTL 過期之後，點仍然存在，跟文件不符。另外 TTL 的時間也似乎是一個 bug，總是提前個 30 幾秒就過期了，比如設定 60 秒，再 30 秒左右就過期了。
  3. ADD HOSTS 命令，用於新增 storage 服務，這樣就可以較好的管理 storage 節點了，但是 BALANCE DATA 命令使用的問題，導致擴縮容沒有 2.6 版本方便了。
  4. 會話超時時間必須要限制了，實測中 session 那裡可能是有一個 bug，session 被程式 release 之後沒有清除，導致觸發了最大 session 數，所以就將 session 超時時間改小一點，清理掉不用的 session。
  5. 修復了大量會引起崩潰的語句，之前的一些聚合語句使用不當就會引起崩潰，著實有點嚇人...

適配層面大致總結這麼多吧，還有一些改動就不再細說了，這裡講到的都是在實際中使用時的感受。

壓測實踐

切換到新的版本，當然要進行一下壓測，以發現一些沒有排查到的問題，下邊就直接上乾貨，講一下實際遇到的問題。

SST 資料匯入問題

由於 v2.6 的時候沒有使用過 SST 匯入，所以壓測時為了快速匯入資料，想使用 SST 去匯入資料。

相簿分片 partition 為 20，匯入配置先設定了 repartitionWithNebula: false，結果發現產生了巨多的 SST 檔案，ingest 極慢，並且出現資料寫入丟失的問題。

然後調整為 ture，並調低了 spark.sql.shuffle.partitions，於是每個檔案合併為了一個 SST 檔案，很快就匯入了。然後又產生新的問題，發現有一些點不存在了，沒有匯入成功，但是 SHOW STATS 統計資訊正常。

經過反覆測試與官方人員溝通，發現是 8 位長度的 vid 有問題，hash 的策略不太對，目前已經被修復了但是好像還未合併到主分支吧。具體可以看帖子：https://discuss.nebula-graph.com.cn/t/topic/8984/14

Client 資料匯入問題

Client 理論上是不會有問題的，畢竟是語句寫入，但是跟使用的方式和相簿狀態也有很大的關係。我是沿用了當時 v2.6 的配置檔案，core：40，batch：2560 的配置。

相簿冷啟動寫入報錯：一開始就遇到相簿冷啟動的問題，冷啟動之後立馬導數，會寫入報錯：

E20220607 11:02:41.447904 108593 StorageAccessExecutor.h:39] InsertEdgesExecutor failed, error E_LEADER_CHANGED, part 17
E20220607 11:02:41.447954 108591 QueryInstance.cpp:137] Storage Error: Not the leader of 17. Please retry later.

但是這個問題不要緊，相簿能自己恢復，過一會就寫入正常了，error 語句會在最後被再次寫入。（PS：這裡注意下，error 語句寫入的 write 方法中文會亂碼，導致再次寫入出錯，我順手改了一下已經提過 PR 了。）

raft buffer full 問題：使用上邊的配置，導數併發太快，導致相簿報錯 raft buffer full，這個感覺是記憶體中的資料沒有被快速 fush 到磁碟中，導致寫入中止。於是調整配置，減小 core，batch，相簿修改 write buff number 為 8，增大 buffer，發現 TOSS 開著，想著是不是為了保證一致性所以 flush 會慢？不太確定於是關掉了。還有一點是當時沒發現，後來總結的時候才想到的，因為機器的網路有點問題，其中一臺用了百 M 寬頻，會不會是網路 IO 阻塞影響的，也不是很確定。（PS：網路真是個大坑，後邊還會遇到，一定要檢查頻寬。）不過在進行了上邊的修改之後，沒有再報錯了。

高併發導數，相簿E_LEADER_LEASE_FAILED

這個問題一共遇到兩次，一次是在導數結束後立馬發起另一個導數任務，檢視到語句大量報錯，於是手動查詢相簿，發現任何查詢都報錯。

(root@nebula) [trans]> match (v) return v limit 10

[ERROR (-1005)]: Storage Error: part: 22, error: E_LEADER_LEASE_FAILED(-3531).

Tue, 07 Jun 2022 22:01:46 CST

嘗試執行 BALANCE LEADER，執行總是 failed，嘗試 Compaction 進行恢復，查詢發現一會報錯 Not the leader of 17. Please retry later. 一會能展示結果，並沒有完全恢復，無奈只能重啟解決。

第二次遇到是在進行壓測的同時，使用 NebulaGraph Exchange 導數，看會有什麼影響，結果再次出現該問題，Exchange 的 task 也大量報錯退出了。

Errors

出現 E_LEADER_LEASE_FAILED 的問題會導致相簿基本不可用，且不會自己恢復，個人猜測併發讀寫太大導致部分資料混亂，引起查詢不可用。該問題目前尚未完全找到原因，所以使用時要稍微注意，導數的 batch 不要太大了，併發也要控制。帖子地址：https://discuss.nebula-graph.com.cn/t/topic/9013/13

其他問題

重啟存在 offline：關閉時需要確保完全關閉再啟動，慎用 restart。資料較多時關閉並不會馬上關閉，需要等待一段時間，這時啟動可能會有一臺 storage 啟動不起來或者報錯，顯示 offline，應該是 stop start 間隔太短，出現這種情況應該完全關閉後，ps 無程式再刪除 storage 的 pid 再啟動。

重啟無分片：相簿重啟後總是出現一個 storage 節點某些相簿無分片的情況，導致查詢這臺機器不幹活，有點奇怪，只能 BALANCE LEADER 使其平衡。

網路問題：在上邊提到過，一定要確保頻寬，否則查詢的執行計劃裡邊，RPC的時間很大，影響查詢速度。併發查詢時發現延遲很高，CPU 使用率也不高，但是怎麼最佳化都下不來，後來才發現網路有問題，著實有點坑。

總結

整體來說，v3.1.0 版本做了很大的改進，無論是新功能還是語法上，都做了很好的改變，但是基於上面的問題，感覺在穩定性上要弱於 2.6 版本。可能也是由於 v3.x 版本在底層上的改動比較大，出現這些問題也無可避免的，希望在今後的版本中有能較好的最佳化，好的產品當然是需要不斷打磨的。

另外，如果上邊提到的問題你有更好的見解也歡迎來討論，也希望這些問題能夠幫助官方人員進行更好的最佳化。

謝謝你讀完本文 (///▽///)

無需煩惱升級問題，現在可以用用 NebulaGraph Cloud 來搭建自己的圖資料系統喲，快來節省大量的部署安裝時間來搞定業務吧~ Nebula Graph 阿里雲端計算巢現 30 天免費使用中，點選連結來用用圖資料庫吧~

想看原始碼的小夥伴可以前往 GitHub 閱讀、使用、(^з^)-☆ star 它 -> GitHub；和其他的 NebulaGraph 使用者一起交流圖資料庫技術和應用技能，留下「你的名片」一起玩耍呢~

相關文章