聊聊圖數據庫和圖數據庫的小知識 Vol.02

2010 年先後，對於社交媒體網絡研究的興起帶動了圖計算的大規模應用。 2000 年先後熱門的是 信息檢索 和 分析 ，主要是 Google 的帶動，以及 Amazon 的 e-commerce 所用的協同過濾推薦，當時 collaborative filtering也被認爲是 information retrieval 的一個細分領域，包括 Google 的 PageRank 也是在信息檢索領域研究較多。後來纔是 Twitter，Facebook 的崛起帶動了網絡科學 network science的研究。 圖理論和圖算法不是新科學，很早就有，只是最近 20 年大數據，網絡零售和社交網絡的發展， big data、social networks、e-commerce 、IoT讓圖計算有了新的用武之地，並且硬件計算力的提升和分佈式計算日益成熟的支持也使圖在高效處理海量關聯數據成爲可能。

上文摘錄了#聊聊圖數據庫和圖數據庫小知識# Vol.01 的【圖數據庫興起的契機】，在本次第二期#聊聊圖數據庫和圖數據庫小知識#咱們將瞭解如下內容，若是有感興趣的圖數據庫話題，歡迎添加 Nebula 小助手微信號：NebulaGraphbot 爲好友進羣來交流圖數據庫心得。

本文目錄

• 圖數據庫和圖數據庫設計
  • 傳統數據庫經過設計良好的數據結構是否是能夠實現圖數據庫的功能
  • 圖數據庫會出於什麼考慮作存儲計算分離
  • 數據量小，業務量小的狀況下，是否單機部署圖數據庫性能也不錯。
  • 圖數據庫 shared-storage 和 shared-nothing 的比較
  • 圖數據庫頂點和邊輸出及超級頂點輸出優化
  • 如何處理圖數據庫中大數據量的點？
• Nebula Graph 實踐細節
  • Nebula Graph 元數據（Meta Service）使用 etcd 嗎？
  • Nebula Graph Cache 位於那一層
  • Nebula Graph 集羣中的 Partition 多大
  • 如何理解 Nebula Graph Partition

☺️ 圖數據庫和圖數據庫設計

在這個部分，咱們會摘錄一些圖數據庫設計通用的設計思路，或者已有圖數據庫的實踐思考。

🤖 傳統數據庫經過設計良好的數據結構是否是能夠實現圖數據庫的功能

圖數據庫相對傳統數據庫優化點在於，數據模型。傳統數據庫是一個關係型，是一種表結構作 Join，但存儲結構代表了很難支持多度拓展，好比一度好友，兩度好友，一度還支持，使用一個 Select 和 Join 就可完成，可是二度查詢開銷成本較大，更別提多度 Join 查詢開銷更大。圖數據庫的存儲結構爲面向圖存儲，更利於查詢多度關係。特別的，有些圖上特有的操做，用關係型數據庫比較難實現和表達，好比最短路徑、子圖、匹配特定規則的路徑這些。

🚀 圖數據庫會出於什麼考慮作存儲計算分離

存儲與計算分離主要出於如下四方面的考慮：

1. 存儲和計算資源能夠獨立擴展，使資源利用更充分，達到縮減成本的目的。
2. 更容易利用異構機型。
3. 解耦計算節點，計算資源能夠更大程度地作到線性擴展。基於以前的項目經歷，存儲計算不分離的分佈式架構，計算能力的水平擴展會比較不方便。舉個例子，在好友關係這種場景——基於好友關係查詢再作一些排序和計算，在某個節點查詢執行過程當中須要去其餘節點獲取數據，或者將某個子計算交給其餘節點，若是執行過程當中須要的數據存儲在本地，相較存儲計算分離效率可能會高；但當涉及到和其餘節點通訊問題時，爲了擴容計算資源而增長的機器會使得計算過程當中的網絡開銷相應增長，抵消了至關一部分的計算能力。若是存儲計算分離，計算和存儲一對一，不存在節點越多網絡通信開銷越大的問題。
4. Nebula Graph在存儲層提供基於圖的查詢接口，但不具有運算能力，方便對接外部的批量計算，好比 Spark，能夠將圖存儲層看成爲圖索引存儲，直接批量掃描、遍歷圖自行計算，這樣操做更靈活。存儲層支持作一些簡單的過濾計算，好比找尋 18 歲好友等過濾操做。

🎨 數據量小，業務量小的狀況下，是否單機部署圖數據庫性能也不錯。

單機按分佈式架構部署，有必定網絡開銷由於通過網卡，因此性能還行。必定要分佈式架構部署的緣由在於強一致、多副本的業務需求，你也能夠按照業務需求部署單副本。

🎏 圖數據庫 Shared-storage 和 Shared-nothing 的比較

【提問】對於圖數據庫來講，是否是 shared-storage 相比 shared-nothing 方式更好呢。由於圖的節點間是高度關聯的，shared-nothing 方式將這種聯繫拆掉了。對於多步遍歷等操做來講，須要跨節點。並且因爲第二步開始的不肯定性，要不要跨節點好像無法提早經過執行計劃進行優化。

【回覆】交流羣羣友 W：errr，單個 storage 能不能放下那麼多數據，特別數據量增長了會是個比較麻煩的問題。另外第二步雖然是隨機的，可是取第二步數據的時候能夠從多臺機器併發

【回覆】交流羣羣友 W：主要的雲廠商，好比 AWS 的共享存儲能夠到 64 T，存儲應該夠，並且這種方式存儲內部有多副本。順便提一句：AWS 的 Neptune 的底層存儲用的也是 Aurora 的那個存儲。網絡這塊的優化，可參考阿里雲的 Polarstore，基本上網絡已經不是什麼問題了。

此外，「第二步雖然是隨機的，可是取第二步數據的時候能夠從多臺機器併發吧」這個卻是，Nebula 有個 storage server 能夠作這個事情，但邏輯上彷佛這個應該是 query engine 應該乾的。

【回覆】交流羣羣友 W：「網絡這塊的優化，可參考阿里雲的 polarstore，基本上網絡已經不是什麼問題了。」 網絡這問題，部署環境的網絡不必定可控，畢竟機房質量良莠不齊，固然雲廠商本身的機房會好不少。

【回覆】交流羣羣友 W：這個確實。因此開源的創業公司走 shared-nothing，雲廠商走 shared-storage，也算是都利用了各自的優點

【回覆】交流羣羣友 S：其實，shared-storage 能夠被當作是一個存儲空間極大的單機版，並非一個分佈式系統

【回覆】交流羣羣友 W：嗯嗯。不過 Neptune 那種跟單機版的區別在於計算那部分是可擴展的，一寫多讀，甚至 Aurora 已經作到了多寫。不過就像前面所說的，開源的東西基於那種需定製的高大上存儲來作不現實。想了下拿 AWS 的存儲作對比不大合適，存儲內部跨網絡訪問的開銷仍是一個問題，拿 Polarstore 這種 RDMA 互聯更能說明。可能 2 種方案都差很少，本質上都是可否減小跨網絡訪問的開銷。

📈 圖數據庫頂點和邊輸出及超級頂點輸出優化

【提問】請教一個問題。Nebula 的頂點和出邊是連續存放的。那麼在查詢語句進行 IO 讀取時，是頂點和出邊會一塊兒讀出來呢，仍是根據查詢語句的不一樣而不一樣？

【回覆】交流羣羣友 W：會一個 block 一塊兒讀出來

【回覆】交流羣羣友 W：恩恩。對於 supernode 這種狀況，有沒有作什麼優化？Titian/Janusgraph 有一個節點全部邊的局部索引，Neo4j 應該有在 object cache 中對一個節點的邊按照類型組織

【回覆】交流羣羣友 S：Nebula 也是用 index 來解決這個問題

【回覆】交流羣羣友 W：Neo4j 的 relationship group 是落在存儲上的，請教下，Nebula 的這種 index 和 Janusgraph 的 vertex centric 索引相似麼，仍是指存儲格式裏面的 ranking 字段啊

【回覆】交流羣羣友 S：相似於 Janusgraph 的索引，可是咱們的設計更 general，支持 multi-column 的索引

【回覆】交流羣羣友 W：ranking 字段其實給客戶用的，通常能夠拿來放時間戳，版本號之類的。

💌 如何處理圖數據庫中大數據量的點？

【提問】：Nebula 的存儲模型中屬性和邊信息一塊兒存儲在頂點上，針對大頂點問題有好的解決方案嗎？屬性和關係多狀況下，針對這種實體的查詢該怎麼處理，好比：好比美國最有名的特產，中國最高的人，浙江大學年齡最大的校友

【回覆】交流羣羣友 W：若是能夠排序，那分數能夠放在 key 上，這樣其實也不用 scan 太多了，ranking 字段就能夠放這個。要否則還有個辦法是容許遍歷的過程當中截斷或者採樣，否則很容易爆炸的。

【回覆】交流羣羣友 B：在作實時圖數據庫的數據模型設計時，儘可能避免大出入度的節點。若是避免不了，那至少避免此類節點再日後的 traversal。若是仍是避免不了，那別期望這樣的查詢會有好的性能

【回覆】交流羣羣友 H：單純的大點若是不從它開始 traversal，其實問題也不大。load 的 unbalance 都是有辦法解決的。數據的 unbalance 由於分 part 存儲，在分配 part 到 host 時可加入 part 數據量的權重，而 load 的 unbalance，對於讀，可經過拓展只讀副本 + cache 解決，寫的話，可作 group commit，client 也能夠作本地 cache。

【回覆】交流羣羣友 B：圖數據庫的一個查詢的性能最終取決於 physical block reads 的數量。不一樣方案會致使最後 block reads 不同，性能會有差異。任何一種方案不可能對全部查詢都是優化的，最終每每就是 tradeoff。主要看你大部分實際的 query pattern 和數據分佈式如何，該數據庫實現是否有優化。拆邊和不拆邊，各有其優缺點。

🤗 Nebula Graph 實踐細節

在這個部分咱們會摘錄一些開源的分佈式圖數據庫 Nebula Graph 在實踐過程當中遇到的問題，或者用戶使用圖數據庫 Nebula Graph 中遇到的問題。

📝 Nebula Graph 元數據（Meta Service）使用 etcd 嗎？

不是。Meta Service的架構其實和 Storage Service 架構相似，是個獨立服務。

🔍 Nebula Graph Cache 位於哪一層

A：KV 那層。目前只有針對頂點的 Cache，頂點的訪問具備隨機性，若是沒有 Cache，性能較差。Query Plan 那層如今尚未。

🔖 如何理解 Nebula Graph Partition

partition 是個邏輯概念，主要目的是爲了一個 partition 內的數據能夠一塊兒遷移到另一臺機器。partition 數量是由建立圖空間時指定的 partition_num 確立。而單副本 partition 的分佈規則以下

經過算子：partID%engine_size，而多副本的狀況，原理相似，follower 在另外兩個機器上。

📚 Nebula Graph 集羣中的 Partition 多大

A：部署集羣時須要設置 Partition 數，好比 1000 個 Partition。插入某個點時，會針對這個點的id作 Hash，找尋對應的 Partition 和對應 Leader。PartitionID 計算公式 = VertexID % num_Partition

單個 Partition 的大小，取決於總數據量和 Partition 個數；Partition 的個數的選擇取決於集羣中最大可能的機器節點數，Partition 數目越大，每一個 Partition 數據量越小，機器間數據量不均勻發生的機率也就越小。

最後，這裏是開源的分佈式圖數據庫 Nebula Graph 的 GitHub 地址：https://github.com/vesoft-inc/nebula， 歡迎給咱們提 issue~~

推薦閱讀

• #聊聊圖數據庫和圖數據庫小知識# Vol.01