共计 5027 个字符，预计需要花费 13 分钟才能阅读完成。
1 什么是图数据库
图数据库 (Graph database) 是以图这种数据结构存储和查问的数据库。与其余数据库不同，关系在图数据库中占首要地位。这意味着应用程序不用应用外键或带外解决（如 MapReduce）来推断数据连贯。与关系数据库或其余 NoSQL 数据库相比，图数据库的数据模型也更加简略，更具表现力。
图数据库在社交网络、常识图谱、金融风控、个性化举荐、网络安全等畛域利用宽泛。
2 图数据库调研
2.1 调研背景
随着常识图谱等业务数据的一直增长，现有图数据库 JanusGraph 应答曾经比拟吃力，导入工夫曾经无奈满足业务的要求。因而寻找性能更好的开源属性图数据库曾经成为了以后迫切要做的事件。
新图数据库应满足以下要求：
- 可能反对 10 亿节点 100 亿边 170 亿属性的大规模图谱
- 全量导入工夫不超过 10h
- 二度查问均匀响应工夫不超过 50ms，QPS 可能达到 5000+
- 开源且反对分布式的属性图数据库
2.2 调研过程
第一步，收集常见的开源分布式属性图数据库，如下表：
第二步，基于美团、LightGraph、TigerGraph、GalaxyBase 等图数据库测试报告，剖析可得几个图数据库性能如下：
导入：NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB
查问：NebulaGraph > HugeGraph > JanusGraph > ArangoDB > OrientDB
NebulaGraph 不论是在导入还是在查问性能上都体现优异。
第三步，为了验证 NebulaGraph 的性能，对 NebulaGraph 和 JanusGraph 进行了一次性能比照测试，测试后果如下：
上图中，将 JanusGraph 性能看作 1，NebulaGraph 导入性能要比 JanusGraph 快一个数量级，查问性能是 JanusGraph 的 4-7 倍。而且随着并发量的增大，性能差距会进一步拉大，而且 JanusGraph 在从 20 个线程开始，三度街坊查问会有 error。而 NebulaGraph 没有任何 error。
NebulaGraph 全量导入 10 亿节点 100 亿边只须要 10h，满足要求，目前正在调研 SST 导入，能够大幅晋升导入速度。
对 NebulaGraph 应用 120 个线程进行二度街坊查问压测，最终 QPS 在 6000+，相比单机有一些晋升。成功率靠近 5 个 9，而且响应实际比较稳定，均匀 18.81ms，p95 38ms，p99 也才 115.6ms，合乎需要。
2.3 调研论断
NebulaGraph 导入性能、响应工夫、以及稳定性均合乎需要，反对数据切分，分布式版本收费开源，应用的企业也多，中文文档，文档全面，社区沉闷，是开源图数据库的现实抉择。
3 NebulaGraph 简介
图片来源于 NebulaGraph 官网
NebulaGraph 是一款开源的、分布式的、易扩大的原生图数据库，可能承载数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查问。
NebulaGraph 基于图数据库的个性应用 C ++ 编写，采纳 shared-nothing 架构，反对在不进行数据库服务的状况下扩缩容，而且提供了十分多原生工具，例如 Nebula Graph Studio、Nebula Console、Nebula Exchange 等，能够大大降低应用图数据库的门槛。
图片来源于 NebulaGraph 官网
NebulaGraph 由三种服务形成：Graph 服务、Meta 服务和 Storage 服务，是一种存储与计算拆散的架构。
Meta 服务负责数据管理，例如 Schema 操作、集群治理和用户权限治理等。服务是由 nebula-metad 过程提供的，生产环境中，倡议在 Nebula Graph 集群中部署 3 个 nebula-metad 过程。请将这些过程部署在不同的机器上以保障高可用。所有 nebula-metad 过程形成了基于 Raft 协定的集群，其中一个过程是 leader，其余过程都是 follower。
Graph 服务次要负责解决查问申请，包含解析查问语句、校验语句、生成执行打算以及依照执行打算执行四个大步骤，服务是由 nebula-graphd 过程提供的，能够部署多个。
Storage 服务负责存储数据，服务是由 nebula-storaged 过程提供的，所有 nebula-storaged 过程形成了基于 Raft 协定的集群，数据在 nebula-storaged 中分区存储，每个分区都有一个 leader，其它正本集形成该分区的 follower。
4 图数据库平台建设
之前在应用的 JanusGraph 时候，遇到过导入迟缓、查问慢、高并发 OOM（JanusGraph 线程池采纳无界队列导致）、FULL GC（业务 Gremlin 语句中蕴含 Value 导致元空间一直收缩导致）等问题，这些在切到 NebulaGraph 后根本失去了解决。
JanusGraph 并没有好用的治理界面，所上图所示，咱们开发了一套蕴含多图治理、Schema 治理、图可视化、图导入、权限治理的治理界面。
而 NebulaGraph Studio 提供多图治理、Schema 治理、图可视化、图导入等性能，省去了很多开发工作，升高了应用门槛。
整个图数据库平台的构造如上图所示，基于 NebulaGraph 和 NebulaGraph 官网工具，着重开发了 全量导入、增量导入、图导出、备份 / 还原、查问工程（图检索）等性能。
官网导入工具须要提供导入配置文件，为了更便于业务应用，咱们设计了一个 schema 配置表格，业务只需填好表格，导入的时候会主动创图，创立图的 schema，主动生成导入配置文件，主动导入数据，主动均衡数据，均衡 leader，创立索引，执行 compact 工作。以后还是批量写入的导入形式，后续会调研 SST 导入，导入性能可进一步晋升。
官网提供的导入工具采纳的是异步客户端，导入时极难管制导入速率，设置过大，容易导致图数据库申请积压，影响集群的稳固运行。设置过小，速度无奈达到最优，导入过慢。咱们批改了官网导入工具源码，将异步客户端改成了同步客户端，能够兼顾性能和稳定性。
官网没有提供导出工具，咱们基于官网的 nebula-spark 开发了一个导出工具，除了可能导出数据，还可能导出 Schema 配置以及索引配置，便于业务做数据迁徙。
为了反对数据回滚，咱们开发了指定图谱的数据疾速备份和还原的性能，不过该性能无奈备份图谱元数据，全量导入会删除并重建图谱，因为元数据发生变化，之前的备份就没有用了。后续会尝试全量导入只清理数据不删图的形式来防止这个问题。
常识图谱业务的边类型十分多，常常一次查问须要查问几十上百种边，每种类型的边其实只须要返回 Top 10（依据 rank 排序）个后果就好。这种状况通过 nGQL 很不好实现，只能查问这些边的所有数据，或者所有边合在一起的 Top N 个数据，前者有性能问题，后者常常只能返回局部类型边的数据，无奈满足需要。针对这种状况，咱们对边进行了分类，对于数量较少的那些边类型，一条语句查问所有数据。对于数量多的边类型，应用多线程并行查问每条边的 Top 10，这样就能进行肯定的躲避。
为了保障服务的高可用，咱们实现了双机房部署。为了不让下层业务感知机房切换，在图数据库下层做了查问工程（图检索），业务间接调用查问工程的服务，查问工程会依据集群状态抉择适合的图数据库集群查问。另外，为了向下层业务屏蔽底层图数据库变更和版本升级，查问工程会治理所有业务的查问语句。遇到图数据库因为版本升级呈现查问语句不兼容的时候，只须要在查问工程中将图查询语言进行调整就好，防止波及下层业务。同时，查问工程也对查问后果进行了缓存，能够极大的进步图查问的吞吐量。
当然咱们还遇到一些问题，如 rank 因大小端问题导致排序生效、查问后果只返回边类型 id 等，因为篇幅起因，在此不一一列举，这些问题通过 NebulaGraph 社区帮忙，曾经失去了躲避或解决。
* 留神：以上提到的 NebulaGraph 问题仅针对 V1.2.0 版本，很多问题后续版本曾经修复。
5 业务落地
5.1 常识图谱及智能问答
在应用图谱之前，小布助手只反对基于文档的问答 DBQA，DBQA 利用的是非结构化的文本，适宜答复 Why、How 等解释性、阐述性问题，而对于事实性问题答复准确率和覆盖率不高。
在应用图谱后，小布助手反对基于知识库的问答 KBQA，在 What、When 等事实性问题的准确率和覆盖率大幅度晋升。例如：xxx 的老婆是？xxx 奥特曼的体重是多少？北京的面积是多少？
除了事实性问答，小布助手还能够利用图谱的推理能力实现一些简单问答：例如：xxx 和 xxx 是什么关系？OPPO 公布的第一款手机是什么？xxx 和 xxx 独特参演的电影有哪些？出世在 xx 的双子座明星有哪些？
因为常识图谱存在规模宏大的半结构化数据，而且数据之间存在很多的关联关系，应用关系型数据库是无奈满足存储和查问要求的，而图数据库恰好可能解决大规模图谱存储和多跳查问的挑战。
5.2 内容标签
在一些举荐场景中，须要了解视频、音频或文本的内容，给其打上和内容相干的标签。例如在短视频举荐中，了解视频的内容有利于对用户进行精准举荐。
对于影视类视频，将演员、影视节目、表演角色结构成一个影视娱乐图谱，当有新的影视类短视频公布时，能够通过视频中人脸识别出演员、题目或字幕中辨认出影视角色，利用图谱疾速推理出对应的影视作品，给视频打上内容标签，从而晋升举荐成果。
5.3 数据血统
在数仓中，常常须要运行各种 ETL Job，数据表和工作十分多，如何直观的察看数据表上下游与工作之间的关系变成一个亟需解决的问题。
应用关系型数据库解决多层级的关联查问十分麻烦，不仅开发工作量大，而且查问性能极慢。而应用图数据库，不仅大大减少了开发工作量，而且可能疾速的查出表的上下游关系，便于直观察看数据的血缘关系。
5.4 服务架构拓扑
在服务资源管理中，业务资源会分为多个层级，每个层级上面有对应的服务器、服务和管理人员，如果应用关系数据库来解决，当须要展现多级资源的时候，查问会很麻烦，性能会很差。这个时候，能够将资源、管理人员、服务器、业务层级之间的关系放到图数据库中，展现的时候，一条查问语句就能搞定，查问速度还很快。
6 总结
通过常识图谱等业务实际落地，实现了从 JanusGraph 向 NebulaGraph 的转变，导入性能晋升了一个数量级，查问性能以及并发能力都有 3-6 倍的晋升。而且，NebulaGraph 比 JanusGraph 更稳固。在实际的过程中，也遇到过很多问题，失去了 NebulaGraph 社区十分多的帮忙，非常感激社区的反对！
图数据库在最近这几年倒退很快，Neo4J 往年上半年融资 3.25 亿美金，刷新了数据库的融资记录。Gartner 公布的报告指出：“到 2023 年，图技术将促成寰球 30% 企业的疾速决策场景化。图技术利用的年增长率超过 100%。”随着 5G 和物联网的遍及，图数据库将成为解决关系的基础设施。
7 参考文档
1. 数据结构: 什么是图：
https://blog.csdn.net/dudu333…
2.NebulaGraph 架构总览：
https://docs.nebula-graph.com…
3. 越来越火的图数据库到底是什么？
https://www.cnblogs.com/manto…
4. 图的利用场景:
https://help.aliyun.com/docum…
5. 最全的常识图谱技术综述：
https://www.sohu.com/a/196889…
6.KBQA 从入门到放弃：
https://www.sohu.com/a/163278…
7.graphdb-benchmarks：
https://github.com/socialsens…
8. 支流开源分布式图数据库 Benchmark：
https://discuss.nebula-graph….
9. 图数据库 LightGraph 测试报告：
https://zhuanlan.zhihu.com/p/…
10.TigerGraph 官网测试：
https://www.tigergraph.com.cn…
11.GalaxyBase 官网测试：
https://blog.csdn.net/qq_4160…
作者简介
Qirong OPPO 高级后端工程师
次要从事图数据库、图计算及相干畛域的工作。
获取更多精彩内容，扫码关注 [OPPO 数智技术] 公众号
