图数据库 Nebula Graph 在 Boss 直聘的应用

本文首发于 Nebula Graph 官方博客：https://nebula-graph.com.cn/posts/nebula-graph-risk-control-boss-zhipin/

摘要：在本文中，BOSS 直聘大数据开发工程师主要分享一些他们内部的技术指标和选型，以及不少小伙伴感兴趣的 Dgraph 对比使用经验。

业务背景

在 Boss 直聘的安全风控技术中，须要用到大规模图存储和挖掘计算，以前主要基于自建的高可用 Neo4j 集群来保障相关应用，而在实时行为分析方面，须要一个支持日增 10 亿关系的图数据库，Neo4j 没法知足应用需求。

针对这个场景，前期咱们主要使用 Dgraph，踩过不少坑并和 Dgraph 团队连线会议，在使用 Dgraph 半年后最终仍是选择了更贴合咱们需求的 Nebula Graph。具体的对比 Benchmark 已经有不少团队在论坛分享了，这里就再也不赘述，主要分享一些技术指标和选型，以及不少小伙伴感兴趣的 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
• 操做系统：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
• 给 Dgraph 提交的 PRs

参考文章

• 360 的 JanusGraph 到 Nebula Graph 数据迁移

本文系 Boss直聘·安全技术中心 文洲 撰写

推荐阅读

• Nebula Graph 在微众银行数据治理业务的实践
• 图数据库选型 ｜ 360 数科的图数据库迁移史