图数据库选型

做图谱不可避免需要到图数据库，但是如何选择一个适合的图数据库，是一个问题，这篇文章是基于前人做的对比评测，希望能让大家对目前主流的图数据库由大致了解。仅为一家之言，如有偏驳，请指正。

文章会出现横向扩展和纵向扩展概念，横向扩展也叫水平扩展，用更多的节点支撑更大量的请求，如成千上万的蚂蚁完成一项搬运工作，也就是多增加几台服务器一起服务。纵向扩展也叫垂直扩展，扩展一个点的能力支撑更大请求，如蜘蛛侠逼停火车，也就是把服务器换成性能更好的机器。

美团评测

1.1前言

美团图谱业务数据量点边总数可达千亿以上，吞吐量可达数万QPS(每秒查询率)，结合业务现状，制定了选型的基本条件：

1.开源项目。

2.支持集群模式，具备存储和计算的横向扩展能力。

3.具备毫秒级多跳查询能力。

4.具备批量导入数据能力。

但Neo4j、ArangeDB、Virtuoso等一些数据库不支持多节点，不能横向扩展存储。无法满足大规模图谱数据的需求。对比实验选择了Nebula(原阿里团队创业开发)、Dgraph(原Google团队创业开发)、HugeGraph(百度团队开发)。

1.2硬件配置

数据库实例：运行在不同物理机上的Dokcer容器

单实例资源：32核心、64G内存，1TB SSD存储。【Intel® Xeon® Gold 5218 CPU @ 2.30GHz】

实例数量：3

1.3测评数据集

 

实体情况：4类实体、总数26亿

关系情况：19类关系、总数177亿

数据格式：csv

1.4导入测试结果

1.4.1数据分析

Nebula：数据存储分布方式是主键哈希，各节点存储分布基本均衡。导入速度快，存储放大比最优。

Dgraph：数据存储分布为三元组谓词，同一种关系只能保存在一个数据节点上，导致存储和计算严重偏斜。

HugeGraph：导入数据，先写满了一个节点1000G的磁盘，造成导入失败，无法导入全量数据。存储放大比最大，同时有严重的数据倾斜。

1.5实时写入测试

 1.5.1数据分析

Nebula：数据存储分布方式是主键哈希，各节点存储分布基本均衡。写入请求可以由多个存储节点分担，因此响应时间和吞吐量大幅领先

Dgraph：数据存储分布为三元组谓词，同一种关系只能保存在一个数据节点上，吞吐量较差。

HugeGraph：存储后端基于HBase，实时并发读写能力低于RocksDB(Nebula)和BadgerDB(Dgraph)，因此性能最差。(这里的RocksDB、BadgerDB均为数据仓库)

1.6 数据查询测试

N跳返回ID

 

N跳返回属性

1.7讨论

有人提到HugeGraph的数据仓库HBase表需要做预分区。经过预分区处理之后，使用比美图评测较差的配置，单task顶点都有几千的QPS(每秒查询率)。

2.腾讯云评测

2.1前言

比较对象：Neo4j，Neo4j是目前业界广泛使用的图数据库，包含社区版和商用版本，测评使用的是社区版。HugeGraph，HugeGraph是百度基于JanusGraph改进而来的分布式图数据库，具有良好的读写性能。Nebola，原阿里团队开发，数据负载均衡，读写速度快。

2.2测试硬件配置

 2.3性能对比

使用不同量级的图从入库时间，一度好友查询，二度好友查询，共同好友查询几个方面进行对比。

2.4讨论

Q:数据集是什么？

A:腾讯云所用的数据集为内部脱敏关系数据，分布如下(将50度以上的结果截断)。

Q：neo4j延迟怎么会这么慢？1000w条边，260G内存，都可以全缓存，为什么一度查询需要6s？

A:测试neo4j的时候使用推荐内存大小，但是测试几次仍稳定在6s左右，可能解释说查询时间是指图中的37ms，实验中记录的都是控制台显示结果的时间，故记录6s

3.Neo4j性能测评

3.1前言

测试的查询和修改均为查询出一条边和修改一条边，并且数据的量级也是基于边的关系，而节点是从这些边中抽取出来之后加上随机属性。以下结果都是基于一度查询，并没有做复杂查询。

3.2 测试配置

3个节点，每台配置差不多

CPU： Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz

内存：total：256G，available：249G

磁盘：size：12T，Avail：12T

数据：通过随机函数随机生成的通话记录数据

3.3测试方法

使用neo4j框架，每次查出相应的关系数据然后，根据关系数据现在的值对其进行更改，然后保存，查询为一条一条地查询，但是保存为每一个事务批次保存100条数据。每次查询与保存的之前和之后都获取时间戳，然后进行相减，对产生的时间段进行累加。

3.4 100万关系数据测试

导入数据时间:7s464ms

数据节点：1,967,732nodes、1,000,000relationships、7,870,928properties

Memory：1.02GB

1.没有索引的情况下：

2.有索引查询3级好友：

3.5一千万关系数据测试

导入数据时间：38s437ms

数据节点：18,260,878nodes、10,000,000relationships、18,260,878properties

Peak memory usage:1.21GB

1.没有索引的情况下：

2.有索引查询：

数据大小：

3.6一亿关系数据测试

导入数据时间：2m 52s 428ms

数据节点：136,004,833nodes、100,000,000rel、544,019,332properties

Peak memory usage:2.52GB

1.没有索引的情况下：

2.有索引查询：

数据大小：

 3.7十亿关系数据测试

导入数据时间：19m 57s 543ms

数据节点：586,648,101 nodes、1,000,000,000rel、2,346,592,404properties

Peak memory usage:7.56GB

1.没有索引的情况下：

2.有索引查询：

数据大小：

 3.8结果对比图：

更多细节，请参考链接原文。

4.贝壳评测

4.1前言

贝壳主要关注以下几个方面：开源、成熟度、可扩展性、文档丰富度、性能、稳定性、运维成本、易用性。其中运维成本是比较容易忽视的，但做技术选型时必须考虑清楚，每种选型的运维成本是否是可接受的，投入产出比是否值得。

贝壳的数据量为480亿量级的三元组。

贝壳选择了JanusGraph和Dgraph进行测评对比。因为他们发展较晚，从设计之初就考虑分布式和扩展性，对分布式支持很好。

4.2测评结果

在48核、128G内存、SATA硬盘的三台物理机环境，4800万个点、6300万条边、4.5亿三元组、总计30G的数据集下进行性能对比测试：

1.写入性能，主要考虑实时写入和初始化写入两种，这两种方法Dgraph的性能优于JanusGraph。

2.查询性能，简单查询场景下，性能差距不大。查询越复杂，Dgraph查询性能稳定并且优于JanusGraph。

如上图所示，Dgraph是完全优于Janusgraph，因此选择了Dgraph。之后做图数据库的集群。

5.总结

从以上的评测结果可以看出，当数据量在一亿，基本大部分主流的图数据库都可以选择，因此，Neo4j等主流的图数据库可以选择使用。当数据量在一亿到十亿级时，主要考虑Nebula或者Dgraph等分布式图数据库。更大数据量时则需要将图数据库扩展到集群。

但是也要注意到，美团和腾讯云发布在Nebula论坛上，评测可能会偏向于Nebula。同时，Neo4j的评测都是一度查询，并未做更为复杂的查询操作。所以实际上的业务场景所需要的时间可能更多。贝壳的评测信息较少，只知道数据量并不知道配置以及其他信息。

参考资料

1.美图主流开源分布式图数据库Benchmark :  https://discuss.nebula-graph.com.cn/t/topic/1377

2. 腾讯云图数据库对比：https://discuss.nebula-graph.com.cn/t/topic/1013

3. 什么是横向扩展、纵向扩展：https://blog.csdn.net/qq_44836294/article/details/107643605

4.数据库排行榜：https://db-engines.com/en/ranking/graph+dbms

5. Neo4j测评：https://blog.csdn.net/sinat_35045195/article/details/96488579

6. 贝壳评测：https://www.modb.pro/db/27286