> 本文首發於 [**Nebula Graph Community 公眾號**](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-blog/WeChatOffical.png)

![基於 Nebula Graph 構建百億關係知識圖譜實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph.jpg)

## 一、專案背景

微瀾是一款用於查詢技術、行業、企業、科研機構、學科及其關係的知識圖譜應用，其中包含著百億級的關係和數十億級的實體，為了使這套業務能夠完美執行起來，經過調研，我們使用 Nebula Graph 作為承載我們知識圖譜業務的主要資料庫，隨著 Nebula Graph 的產品迭代，我們最終選擇使用 v2.5.1 版本的 Nebula Graph 作為最終版本。

## 二、為什麼選擇 Nebula Graph？

在開源圖資料庫領域，無疑存在著很多選擇，但為了支撐如此大規模資料的知識圖譜服務，Nebula Graph 對比其他的圖資料庫具有以下幾個優點，這也是我們選擇 Nebula Graph 的原因：

1. **對於記憶體的佔用較小**

在我們的業務場景下，我們的 QPS 比較低且沒有很高的波動，同時相比起其他的圖資料庫，Nebula Graph 具有更小的閒時記憶體佔用，所以我們可以透過使用記憶體配置更低的機器去執行 Nebula Graph 服務，這無疑為我們節省了成本。

2. **使用 multi-raft 一致性協議**

multi-raft 相比於傳統的 raft，不僅增加了系統的可用性，而且效能比傳統的 raft 要高。共識演算法的效能主要在於其是否允許空洞和粒度切分，在應用層無論 KV 資料庫還是 SQL ，能成功利用好這兩個特性，效能肯定不會差。由於 raft 的序列提交極其依賴狀態機的效能，這樣就導致即使在 KV 上，一個 key 的 op 慢，顯著會拖慢其他 key。所以，一個一致性協議的效能高低的關鍵，一定是在於狀態機如何讓可以並行地儘量並行，縱使 multi-raft 的粒度切分比較粗（相比於 Paxos），但對於不允許空洞的 raft 協議來說，還是有巨大的提升。

3. **儲存端使用 RocksDB 作為儲存引擎**

RocksDB 作為一款儲存引擎/嵌入式資料庫，在各種資料庫中作為儲存端得到了廣泛地使用。更關鍵的是 Nebula Graph 可以透過調整 RocksDB 的原生引數來改善資料庫效能。

4. **寫入速度快**

我們的業務需要頻繁地大量寫入，Nebula Graph 即使在具有大量長文字內容的 vertex 的情況下（叢集內3 臺機器、3 份資料，16 執行緒插入）插入速度也能達到 2 萬/s 的插入速度，而無屬性邊的插入速度在相同條件下可以達到 35 萬/s。

## 三、使用 Nebula Graph 時我們遇到了哪些問題？

在我們的知識圖譜業務中，很多場景需要向使用者展示經過分頁的一度關係，同時我們的資料中存在一些超級節點，但根據我們的業務場景，**超級節點一定會是使用者訪問可能性最高的節點，所以這不能被簡單歸類到長尾問題上**；又因為我們的使用者量並不大，所以快取必然不會經常被撞到，我們需要一套解決方案來使使用者的查詢延遲更小。

舉例：業務場景為查詢這個技術的下游技術，同時要根據我們設定的排序鍵進行排序，此排序鍵是區域性排序鍵。比如，某個機構在某一領域排名特別高，但是在全域性或者其他領域比較一般，這種場景下我們必須把排序屬性設定在邊上，並且對於全域性排序項進行擬合與標準化，使得每個維度的資料的方差都為 1，均值都為 0，以便進行區域性的排序，同時還要支援分頁操作方便使用者查詢。

語句如下：

`SQL
MATCH (v1:technology)-[e:technologyLeaf]->(v2:technology) WHERE id(v2) == "foobar" \ 
RETURN id(v1), v1.name, e.sort_value AS sort ORDER BY sort | LIMIT 0,20;
`
此節點有 13 萬鄰接邊，這種情況下即使對 sort_value 屬性加了索引，查詢耗時還是將近兩秒。這個速度顯然無法接受。

我們最後選擇使用螞蟻金服開源的 OceanBase 資料庫來輔助我們實現業務，資料模型如下：

![基於 Nebula Graph 構建百億關係知識圖譜實踐](http://img.blog.itpub.net/blog/2022/06/27/c915002e16270471.png?x-oss-process=style/bb)

查詢語句如下：

`SQL
SELECT technology.name FROM technology INNER JOIN (SELECT technologydownstream.downstream_id FROM technologydownstream 
WHERE technologydownstream.technology_id = 'foobar' ORDER BY technologydownstream.sort_value DESC LIMIT 0,20) AS t 
WHERE t.downstream_id=technology.id; 
`
此語句耗時 80 毫秒。這裡是整個架構設計

![基於 Nebula Graph 構建百億關係知識圖譜實踐](https://www-cdn.nebula-graph.com.cn/nebula-blog/use-case-build-ten-billion-graph-knowledge-with-nebula-graph-01.jpeg)

## 四、使用 Nebula Graph 時我們如何調優？

前面講過 Nebula Graph 的一個很大的優勢就是可以使用原生 RocksDB 引數進行調優，減少學習成本，關於調優項的具體含義以及部分調優策略我們分享如下：
![基於 Nebula Graph 構建百億關係知識圖譜實踐](http://img.blog.itpub.net/blog/2022/06/27/511b3fbdd0d61032.png?x-oss-process=style/bb)
![基於 Nebula Graph 構建百億關係知識圖譜實踐](http://img.blog.itpub.net/blog/2022/06/27/f54cccdb0e549d56.png?x-oss-process=style/bb)
![基於 Nebula Graph 構建百億關係知識圖譜實踐](http://img.blog.itpub.net/blog/2022/06/27/9b5a32ad43165ea3.png?x-oss-process=style/bb)
---

交流圖資料庫技術？加入 Nebula 交流群請先[填寫下你的 Nebula 名片](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手會拉你進群~

基於 Nebula Graph 構建百億關係知識圖譜實踐

相關文章