RedisTimeSeries 版本 1.2 基准测试

为了对我们新发布的 RedisTimeSeries 1.2 模块的性能进行基准测试，我们使用了时间序列基准测试套件 (TSBS)。TSBS 基于 InfluxDB 和 TimescaleDB 公开的工作，是一组基于 Go 的程序，旨在让开发人员生成数据集，然后对读写性能进行基准测试。TSBS 支持许多其他时间序列数据库，这使得数据库比较变得简单。

有关 RedisTimeSeries 1.2 的更多信息，请查看 RedisTimeSeries 版本 1.2 发布了！

这篇文章将深入探讨基准测试过程，但要记住关键的一点：RedisTimeSeries 速度很快……真的很快！ 这使得 RedisTimeSeries 成为在 Redis 中处理时间序列数据的最佳选择：

1. 如果分片没有受到 CPU 限制，则压缩不会导致性能下降。
2. 当基数增加时，性能不会下降（见下文注释）。
3. 当您向时间序列添加更多样本时，性能不会下降。
4. 与版本 1.0 相比，RedisTimeSeries 1.2 可以将查询延迟提高高达 50%，并将吞吐量提高高达 70%。 查询越复杂，性能提升就越大。

为了将 RedisTimeSeries 1.2 与版本 1.0.3 进行比较，我们选择了三个数据集：前两个数据集在每个时间序列中具有相同的样本数量，但在基数方面有所不同。

注意：时间序列数据集的最大基数定义为数据集在任何给定时间点可以包含或引用的不同元素的最大数量。例如，如果一个智慧城市有 100 个物联网 (IoT) 设备，每个设备报告 10 个指标（空气温度、二氧化碳水平等），分布在 50 个地理位置，那么这个数据集的最大基数将是 50,000 [100（设备 ID）x 10（指标 ID）x 50（地理位置 ID）]。

我们选择这两个数据集是为了针对基数对查询/摄取性能进行基准测试。第三个数据集的基数与第一个数据集相同，但每个时间序列中的样本数量是第一个数据集的三倍。该数据集用于对摄取时间与时间序列中样本数量之间的关系进行基准测试。

基准测试基础设施

性能基准测试是在亚马逊网络服务实例上运行的，这些实例通过 Redis 的基准测试基础设施进行配置。基准测试客户端和数据库服务器都在独立的 c5.24xlarge 实例上运行。这些测试的数据库在一个安装了 Redis Enterprise 版本 5.4.10-22 的单台机器上运行。该数据库由 10 个主分片组成。

除了这些主要基准测试/性能分析场景之外，我们还启用在网络、内存、CPU 和 I/O 上运行基准测试，以了解底层网络和虚拟机特征。我们将我们的基准测试基础设施表示为代码，使其稳定且易于复制。

摄取基准测试

下表比较了 RedisTimeSeries 版本 1.0.3 和新版本 1.2 在所有三个数据集上的吞吐量。您可以看到，这两个版本之间的差异很小。但是，我们引入了压缩，这消耗了 5% 的额外 CPU 周期。由此可以得出结论：如果分片没有受到 CPU 限制，则压缩不会导致吞吐量下降。

下面的三个图像跟踪了摄取第三个（也是最大）数据集时的吞吐量、延迟和内存消耗。我们在不到两个小时的时间里，将 8 亿个样本插入到单个数据库中。这里重要的是，时间序列中样本数量增加时，延迟和吞吐量不会下降。图表最后一行比较了前两个数据集的吞吐量。几乎没有区别，这说明当基数增加时，性能不会下降。大多数其他时间序列数据库在基数增加时性能会下降，因为它们使用的底层数据库和索引技术。

查询性能

TSBS 包含一系列不同的读取查询。下面的图表表示比较了 RedisTimeSeries 版本 1.0.3 与版本 1.2 的多范围查询的查询速率和查询延迟。它们表明查询延迟可以提高高达 50%，吞吐量可以提高高达 70%，具体取决于查询复杂性、计算响应所需访问的时间序列数量以及查询时间范围。总的来说，查询越复杂，性能提升就越明显。

这种行为是由于压缩和 API 更改造成的。由于更多数据可以容纳在更少的内存空间中，因此需要更少的内存块访问才能回答相同的查询。同样，API 默认行为的更改（不返回每个时间序列的标签）导致每个TS.MRANGE命令的负载和整体 CPU 时间大幅减少。

内存使用率

RedisTimeSeries 1.2 中添加的压缩功能使得比较这三个数据集的内存使用率很有趣。结果是这三个数据集的内存消耗在该基准测试中减少了 94%。当然，这只是一个实验室设置，其中时间戳是在固定的时间间隔内生成的，这非常适合双增量压缩（有关双增量压缩的更多信息，请查看RedisTimeSeries 版本 1.2 发布了！)。如前所述，对于实际用例，内存减少 90% 是一种常见的现象。

RedisTimeSeries 速度很快

我们在去年夏天推出 RedisTimeSeries 时，对其进行了基准测试，与使用 Redis 中普通数据结构（如排序集和散列或流）的时间序列建模选项进行了比较。在内存消耗方面，它已经超过了除了流之外的其他建模技术，流消耗了 RedisTimeSeries 一半的内存。随着 Gorilla 压缩的引入（有关详细信息，请查看这篇文章：RedisTimeSeries 版本 1.2 发布了！），RedisTimeSeries 是在 Redis 中持久化时间序列数据的最佳方式。

除了证明压缩不会导致性能下降之外，基准测试还表明基数或时间序列中样本数量不会导致性能下降。所有这些特征的结合在时间序列数据库领域是独一无二的。再加上显著提升的读取性能，您一定很想自己试用一下 RedisTimeSeries。

最后，需要指出的是，时间序列基准测试生态系统丰富且由社区驱动——我们很高兴成为其中的一部分。拥有一个通用的基准测试平台已被证明对消除性能瓶颈和加强 RedisTimeSeries 1.2 中的每一个解决方案都具有极其重要的意义。我们已经开始为更好地理解 TSBS 上的延迟和应用程序响应性做出贡献，并计划提出对当前基准测试的进一步扩展。