?

本文整理自同花順知識圖譜團隊在 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 存儲引擎的話，結果不會產生如此大的一個量級差距；

下面是同花順的一個性能測試結果：我們不僅對比不同圖數據庫，還對比了 Nebula Graph 兩種查詢語言（原生 nGQL 和兼容 openCypher 的 nGQL）。

從數據上可以看到原生的查詢語言 nGQL 會表現更好點（上圖的 nebula-ngql 和 nebula-cypher）。而在多跳查詢中，可以看到基本上在 5 跳以上的查詢，Neo4j 都是處于一個超時的狀態。

在性能上，Nebula 相對 Neo4j 還是有比較大性能優勢的。

綜合考慮架構、性能、社區支持情況等等因素，我們還是會選擇更適合我們的圖數據庫——Nebula Graph。雖然在使用的過程中發現了一些小問題：

• 不支持中文標識符
• 語法錯誤提示不友好
• Java 不支持參數化查詢
• GO 查詢必須指定起點 ID

但，總的來說還是滿足我們的業務要求的。

同花順·知識圖譜團隊介紹

最后來介紹下我們的團隊——同花順知識圖譜團隊，主要面向的業務是：智能對話、推薦系統、搜索引擎、投資策略以及多模融合、股票亮點、投顧投教這樣的一些業務，后面可能接入更多的業務場景。

當前我們維護了這么幾個圖譜，一個是產業鏈的圖譜，就是數據來源于一些公開的數據。通過語義抽取，構建出來的產業鏈圖譜；

還有供應鏈圖譜。

人物關系圖譜

以及企業圖譜

從而滿足同花順這邊金融投資的需求。

?

聲明：本作品系原創，采用《署名-非商業使用-禁止演繹4.0國際》許可協議

?