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

NebulaGraph發表於2019-09-16

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

相關文章