【AICon】探索RAG 技术在实际应用中遇到的挑战及应对策略!AICon精华内容已上线73%>>> 了解详情
写点什么

使用 Redis 作为时间序列数据库:原因及方法

  • 2016-01-31
  • 本文字数:6369 字

    阅读完需:约 21 分钟

自从 Redis 出现以来,就在时间序列数据的存储与分析方面得到了一定程度的使用。Redis 最初只是被实现为一种缓冲,其目的是用于日志的记录,而随着其功能的不断发展,它已经具备了 5 种显式、3 种隐式的结构或类型,为 Redis 中的数据分析提供了多种方法。本文将为读者介绍使用 Redis 进行时间序列分析最灵活的一种方法。

关于竞态与事务

在 Redis 中,每个单独的命令本身都是原子性的,但按顺序执行的多条命令却未必是原子性的,有可能因出现竞态而导致不正确的行为。为了应对这一限制,本文将使用“事务管道”以及“Lua 脚本"这两种方式避免出现数据的竞态冲突。

在使用 Redis 以及用于连接 Redis 的 Python 客户端时,我们会调用 Redis 连接的.pipeline() 方法以创建一个“事务管道”(在使用其他客户端时,通常也将其称为“事务”或“MULTI/EXEC 事务”),在调用时无需传入参数,或者可以传入一个布尔值 True。通过该方法创建的管道将收集所有传入的命令,直到调用.execute() 方法为止。当.execute() 方法调用之后,客户端将对 Redis 发送 MULTI 命令,然后发送所收集的全部命令,最后是 EXEC 命令。当 Redis 在执行这一组命令时,不会被其他任何命令所打断,从而确保了原子性的执行。

在 Redis 中对一系列命令进行原子性的执行还存在着另一种选择,即服务端的 Lua 脚本。简单来说,Lua 脚本的行为与关系型数据库中的存储过程非常相似,但仅限于使用 Lua 语言以及一种专用的 Redis API 以执行 Lua。与事务的行为非常相似,Lua 中的脚本在执行时通常来说不会被打断 1,不过未处理的错误也会造成 Lua 脚本提前中断。从语法上说,我们将通过调用 Redis 连接对象的.register_script() 方法以加载一个 Lua 脚本,该方法所返回的对象可以作为一个函数,以调用 Redis 中的脚本,而无需再调用 Redis 连接中的其他方法,并结合使用 SCRIPT LOAD 与 EVALSHA 命令以加载与执行脚本。

用例

当谈到 Redis 以及使用它作为一个时间序列数据库时,我们首先提出的一个问题是:“时间序列数据库的用途或目的是什么?”时间序列数据库的用例更多地与数据相关,尤其在你的数据结构被定义为一系列事件、一个或多个值的示例、以及随着时间推移而变化的度量值的情况下。以下是这些方面应用的一些示例(但不仅限于此):

  • 股票交易的卖价与交易量
  • 在线零售商的订单总价与送货地址
  • 视频游戏中玩家的操作
  • IoT 设备中内嵌的传感器中收集的数据

我们将继续进行深入的探讨,不过基本上来说,时间序列数据库的作用就是如果发生了某件事,或是你进行了一次评估操作后,可以在记录的数据中加入一个时间戳。一旦你收集了某些事件的信息,就可以对这些事件进行分析。你可以选择在收集的同时进行实时分析,也可以在事件发生后需要进行某些更复杂的查询时进行分析。

使用通过有序集合与哈希进行高级分析

在 Redis 中,对于时间序列数据的保存与分析有一种最为灵活的方式,它需要结合使用 Redis 中的两种不同的结构,即有序集合(Sorted Set)与哈希(Hash)。

在 Redis 中,有序集合这种结构融合了哈希表与排序树(Redis 在内部使用了一个跳表结构,不过你可以先忽略这一细节)的特性。简单来说,有序集合中的每个项都是一个字符串型的“成员”以及一个 double 型的“分数”的组合。成员在哈希中扮演了键的角色,而分数则承担了树中的排序值的作用。通过这种组合,你就可以通过成员或分数的值直接访问成员与分数,此外,你也可以通过多种方式对按照分数的值排好序的成员与分数进行访问 2。

保存事件

如今,从各种方面来说,使用一个或多个有序集合以及部分哈希的组合用于保存时间序列数据的做法都是 Redis 最常见的用例之一。它表现了一种底层的构建块,用于实现各种不同的应用程序。包括像 Twitter 一样的社交网络,以及类似于 Reddit 和 Hacker News 一样的新闻网站,乃至于基于 Redis 本身的一种接近完成的关系 - 对象映射器

在本文的示例中,我们将获取用户在网站中的各种行为所产生的事件。所有的事件都将共享 4 种属性,以及不同数量的其他属性,这取决于事件的类型。我们已知的属性包括:id、timestamp、type 以及 user。为了保存每个事件,我们将使用一个 Redis 哈希,它的键由事件的 id 所派生而来。为了生成事件的 id,我们将在大量的源中选择一种方式,但现在我们将通过 Redis 中的一个计数器来生成我们的 id。如果在 64 位的平台上使用 64 位的 Redis,我们将能够创建最多 263-1 个事件,主要的限制取决于可用的内存大小。

当我们准备好进行数据的记录与插入后,我们就需要将数据保存为哈希,并在有序集合中插入一个成员 / 分数对,分别对应事件的 id(成员)与事件的时间戳(分数)。记录某个事件的代码如下

复制代码
def record_event(conn, event):
id = conn.incr('event:id')
event['id'] = id
event_key = 'event:{id}'.format(id=id)
pipe = conn.pipeline(True)
pipe.hmset(event_key, event)
pipe.zadd('events', **{id: event['timestamp']})
pipe.execute()

在这个 record_event() 函数中,我们获取了一个事件,从 Redis 中获得一个计算得出的新 id,将它赋给事件,并生成了事件保存的键。这个键的构成是字符串“event”加上新的 id,并在两者之间由冒号分割所构成的 3。随后我们创建了一个管道,并准备设置该事件相关的全部数据,同时准备将事件 id 与时间戳对保存在有序集合中。当事务管道完成执行之后,这一事件将被记录并保存在 Redis 中。

事件分析

从现在起,我们可以通过多种方式对时间序列进行分析了。我们可以通过 ZRANGE 4 的设置对最新或最早的事件 id 进行扫描,并且可以在稍后获取这些事件本身以进行分析。通过结合使用 ZRANGEBYSCORE 与 LIMIT 参数,我们能够立即获取到某个时间戳之前或之后的 10 个、甚至是 100 个事件。我们也可以通过 ZCOUNT 计算某一特定时间段内事件发生的次数,甚至选择用 Lua 脚本实现自己的分析方式。以下的示例将通过 Lua 脚本计算在一个给定时间范围内各种不同的事件类型的数量。

复制代码
import json
def count_types(conn, start, end):
counts = count_types_lua(keys=['events'], args=[start, end])
return json.loads(counts)
count_types_lua = conn.register_script('''
local counts = {}
local ids = redis.call('ZRANGEBYSCORE', KEYS[1], ARGV[1], ARGV[2])
for i, id in ipairs(ids) do
local type = redis.call('HGET', 'event:' .. id, 'type')
counts[type] = (counts[type] or 0) + 1
end
{1}
return cjson.encode(counts)
''')

这里所定义的 count_types() 函数首先将参数传递给经过封装的 Lua 脚本,并对经过 json 编码的事件类型与数量的映射进行解码。Lua 脚本首先创建了一个结果表(对应 counts 变量),随后通过 ZRANGEBYSCORE 读取这一时间范围内的事件 id 的列表。当获取到这些 id 之后,脚本将一次性读取每个事件中的类型属性,让事件数量表保持不断增长,最后结束时返回一个经过 json 编码的映射结果。

对性能的思考以及数据建模

正如代码所展示的一样,这个用于在特定时间范围内计算不同事件类型数量的方法能够正常工作,但这种方式需要对这一时间范围内的每个事件的类型属性进行大量的读取。对于包含几百或是几千个事件的时间范围来说,这样的分析是比较快的。但如果某个时间范围内饮食了几万乃至几百万个事件,情况又会如何呢?答案很简单,Redis 在计算结果时将会阻塞。

有一种方法能够处理在分析事件流时,由于长时间的脚本执行而产生的性能问题,即预先考虑一下需要被执行的查询。具体来说,如果你知道你需要对某一段时间范围内的每种事件的总数进行查询,你就可以为每种事件类型使用一个额外的有序集合,每个集合只保存这种类型事件的 id 与时间戳对。当你需要计算每种类型事件的总数时,你可以执行一系列 ZCOUNT 或相同功能的方法调用 5,并返回该结果。让我们来看一下这个修改后的 record_event() 函数,它将保存基于事件类型的有序集合。

复制代码
def record_event_by_type(conn, event):
id = conn.incr('event:id')
event['id'] = id
event_key = 'event:{id}'.format(id=id)
type_key = 'events:{type}'.format(type=event['type'])
ref = {id: event['timestamp']}
pipe = conn.pipeline(True)
pipe.hmset(event_key, event)
pipe.zadd('events', **ref)
pipe.zadd(type_key, **ref)
pipe.execute()

新的 record_event_by_type() 函数与旧的 record_event() 函数在许多方面都是相同的,但新加入了一些操作。在新的函数中,我们将计算一个 type_key,这里将保存该事件在对应这一类型事件的有序集合中的位置索引。当 id 与时间戳对添加到 events 有序集合中后,我们还要将 id 与时间戳对添加到 type_key 这个有序集合中,随后与旧的方法一样执行数据插入操作。

现在,如果需要计算两个时间点之间“visit”这一类型的事件所发生的次数,我们只需在调用 ZCOUNT 命令时传入所计算的事件类型的特定键,以及开始与结束的时间戳。

复制代码
def count_type(conn, type, start, end):
type_key = 'events:{type}'.format(type=type)
return conn.zcount(type_key, start, end)

如果我们能够预先知道所有可能出现的事件类型,我们就能够对每种类型分别调用以上的 count_type() 函数,并构建出之前在 count_types() 中所创建的表。而如果我们无法预先知道所有可能会出现的事件类型,或是有可能在未来出现新的事件类型,我们将可以将每种类型加入一个集合(Set)结构中,并在之后使用这个集合以发现所有的事件类型。以下是经我们修改后的记录事件函数。

复制代码
def record_event_types(conn, event):
id = conn.incr('event:id')
event['id'] = id
event_key = 'event:{id}'.format(id=id)
type_key = 'events:{type}'.format(type=event['type'])
ref = {id: event['timestamp']}
pipe = conn.pipeline(True)
pipe.hmset(event_key, event)
pipe.zadd('events', **ref)
pipe.zadd(type_key, **ref)
pipe.sadd('event:types', event['type'])
pipe.execute()

与之前相比,唯一的改变就在于我们将事件的类型加入了一个命名为“event:types”的集合,然后我们需要相应地修改一下 count_types() 函数的实现……

复制代码
def count_types_fast(conn, start, end):
event_types = conn.smembers('event:types')
counts = {}
for event_type in event_types:
counts[event_type] = conn.zcount(
'events:{type}'.format(type=event_type), start, end)
return counts

如果某个时间范围内存在大量的事件,那么新的 count_types_fast() 函数将比旧的 count_types() 函数执行更快,主要原因在于 ZCOUNT 命令比起从哈希中获取每个事件类型速度更快。

以 Redis 作为数据存储

虽然 Redis 自带的分析工具及其命令和 Lua 脚本非常灵活并且性能出色,但某些类型的时间序列分析还能够从特定的计算方法、库或工具中受益。对于这些情形来说,将数据保存在 Redis 中仍然是一种非常有意义的做法,因为 Redis 对于数据的存取非常快。

举例来说,对于一支股票来说,整个 10 年的成交金额数据按照每分钟取样也最多不过 120 万条数据,这点数据能够轻易地保存在 Redis 中。但如果要通过 Redis 中的 Lua 脚本对数据执行任何复杂的函数,则需要对现有的优化库进行移植或是调试,让他们在 Redis 中也实现相同的功能。而如果使用 Redis 进行数据存储,你就可以获取时间范围内的数据,将他们保存在已有的经过优化的内核中,以计算不断变化的平均价格、价格波动等等。

那么为什么不选用一种关系型数据库作为替代呢?原因就在于速度。Redis 将所有数据都保存在 RAM 中,并且对数据结构进行了优化(正如我们所举的有序集合的例子一样)。在内存中保存数据及经过优化的数据结构的结合在速度上不仅比起以 SSD 为存储介质的数据库快了 3 个数量级,并且对于一般的内存键值存储系统、或是在内存中保存序列化数据的系统也快了 1 至 2 个数量级。

结论及后续

当使用 Redis 进行时间序列分析,乃至任何类型的分析时,一种合理的方式是记录不同事件的某些通用属性与数值,保存在一个通用的地址,以便于搜索包含这些通用属性与数值的事件。我们通过为每个事件类型实现对应的有序集合实现了这一点,并且也提到了集合的使用。虽然这篇文章主要讨论的是有序集合的应用,但 Redis 中还存在着更多的结构,在分析工作中使用 Redis 还存在其他许多不同的选择。除了有序集合与哈希之外,在分析工作中还有一些常用的结构,包括(但不限于):位图、数组索引的字节字符串、HyperLogLogs、列表(List)、集合,以及很快将发布的基于地理位置索引的有序集合命令 6。

在使用 Redis 时,你会不时地重新思索如何为更特定的数据访问模式添加相关的数据结构。你所选择的数据保存形式既为你提供了保存能力,也限定了你能够执行的查询的类型,这一点几乎总是不变的。理解这一点很重要,因为与传统的、更为人熟悉的关系型数据库不同,在 Redis 中可用的查询与操作受限于数据保存的类型。

在看过了分析时间序列数据的这些示例之后,你可以进一步阅读《Redis in Action》这本书第 7 章中关于通过创建索引查找相关数据的各种方法,可以在 RedisLabs.com 的 eBooks 栏目中找到它。而在《Redis in Action》一书的第 8 章中提供了一个近乎完整的、类似于 Twitter 的社交网络的实现,包括关注者、列表、时间线、以及一个流服务器,这些内容对于理解如何使用 Redis 保存时间序列中的时间线及事件以及对查询的响应是一个很好的起点。

1 如果你启动了 lua-time-limit 这一配置选项,并且脚本的执行时间超过了配置的上限,那么只读的脚本也可能会被打断。

2 当分数相同时,将按照成员本身的字母顺序对于项目进行排序。

3 在本文中,我们通常使用冒号作为操作 Redis 数据时对名称、命名空间以及数据的分割符,但你也可以随意选择任何一种符号。其他 Redis 用户可能会选择句号“.”或分号“;”等作为分割符。只要选择一种在键或数据中通常不会出现的字符,就是一种比较好的做法。

4 ZRANGE 及 ZREVRANGE 提供了基于排序位置从有序集合中获取元素的功能,ZRANGE 的最小分数索引为 0,而 ZREVRANGE 的最大分数索引为 0。

5 ZCOUNT 命令将对有序集合中某个范围内的数据计算值的总和,但它的做法是从某个端点开始增量式的遍历整个范围。对于包含大量项目的范围来说,这一命令的开销可能会很大。作为另一种选择,你可以使用 ZRANGEBYSCORE 和 ZREVRANGEBYSCORE 命令以查找范围内成员的起始与终结点。而通过在成员列表的两端使用 ZRANK,你可以查找这些成员在有序集合中的两个索引,通过使用这两个索引,你可以将两者相减(再加上 1)以得到相同的结果,而其计算开销则大大减少了,即使这种方式需要对 Redis 进行更多的调用。

6 在 Redis 2.8.9 中引入的 Z*LEX 命令会使用有序集合以提供对有序集合有限的前缀搜索功能,与之类似,最新的还未发布的 Redis 3.2 中将通过 GEO* 命令提供有限的地理位置搜索与索引功能。

关于作者

Josiah Carlson博士是一位经验丰富的数据库专家,也是 Redis 社区的活跃贡献者。作为初创公司方面的老手,自从了解了 Salvatore Sanfilippo 在 2010 年的工作后,Josiah 就查觉了 Redis 的价值与目的。经过大量的使用、误用以及帮助他人理解 Redis 的各种文档化或未文档化的特性之后,他最终在为他的前一家初创公司进行技术开拓时编写了《Redis in Action》一书。他的部分工作成果转化为了使用 Redis 的功能的相关开源库,并且持续地在邮件列表中回答各种问题,同时也不时地编写 Redis 与其他主题的博客文章。Josiah Carlson 博士目前在 Openmail 担任技术部的 VP,这是一家位于洛杉矶的尚处于早期的初创公司。他非常乐于为你讲解如何通过 Redis 帮助你解决公司中的各种问题。

查看英文原文: Using Redis As a Time Series Database: Why and How

公众号推荐:

2024 年 1 月,InfoQ 研究中心重磅发布《大语言模型综合能力测评报告 2024》,揭示了 10 个大模型在语义理解、文学创作、知识问答等领域的卓越表现。ChatGPT-4、文心一言等领先模型在编程、逻辑推理等方面展现出惊人的进步,预示着大模型将在 2024 年迎来更广泛的应用和创新。关注公众号「AI 前线」,回复「大模型报告」免费获取电子版研究报告。

AI 前线公众号
2016-01-31 17:5112798
用户头像

发布了 428 篇内容, 共 171.4 次阅读, 收获喜欢 36 次。

关注

评论

发布
暂无评论
发现更多内容

阿里云 RTC QoS 屏幕共享弱网优化之若干编码器相关优化

阿里云视频云

音视频 WebRTC 网络 RTC 视频会议

技术分享 | 漫谈音视频中的拥塞控制

拍乐云Pano

企业短信服务质量与用户体验如何监控?短信监测技术震撼来袭

博睿数据

短信 数据监测

Redis 学习笔记 08:数据结构与对象小结

架构精进之路

redis 七日更 28天写作

EXCEL数据太“脏”无从下手?何须用python,ETL一分钟搞定

智分析

Excel ETL

第一周作业

Esther

跨界融合,区块链推动实体经济提档升级

CECBC

人工智能 云计算 大数据

蝉联 Apache 最活跃项目,Flink 社区是如何保持高速发展的?

Apache Flink

flink

边缘安全 | 正确使用CDN 让你更好规避安全风险

阿里云Edge Plus

安全 CDN

​Kubernetes资源清单篇:如何创建资源?​

xcbeyond

Kubernetes 28天写作 Kubernetes从入门到精通

关于JDK15的简单理解

Java架构师迁哥

Soul网关源码阅读(八)路由匹配初探

Java 源码阅读 网关

Android面试(二)

我就感觉到快

阿里开源SpringSecurity:用户+案例+认证+框架

996小迁

Java 程序员 架构 面试 springsecurity

LeetCode题解:105. 从前序与中序遍历序列构造二叉树,递归+哈希表,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

永续合约APP系统软件开发

系统开发

观看辽篮比赛,思考团队管理——关于团队的灵魂拷问,你中了几个?

伯薇

团队管理 团队建设 团队 赋能 激励

一文读懂 Serverless,将配置化思想复用到平台系统中

Serverless Devs

Serverless 云原生 PaaS

实现数字经济和实体经济深度融合

CECBC

区块链

客户服务高触达,零代码从短信/邮件跳转小程序客服

环信

【盘点2020】机房网络性能哪家强?年度冠军揭晓

博睿数据

机房 评测

程序员生产环境-软件篇

ITCamel

程序员 效率工具 工作效率

胜天半子!阿里内部力荐SpringBoot全栈笔记全网首发,源码实战齐飞

Java架构之路

Java 程序员 架构 面试 编程语言

AES128解密只能解一半的问题

李日盛

AES 问题定位

万字带你深入阿里开源的Canal工作原理

大数据老哥

大数据 canal

为什么你家的 K8s 应用平台不好用?

孙健波

Kubernetes PaaS KubeVela

数字货币应用从C端走向B端 实践中这些难题仍需关注

CECBC

数字货币

《价值》- 护城河(6)

石云升

读书笔记 护城河 28天写作

你kin你擦!阿里终于肯把内部高并发编程高阶笔记开源出来了

Java架构之路

Java 程序员 架构 面试 编程语言

百度首届智能小程序高校大赛圆满结束:关注学生心理健康小程序获全国一等奖

DT极客

架构师训练营第三周作业 - 学习总结

阿德儿

使用Redis作为时间序列数据库:原因及方法_数据库_Josiah Carlson_InfoQ精选文章