基于LDBC-SNB基准的图数据库性能比较：TigerGraph vs Dgraph

点击上方蓝字关注我们，实时跟进最新技术

我们在不同规模的LDBC-SNB数据集上对TigerGraph和Dgraph进行了性能测试，主要结论如下：

• 加载数据时，TigerGraph比Dgraph Bulk快2到4倍，比Dgraph Live快9到30倍。

• 运行复杂程序时，TigerGraph的只读查询速度是Dgraph的2到3000倍。

• 运行最短的只读查询时，TigerGraph大约比Dgraph快2到2000倍。

• 运行简短的只读查询时，TigerGraph的响应时间不随数据集大小的增加而波动，而Dgraph的响应时间则随数据集大小的增加而波动。

• 运行大多数商业智能工作负载时，TigerGraph的速度大约是Dgraph的2到1600倍。

• 随着数据集大小和查询复杂度的增加，TigerGraph的查询响应时间增加了2～5倍，而Dgraph的查询响应时间增加了14倍以上。

综上，在我们的测试中，TigerGraph在数据加载及查询方面效率高于Dgraph。

本次测试的相关配置为：

LDBC（The Linked Data Benchmark Council）是图和RDF数据管理的基准指南制定者。LDBC遵循GPLv3的开源思想，可以在https://github.com/ldbc上可以找到其相关基准规范、用于评估基准的软件、工具和源代码、问题沟通及其他技术文件。

社交网络基准（SNB）是LDBC开发的软件基准之一。LDBC SNB将通过两种典型场景来评估图形数据库或图形数据管理技术：

• 交互场景，即事物查询任务，类似OLTP；

• 商业智能场景，即统计查询任务，类似OLAP。

SNB具有三种类型的工作负载：

• IS：简单只读查询任务，是相对简单的路径遍历，最多从原点两跳访问顶点；

• IC：复杂只读查询任务，查询超出两个跃点的路径，计算简单的聚合，而不只是返回数据；

• BI：商务智能类任务，查询访问图中更广泛的部分，它的遍历不是从一个源开始，而是从图中的多个点开始的。

我们的测试将运行超过2000秒的1次、运行超过500秒的查询10次并报告平均结果、运行小于500秒的查询50次并获得平均结果。

3.1 Schema

图3.1：LDBC-SNB Schema

Schema是根据实体及其关系定义benchmark中使用的数据结构。图3.1显示了我们测试中使用的数据模式，包括个人、组织和地点等实体。该模式模拟了人与人之间的互动方式（与其他人建立的朋友关系），模拟了一些内容共享，诸如消息（文本和图像）、对消息的回复、喜欢的消息等。人们还组成小组讨论特定的话题，我们将这些话题用标签来表示。

3.2 数据集

我们在测试中使用了三个规模的数据集：SF-1、SF-10和SF-100。每个数据集的大小如表3.1所示。

表3.1：数据集大小

3.3 任务

在测试中我们使用了LDBC-SNB定义的三种类型的查询工作负载：

• 简单交互查询（IS）：在测试中我们运行了6个简短的只读查询

• 复杂交互查询（IC）：在测试中我们运行了12个复杂的只读查询

• 商业智能查询（BI）：在测试中我们运行了12个复杂的查询

4.1 Loading Functionality

为了理解如何优化每个图数据库的加载，在考虑查询性能之前，有必要比较图数据库的加载功能。

TigerGraph提供了一种声明性的加载语言，允许用户指定加载作业，它将自动创建RESTful端点。然后，用户可以通过gsqlshell或通过向RESTful服务器提交HTTP请求来运行作业。在其他数据访问服务运行时，所有加载作业联机进行。此测试采用RESTful接口的直接调用。

在Dgraph中，Live Loader和Bulk Loader都可以用于快速数据加载。Bulk Loader比Live Loader快得多，但Bulk Loader只能用于将数据加载到新的集群中。这意味着如果Dgraph中已经有数据，用户只能使用Live Loader来加载数据。

我们在此次测试中对这两种方法都进行了测试。

4.2 Loading Times

表4.1：SF-1, SF-10, SF-100的加载用时

为方便比较不同加载方式的耗时差异，这里以TigerGraph的加载时间为基底，标准化三种加载方式的加载时间，并绘制图4.1。

图 4.1: 不同加载方式的加载用时（以TigerGraph为基底进行标准化；t/o 表示24h内未完成加载任务）

在加载SF-100数据集时，Dgraph Live Loader未能在24小时内完成加载。通过此次对加载数据任务的测试，可以看到随着数据集大小的增加，TigerGraph比Dgraph Bulk快2到4倍，比Dgraph Live快9到30倍。

5.0 未实现的查询

截止测试结束日期（2020-10-01）。

在LDBC-SNB中，IC、IS和BI系列分别有14、7和25个查询，Dgraph的查询语言GraphQL+-无法实现的查询有2个、1个和13个，其无法完成查询的原因如下：

而用TigerGraph可以实现所有的查询任务，因此在接下来的比较分析中，我们只选取Dgraph可以完成的查进行比较。

5.1 IC系列查询

复杂交互查询（IC）系列中有14个查询，Dgraph未能完成查询IC10和IC14。表5.1给出了在SF-1、SF-10和SF-100数据集上Dgraph和TigerGraph在剩余11个查询上的响应时间。

表5.1：IC系列查询用时(s)

为了让TigerGraph和Dgraph的查询耗时差异比较更加清晰直观，我们以TigerGraph的查询用时为基底，对表5.1中的查询用时作标准化处理，然后绘制图5.1。

图5.1：IC系列查询用时（以TigerGraph为基底进行标准化）

从图5.1可以看出：

• 数据集大小增加时，在Dgraph上运行的一些查询的响应时间呈指数级增长，而TigerGraph的响应时间仅略有增加。在大数据集上，TigerGraph的查询效率远高于Dgraph；

• 大多数情况下，TigerGraph对查询的响应速度是Dgraph的2倍。

5.2 IS系列查询

简单交互查询（IS）系列中有7个查询，Dgraph未能完成查询IS2。表5.2给出了在SF-1、SF-10和SF-100数据集上Dgraph和TigerGraph完成剩余6个查询上的响应时间。

表5.2：IS系列查询用时(s)

从图5.1和图5.2可以看出，当数据量增加10倍和100倍时，Dgraph的查询响应时间会成倍增加，相比之下TigerGraph的表现较为平稳，从侧面表明Dgraph可能不适合用于大型数据集。

图5.2：IS系列查询用时（以TigerGraph为基底进行标准化）

从图5.2可以看出：

• TigerGraph的查询响应时间受数据集大小的影响较小；

• Dgraph可能不适用于大型数据集；

• 大多数情况下，TigerGraph的查询响应时间比Dgraph快2到2000倍。

5.3 BI系列查询

商业智能查询（BI）系列中有25个查询，Dgraph未能完成的查询有13个。表5.3给出了在SF-1、SF-10和SF-100数据集上Dgraph和TigerGraph在剩余12个查询上的响应时间。

表5.3：BI系列查询用时(s)

尽管BI系列的查询比IS系列的查询复杂得多，但根据图5.3，我们依然可以得出同样的结论：Dgraph可能不适合超大数据集，因为它在大规模数据集上的表现远不如TigerGraph。

图5.3：BI系列查询用时（以TigerGraph为基底进行标准化）

从图5.3中可以看出：

• 大多数情况下，TigerGraph的查询响应时间大约是Dgraph的2到1600倍

BI查询序列比IS和IC需要更多的统计计算。我们想知道TigerGraph和Dgraph是否因为统计计算而增加了查询响应时间，因此选取三个不同数据大小的查询序列，计算它们的平均响应时间，以此来绘制图5.4。

图5.4：不同数据集大小的平均查询响应时间(s)

如图5.4所示，随着数据集规模和查询复杂度的增加，TigerGraph的查询响应时间增加了2-5倍，但最大平均查询响应时间仅为15.6s；而Dgraph的最大平均查询响应时间则高达518.7s。

• 随着数据集大小和查询复杂度的增加，Dgraph的查询响应时间提高了14倍以上，TigerGraph的查询响应时间提高了2-5倍。

在最近的一项使用链接数据基准理事会社会网络基准的测试中，我们得到以下结论：

• 加载数据时，TigerGraph比Dgraph Bulk快2到4倍，比Dgraph Live快9到30倍；

• 当运行复杂程序时，TigerGraph的只读查询速度是Dgraph的2到3000倍；

• 当运行最短的只读查询时，TigerGraph大约比Dgraph快2到2000倍；

• 当运行简短的只读查询时，TigerGraph的响应时间不随数据集大小的增加而波动，而Dgraph的响应时间则随数据集大小的增加而波动；

• 在运行大多数商业智能工作负载时，TigerGraph的速度大约是Dgraph的2到1600倍；

• 随着数据集大小和查询复杂度的增加，TigerGraph的查询响应时间增加了2～5倍，而Dgraph的查询响应时间增加了14倍以上；

因此，在我们的测试中，TigerGraph在数据加载及查询方面效率高于Dgraph。