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

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

### 有向屬性圖 DirectedPropertyGraph

Nebula Graph 採用易理解的有向屬性圖來建模，也就是說，在邏輯上，圖由兩種圖元素構成：頂點和邊。
![image.png](https://cdn.nlark.com/yuque/0/2019/png/208152/1563867709529-f9081a47-6a19-45c4-a2a4-f69067c2cb86.png#align=left&display=inline&height=702&name=image.png&originHeight=702&originWidth=922&size=52865&status=done&width=922)

#### 頂點 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 數量為靜態設定並不可更改。

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2F4fc16f78-f391-492f-9b30-17e591498e75.png)

### 資料模型 DataModel

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

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2F72b83116-9880-4882-a836-64aa2b7ca77b.png)

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

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2Ff252b91b-94b0-4187-b19c-83d7eb6b0af1.png)

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

### 系統架構Architecture

Nebula Graph 包括四個主要的功能模組，分別是**儲存層**、**後設資料服務**、**計算層**和**客戶端**。<br>![image.png](https://cdn.nlark.com/yuque/0/2019/png/208152/1563851860692-ccc07a2d-9c65-4e31-8d88-b997fdb8a6fc.png#align=left&display=inline&height=566&name=image.png&originHeight=566&originWidth=1011&size=122565&status=done&width=1011)

#### 儲存層 Storage

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

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

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2F587f3e99-e99c-46df-8361-8dad4d997adc.png)

#### 後設資料服務層 Metaservice

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

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

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

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2Fc102cdb9-c78c-4c80-b716-a46282b41407.png)

#### 計算層 Query Engine & Query Language(nGQL)

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

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

![image.png](https://obs-emcsapp-public.obs.cn-north-4.myhwclouds.com:443/image%2Feditor%2F47ec9e22-63d6-4a3f-8c3f-e4b3f646958b.png)

#### 客戶端 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://0x7.me/osc2github)

> 知乎：[https://www.zhihu.com/org/nebulagraph/posts](https://www.zhihu.com/org/nebulagraph/posts)

> 微博：[https://weibo.com/nebulagraph](https://weibo.com/nebulagraph)

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

相關文章