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

在上次的 nebula-storage on nLive 直播中，來自 Nebula 儲存團隊的負責人王玉珏（四王）同大家分享了 nebula storage 這塊的設計思考，也解答了一些來自社群小夥伴的提問。本文整理自該場直播，按照問題涉及的分類進行順序調整，並非完全按照直播的時間先後排序。

## Nebula 的儲存架構

![Nebula 的儲存架構](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-reading-storage-architecture.png)

整個 Storage 主要分三層，最下面是 Store Engine，也 就是 RocksDB，中間是 raft 一致性協議層，最上層 storage service 提供對外的 rpc 介面，比如取點屬性，或者邊屬性，或者是去從某個點去找它的鄰居之類的介面。當我們透過語句`CREATE SPACE IF NOT EXISTS my_space_2 (partition_num=15, replica_factor=1, vid_type=FIXED_STRING(30));` 建立 space 時，根據填寫的引數將 space 劃分為多個邏輯單元成為 partition，各個 partition 會落到不同機器上，同一個 Partition 的多個副本會組成一個邏輯單元，並透過 raft 共識演算法 raft 保證一致。

## Nebula 的儲存資料格式

![Nebula 的儲存資料格式](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-vertex-data-format.png)

![Nebula 的儲存資料格式](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-edge-data-format.png)

這裡著重講述為何 v2.x 會有這些資料格式的改動：在 v1.x 版本中，Nebula VID 主要是 int 型別，所以大家可以看到上圖 v1.x 中不管是點還是邊，它的 VID 是定長的、佔 8 個位元組。2.x 版本開始，為了支援 string 型別 VID，VertexID 就變成不定長的 n 個位元組。所以大家建立 Space 的時候需要指定 VID 的長度，這個是最主要的改動，其他的話還有一些小的改動，去掉了時間戳。整體來說，目前的儲存格式更貼近圖的使用場景——從某個點開始找它的鄰居，以 v2.x 這樣  VertexID + EdgeType  儲存格式來儲存邊的話，可以迅速地找到某個點出邊。

同時，v2.x 也做了 key（Nebula 底層是 KV 儲存的）編碼格式上的改變，簡單來說就是把點和邊分開。這樣的話，取某一個點所有 tag 時透過一次 prefix 就可以直接掃到，避免了像 v1.x 那樣掃描點的過程中夾雜多個邊的問題。

## 底層的資料儲存

針對使用者提出的“Nebula 底層如何儲存資料”的問題，四王了進行了回覆：Nebula 的儲存層使用 KV 進行儲存點邊資料。對於一個點而言，key 裡面儲存 VID 和它的 tag 型別。點的 value 中，會根據 這個 tag 的 schema，將 schema 中的各個屬性進行編碼並存在 value 中。比如，player 這個 tag 可能會有一個 age 這樣一個整型年齡欄位，使用儲存的時候會把 age 欄位的值，按某種編碼儲存在 value 中。再來說下邊，邊的儲存 key 會多幾個欄位，主要是邊的起點 ID、邊型別、ranking 及終點型別，透過這四元組確定唯一的邊。邊的 value 和點的 value 類似，根據邊的 Schema 欄位定義，將各個欄位進行編碼儲存。這裡要說一下，Nebula 中儲存邊是儲存兩份：Nebula 中的邊是有向邊，儲存層會儲存正向邊和反向邊，這樣的好處在於使用 `GO FROM` 進行遍歷查詢那些點指向點 A 或者點 A 指向哪些點可以快速透過雙向查詢實現。

一般來說，圖儲存分為切邊和切點兩種方式，像上面說的 Nebula 其實採用了切邊方式：一條邊儲存兩份 KV。

> 使用者提問：為什麼採用切邊方式，切點和切邊各自有啥利弊？

切邊的話，每一份邊存兩份，資料總量會比切點大很多，因為圖資料邊的數量是遠大於點的數量，造成邊的大量冗餘，相對好處是對起點和它的邊進行對映時會對映到同一個 partition 上，這樣進行一些從單個點觸發的 query 時會很快速得到結果。切點的話，由於點可能被分在多個機器上，更新資料時得考慮資料的一致性問題，一般在圖計算裡面切點的使用會更廣泛。

## 你問我答

下面內容收集於之前活動預告的 AMA 環節，以及直播時彈幕中提出的問題。

### 問題目錄

* 邊的 value 儲存邊屬性嗎？
* 強 Schema 的設計原因
* 存一份邊的設計
* 圖空間如何做物理隔離
* Meta 如何儲存 Schema
* 儲存未來規劃
* VID 遍歷點和邊的原理
* 資料預校驗
* Nebula 監測
* Nebula 的事務
* 資料膨脹問題
* 磁碟容量本身不均怎麼處理
* Nebula 的 RocksDB “魔改”

### 邊的 value 儲存邊屬性嗎？

和上面底層儲存裡講的那樣，建立 Edge 的 schema 時候會指定邊型別上的屬性，這些屬性會作為底層 RocksDB key 的 value 儲存起來，這個 value 的佔位是定長的，和下面這個問題類似：

### 強 Schema 的設計原因

> 強 schema 是因為技術原因還是產品原因? 因為考慮到 string 型別是變長的，每行長度本身就不固定，感覺跟無 schema 無區別。 如果非定長，那查詢時怎麼知道該查詢到哪裡呢? 是有標誌位麼?

其實本質上原因是用強 Schema 的好處是快，先說下常見的簡單資料型別，比如：int 和 double，這樣的資料型別長度是固定的，我們會直接在 value 相應的位置進行編碼。再說下 string 型別，在 Nebula 中有兩種 string ：一種是定長 string，長度是固定，和前面的簡單資料型別一樣，在 value 的固定位置進行編碼。另外一種是變長的 string，通常來說大家都會比較傾向於變長 string（靈活），非定長 string 會以指標形式儲存。

舉個例子，schema 中有個屬性是變長 string 型別，我們不會和簡單資料型別一樣直接編碼儲存，而是在相應位置儲存一個 offset 指標，實際指向 value 中的第 100 個位元組，然後在 100 這個位置才儲存這個變長 string。所以讀取變長 string 的時候，我們需要在 value 中讀兩次，第一次獲取 offset，第二次才能真正把 string 讀出來。透過這樣的形式，把所有型別的屬性都轉化成"定長"，這樣設計的好處是，根據要讀取的屬性和它前面所有欄位的佔用位元組大小，可以直接計算出要讀取的欄位在 value 中儲存的位置，並把它讀出來。讀取過程中，不需要讀取無關的欄位，避免了弱 schema 需要對整個 value 進行解碼的問題。

像 Neo4j 這種圖資料庫，一般是 No Schema，這樣寫入的時候會比較靈活，但序列化和反序列化時都會消耗一些 CPU，並且讀取的時候需要重新解碼。

> 追問：如果有變長 string，會不會導致每行資料長度不一樣

可能 value 長度會不一樣，因為本身是變長嘛。

> 追問：如果每行長度不一樣，為什麼要強 schema？
Nebula 底層儲存用的 RocksDB，以 block 的形式組織，每個 block 可能是 4K 大小，讀取的時候也是按 block 大小進行讀取，而每個 block 中的各個 value 長度可能是不一樣的。強 schema 的好處在於讀單條資料的時候會快。

存一份邊的設計

> Nebula 存邊是儲存了兩份，可以只儲存一份邊嗎？存一份邊反向查詢是否存在問題？

其實這是一個比較好的問題，其實在 Nebula  最早期設計中是隻存一份邊的屬性，這適用於部分業務場景。舉個例子，你不需要任何的反向遍歷，這種情況下是完全不需要存反向邊。目前來說，存反向邊最大的意義是方便於我們做反向查詢。其實在 Nebula 比較早的版本中，準確說它是隻存了反向邊的 key，邊型別的屬性值是沒有存，屬性值只存在正向邊上。它可能帶來一些問題，雙向遍歷或者反向查詢時，整個程式碼邏輯包括處理流程都會比較複雜。
如果只存一份邊，反向查詢的確存在問題。

### 圖空間如何做物理隔離

大家在用 Nebula 時，首先會建圖空間 `CREATE SPACE`，在建圖空間時，系統會分配一個唯一圖空間 ID 叫 spaceId，透過 `DESCRIBE SPACE` 可以獲取 spaceId。然後 Storage 發現某臺機器要儲存 space 部分資料時，會先單獨建一個額外的目錄，再建單獨 RocksDB 在這個上面起 Rocks 的 instance（例項）用來儲存資料，透過這樣方式進行物理隔離。這樣設計的話，有個弊端：雖然 rocksdb 的 instance，或者說整個 space 目錄是互相隔離，但有可能存在同一塊盤上，目前資源隔離還做的不夠好。

### Meta 如何儲存 Schema

我們以 `CREATE TAG` 為例子，當我們建 tag 時，首先會往 meta 發一個請求，讓它把這個資訊寫進去。寫入形式非常簡單，先獲取 tagId，再儲存 tag name。底層 RocksDB 儲存的 key 便是 tagId 或者是 tag name，value 是它每一個欄位裡面的定義，比如說，第一個欄位是年齡，型別是整型 int；第二個欄位是名字，型別是 string。schema 把所有欄位的型別和名字全部存在 value 裡，以某種序列化形式寫到 RocksDB 中。

這裡說下，meta 和 storage 兩個 service 底層都是 RocksDB 採用 kv 儲存，只不過提供了不一樣的介面，比如說，meta 提供的介面，可能就是儲存某個 tag，以及 tag 上有哪些屬性；或者是機器或者 space 之類的元資訊，包括像使用者許可權、配置資訊都是存在 meta 裡。storage 也是 kv 儲存，不過儲存的資料是點邊資料，提供的介面是取點、取邊、取某個點所有出邊之類的圖操作。整體上，meta 和 storage 在 kv 儲存層程式碼是一模一樣，只不過往上暴露的對外介面是不一樣的。

最後，storage 和 meta 是分開儲存的，二者不是一個程式且存的目錄在啟動的時指定的也不一樣。

> 追問：meta 機器掛了，該怎麼辦？

是這樣，通常來說 Nebula 建議 meta 以三副本方式部署。這樣的話，只掛一臺機器是沒有問題的。如果單副本部署 meta 掛了的話，是無法對 schema 進行任何操作，包括不能建立 space。因為 storage 和 graph 是不強依賴 meta 的，只有在啟動時會從 meta 獲取資訊，之後都是定期地獲取 meta 儲存的資訊，所以如果你在整個叢集跑的過程中，meta 掛了而又不做 schema 修改的話，對 graph 和 storage 是不會有任何影響的。

### 儲存未來規劃

> Nebula 後面在儲存層有什麼規劃嗎？效能，可用性，穩定性方面

效能這塊，Nebula 底層採用了 RocksDB，而它的效能主要取決於使用方式，和調參的熟練程度，坦白來說，即便是 Facebook 內部員工來調參也是一門玄學。再者，剛才介紹了 Nebula 的底層 key 儲存，比如說 VID 或者是 EdgeType 在底層儲存的相對位置某種程度上決定了部分 Query 會有效能影響。從拋開 RocksDB 本身來說，其實還有很多效能上的事情可做：一是寫點或者寫邊時，有些索引需要處理，這會帶來額外效能開銷。此外，Compaction 和實際業務 workload 也會對效能有很大影響。

穩定性上，Nebula 底層採用 raft 協議，這是保證 Nebula Graph 不丟資料一個非常關鍵的點。因為只有這層穩定了，再往下面的 RocksDB 寫入資料才不會出現資料不一致或者資料丟失的情況發生。此外，Nebula 本身是按照通用型資料庫來設計的，會遇到一些通用型資料庫共同面臨的問題，比如說 DDL 改變；而本身 Nebula 是一款分散式圖資料庫，也會面臨分散式系統所遇到的問題，像網路隔離、網路中斷、各種超時或者因為某些原因節點掛了。上面這些問題的話，都需要有應對機制，比如 Nebula 目前支援動態擴縮容，整個流程非常複雜，需要在 meta 上、以及掛掉的節點、剩餘“活著”的節點進行資料遷移工作。在這個過程中，中間任何一步失敗都要做 Failover 處理。

可用性方面，我們後續會引入主備架構。在有些場景下所涉及的資料量會比較少，不太需要存三副本，單機儲存即可。這種全部資料就在單機上的情況，可以減去不必要的 RPC 呼叫，直接換成本地呼叫，效能可能會有很大的提升。因為，Nebula 部署一共起 3 個服務：meta、graph 和 storage，如果是單機部署的話，graph + storage 可以放在同一臺機器上，原先 graph 需要透過 RPC 呼叫 storage 介面去獲取資料再回到 graph 進行運算。假如你的查詢語句是多跳查詢，從 graph 傳送請求到 storage 這樣的呼叫鏈路反覆執行多次，這會導致網路開銷、序列化和反序列化的這些損耗提高。 當 2 個程式（storaged 和 graphd）合在一起，便沒有了 RPC 呼叫，所以效能會有個大提升。此外，這種單機情況下 CPU 利用率會很高，這也是目前 Nebula 儲存團隊在做的事情，會在下一個大版本同大家見面。

### VID 遍歷點和邊的原理

> 可以依據 VID 遍歷點和邊？

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-vertex-data-format.png)

![](https://www-cdn.nebula-graph.com.cn/nebula-blog/nebula-graph-edge-data-format.png)

從上圖你可以看到儲存了個 Type 型別，在 v1.x 版本中無論點和邊 Type 型別都是一樣的，所以就會發生上面說到過的掃描點會夾雜多個邊的問題。在 v2.x 開始，將點和邊的 Type 進行區分，字首 Type 值就不一樣了，給定一個 VID，無論是查所有 tag 還是所有邊，都只需要一次字首查詢，且不會掃描額外資料。

### 資料預校驗

> Nebula 是強 Schema 的，插入資料時如何去判斷這個欄位是否符合定義？

是否符合定義的話，大概是這樣，建立 Schema 時會要求指定某個欄位是 nullable 或者是有預設值，或者既不是 nullable 也不帶預設值。當我們插入一條資料的時候，插入語句會要求你“寫明”各個欄位的值分別是什麼。而這條插入 Query 發到儲存層後，儲存層會檢查是不是所有欄位值都有設定，或者寫入值的欄位是否有預設值或者是 nullable。然後程式會去查是不是所有的欄位都可以填上值。如果不是的話，系統會報錯，告知使用者 Query 有問題無法寫入。如果沒有報錯，storage 就會對 value 進行編碼，然後透過 raft 最後寫到 RocksDB 裡，整個流程大概是這樣的。

### Nebula 監測

> Nebula 可以針對 space來進行統計嗎？因為我記得好像針對機器。

這個是非常好的問題，目前答案是不能。這塊我們在規劃，這個問題的主要原因是 metrics 較少，目前我們支援的 metrics 只有 latency、qps 還有報錯的 qps 這三類。每個指標有對應的平均值、最大值、最小值，sum 和 count，以及 p99 之類引數。目前是機器級別的 metrics，後續的話會做兩個最佳化：一個增多 metrics；二是按 space 級別進行統計，對於每個空間來說，我們會提供諸如 fetch、go、lookup 之類語句的 qps。上面是 graph 這邊的 metrics，而 storage 這塊因為沒有強資源隔離能力，還是提供叢集或者單個機器級別的 metrics 而不是 space 級別的。

### Nebula 的事務

> nebula 2.6.0 的邊事務是怎麼實現的呢？

先說下邊事務的背景，背景是上面提到的 Nebula 是存了兩份邊 2 個 kv，這 2 個 kv 可能會存在不同的節點上，這會導致如果有臺機器掛了，其中有一條邊可能是沒有成功寫入。所謂邊事務或者叫 TOSS，它主要解決的問題就是當我們遇到其中有一臺機器當機時，儲存層能夠保證這兩個邊（出邊和入邊）的最終一致。這個一致性級別是最終一致，沒有選擇強一致是因為研發過程中碰到一些報錯資訊以及資料處理流程上的問題，最後選擇了最終一致性。

再來說下 TOSS 處理的整體流程，先往第一個要寫入資料的機器發正向邊資訊，在機器上寫個標記，看標記有沒有寫成功，如果成功了進入到下一步，如果失敗直接報錯。第二步的話，把反向邊資訊從第一臺機器發給第二臺機器，能讓存正向邊的機器向第二臺機器傳送反向邊資訊的原因是，Nebula 中正反向邊只有起點和終點調換了一個位置，所以存正向邊的機器是完全可以拼出反向邊。存反向邊的機器收到之後，會直接寫入邊，並將它的寫入結果成功與否告訴第一臺機器。第一臺機器收到這個寫入結果之後，假設它是成功的，它就會把之前第一步寫的標記刪掉，同時換成正常的邊，這時整個邊的正常寫入流程就完成了，這是一個鏈式的同步機制。

簡單說下失敗的流程，一開始第一臺機器寫失敗了直接就報錯；第一臺機器成功之後，第二臺機器寫失敗了，這種情況下機器一會有背景執行緒，會一直不斷嘗試修復第二臺機器的邊，保證和第一臺機器一樣。當中比較複雜的是，第一臺機器會根據第二臺機器返回的錯誤碼進行處理。目前來說，所有的流程都會直接把標記刪掉，直接換成正常的正向邊，同時寫些更額外的標記來表示現在需要恢復的失敗邊，讓它們最終保持一致。

> 追問：點沒有事務嗎？

是這樣，因為點是隻存了一份，所以它是不需要事務的。一般來說，問這個問題的人是想強調點和邊之間的事務，像插入邊時看點是否存在，或者刪除點時刪除對應邊。目前 Nebula 的懸掛點的設計是出於效能上的考慮。如果要解決上面的問題的話，會引入完整的事務，但這樣效能會有個數量級的遞減。順便提下，剛說到 TOSS 是鏈式形式同步資訊，上面也提到能這樣做的原因是因為第一個節點能完整拼出第二個節點的資料。但鏈式的話對完整的事務而言，效能下降會更嚴重，所以未來事務這塊的設計不會採納這種方式。

### 資料膨脹問題

> 首次匯入資料是怎麼儲存的，因為我發現首次匯入資料磁碟佔用會較多？

大家發現如果磁碟佔用高，一般來說是 WAL 檔案比較多。因為我們匯入的資料量一般比較大，這會產生大量的 wal，在 Nebula 中預設的 wal ttl 是 4 個小時，在這 4 個小時中系統的 WAL 日誌是完全不會刪除的，這就導致佔用的磁碟空間會非常大。此外，RocksDB 中也會寫入一份資料，相比後續叢集正常執行一段時間，這時候磁碟佔用會很高。對應的解決方法也比較簡單，匯入資料時調小 wal ttl 時間，比如只存半小時或者一個小時，這樣磁碟佔用率就會減少。當然磁碟空間夠大你不做任何處理使用預設 4 小時也 ok。因為過了若干個小時後，有一個背景執行緒會不斷去檢查哪些 wal 可以刪掉了，比如說預設值 4 個小時之後，一旦發現時過期的 wal 系統便會刪掉。

除了初次匯入會有個峰值之外，線上業務實時寫入資料量並不會很大，wal 檔案也相對小。這裡不建議手動刪 wal 檔案，因為可能會出問題正常按照 ttl 來自動刪除就行。

> compact 都做了什麼事可以提高查詢，也減小了資料儲存佔用？
可以看下 RocksDB 介紹和文章，簡單說下 Compaction 主要是多路歸併排序。RocksDB 是 LSM-Tree 樹結構，寫入是 append-only 只會追加地寫，這會導致資料存在一定的冗餘。Compaction 就是用來降低這種冗餘，以 sst 作為輸入，進行歸併排序和去除冗餘資料，最後再輸出一些 sst。在這個輸入輸出過程中，Compaction 會檢查同一個 key 是否出現在 LSM 中的不同層，如果同一個 key 出現了多次會只保留最新的 key，老 key 刪掉，這樣提高了 sst 有序的程度，同時 sst 數量和 LSM-Tree 的層數可能會減小，這樣查詢時候需要讀取的 sst 數量就會減少，提高查詢效率。

### 磁碟容量本身不均怎麼處理

> 不同大小的磁碟是否考慮按百分比佔用，因為我使用兩塊不同大小的磁碟，一塊佔滿之後導數就出現問題了

目前是不太好做，主要原因是儲存 partition 分佈查詢是按照輪循形式進行的，另外一個原因是 Nebula 進行 Hash 分片，各個資料盤資料儲存大小趨近。這會導致如果兩個資料盤大小不一致，一個盤先滿了後面的資料就寫入不進去。解決方法可以從系統層進行處理，直接把兩塊盤綁成同一塊盤，以同樣一個路徑掛載。

### Nebula 的 RocksDB “魔改”

> Nebula 的 RocksDB 儲存中，是透過列 column family 來區別 vertex 屬性嗎？

目前來說，其實我們完全沒有用 column family，只用了default column family。後續可能會用，但是不會用來區分 vertex 屬性，而是把不同 partition 資料分到不同 column family，這樣的好處是直接物理隔離。

> Nebula 的魔改 wal 好像是全域性 multi-raft 的 wal，但是在目錄上體現出來的好像每個圖空間都是單獨的 wal，這個原理是啥？
首先，Nebula 的確是 multi-raft，但沒有全域性 wal 的概念。Nebula 的 wal 是針對 partition 級別的，每個 partition 有自己的 wal，並不存在 space 的 wal。至於為啥這麼設計，相對來說現在實現方式比較容易，雖然會存在效能損耗，像多個 wal 的話磁碟寫入就是個隨機寫入。但是對 raft 而言，寫入瓶頸並不是在這而是系統的網路開銷，使用者的複製操作 replication 開銷是最大的。

---
[Nebula 社群首屆徵文活動進行中！](https://discuss.nebula-graph.com.cn/t/topic/8304)? 獎品豐厚，全場景覆蓋：擼碼機械鍵盤⌨️、手機無線充?、健康小助手智慧手環⌚️，更有資料庫設計、知識圖譜實踐書籍? 等你來領，還有 Nebula 精緻周邊送不停～?

歡迎對 Nebula 有興趣、喜鑽研的小夥伴來書寫自己和 Nebula 有趣的故事呀～
![Nebula 社群首屆徵文活動](https://oscimg.oschina.net/oscnet/up-099c19fd9316db17d22fc566b23d9e42ca7.jpg)

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

[關注公眾號](https://www-cdn.nebula-graph.com.cn/nebula-blog/WeChatOffical.png)

一文帶你瞭解「圖資料庫」Nebula 的儲存設計和思考

相關文章

一文帶你瞭解 「圖資料庫」Nebula 的儲存設計和思考

相關文章

一文帶你瞭解「圖資料庫」Nebula 的儲存設計和思考