圖資料庫愛好者的聚會在談論什麼？

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

聚會概述

在上週六的聚會中，Nebula Graph Committer 吳敏給愛好者們介紹了整體架構和特性，並隨後被各位大佬輪番蹂躪（劃掉）。

本次分享主要介紹了 Nebula Graph 的特性，以及新上線的《使用 Docker 構建 Nebula Graph》功能。

下面是現場的 Topic ( 以下簡稱：T ) & Discussion ( 以下簡稱：D ) 速記：

討論話題目錄

• 演算法和語言
  • 相簿的 builtin 只搞線上查詢可以嗎？有必要搞傳播演算法和最短路徑嗎？Nebula 怎麼實現對圖分析演算法的支援？
  • 為什麼要新開發一種查詢語言 nGQL？做了哪些最佳化？
  • 對於超大點，有啥最佳化的辦法嗎，或者對於構圖有什麼建議嘛？
  • 相簿相比其它系統和資料庫未來發展趨勢，比如相比文件和關係型，它的核心價值是什麼？
• 架構和工程
  • key 為什麼選擇用 hash 而不是 range？
  • gRPC，bRPC，fbthrift 為什麼這麼選 rpc？有沒有打算自己寫一個？
  • 相簿在設計上趨同化和同質化，架構上還有哪些創新值得嘗試？
• 關於生態
  • 圖的生態怎麼打造？和周邊其它系統怎麼整合融合？

演算法和語言

T: 相簿的 builtin 只搞線上查詢可以嗎？有必要搞傳播演算法和最短路徑嗎？Nebula 怎麼實現對圖分析演算法的支援？

🎙️D：Nebula 目前階段側重 OLTP，現在支援的演算法是 全路徑 和 最短路徑 。在相簿 builtin LPA 有不少工作要做（當然其實市面上也有產品），Nebula 現階段的考慮是採用 儲存計算分離架構 ，使用者可以將圖結構或者子圖抽取到 GraphX 這種圖計算框架，在圖計算框架中實現傳播演算法。如果 OLTP 這塊工作完成比較多了，再考慮向 OLAP 這個方向走。

🙋 T：為什麼要新開發一種查詢語言 nGQL？做了哪些最佳化？

🎙️ D：其實目前市場上沒有統一的圖查詢語言，可能 Cypher 和 Gremlin 影響力要大一些，當然要說圖語言類的其實更多，比如還有 GraphQL，SPARQL。nGQL 與 SQL 接近，比較容易上手，但不用 SQL 那樣巢狀（embedding)。

我感覺描述性的語言，大家的總體風格還是挺類似的，上手學習成本其實真沒有想象那麼高，花個十幾分鍾看看大概也明白了。有點類似中國各地方言（溫州話除外，劃掉），或者歐洲的各語言，共通的部分挺多的，連蒙帶猜基本也能用。當然特別複雜的邏輯還是得看看手冊才行。

最佳化方面：為避免儲存層將過多資料回傳到計算層，佔用寶貴頻寬，Nebula 做了 計算下沉 ，條件過濾會隨查詢條件一同下發到儲存層節點。如果不帶這個過濾，傳 100% 和 1% 的資料，效能是數量級的差異。

對圖查詢的執行計劃最佳化也進行了一定的探索，包括 執行計劃快取 和上下文無關語句的 併發執行 。當然其實查詢最佳化挺難做的，我感覺 更能有效提升速度的是如何構圖 。因為圖的自由度還是挺大的，同一個東西，其實既可以構圖成點、邊也可以做成屬性，其實對大多數目前的使用者來說，構圖對效能的影響應該會比 DB 最佳化更明顯更快。當然構圖其實是和 DB 怎麼實現也挺有關係的，比如減少網路傳輸（比如過濾）、用好 SSD 和 cache（比如減少隨機讀）、增加各種併發（多執行緒、多機）。

還有不要構造一個超大點出來，不然熱點太明顯了。回到語言，我們也考慮是不是 nGQL 上面加一層 Driver 支援 Cypher 和 Gremlin，比如 80% 的常見功能。還有就是考慮在 webconsole 上增加一些流程圖的功能模組，CRUD 操作用圖形化支援，複雜的就寫 query，對長尾使用者上手也有幫助。

🙋 T：剛才聊到超大點，有啥最佳化的辦法嗎，或者對於構圖有什麼建議嘛？

🎙️ D：對於超大點建議還是構圖和查詢時，想辦法處理（分解）比較好，這個和 SQL 分庫分表差不多。比如：遍歷過程中 touch 到的交易對手很大（比如：美團），那最好能給這種大點打標，遍歷時候過濾掉。當然打標可能要離線 count 一下才知道。

比方說，根據業務型別、時間片段，把一個超大點最好能拆成多個小點，這樣操作點一般不會落在一個 partition 上，再把當中熱點的 partition 遷移到不同的機器上。舉例來說，遍歷太深的話，通常效能都不會太好，所以可以把屬性放在起點和終點上。像 (Subject1)->(Predicate1)->(Object1) 這樣， (Subject1)、(Predicate1)、(Object1) 三個節點，兩跳深度，可能要走一次網路，但改成 (Subject1)-[Predicate1]->(Object1) 這樣 -[Predicate1]-> 改成一種型別的邊，那就不走網路，特別當查詢深度更深時，這種構圖對效能最佳化很明顯。類似的，還有屬性值處理，如：起點的 Name(string)，不要作為邊屬性，不然同一個點出去的所有邊上都冗餘了這個 Name(string)，更新的時候也巨麻煩。

🙋 T：相簿相比其它系統和資料庫未來發展趨勢，比如相比文件和關係型，它的核心價值是什麼？

️ D: Everything is connected. 圖資料庫天生適合表達 connection，或者說多對多的關係。

圖資料庫可以很高效的查詢幾度關係，而傳統關係型資料庫不擅長，一般都需要做表連線，表連線是一個很昂貴的操作，涉及到大量的 IO 操作及記憶體消耗。

但我覺得其實文件、關係和圖相互還是借鑑非常多的，我記得《DesigningData-Intensive Applications》裡面有章就是做它們之間的比較。

架構和工程

🙋 T：key 為什麼選擇用 hash 而不是 range？

🎙️ D：其實並不是一定要 hash，只是要求 vid 是定長的 64 bit。定長主要是出於對齊效能考慮，還可以用上 prefix bloomfilter。那麼變長 id 一般 hash 成 64 bit 最簡單，當然使用者自己指定 vid 也是支援的，一般這個時候，需要把原始 id 放到點的屬性裡。

🙋 T：gRPC，bRPC，fbthrift 為什麼這麼選 rpc？有沒有打算自己寫一個？

🎙️ D：從使用體驗上看，fbthrift 易讀性不錯。gRPC 之前用過也挺多。當然寫個好的 rpc 還是挺不容易的，這個輪子暫時不是很急迫。

🙋 T：相簿在設計上趨同化和同質化，架構上還有哪些創新值得嘗試？

️ D：其實圖產品有很多，我覺得這些產品不能說都是趨同，畢竟從幾個知名競品的架構看，彼此之間相差還是蠻大的 :)。因為功能集和架構出發點主要還是針對業務目標，Nebula 設計目標是實現 萬億級別關聯關係 和 大併發 低時延 ，所以選擇了儲存計算分離，儲存層採用 raft 一致協議，資料 partition 到不同機器上。這樣設計主要考慮到儲存和計算兩者的業務特點和增長速度不一樣，比如 learner 可以拿來給一些 throughput 優先的場景使用，原叢集給 latency 優先的場景使用。

說到大的架構創新，主要看長期的硬體更新速度。當然 DB 可做的最佳化的事情已經很多的，剛才 PPT 裡面有提及。

🙋 T：在測試方面，Nebula 做了哪些工作？

🎙️ D：一個是整合測試框架，包括 混沌工程 、 錯誤注入 這些，等完善之後也會開放出來。還有是關於測試集和資料集，對於 DB 來說，這部分的價值是最大的，不過圖領域可參考的資料集較少，都是大家自己積累的。

關於生態

🙋 T：圖的生態怎麼打造？和周邊其它系統怎麼整合融合？

🎙️ D：在查詢語言方面，增加對 Gremlin、Cypher 的支援。

在工具方面，提供資料批次匯入和匯出的工具，比如 GraphX，Yarn，Spark 等。還有，就是對機器學習的需求支援，儲存計算相分離的架構使得 Nebula 非常容易整合圖計算框架。因為 Nebula 是開源產品，這些工具歡迎大家一起參與:)

Nebula Graph：一個開源的分散式圖資料庫。

GitHub：https://github.com/vesoft-inc/nebula

知乎：https://www.zhihu.com/org/nebulagraph/posts

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