圖資料庫 Nebula Graph 的資料模型和系統架構設計

Nebula Graph：一個開源的分散式圖資料庫。作為唯一能夠儲存萬億個帶屬性的節點和邊的線上圖資料庫，Nebula Graph 不僅能夠在高併發場景下滿足毫秒級的低時延查詢要求，還能夠實現服務高可用且保障資料安全性。

本篇主要介紹 Nebula Graph 的資料模型和系統架構設計。

有向屬性圖 DirectedPropertyGraph

Nebula Graph 採用易理解的有向屬性圖來建模，也就是說，在邏輯上，圖由兩種圖元素構成：頂點和邊。

頂點 Vertex

在 Nebula Graph 中頂點由標籤 tag 和對應 tag 的屬性組構成， tag 代表頂點的型別，屬性組代表 tag 擁有的一種或多種屬性。一個頂點必須至少有一種型別，即標籤，也可以有多種型別。每種標籤有一組相對應的屬性，我們稱之為 schema 。

如上圖所示，有兩種 tag 頂點：player 和 team。player 的 schema 有三種屬性 ID （vid），Name （sting）和 Age （int）；team 的 schema 有兩種屬性 ID （vid）和 Name （string）。

和 Mysql 一樣，Nebula Graph 是一種強 schema 的資料庫，屬性的名稱和資料型別都是在資料寫入前確定的。

邊 Edge

在 Nebula Graph 中邊由型別和邊屬性構成，而 Nebula Graph 中邊均是有向邊，有向邊表明一個頂點（ 起點 src ）指向另一個頂點（ 終點 dst ）的關聯關係。此外，在 Nebula Graph 中我們將邊型別稱為 edgetype ，每一條邊只有一種edgetype ，每種 edgetype 相應定義了這種邊上屬性的 schema 。

回到上面的圖例，圖中有兩種型別的邊，一種為 player 指向 player 的 like 關係，屬性為 ** likeness (double)；另一種為 player 指向 team 的 serve** 關係，兩個屬性分別為 start_year (int) 和 end_year (int)。

需要說明的是，起點 1 和終點 2 之間，可以同時存在多條相同或者不同型別的邊。

圖分割 GraphPartition

由於超大規模關係網路的節點數量高達百億到千億，而邊的數量更會高達萬億，即使僅儲存點和邊兩者也遠大於一般伺服器的容量。因此需要有方法將圖元素切割，並儲存在不同邏輯分片 partition 上。Nebula Graph 採用邊分割的方式，預設的分片策略為雜湊雜湊，partition 數量為靜態設定並不可更改。

資料模型 DataModel

在 Nebula Graph 中，每個頂點被建模為一個 key-value ，根據其 vertexID（或簡稱 vid）雜湊雜湊後，儲存到對應的 partition 上。

一條邏輯意義上的邊，在 Nebula Graph 中將會被建模為兩個獨立的 key-value ，分別稱為 out-key 和 in-key 。out-key 與這條邊所對應的起點儲存在同一個 partition 上，in-key 與這條邊所對應的終點儲存在同一個 partition 上。

關於資料模型的詳細設計會在後續的系列文章中介紹。

系統架構 Architecture

Nebula Graph 包括四個主要的功能模組，分別是儲存層、後設資料服務、計算層和客戶端。

儲存層 Storage

在 Nebula Graph 中儲存層對應程序是 nebula-storaged ，其核心為基於 Raft（用來管理日誌複製的一致性演算法）協議的分散式 Key-valueStorage 。目前支援的主要儲存引擎為「Rocksdb」和「HBase」。Raft 協議透過 leader/follower 的方式，來保持資料之間的一致性。Nebula Storage 主要增加了以下功能和最佳化：

1. Parallel Raft：允許多臺機器上的相同 partiton-id 組成一個 Raft group 。透過多組 Raft group 實現併發操作。
2. Write Path & batch：Raft 協議的多機器間同步依賴於日誌 id 順序性，這樣的吞吐量 throughput 較低。透過批次和亂序提交的方式可以實現更高的吞吐量。
3. Learner：基於非同步複製的 learner。當叢集中增加新的機器時，可以將其先標記為 learner，並非同步從 leader/follower 拉取資料。當該 learner 追上 leader 後，再標記為 follower，參與 Raft 協議。
4. Load-balance：對於部分訪問壓力較大的機器，將其所服務的 partition 遷移到較冷的機器上，以實現更好的負載均衡。

後設資料服務層 Metaservice

Metaservice 對應的程序是 nebula-metad ，其主要的功能有：

1. 使用者管理：Nebula Graph 的使用者體系包括 Goduser ， Admin ， User ， Guest 四種。每種使用者的操作許可權不一。
2. 叢集配置管理：支援上線、下線新的伺服器。
3. 圖空間管理：增持增加、刪除圖空間，修改圖空間配置（Raft 副本數）
4. Schema 管理：Nebula Graph 為強 schema 設計。
   • 透過 Metaservice 記錄 Tag 和 Edge 的屬性的各欄位的型別。支援的型別有：整型 int, 雙精度型別 double, 時間資料型別 timestamp, 列表型別 list 等；
   • 多版本管理，支援增加、修改和刪除 schema，並記錄其版本號
   • TTL 管理，透過標識到期回收 time-to-live 欄位，支援資料的自動刪除和空間回收

MetaService 層為有狀態的服務，其狀態持久化方法與 Storage 層一樣透過 KVStore 方式儲存。

計算層 Query Engine & Query Language(nGQL)

計算層對應的程序是 nebula-graphd ，它由完全對等無狀態無關聯的計算節點組成，計算節點之間相互無通訊。Query Engine ** 層的主要功能，是解析客戶端傳送 nGQL 文字，透過詞法解析 Lexer 和語法解析 Parser 生成執行計劃，並透過最佳化後將執行計劃交由執行引擎，執行引擎透過 MetaService 獲取圖點和邊的 schema，並透過儲存引擎層獲取點和邊的資料。Query Engine** 層的主要最佳化有：

1. 非同步和併發執行：由於 IO 和網路均為長時延操作，需採用非同步及併發操作。此外，為避免單個長 query 影響後續 query，Query Engine 為每個 query 設定單獨的資源池以保證服務質量 QoS。
2. 計算下沉：為避免儲存層將過多資料回傳到計算層佔用寶貴的頻寬，條件過濾 where 等運算元會隨查詢條件一同下發到儲存層節點。
3. 執行計劃最佳化：雖然在關聯式資料庫 SQL 中執行計劃最佳化已經經歷了長時間的發展，但業界對圖查詢語言的最佳化研究較少。Nebula Graph 對圖查詢的執行計劃最佳化進行了一定的探索，包括執行計劃快取和上下文無關語句併發執行。

客戶端 API & Console

Nebula Graph 提供 C++、Java、Golang 三種語言的客戶端，與伺服器之間的通訊方式為 RPC，採用的通訊協議為 Facebook-Thrift。使用者也可透過 Linux 上 console 實現對 Nebula Graph 操作。Web 訪問方式目前在開發過程中。

Nebula Graph：一個開源的分散式圖資料庫。

GitHub：https://github.com/vesoft-inc/nebula

知乎：https://www.zhihu.com/org/nebulagraph/posts

微博：https://weibo.com/nebulagraph