共計 3052 個字符，預計需要花費 8 分鐘才能閱讀完成。
本篇文章為大家展示了如何進行圖數據庫 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 主要增加了以下功能和優化：
Parallel Raft：允許多臺機器上的相同 partiton-id 組成一個 Raft group 。通過多組 Raft group 實現并發操作。
Write Path batch：Raft 協議的多機器間同步依賴于日志 id 順序性，這樣的吞吐量 throughput 較低。通過批量和亂序提交的方式可以實現更高的吞吐量。
Learner：基于異步復制的 learner。當集群中增加新的機器時，可以將其先標記為 learner，并異步從 leader/follower 拉取數據。當該 learner 追上 leader 后，再標記為 follower，參與 Raft 協議。
Load-balance：對于部分訪問壓力較大的機器，將其所服務的 partition 遷移到較冷的機器上，以實現更好的負載均衡。
元數據服務層 Metaservice
Metaservice 對應的進程是 nebula-metad ，其主要的功能有：
用戶管理：Nebula Graph 的用戶體系包括 Goduser ， Admin ， User ， Guest 四種。每種用戶的操作權限不一。
集群配置管理：支持上線、下線新的服務器。
圖空間管理：增持增加、刪除圖空間，修改圖空間配置（Raft 副本數）
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 層的主要優化有：
異步和并發執行：由于 IO 和網絡均為長時延操作，需采用異步及并發操作。此外，為避免單個長 query 影響后續 query，Query Engine 為每個 query 設置單獨的資源池以保證服務質量 QoS。焦作國醫胃腸醫院：https://www.jianshu.com/p/b8966d1a468e
計算下沉：為避免存儲層將過多數據回傳到計算層占用寶貴的帶寬，條件過濾 where 等算子會隨查詢條件一同下發到存儲層節點。
執行計劃優化：雖然在關系數據庫 SQL 中執行計劃優化已經經歷了長時間的發展，但業界對圖查詢語言的優化研究較少。Nebula Graph 對圖查詢的執行計劃優化進行了一定的探索，包括執行計劃緩存和上下文無關語句并發執行。
客戶端 API Console
Nebula Graph 提供 C++、Java、Golang 三種語言的客戶端，與服務器之間的通信方式為 RPC，采用的通信協議為 Facebook-Thrift。用戶也可通過 Linux 上 console 實現對 Nebula Graph 操作。Web 訪問方式目前在開發過程中。
上述內容就是如何進行圖數據庫 Nebula Graph 的數據模型和系統架構設計，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注丸趣 TV 行業資訊頻道。
