简单地说,我们现在是Redis

了解更多

RedisTimeSeries版本1.2基准测试

测试我们新发布的产品的性能RedisTimeSeries1.2模块中,我们使用了时间序列基准套件(tsb).TSBS是一个Go程序的集合,它基于由inflxdb和TimescaleDB公开的工作,旨在让开发人员生成数据集,然后对读写性能进行基准测试。万博最新版本下载苹果ag万博下载TSBS支持许多其他时间序列数据库,这使得比较数据库变得很简单。

有关RedisTimeSeries 1.2的更多信息,请参见RedisTimeSeries版本1.2在这里

本文将深入探讨基准测试过程,但关键是要记住:RedisTimeSeries非常快……非常快!这使得RedisTimeSeries到目前为止是Redis中处理时间序列数据的最佳选择:

    1. 压缩不会降低性能如果shard没有被CPU绑定。
    2. 当基数增加时,性能不会降低(请参见下面的note)。
    3. 在时间序列中添加更多的样本不会降低性能。
    4. 与1.0版本相比,RedisTimeSeries 1.2可以将查询延迟提高50%,吞吐量提高70%。查询越复杂,获得的性能就越大。

为了比较RedisTimeSeries 1.2和版本1.0.3,我们选择了三个数据集:前两个数据集每个时间序列的样本数量相同,但基数不同。

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

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

基准基础设施

性能基准在Amazon Web Services实例上运行,通过Redis的基准测试基础设施提供。基准测试客户端和数据库服务器都运行在单独的c5.24xlarge实例上。这些测试的数据库运行在一台安装了Redis Enterprise 5.4.10-22版本的机器上。万博体育彩数据库由10个主碎片组成。

除了这些主要的基准测试/性能分析场景外,我们还支持在网络、内存、CPU和I/O上运行基准测试,以便了解底层网络和虚拟机特征。我们将基准测试基础架构表示为代码,这样它就稳定且易于复制。

摄入标准

下表比较了三个数据集的RedisTimeSeries版本1.0.3和新版本1.2之间的吞吐量。您可以看到两个版本之间的差异是最小的。但是,我们引入了压缩,这额外消耗了5%的CPU周期。由此,我们可以得出结论,如果碎片不受CPU限制,那么就存在压缩不会降低吞吐量

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

在摄取阶段监视吞吐量的Grafana仪表板的屏幕截图。
在摄取阶段监视延迟的Grafana仪表板的屏幕截图。
Grafana仪表盘监控Redis消耗的内存的截图。

查询性能

TSBS包括一系列不同的读查询。下面的图表表示了RedisTimeSeries版本1.0.3和版本1.2之间多范围查询的查询速率和查询延迟的比较。它们表明查询延迟可以提高50%,吞吐量可提高70%,根据查询复杂度、访问次数来计算响应时间序列,以及查询时间范围。一般来说,查询越复杂,获得的性能就越明显。

这种行为是由于压缩和API的更改。因为更多的数据适合更少的内存空间,所以回答相同的查询需要更少的内存访问块。类似地,更改API不返回每个时间序列的标签的默认行为,将大幅减少每个时间序列的负载和总体CPU时间TS.MRANGE命令。

内存利用率

在RedisTimeSeries 1.2中增加了压缩功能,这使得比较这三个数据集中的内存利用率变得很有趣。在这个基准测试中,所有三个数据集的内存消耗都减少了94%。当然,这是一个实验室设置,在固定的时间间隔中生成时间戳,这是双增量压缩的理想选择(有关双增量压缩的更多信息,请参阅RedisTimeSeries版本1.2在这里!.如前所述,内存减少90%对于真实世界的用例来说是很常见的。

RedisTimeSeries非常快

当我们去年夏天推出RedisTimeSeries时,我们基准测试它反对时间序列建模选项与普通数据结构在Redis,如排序集和哈希或流。在内存消耗方面,它已经超过了除Streams之外的其他建模技术,后者消耗的内存是RedisTimeSeries的一半。随着Gorilla压缩的引入(更多内容在本文中:RedisTimeSeries版本1.2在这里!)到目前为止,RedisTimeSeries是Redis中保存时间序列数据的最好方法

除了证明压缩不会导致性能下降之外,基准测试还表明,在时间序列中没有基数或样本数量的性能下降。所有这些特征的组合在时间序列数据库景观中是独一无二的。再加上它极大地提高了读取性能,您肯定想亲自检查一下RedisTimeSeries。

最后,值得注意的是,时间序列基准系统是丰富的,并且由社区驱动的——我们很高兴成为其中的一员。在RedisTimeSeries 1.2中,拥有基准测试的共同基础已被证明对消除性能瓶颈和强化每个解决方案具有极大的价值。我们已经开始有助于更好地理解TSBS上的延迟和应用程序响应,并计划对当前基准进行进一步扩展。

Baidu