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 主要增加了以下功能和優化:
- 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。
- 計算下沉:爲避免存儲層將過多數據回傳到計算層佔用寶貴的帶寬,條件過濾
where
等算子會隨查詢條件一同下發到存儲層節點。 - 執行計劃優化:雖然在關係數據庫 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...
知乎:https://www.zhihu.com/org/neb...
微博:https://weibo.com/nebulagraph