圖數據庫 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