一.时间序列数据

时间序列数据:没有严格的关系模型，记录的信息可以表示成键和值的关系。

(例如,一个设备ID对应一条记录）；

时间序列数据的读写特点

持续高并发写入，需要连续记录数万个设备的实时状态值
时序数据的写入主要就是插入新数据，而不是更新一个已经存在的数据
一个时间序列数据被记录后通常就不会变了，他就代表一个设备在某个时刻的状态值

写入特点简单，插入数据快，时间复杂度低，尽量避免阻塞。

时间序列数据的"读"操作特点：

单条记录查询（查询某个设备在某一时刻的运行状态信息）
对某个时间范围内数据的查询）（早上8点到10点范围内所有设备的状态信息）
聚合计算，某个时间范围内的数据做聚合计算（对符合查询条件的所有数据做计算，包括计算均值，最大值/最小值，求和等）

基于Hash和Sorted Set保存时间序列数据

Hsah和sorted set组合实现方式

好处：

Redis内在数据类型，代码成熟性能稳定--->基于这两个数据类型保存时间序列数据，系统稳定性可以预期。

缺点：使用了两种类型保存

为什么保存时间序列数据，需要同时使用两种类型

Hash类型：可以实现对单键的快速查询。满足时间序列数据的单键查询需求。

将时间戳作为Hash集合的key，把记录设备状态值作为Hash集合的value。

使用：查询某个时间点或多个时间点上温度数据，直接使用HGET或HMGET命令。

HGET device:temperature 202008030905
1) "25"HMGET device:temperature 202008030905 202008030906 202008030907
1) "25"
2) "26"
3) "27"

Hash类型实现单键查询简单，但是，不支持对数据进行范围查询。

时间序列数据是按时间递增顺序插入Hash集合中，但是Hash类型的底层结构是哈希表，并没有对数据进行有序索引。
对Hash类型进行范围查询，就需要扫描Hash集合中的所有数据，再将这些数据在客户端排序，这样能在客户端得到所查询范围内的数据。

Sorted Set

目的：支持按时间戳范围的查询，可以根据元素的权重分数来排序

实现：把时间戳作为Sorted Set集合的元素分数，把时间点上记录的数据作为元素本身。

以保存设备温度的时间序列数据为例：

ZRANGEBYSCORE命令：

根据输入的最大时间戳和最小时间戳来查询时间范围内的温度值

例如：查询2020-08-03 09:07到 09:10温度值

ZRANGEBYSCORE device:temperature 202008030907 202008030910
1) "25.9"
2) "24.9"
3) "25.3"
4) "25.2"

同时使用Hash和sorted Set，满足单个时间点和一个时间范围内数据查询的需求。

如何保证写入Hash和Sorted Set是一个原子性操作

原子性操作：我们在执行多个写命令操作时候，这些命令要么全部完成，要么都不完成。

为什么要保证原子性：

只有保证原子性，才能保证同一时间序列数据，在Hash和Sorted Set中，要么都保存要么都不保存，都和可能出现hash集合中有时间序列数据而sorted set中没有,产生异常数据。

Redis怎么保证原子性操作

Redis实现简单事务的MULTI和EXEC命令。

MULTI	一些列原子性操作开始，收到这个命令后，Redis知道，接下来在收到命令需要放到一个内部队列中。后续一起执行，保证原子性。
EXEC	一系列原子性操作的结束。一旦Redis收到这个命令，就表示所有要保证原子性的命令操作都已经发送完成。此时Redis开始执行刚才放到内部队列中的所有命令操作。

命令1到命令N是在MULTI命令后，EXEC命令前发送的，他们会被一起执行，保证原子性。

使用方式


127.0.0.1:6379> MULTI
OK127.0.0.1:6379> HSET device:temperature 202008030911 26.8
QUEUED127.0.0.1:6379> ZADD device:temperature 202008030911 26.8
QUEUED127.0.0.1:6379> EXEC
1) (integer) 1
2) (integer) 1

如何对时间序列数据进行聚合计算？

聚合计算使用场景：周期性的统计时间窗口内的数据汇总状态，在实时监控与预警场景下会频繁执行。

Sorted set只支持范围查询，无法直接进行聚合计算，所以只能把时间范围内的数据取回客户端，然后在客户端自行完成聚合计算。
大量数据在Redis实例和客户端间频繁传输，会和其他操作命令竞争网络资源，导致其他操作变慢。

RedisTimeSeries

RedisTimeSeries是Redis的一个扩展模块。
专门面向时间序列数据提供数据类型和访问接口。
支持在Redis实例上直接对数据进行按时间范围的聚合计算

因为RedisTimeSeries不属于Redis的内建功能模块，在使用时，我们需要先把他们的源码单独编译成动态链接库 redistimeseries.so再使用 loadmodule 命令进行加载：

loadmodule redistimeseries.so

当用于时间序列数据存储时，RedisTimeSeries的操作主要有5个：

用TS.CREATE命令创建时间序列数据集合。
用TS.ADD命令插入数据；
用TS.GET命令读取最新数据；
用TS.MGET命令按标签过滤查询数据集合；
用TS.RANGE支持聚合计算的范围查询。

1. 用 TS.CREATE 命令创建一个时间序列数据集合

TS.CREATE命令，我们需要设置时间序列数据集合的key和数据的过期时间（以毫秒为单位）。

此外，我们还可以为数据集合设置标签，来表示数据集合的属性

TS.CREATE device:temperature RETENTION 600000 LABELS device_id 1
OK

创建key为device:temperature 数据有效期是600s的时间序列数据集合。

数据创建600s后就会被自动删除。

最后我们给这集合标签属性{device_id:1},表示这个数据集合中记录的是属于设备ID为1的数据。

2.TS.ADD命令插入数据，TS.GET命令读取最新数据

用TS.ADD命令像时间序列集合插入数据，包括时间戳和具体的数值
使用TS.GET命令读取数据集合中的最新一条数据


TS.ADD device:temperature 1596416700 25.1
1596416700TS.GET device:temperature
25.1

执行 TS.ADD 命令，往 device:temperature 集合中插入了一条数据，记录的是设备在 2020 年 8 月 3 日 9 时 5 分的设备温度；再执行 TS.GET 命令时，就会把刚刚插入的最新数据读取出来。

3.用TS.MGET命令按标签过滤查询数据集合

保存多个设备的时间序列数据时，我们通常会把不同设备的数据保存到不同集合中。

此时我们可以使用TS.MGET命令，按照标签查询部分集合中的最新数据，

在使用TS.CREATE 创建数据集合时，我们可以给集合设置标签属性。

当我们进行查询时候，可以在查询条件中对集合标签属性进行匹配，最后的查询结果只返回匹配上的集合中的最新数据。

假设我们一共用4个集合为4个设备保存时间序列数据，设备的ID号是1,2,3,4，我们在创建集合时，把device_id设置为每个集合的标签。此时，我们就可以使用下列TS.MGET命令以及FILTER设置（这个配置项用来设置集合标签的过滤条件）。

查询device_id不等于2的所有其他设备的数据集合，并返回各自集合的最新一条数据。

TS.MGET FILTER device_id!=21) 1) "device:temperature:1"2) (empty list or set)3) 1) (integer) 15964170002) "25.3"
2) 1) "device:temperature:3"2) (empty list or set)3) 1) (integer) 15964170002) "29.5"
3) 1) "device:temperature:4"2) (empty list or set)3) 1) (integer) 15964170002) "30.1"

4.用TS.RANGE支持需要聚合计算的范围查询

使用TS.RANGE命令指定要查询的数据时间范围
AGGREATION参数指定要执行的聚合计算类型
支持求均值（avg）,求最大值/最小值（max/min）求和（sum）等。

计算2020年8月3日9点5分到12分的数据进行均值计算（按照每 180s 的时间窗口）


TS.RANGE device:temperature 1596416700 1596417120 AGGREGATION avg 180000
1) 1) (integer) 15964167002) "25.6"
2) 1) (integer) 15964168802) "25.8"
3) 1) (integer) 15964170602) "26.1"

总结

Redis 提供了两种方案

组合使用 Redis 内置的 Hash 和 Sorted Set 类型，把数据同时保存在 Hash 集合和 Sorted Set 集合中
在执行聚合计算时，我们需要把数据读取到客户端再进行聚合，当有大量数据要聚合时，数据传输开销大
所有的数据会在两个数据类型中各保存一份，内存开销不小
通过设置适当的数据过期时间，释放内存，减小内存压力

使用 RedisTimeSeries 模块

专门为存取时间序列数据而设计的扩展模块。和第一种方案相比，RedisTimeSeries 能支持直接在 Redis 实例上进行多种数据聚合计算，避免了大量数据在实例和客户端间传输。
RedisTimeSeries 的底层数据结构使用了链表，它的范围查询的复杂度是 O(N) 级别的
它的 TS.GET 查询只能返回最新的数据，没有办法像第一种方案的 Hash 类型一样，可以返回任一时间点的数据

部署环境中网络带宽高、Redis 实例内存大	Redis 内置的 Hash 和 Sorted Set 类型
部署环境中网络、内存资源有限，而且数据量大，聚合计算频繁，需要按数据集合属性查询	RedisTimeSeries

Redis核心技术与实战-学习笔记（十四）：时间序列数据相关推荐

Redis核心技术与实战-学习笔记（三十五）Redis使用建议
键值对使用规范 key的命令规范,只有命名规范,才能提供可读性强,可维护性好的key,方便日常管理: value的设计规范,包括避免bigkey,选择高效序列化方法和压缩方法,使用整数对象共享池,数据 ...
Redis核心技术与实战-学习笔记（二十六）：缓存雪崩、击穿、穿透
一.缓存雪崩缓存雪崩:大量应用请求无法在Redis缓存中进行处理,应用请求频繁访问数据库,导致数据库压力激增. 产生原因: 缓存中有大量数据同时过期,导致大量请求无法得到处理数据保存在缓存中,并设 ...
Redis核心技术与实战-学习笔记（二十九）：Redis并发控制
一.需要并发控制的原因 Redis不可避免的会遇到并发访问问题,比如多用户同时下单,就会对缓存在Redis中的商品库存并发更新,一旦有了并发操作,数据就会被修改,如果我们没有对并发写请求做好控制,就可 ...
Redis核心技术与实战-学习笔记（十五）：消息队列（Redis的解决方案）
一.消息队列消息队列:分布式系统必备的一个基础软件,能支持组件通信消息的快速读写 Redis本身支持数据的快速访问,满足消息队列的读写性能需求二.Redis适合做消息队列吗? 消息队列的消息存取需 ...
Redis核心技术与实战-学习笔记（五）内存快照RDB
一.为什么需要RDB AOF 方法优势:每次执行只需要记录操作命令,需要持久化的数据量不大.在进行写后日志只要不采用always(同步写回)的持久化策略就不会对性能造成太大影响. AOF方法劣势:AO ...
Redis核心技术与实战-学习笔记（七）哨兵机制
一.主库挂了,如何不间断服务? 主库挂了,需要运行一个新的主库:将从库切换为主库.这就涉及到三个问题: 主库真的挂了吗? 选择哪个从库作为主库? 如何把新主库相关信息通知给从库和客户端 Redis主从 ...
吴恩达《机器学习》学习笔记十四——应用机器学习的建议实现一个机器学习模型的改进
吴恩达<机器学习>学习笔记十四--应用机器学习的建议实现一个机器学习模型的改进一.任务介绍二.代码实现 1.准备数据 2.代价函数 3.梯度计算 4.带有正则化的代价函数和梯度计算 5 ...
“物联网开发实战”学习笔记-（四）智能音箱制作和语音控制
"物联网开发实战"学习笔记-(四)智能音箱制作和语音控制这次来造一个属于自己的智能音箱,这里详细介绍了智能音箱的语音控制的实现. 智能音箱的技术架构智能音箱主要涉及拾音.前端信 ...
Polyworks脚本开发学习笔记(十四)-WORKSPACE信息读取及管理
Polyworks脚本开发学习笔记(十四)-WORKSPACE信息读取及管理 Polyworks的工作任务存储分为工作区和项目两级,通过WORKSPACE命令获取工作任务信息,实现更好的任务管理. 下 ...

Redis核心技术与实战-学习笔记（十四）：时间序列数据