圖資料庫是一個使用圖結構進行語義查詢的非關係型資料庫，通過使用節點、邊和屬性這三個元素來表示和儲存數據。圖資料庫作為新型NoSQL資料庫的代表，受到了諸多企業的關注，數易軒致力於圖資料庫技術服務，為您介紹圖資料庫的定義和原理。
在計算機科學中，圖資料庫（英語：graph database，GDB）是一個使用圖結構進行語義查詢的資料庫，它使用節點、邊和屬性來表示和存儲數據。該系統的關鍵概念是圖，它直接將存儲中的數據項，與數據節點和節點間表示關係的邊的集合相關聯。這些關係允許直接將存儲區中的數據連結在一起，並且在許多情況下，可以通過一個操作進行檢索。圖資料庫將數據之間的關係作為優先級。查詢圖資料庫中的關係很快，因為它們永久存儲在資料庫本身中。可以使用圖資料庫直觀地顯示關係，使其對於高度互連的數據非常有用。
圖資料庫是一種非關係型資料庫，以解決現有關係資料庫的局限性。圖模型明確地列出了數據節點之間的依賴關係，而關係模型和其他 NoSQL 資料庫模型則通過隱式連接來連結數據。圖資料庫從設計上，就是可以簡單快速地檢索難以在關係系統中建模的複雜層次結構的。圖資料庫與 20 世紀 70 年代的網絡模型資料庫相似，它們都表示一般的圖，但是網絡模型資料庫在較低的抽象層次上運行，並且不能輕鬆遍歷一系列邊。
圖資料庫的底層存儲機制可能各有不同。有些依賴於關係引擎並將圖數據「存儲」到表中（雖然表是一個邏輯元素，但是這種方法在圖資料庫、圖資料庫管理系統和實際存儲數據的物理設備之間施加了另一層抽象）。另一些則使用鍵值存儲或面向文檔的資料庫進行存儲，使它們具有固有的 NoSQL 結構。大多數基於非關係存儲引擎的圖資料庫還添加了標記或屬性的概念，這些標記或屬性本質上是具有指向另一個文檔的指針的關係。這樣就可以對數據元素進行分類，以便於集中檢索。
從圖資料庫中檢索數據需要 SQL 之外的查詢語言，SQL是為了處理關係系統中的數據而設計的，因此無法「優雅地」處理遍歷圖。截至 2017 年，沒有一個像 SQL 那樣通用的圖查詢語言，通常都是僅限與一個產品的。不過，已經有一些標準化的工作，使得 Gremlin、SPARQL 和 Cypher 成為了多供應商查詢語言。除了具有查詢語言接口外，還可以通過應用程式接口（API）訪問一些圖資料庫。
圖資料庫與圖計算引擎不同。圖資料庫是轉換關係 OLTP 資料庫的技術。而圖計算引擎在 OLAP 中用於批量分析。由於主要技術公司在使用專有圖資料庫方面的成功以及開源圖資料庫的引入，圖資料庫在 2000 年代引起了相當大的關注。
上面部分引用了維基百科對圖資料庫的詞條來講解何為圖資料庫，而本文整理於圖資料庫 Nebula Graph 交流群中對圖資料庫的零碎知識，作為對圖資料庫知識的補充。本文分為小知識及 Q&A 兩部分。
01圖資料庫興起的契機
2010 年前後，對於社交媒體網絡研究的興起帶動了圖計算的大規模應用。
2000 年前後熱門的是 信息檢索 和 分析 ，主要是 Google 的帶動，以及 Amazon 的 e-commerce 所用的協同過濾推薦，當時 collaborative filtering也被認為是 information retrieval 的一個細分領域，包括 Google 的 PageRank 也是在信息檢索領域研究較多。後來才是 Twitter，Facebook 的崛起帶動了網絡科學 Network science的研究。
圖理論和圖算法不是新科學，很早就有，只是最近 20 年大數據，網絡零售和社交網絡的發展， big data、social networks、e-commerce 、Web 2.0讓圖計算有了新的用武之地，而且硬體計算力的提高和分布式計算日益成熟的支持也使圖計算在高效處理海量數據成為可能。
學習完圖資料庫發展的契機，我們來學習下圖資料庫存儲方式和一種圖資料庫存儲層的設計探討。
02圖資料庫存儲方式 —— 基於內存存儲 vs 基於分布式 kv 存儲
基於內存的圖資料庫有其優勢，特別對於 大規模深度遍歷以及基於之上的 graph model 計算，這在大規模並行處理（ MPP ）是有較強優勢，其訪問語言更像是程式語言而並非圖遍歷。
各種存儲各有優缺點，各有擅長的應用場景，所以離開了場景和需求，很難對比不同的解決方案。
基於分布式 kv 之上的圖資料庫，對於大規模深度遍歷和計算，對於graph model 的支持，有其缺陷。圖資料庫需要有分類，我們需要明白討論的是哪一種。
1. 實時在線圖資料庫，
2. 線下圖資料庫，
3. 大規模數學分析用圖資料庫。
如果講到第 3 種，圖結構基於內存的方案有優勢。第 1 和 2 種大規模圖資料庫主要也就是基於 kv+ 索引
03一種圖資料庫存儲層的設計探討
無中心化的存儲集群，一般單個集群還是有一定的大小限制，不宜過大。存儲層的抽象在於，數據集（圖的話就是不同的點和邊）到存儲集群的邏輯映射對用戶透明，用戶可用性要求高的場景需要考慮雙集群互為災備。單集群的數據平衡是集群內部的事，集群和集群間的數據平衡是需要設計的，其中線下到線上的數據傳輸通道尤其重要。
設計原則： - 不要使得單集群過大； - 本地互為備份集群支持讀 active-active； - 利用線下到線上數據傳輸通道做好數據集群間遷移、backfill、recovery，batch update 等等工作： - 數據訪問有抽象，使得集群的運維對於用戶訪問透明； - 做好集群間的跨數據中心數據複製； - 到達即使逐步投資也能線性擴展的設計；
學習完存儲和設計的小知識，來對比下圖資料庫圖結構的可視化和 GIS 數據的可視化。
04圖結構的可視化與 GIS 數據的可視化
關於圖結構可視化與 GIS 數據的可視化本質上有比較大的差異：
GIS 是 Hierarchical + 瓦片式貼片展示的，而圖結構本身是 flat 的，只能一次性將所有 touch 到的數據全部展示出來。但是 GIS 的做法可以給我們啟示，結合具體的業務場景，能否也做一個 層級抽樣，但是圖抽樣的問題是：如何在抽樣的同時，儘量 保留子圖的連通性（否則可能 high level 的層顯示的都是孤立的點，只有最後最細粒度的層才會顯示所有數據）。 一些粗淺的想法：可以結合圖計算的技術，先算連通子圖，然後在連通子圖內部算 PageRank，按照 PageRank 大小劃分成不同的區間，相當於按照 PageRank 值做 Hierarchical 分層，在層次切換時，為了保證圖的連通性，除了顯示下一個層次的頂點（PageRank 值在下一個區間）之外，還需要顯示這 2 個層次抽樣出來的頂點的邊（這相當於一個子圖內部的連通路徑的檢索，如果能做 aggreate 更好，如果這些邊很多，是否可以按照 EdgeType aggregate，先顯示統計值，如果用戶有興趣再展開——即圖資料庫返回 aggregation 值，前端生成」虛擬」的邊，隨著進一步展開，這些」虛擬的邊」會被實際明細邊取代）。
上述 trick 只是為了解決圖數據像 GIS 一樣平滑展示的問題，缺點也比較明顯，Hierarchical 抽樣代價高。
另外，圖數據的展示問題，不是一個獨立的前端技術問題，還涉及到後端圖資料庫如下 feature 的支持：
1. degree 統計
2 按照 EdgeType 進行 aggregation
3. query 時遇到超級頂點做截斷，並返回截斷信息給 client
內置一些 AP 性算法，如 PageRank、lpa、環探測等。
圖數據可視化，還需要考慮： 前端數據承載量是有限的，CS 類型的可視化工具還好點，BS 類型的可視化工具，瀏覽器承載的量就更少。如何在業務上將 touch 到的數據量限制在一定範圍內是應用是要考慮的。 此外，由於頂點和邊的 name 和其他 tag 信息，一般在可視化的時候不會一次性都顯示在圖上，首次繪製可僅向圖資料庫請求 name，後續 tag 的 properties 在用戶感興趣的時候（點擊/hover）時再次請求。
布局問題：目前常見的無非是力導引、圓形、樹形、網格型，這些都是無任何業務語義的布局，如樹形布局，哪些應該作為頂層節點，哪些是下一級節點，如果僅僅通過邊的有向性，單個 EdgeType 顯示還好，多個 EdgeType 混合在一棵樹上顯示的時候會破壞掉單個 EdgeType 樹的結構，必須引入業務規則來限制不同布局下的問題
05Q&A 提問回答
由於 Q&A 整理於 Nebula Graph 交流群，有多人參與討論，所以以下問題回覆中會有群友暱稱出現，不做 Nebula Graph 官方成員和群友身份區分，僅交流圖資料庫技術~如果你對下列問題有不同的看法歡迎本文評論區交流(≧▽≦)，加入圖資料庫交流群請加 WeChat：NebulaGraphbot
06圖資料庫計算存儲分離設計及該設計模式的考量原因
提問：計算存儲分離的話，數據遷移，請問下大佬們，網絡帶寬會是瓶頸嗎？Nebula 怎麼解決的呀？
現在都萬兆網卡了，一般機房內很難把帶寬打滿的，通常 IO 會先是瓶頸。
如果是地理分布式的圖資料庫，帶寬是要考慮的性能限制因素。
是的，現在比較流行的做法是兩地三中心或者三地五中心。分布式圖資料庫，既有圖的部分，也必然會涉及到分布系統的部分
由於大規模在線圖資料庫都設計成計算和存儲分離，數據存儲的設計是尤為重要。就金融 Risk 而言，邏輯上其實就是一張大圖，有上百 TB 的數據量，可線性擴展的存儲層設計是圖資料庫的關鍵
提問：為什麼都設計成計算存儲分離的模式，有什麼重要的考量嗎
對於 Risk 而言，在線是 inference 為主，大部分場景是為了 feature 計算，基本在 2-3 跳以內的圖遍歷，都很簡單，但是對於性能和可用性的要求很高，所以在線圖資料庫存儲分離很合理。但針對數據分析的圖資料庫，其設計會不一樣，更需要的是圖的深度遍歷能力，因此存儲分離應該是個問題，但如何支持大規模的圖，如何 scale up 應該是關鍵，而不是 scale out。
存儲計算分離大多是適應雲計算架構：存儲層買空間，計算層買彈性虛機。
長期看，計算、存儲和網絡幾個硬體模塊發展的速度是不太一樣的，並不都是摩爾定理的速度，分離能更合適長期硬體演進
我覺得存儲計算分離的一個很大的好處是存儲集群和計算集群可以獨立擴縮容，可以通過對不同集群容量的調整，最終達到能夠滿足業務需求的最佳搭配。
07怎麼理解圖資料庫頂點和標籤
提問：怎麼理解 Vertex 和 Tag 之間的關係，Schema 裡面有沒有 Vertex 的概念？一個頂點 ID 可以對應多個 Tag 是這個意思嗎？
解釋一下 Vertex，Tag，Edge 以及他們之間的關係：
Vertex 是一個頂點，用一個 64 位的 ID 來標識，一個 Vertex 可以被打上多個 Tag（標籤），每個 Tag 定義了一組屬性。
舉個例子，我們可以有 Person 和 Developer 這兩個 Tag，Person 這個 Tag 裡定義了姓名、電話、住址等等信息，Developer 這個 Tag 裡可能定義了熟悉的程式語言、工作年限、GitHub 帳號等等信息。一個 Vertex 可以被打上 Person 這個 Tag，這就表示這個 Vertex 代表了一個 Person，同時也包含了 Person 裡的屬性。另一個 Vertex 可能被同時打上了 Person 和 Developer 這兩個 Tag，那就表示這個 Vertex 不僅是一個 Person，還是一個 Developer。
Vertex 和 Vertex 之間可以用 Edge 相連，每一條 Edge 都會有類型，比如是好友關係。每個 Edge Type 也可以定義一組屬性。Edge 一般用來表示一種關係，或者一個動作。比如，Peraon A 給 Person B 轉了一筆錢，那 A 和 B 之間就會有一條 transfer 類型的邊，transfer 這個邊類型（Edge Type）可以定義一組屬性，比如轉帳金額，轉帳時間等等。
任何兩個 Vertex 之間可以有多種類型的邊，也可以有多條同種類型的邊，比如轉帳，兩個 Person 之間可以有多筆轉帳，那麼每筆轉帳就是一條邊。
提問：對於例子有一個小小疑問，這裡的 Tag 可以理解為本體 ontology 嗎？
按我的理解，ontology 應該是整張知識圖譜，也就是說包含 Vertex 和 Edge。在 Nebula 裡，Vertex 本身不含內容（也就是說沒有屬性），內容是存放在 Tag 裡的，這裡「內容」指的是 ontology 裡的concept，「邊」就是 ontology 裡的 relationship。
提問：追加個問題: 多個標籤是否支持層級關係，比如組織架構什麼的？謝謝？
在 Nebula 裡，可以定義標籤之間的依賴關係，比如上面的例子裡，Developer 依賴 Person。
08Nebula 如何處理 ID 衝突問題
提問：如果要構建一個網絡，用戶，商家，公眾號，文章，這些 ID 會重複衝突的。根據現在 vertex id就可以唯一指代點的原則，原有的 ID 不能直接使用，有什麼辦法構建出這個網絡嗎？還是把 ID 作為Tag屬性，然後建索引。
類型和原始 ID 拼在一起 hash，作為 VID，然後把原始 ID 作為一個 property。
由於業務千變萬化，所以當初我們決定把如何產生 VID 交個業務來決定。VID 是一個 64 位整數，在你的 case 裡，如果 ID 不足 64 位，那就可以用 2-4 bit 來表示不同的類型，這樣就把原來可能衝突的 ID 分到了不同的空間。如果原來的 ID 已經是 64 bit 的了，那可以像@吳敏說的那樣做 hash，把真實 ID 保存在屬性裡
09圖資料庫 0 標籤的意義
提問： 我看我們的文檔裡寫著「一個頂點必須至少有一個類型的標籤」，但是我注意到 Neo4j 是支持 0 個標籤的，請問沒有標籤的節點在查詢時跟普通標籤用法一樣麼，為什麼要支持 0 個標籤呢？這樣做有什麼意義呢？
多數的圖計算性能評測的數據集（如 Graph500、Twitter）都是 0 標籤，也就是無屬性過濾條件。這樣能看出一個圖引擎的最核心的性能。通過標籤過濾在大多數情況下對圖進行動態剪枝，時耗進而兒會縮短。
10大家怎麼看「圖資料庫要有索引」這個問題？
提問：大家怎麼看「圖資料庫要有索引」這個問題？
最終這是一個設計上的trade off問題，不同數據分布和不同訪問需求對於不同的設計方案，性能肯定是不同的。最好的方案是設計存儲訪問抽象，保留設計和實現靈活性，針對不同場景可以有不同優化。
相鄰邊的索引和節點 inline 存儲本是一種優化，可以減少物理磁碟 block read 數量，和節點一塊讀和寫。但到了一些特殊場景： 1. 如果更新非常頻繁，會造成寫放大問題 1. 單節點邊出入度異常高，但訪問只遍歷前幾個。其性能反而會變差，屬性索引是另一個問題
索引的使用要看場景，過度使用索引會得不償失。
提問：Nebula 是對臨接點有索引的 對吧
對屬性有索引
11在知識圖譜場景下計算、存儲及副本一致性問題
提問：我們知識圖譜業務場景，查節點間的路徑，請問下實時計算結果的效率怎麼樣呀？還是說比較推薦離線計算？Nebula 是存儲計算分離的是吧？
說一下個人理解，我覺得知識圖譜的場景一般是需要在線查詢的，因為不知道會有怎麼樣的查詢問題。嗯，是的，Nebula 是存儲計算分離的，最好的好處是部署方式靈活，計算節點和存儲節點可以根據不同的需求獨立擴縮容。
提問：各副本之間是最終一致嗎？還是強一致呀？
各副本之間是基於 Raft 協議的強一致。