共计 2334 个字符，预计需要花费 6 分钟才能阅读完成。
本文首发于 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 数科的图数据库迁徙史
