RedisGraph 1.0 基准测试：更新

引言

在我们发布最近的 RedisGraph 基准测试结果后，TigerGraph 的人对此发表了一些看法。我们感谢听到竞争对手的观点，但想回应他们关于假新闻的指控。

在我们的博文中，我们介绍了一个并行请求基准测试。此测试与 TigerGraph 创建的K 跳邻居计数查询测试相同，但在我们的测试中，我们有 22 个客户端同时对 RedisGraph 执行查询。我们引入并发请求测试是因为我们认为它代表了几乎所有实时、实际场景。

我们发布的结果衡量了 RedisGraph 针对 300 个种子的整体基准测试时间。这是从提交第一个查询到最后一个查询返回所花费的时间。然而，对于 TigerGraph，我们推断了整体基准测试时间，而不是执行基准测试。我们错误地假设在此并发测试中可以看作请求在 TigerGraph 中是顺序执行的，因为我们观察到 TigerGraph 中的某些查询会占用机器的所有 32 个核心。我们首次发布的 TigerGraph 整体基准测试时间结果是基于 TigerGraph 已发布的平均查询时间乘以种子总数。

我们承认这是一个不公平的假设，因此我们决定对 TigerGraph 执行完整的基准测试。

并行请求的整体基准测试时间

发布结果：2018 年 11 月

为了方便起见，下面是我们最初发布的结果。 下表中显示的时间是整体基准测试时间（对于 RedisGraph，这些是测量的；对于 TigerGraph，如上所述是推断的）。

新测量结果：2019 年 1 月

以下数字表示我们最近为 TigerGraph 测量的整体基准测试时间。

虽然我们发现 RedisGraph 仍然比 TigerGraph 快，但新数据显示我们快 5-15 倍（与我们最初发布的 6-65 倍估算值不同）。最大的变化在于一跳查询，而对于更长路径的查询，时间略有减少。这是由于一跳查询在计算上远低于多跳查询，因此允许更高的并发性。但引用 TigerGraph 的话：“在现实世界中，如果你只需要进行一跳查询，键值数据库或 RDBMS 就足够了；你不需要图产品。”

并行请求的平均查询时间

除了整体基准测试时间，我们还想发布并行请求基准测试的平均查询时间，因为整体基准测试时间实际上并非此测试的最佳度量标准。这是因为对于 22 个并行请求而言，种子（300）的数量太少。例如，如果运行时间最长的查询是作为最后一个查询提交的，那么其他 21 个客户端将处于空闲状态，这会对整体基准测试时间产生负面影响。

更正确的度量标准是平均查询时间，它对所有 300 个种子的各个响应时间进行平均。理想情况下，我们不会将前 22 个和后 22 个响应时间包含在此平均值中，但由于种子的数量已经很少，我们选择保留它们。下面是我们在 RedisGraph 和 TigerGraph 中测量的平均查询时间。这些是新结果，未包含在我们首次发布的基准测试中，我们没有使用任何推断来确定下面的时间结果。

这表明在并行负载下，RedisGraph 的平均查询时间比 TigerGraph 快 5-20 倍。我们认为这才是对我们的 RedisGraph 用户真正重要的——一个能够以最低延迟实现最高吞吐量的数据库。

此外，我们将对 TigerGraph 最初创建的基准测试代码的修改开放给所有人，并记录了一个关于我们的可变长度路径查询行为的已知问题。我们还想确认，我们最初的博文中发布的非针对 TigerGraph 或 RedisGraph 的任何结果，均是 TigerGraph 最初发布的结果——没有提供任何优化（或“作弊”）。是的，除了 RedisGraph，TigerGraph 是另一个在任何测试中都没有超时的解决方案。