圖數據庫 Nebula Graph 的數據模型和系統架構設計

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

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

有向屬性圖 DirectedPropertyGraph

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


image.png
image.png

頂點 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
image.png

數據模型 DataModel

在 Nebula Graph 中,每個頂點被建模為一個 key-value ,根據其 vertexID(或簡稱 vid)哈希散列后,存儲到對應的 partition 上。

image.png
image.png

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

image.png
image.png

關于數據模型的詳細設計會在后續的系列文章中介紹。

系統架構Architecture

Nebula Graph 包括四個主要的功能模塊,分別是存儲層、元數據服務、計算層客戶端。

image.png
image.png

存儲層 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 遷移到較冷的機器上,以實現更好的負載均衡。
image.png
image.png

元數據服務層 Metaservice

Metaservice 對應的進程是 nebula-metad ,其主要的功能有:

  1. 用戶管理:Nebula Graph 的用戶體系包括 GoduserAdmin , 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 方式存儲。

image.png
image.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。
  2. 計算下沉:為避免存儲層將過多數據回傳到計算層占用寶貴的帶寬,條件過濾 where 等算子會隨查詢條件一同下發到存儲層節點。
  3. 執行計劃優化:雖然在關系數據庫 SQL 中執行計劃優化已經經歷了長時間的發展,但業界對圖查詢語言的優化研究較少。Nebula Graph 對圖查詢的執行計劃優化進行了一定的探索,包括執行計劃緩存上下文無關語句并發執行。
image.png
image.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://nebula-graph.io/cn/posts/

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

image
最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。

推薦閱讀更多精彩內容