基于10亿+数据，HugeGraph与Nebula Graph的图遍历查询性能测试

随着社交、电商、金融、零售、物联网等行业的快速发展，现实社会织起了了一张庞大而复杂的关系网，亟需一种支持海量复杂数据关系运算的数据库即图数据库。本系列文章是学习知识图谱以及图数据库相关的知识梳理与总结

本文会包含如下内容：

• 基于friendster数据，对比测试HugeGraph与Nebula的图遍历查询性能

本篇文章适合人群：架构师、技术专家、对知识图谱与图数据库感兴趣的高级工程师

1. 环境准备及数据导入

在nebula，hugegraph单机版分别导入 friendster数据。 服务器版本是：CPU:  2 * Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz，内存：256GB， 硬盘：SAS盘

friendster数据集的统计信息如下：共有65608366个顶点，1806067135条边，约18亿+的数据量

测试基于导入的friendster数据进行。

环境搭建及数据导入，参见我之前的blog，地址如下：

图数据库hugegraph如何快速导入10亿+数据

Nebula Graph图数据的安装部署

图数据库Nebula Graph如何快速导入10亿+数据

2. 测试语句及性能

注意：

1. nebula如果要使用match语句，需要提前针对person创建索引，语句如下：

            create tag index indexPerson on person();

            rebuild tag index indexEntityName;

            索引创建完毕后，则能正常使用match语句

2. hugegraph rest api测试时，只写了请求路径，在实际测试中，需要在前面添加http://ip:port, 并将xxxgraph替换为实际的图名称

测试结论：

1. nebula与hugegraph针对业务上常用的图遍历查询【一二度好友、共同好友】都能在秒内返回

2. nebula的go语句的查询性能比match语句要好，match语句估计官方后续会持续优化，建议使用go语句

3. hugegraph基于REST API查询性能比使用gremlin语句要好，建议使用REST API.

图遍历类型	nebula go语句	nebula match语句	hugegraph gremlin语句	hugegraph rest api
一度好友	go from 969679 over friend yield friend._dst as vid 结果：35条 耗时：0.002s	MATCH (v:person)-[e:friend*1]->(p) where id(v)==969679 RETURN id(p) 结果：35条 耗时：0.011s	g.V(969679).outE().otherV() .valueMap('id') 结果：35条 耗时：0.047s	/graphs/xxxgraph/traversers/kout ?source=969679 &direction=OUT&max_depth=1 结果：35条 耗时：0.003s
二度好友	go 2 steps from 969679 over friend yield friend._dst as vid 结果：5645条 耗时：0.021s	MATCH (v:person)-[e:friend*2]->(p) where id(v)==969679 RETURN id(p) 结果：5645条 耗时：0.172s	g.V(969679).outE().otherV().outE() .otherV().valueMap('id') 结果：5645条 耗时：0.067s	/graphs/xxxgraph/traversers/kout?source=969679&direction=OUT &max_depth=2 结果: 5446条，因为针对结果去重， 耗时：0.029s
共同好友	go from 969679 over friend intersect go from 6109361 over friend 结果：1条 耗时：0.016s	MATCH (v:person)-[e:friend*1]->(p) where id(v)==969679 return id(p) intersect MATCH (v:person)-[e:friend*1]->(p) where id(v)==6109361 return id(p) 结果：1条 耗时：0.021s	g.V(969679).outE().otherV() .aggregate('x') .has('id',6109361).outE().otherV() .where(within('x')).dedup().valueMap('id') 结果：1条 耗时：0.008s	/graphs/xxxgraph/traversers/sameneighbors?vertex=969679&other=6109361 &direction=OUT&label=friend 结果: 1条 耗时：0.004s

3. 其它查询语句

针对kout，hugegraph的REST API提供了基础版和高级版两个版本，高级版使用POST请求，参数如下：

注意：

1. 如果将nearest参数修改为false,则数量是：5463，nearest参数解释如下：

     nearest为true时，代表起始顶点到达结果顶点的最短路径长度为depth，不存在更短的路径；

     nearest为false时，代表起始顶点到结果顶点有一条长度为depth的路径（未必最短且可以有环），选填项，默认为true

2. rest api的返回结果是去重的，所以数量上少一些（不去重是5645条）

{
    "source":969679,
    "step":{
        "direction":"OUT",
        "labels":[
            "friend"
        ]
    },
    "max_depth":1,
    "nearest":true,
    "with_vertex":false,
    "with_path":true,
    "limit":10000
}