> 本文首發於 Nebula Graph 官方部落格：[https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/](https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/) 摘要：在本文中，BOSS 直聘大資料開發工程師主要分享一些他們內部的技術指標和選型，以及很多小夥伴感興趣的 Dgraph 對比使用經驗。 ## 業務背景 在 Boss 直聘的安全風控技術中，需要用到大規模圖儲存和挖掘計算，之前主要基於自建的高可用 [Neo4j](https://github.com/neo4j/neo4j) 叢集來保障相關應用，而在實時行為分析方面，需要一個支援日增 10 億關係的圖資料庫，Neo4j 無法滿足應用需求。 針對這個場景，前期我們主要使用 [Dgraph](https://github.com/dgraph-io/dgraph)，踩過很多坑並和 Dgraph 團隊連線會議，在使用 Dgraph 半年後最終還是選擇了更貼合我們需求的 [Nebula Graph](https://github.com/vesoft-inc/nebula)。具體的對比 [Benchmark](https://discuss.nebula-graph.com.cn/t/topic/1377) 已經有很多團隊在論壇分享了，這裡就不再贅述，主要分享一些技術指標和選型，以及很多小夥伴感興趣的 Dgraph 對比使用經驗。 ## 技術指標 ### 硬體 配置如下： * 處理器：Intel(R) Xeon(R) Gold 6230 CPU @ 2.10GHz 80(cores) * 記憶體：DDR4，128G * 儲存：1.8T SSD * 網路：萬兆 Nebula Graph 部署 5 個節點，按官方建議 3 個 metad / 5 個 graphd / 5 個 storaged ### 軟體 * Nebula Graph 版本：[V1.1.0](https://github.com/vesoft-inc/nebula/releases/tag/v1.1.0) * 作業系統：CentOS Linux release 7.3.1611 (Core) ### 配置 ``` 主要調整的配置和 storage 相關 # 按照文件建議，配置記憶體的 3 分之 1 --rocksdb_block_cache=40960 # 引數配置減小記憶體使用 --enable_partitioned_index_filter=true --max_edge_returned_per_vertex=100000 ``` ### 指標 目前安全行為圖儲存 3 個月行為，近 500 億邊，10 分鐘聚合寫入一次，日均寫入點 3,000 萬，日均寫入邊 5.5 億，插入延時 <=20 ms。    讀延時 <= 100 ms，業務側介面讀延時 <= 200 ms，部分超大請求 < 1 s   當前磁碟空間佔用 600G * 5 左右  CPU 耗用 500% 左右，記憶體使用穩定在 60 G 左右  ## Dgraph 使用對比 目前來說原生分散式圖資料庫國內選型主要比對 Dgraph和 Nebula Graph，前者我們使用半年，整體使用對比如下，這些都是我們踩過坑的地方。  就我們使用經驗，Dgraph 設計理念很好，但是目前還不太滿足我們業務需求，GraphQL 的原生支援還是有很大吸引力，但是儲存結構決定容易 OOM（邊儲存也分組的話會優化很多，官方之前計劃優化）；另外，採用自己編寫的 badger 和 ristretto，目前最大的問題是從官方釋放的使用案例來看，未經大規模資料場景驗證，在我們實際使用中，大資料量和高 QPS 寫入場景下容易出現崩潰和 OOM，且如果採用 SSD 儲存海量資料，Dgraph 的磁碟放大和記憶體佔用也需要優化。 如果沒有高 QPS 寫入，目前 Dgraph 還是值得一試，對於很多快速原型的場景，作為 GraphQL 原生圖資料庫使其非常適合做基於圖的資料中臺，這是目前的一個大趨勢，它也上線了自己的雲服務，業內標杆 TigerGraph 也在做相關探索，另外事務的完善支援也是它的優勢，這塊暫時用不到，所以沒做相關評測。實測 Dgraph 線上寫入併發不高或只是離線匯入資料使用的情況下還是很穩定的，如果想借助它的高可用和事務功能，可以嘗試下。 對比來說，Nebula Graph 很優秀，特別是工程化方面，體現在很多細節，可以看出開發團隊在實際使用和實現上做較了較好的平衡： - 1.支援手動控制資料平衡時機，自動固然很好，但是容易導致很多問題 - 2.控制記憶體佔用（enable_partitioned_index_filter 優化和設定單次最大返回邊數目），都放在記憶體固然快，但有時候也需要考慮資料量和效能的平衡 - 3.多圖物理隔離，多張圖實在太有必要 - 4.nGQL 最大程度接近最常用 MySQL 語句，2 期相容 Cypher 更加完美；對比 GraphQL 固然香，但寫起復雜圖查詢真的讓人想爆炸，可能還是更加適合做資料中臺查詢語言 - 5.和圖計算框架的結合，最近釋放的 Spark GraphX 結合演算法非常有用，原先我們的圖計算都是基於 GraphX 從 Neo4j 抽取後離線計算團伙，後續打算嘗試 Nebula Graph 抽取 這裡主要從實際經驗對比分享，二者都在持續優化，都在快速迭代，建議使用前多看看最新版本 release說明。 ## 建議 當前 Nebula Graph 做得很優秀，結合我們現在的需求也提一點點建議： - 1.**更多離線演算法**，包括：現有的圖神經網路這塊的支援，圖線上查詢多用在分析，真正線上應用目前很多還是圖計算離線算完後入庫供查詢 - 2.**Plato 框架的合併支援**，Spark GraphX 相對計算效率還是低一些，如果能整合騰訊的 Plato 框架更好 - 3.借鑑 TigerGraph 和 Dgraph，**支援固化 nGQL 查詢語句直接生成服務 REST 端點**，**HTTP 傳入引數即可查詢**，這樣可快速生成資料查詢介面，不用後臺再單獨連線資料庫寫 SQL 提供資料服務 目前 Boss 直聘將 Nebula Graph 圖資料庫應用在安全業務，相關應用已經線上穩定執行大半年，本文分享了一點經驗，拋磚引玉，期望更多技術夥伴來挖掘Nebula這座寶庫。 Dgraph 遇到的一些問題，供有需要小夥伴參考 - 給 Dgraph 一些 [issues](https://github.com/dgraph-io/dgraph/issues?q=jimwen) - 給 Dgraph 提交的 [PRs](https://github.com/dgraph-io/dgraph/pulls?q=is%3Apr+author%3A%40me+is%3Aclosed) ## 參考文章 - [360 的 JanusGraph 到 Nebula Graph 資料遷移](https://discuss.nebula-graph.com.cn/t/topic/1172) > 本文系 Boss直聘·安全技術中心 文洲 撰寫 ## 推薦閱讀 - [Nebula Graph 在微眾銀行資料治理業務的實踐](https://nebula-graph.com.cn/posts/practicing-nebula-graph-webank/) - [圖資料庫選型 ｜ 360 數科的圖資料庫遷移史](https://nebula-graph.com.cn/posts/why-migrate-janusgraph-nebula