RedisTimeSeries 1.0 发行说明

下采样 / 压缩。二级索引。读取时聚合。与 Prometheus、Grafana 和 Telegram 集成。

要求

RedisTimeSeries v1.0.3 需要：

• 最低 Redis 兼容版本（数据库）：5.0.0
• 最低 Redis 企业软件版本（集群）：5.4.0

v1.0.3（2019 年 9 月）

更新紧急度：中

这是版本 1.0 的维护版本。

此版本提高了整体稳定性，并修复了在上一版本之后发现的问题。

主要特点：

• #143 聚合的标准差
• #163 TS.RANGE和TS.MRANGE可以通过可选COUNT旗
• #161 支持 ARM 架构
• #160 个可选TIMESTAMP在TS.INCRBY和TS.DECRBY

主要修复：

• #199 RETENTION现在是 64 位
• #211 写入命令，当 redis 达到最大内存时返回 OOM 错误

主要性能改进：

• #3651 请勿使用_union如果索引中只有 1 个叶子
• #0a68 通过迭代左 dict（始终较小）使_difference更快

v1.0.1（2019 年 7 月）

更新紧急程度：次要

这是版本 1.0 的维护版本。

当过滤器由 k=v 谓词列表组成时，二级索引应该工作得更快。

v1.0.0（2019 年 6 月）

这是 RedisTimeSeries 的正式发布版本！在此处阅读完整案例

特征

在 RedisTimeSeries 中，我们引入了一种新的数据类型，该数据类型将固定大小的内存块用于时间序列样本，由与 Redis Streams 相同的基数树实现编制索引。使用 Streams，您可以创建一个 [capped stream]（/commands/xadd/），从而有效地按计数限制消息数量。在 RedisTimeSeries 中，您可以应用以毫秒为单位的保留策略。这更适合时间序列使用案例，因为它们通常对给定时间窗口内的数据感兴趣，而不是对固定数量的样本感兴趣。

下采样/压缩

如果您想无限期地保留所有原始数据点，您的数据集将随着时间的推移线性增长。但是，如果您的使用案例允许您拥有更远的更早的精细数据，则可以应用缩减采样。这允许您使用给定聚合函数聚合给定时间窗口的原始数据，从而保留更少的历史数据点。RedisTimeSeries 支持使用以下聚合进行下采样：avg、sum、min、max、range、count、first 和 last。

二级索引

使用 Redis 的核心数据结构时，您只能通过知道保存时间序列的确切键来检索时间序列。遗憾的是，对于许多时间序列使用案例（例如根本原因分析或监控），您的应用程序不会知道它要查找的确切键。这些使用案例通常希望查询一组在几个维度中彼此相关的时间序列，以提取您需要的见解。您可以使用核心 Redis 数据结构创建自己的二级索引来帮助解决这个问题，但这将带来高昂的开发成本，并且需要您管理边缘情况以确保索引正确。

RedisTimeSeries 根据field value您可以添加到每个时间序列的对（也称为标签），并在查询时用于筛选（这些筛选条件的完整列表可在我们的文档中找到）。以下是创建具有两个标签（sensor_id 和 area_id 分别是值为 2 和 32 的字段）和 60000 毫秒保留时段的时间序列的示例：

TS.CREATE temperature RETENTION 60000 LABELS sensor_id 2 area_id 32

Aggregation at read time

127.0.0.1:6379> TS.RANGE temperature:3:32 1548149180000 1548149210000 AGGREGATION avg 5000
1) 1) (integer) 1548149180000
   2) "26.199999999999999"
2) 1) (integer) 1548149185000
   2) "27.399999999999999"
3) 1) (integer) 1548149190000
   2) "24.800000000000001"
4) 1) (integer) 1548149195000
   2) "23.199999999999999"
5) 1) (integer) 1548149200000
   2) "25.199999999999999"
6) 1) (integer) 1548149205000
   2) "28"
7) 1) (integer) 1548149210000
   2) "20"