同花順知識圖譜資料庫選型—金融海量資料毫秒級響應查詢

語言: CN / TW / HK

時間 2022-08-24 20:01:10 NebulaGraph

本文整理自同花順知識圖譜團隊在 nMeetup·杭州場的演講

這次分享主要站在（意向）使用者角度講下技術團隊選擇資料庫產品時，會有哪些考量點。在同花順知識圖譜團隊開啟知識圖譜戰略之後，一開始使用的是 Neo4j，但在使用過程中發現隨著金融業務的增長，Neo4j 並不能很好地應對增長的業務。所以，技術團隊出了一個解決方案：資料庫和應用層之間增加多級快取。雖然快取能一定程度緩解問題提升效能，但是它其實會引發更多的問題。

於是，我們開始思考有沒有一款圖資料庫能滿足目前的業務需求之外，還能應對未來的業務增長。至此，知識圖譜團隊開始了選型之旅。

如何選圖資料庫

同花順知識圖譜團隊的圖資料庫選型

選型這塊，主要分為了：How 怎麼選、What 選什麼、Why 為什麼這三部分內容，此外最後講述下同花順這塊的知識圖譜團隊和團隊業務。

選型依據這塊，主要分為：

功能強大：具備極佳的效能
商用成熟：產品成熟
社群活躍
資料量大：能應對目前的業務量，以及未來的業務增長
開源優先
技術支援
國產優先

選圖資料庫和選股票類似，我們會考慮一些訊息面、基本面和技術面，當然二者之間還是有區別的。圖資料庫的三面主要是下面幾點：

訊息面：是否滿足選型依據
基本面：是否能夠穩定持久
技術面：是否達到技術要求

訊息面

同花順知識圖譜團隊的圖資料庫選型

在圖資料庫訊息面這塊，一般我們會上一個網站：DB-Engine，可以看到排名第一的是 Neo4j，畢竟是最早的一款圖資料庫相對成熟。一圈調研下來，發現他們營銷做得不錯：在百度或者 Google 上面搜尋圖資料庫，就能看到他們的廣告。

在這個 DB-Engine 排名上，可以看到其他的像是比較出名的（排名第七）JanusGraph，我們如何在這麼多的資料庫中確定我們最終使用的資料庫呢？

同花順知識圖譜團隊的圖資料庫選型

插個題外話，這裡說下 DB-Engine 的排名規則，它的排序依據是 Google、Bing 搜尋引擎的搜尋結果，Google Trends 裡的關鍵詞趨勢，像 Stack Overflow、DBA Stack Exchange 上的討論，Indeed 之類的招聘網站的招聘數，Linkedin 裡的職位數以及社交網路主要是 Twitter 的討論量。

我們可以發現一個問題：上面的網站要麼是國內無法訪問的或者是相對小眾的網站。

所以 DB-Engine 上面的排名，對國內的一些產品來說，其實是有失偏頗的，至少它的資料肯定是不能反映它的一些真實情況的。如果考慮到國內的一些使用情況的話，這 DB-Engine 裡百度出品的 HugeGraph，以及 Nebula Graph 排名肯定是要上升好多檔。

說完 DB-Engine，再說下我們針對 DB-Engine 上的資訊做得簡單篩選：

同花順知識圖譜團隊的圖資料庫選型

上面這些資料庫從訊息面上是不滿足同花順知識圖譜團隊的需求。而這份結果也再次證明了 DB-Engine 的排名結果並非精準，比如：排名在 Nebula Graph 之上的一些資料庫已經是一些不活躍、不再更新的產品了。以上截圖資訊都來源於 DB-Engine 公開資訊。

基本面

同花順知識圖譜團隊的圖資料庫選型

經過訊息面之後，我們篩選出了 Neo4j、Orient DB、Dgraph、JanusGraph、HugeGraph、Nebula 等 6 款圖資料庫產品，這 6 款產品相對活躍，支援多語言。

按照產品的最早釋出時間，排在最前面的是 07 年釋出的 Neo4j，然後依次是 OrientDB、Dgraph、JanusGraph、HugeGraph，以及 19 年釋出的 Nebula Graph。排名越靠前的資料庫產品，它的支援語言程度越高，系統功能也會相對更加完善。這塊也是“後起之秀”新資料庫需要去完善、改進的地方。

同花順知識圖譜團隊的圖資料庫選型

而像 HugeGraph、Neo4j 很多產品功能只是在商業版本（企業版）才會支援，我們還需要了解他們的商用版本內容以及報價。

同花順知識圖譜團隊的圖資料庫選型

上面這張圖比較有意思，它指出了各類圖資料庫在不同場景下支援的數量級：比如 Neo4j 是支援十億的點、萬億的邊，毫秒級的響應時間。OrientDB 的資料就比較有意思了，支援無限量級的資料，我不知道它是如何做到這個數值。Dgraph 並沒有明確資料量情況，只是說提供了一個 Google 生產級別的資料，支援實時查詢，以及 TB 級別的結構化資料。

後面兩款一個是百度開源的 HugeGraph，一個 Nebula Graph，Nebula 這邊還是比較佔優勢的——它提供千億級別、萬億邊關係的資料量支援情況。

技術面

同花順知識圖譜團隊的圖資料庫選型

經過訊息面、基本面，其實沒有一個非常明確的勝出者。我們看下技術面這塊，由於 HugeGraph 和 JanusGraph 架構類似，OrientDB 技術支援一般，所以在技術面這塊我們著重考察：Neo4j、HugeGraph、Nebula Graph 這 3 款圖資料庫。

Neo4j 只支援同構部署，不支援異構部署，所以不能發揮每臺機器的特異性，比如：有的機器它可能是計算型的，有的機器 IO 強，如果按照 Neo4j 的部署設定，這就要求每臺機器情況等同。Neo4j 的分析能力和效能提升，主要依靠兩個 Fabric 組成的虛擬機器提供區域分割槽能力（上圖綠色部分）。

在架構層面，Nebula Graph 和 HugeGraph 的儲存計算分離的架構更有優勢，至少使用者可以針對業務部門的實際情況搭配機器配置。

同花順知識圖譜團隊的圖資料庫選型

HugeGraph 在儲存這塊支援多種儲存引擎，可對接多種第三方引擎，然後在此基礎之上加上了一個計算框架，在計算框架之上是介面層，例如：Huge Console、Huge Loader 等等。

在計算這塊，主要基於底部的儲存引擎提供了 OLTP 和 OLAP 能力。這裡 HugeGraph 的儲存引擎不是用自己的儲存引擎，主要還是依賴於其他的儲存引擎，這裡可能不如 Nebula 用自己的儲存引擎。舉個例子，我們用的第三方儲存引擎是 HBase，HBase 的實時性是非常差的，這時候用它做儲存引擎就會影響到上一層的效能。

同花順知識圖譜團隊的圖資料庫選型

Nebula Graph 這裡也是一個儲存和計算分離的一個架構，每一層都可無限擴充套件，你的儲存不夠就加儲存，計算不夠就加計算，相對而言還是一個比較先進的架構。

講完架構之後，同花順這邊參考了其他技術團隊的測試結果：

同花順知識圖譜團隊的圖資料庫選型

這是騰訊雲安全團隊在 v1.x 版本的效能測試。

同花順知識圖譜團隊的圖資料庫選型

這是美團 NLP 團隊做的 Nebula、Dgraph、HugeGraph 的效能對比：在這裡，HugeGraph 的儲存引擎用的是 HBase，而 Dgraph 和 Nebula Graph 用的是 RocksDB，就像之前說的那樣 HBase 在實時性這塊是一個短板。如果資料庫儲存引擎層面，3 個數據庫都是用的 KV 儲存引擎的話，結果不會產生如此大的一個量級差距；

同花順知識圖譜團隊的圖資料庫選型