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