ITPub博客

首页 > 人工智能 > 人工智能 > Redis 8.10:紧凑 Hash、JSONPath 扩展与增量备份

Redis 8.10:紧凑 Hash、JSONPath 扩展与增量备份

原创 人工智能 作者:虹科云科技 时间:2026-10-26 18:04:34 0 删除 编辑
Redis Open Source 8.10 已正式发布。这一版本主要围绕三个方向改进:提高内存与处理效率,增强数据结构的表达能力,以及降低大规模部署的运维负担。
其中,紧凑 Hash 可以让结构相似的数据共享字段名,降低内存占用;新的批量导入方式减少重复传输和解析字段的开销。JSON、Streams、Sets、Lists 和 Time Series 的命令也得到扩展,使应用能够在 Redis 内完成更多处理,减少网络往返。增量备份与恢复则为多分片集群提供了资源峰值更低的备份方式。

Hash 与 Streams 的性能改进

Redis 团队在发布说明中列出了以下性能与内存优化结果。这些数字对应表中描述的操作和数据形态,不能直接套用于所有工作负载。
数据类型 操作或数据形态 改善情况
Hash 对新建、字段较多的 Hash 执行 HSET、HMSET 吞吐量最高提高 104%
Hash 多个键使用相同字段名 Schema 内存占用最高降低 50%
Streams XREADGROUP,COUNT 100 吞吐量最高提高 28%
Streams 条目较多的 Stream 内存占用最高降低 26%

Compact Hash:共享字段名,减少重复存储

用户画像、会话和特征存储中,经常存在大量字段相同的 Hash。例如,数百万份用户记录都包含 name、 email、 country 和 last_login。以往每个 Hash 都要单独保存一份字段名。
Redis 8.10 引入 Hash 模板这种内部编码,让多个 Hash 共享同一组字段名,同时独立保存各自的值。对于大量结构相似的 Hash,内存占用最高可以降低 50%。
新命令 HIMPORT 则用于高效批量导入具有相同字段的 Hash。客户端先准备一次字段集:
HIMPORT PREPARE user-profile name email country last_login
之后导入每条记录时,只需发送对应的值:
HIMPORT SET user:1 user-profile "Alice" "alice@example.com" "UK" "2026-07-14"
HIMPORT SET user:2 user-profile "Bob" "bob@example.com" "US" "2026-07-14"
字段名不再为每个 Hash 重复传输和解析,网络与服务端处理开销随之降低,Hash 导入吞吐量最高可达到原来的 2 倍。已有 Hash 命令继续保持原有语义。运维人员也可以选择对符合条件的 Hash 启用自动模板转换,而不要求应用改用 HIMPORT。
这项机制尤其适合字段集稳定、记录数量大的用户画像、会话、特征存储,以及批量导入和 ETL 负载。

JSONPath:在 Redis 内完成更多过滤与计算

Redis JSON 使用 JSONPath 访问和操作文档中的特定部分,无需每次获取完整文档。Redis 8.10 扩展了 JSONPath 的语法与函数,让过滤、计算和聚合可以更多地在服务端完成。
新增能力包括算术与比较运算、 in、 nin 和过滤条件取反,也涵盖字符串、数组、对象及节点列表操作。字符串函数包括 match()、 search() 和 concat();数组函数包括 first()、 last()、 append() 和 index()。聚合函数提供 min()、 max()、 avg()、 sum()、 stddev(),还增加了 length()、 count()、 keys()、 value() 等函数。
例如,可以直接计算折扣价格、数组平均值,或统计符合条件的项目数量:
JSON.GET key '$.price * 0.8'
JSON.GET key '$.arr1.avg()'
JSON.GET key 'count($.items[?@.price > 10])'
把这部分过滤和后处理放到 Redis 中,可以减少返回客户端的数据量,也让应用代码更简洁。

Streams:限制跨多个 Stream 的总返回量

XREAD 和 XREADGROUP 原有的 COUNT 限制分别作用于每个 Stream。一次读取多个 Stream,或者条目本身较大时,总响应仍可能超出预期。
Redis 8.10 增加 MAXCOUNT 和 MAXSIZE:前者限制所有 Stream 合计返回的消息数量,后者限制整体响应的字节大小。
XREAD COUNT 100 MAXCOUNT 200 STREAMS stream:1 stream:2 stream:3 0 0 0
这个示例最多从每个 Stream 读取 100 条消息,但所有 Stream 合计不超过 200 条。应用可以据此约束网络传输和内存消耗,避免出现过大的响应。

Sets:不取回成员,也能计算并集与差集大小

用户分群、权限集合、商品分类和搜索过滤经常使用 Set。很多场景只关心运算结果有多少成员,并不需要拿到成员本身。
Redis 已有用于交集基数计算的 SINTERCARD,8.10 又增加了并集与差集的对应操作:
SUNIONCARD numkeys key [key ...] [APPROX] [LIMIT limit]
SDIFFCARD numkeys key [key ...] [LIMIT limit]
SUNIONCARD 返回并集的基数, SDIFFCARD 返回第一个集合减去后续集合后的基数。应用因此不必为了计数传回大量成员,也不必先创建临时 Set。
SUNIONCARD 还可以通过 APPROX 使用基于 HyperLogLog 的快速估算,其标准误差为 0.81%。

Lists:原子移动一批元素

Redis List 常用于队列、栈和处理流水线。 LMOVE、 BLMOVE 已经能够在两个 List 之间原子移动单个元素,8.10 则引入批量形式:
LMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT>
       [<COUNT|EXACTLY> count <OBO|BULK>]
BLMOVEM source destination <LEFT|RIGHT> <LEFT|RIGHT> timeout
        [<COUNT|EXACTLY> count <OBO|BULK>]
COUNT 表示最多移动指定数量的元素; EXACTLY 则要求可用元素达到指定数量,才移动整批。应用还可以选择逐个移动的 OBO 顺序,或保留所移动元素相对顺序的 BULK 模式。
批量任务领取、队列处理、流水线交接和重试队列,都可以利用这些命令,在一组元素需要一起转移时保持原子性。

Time Series:按时间戳组织跨序列查询

彼此相关的时间序列往往拥有相同时间戳,却分开存储。例如金融 OHLCV 数据会分别保存开盘价、最高价、最低价、收盘价和成交量。
TS.MRANGE 按时间序列组织返回结果,需要时间戳对齐的应用还要在客户端重新整理。Redis 8.10 新增 TS.NRANGE 和 TS.NREVRANGE,对明确指定的一组序列查询,并按时间戳组织结果:
TS.NRANGE 5 {ACMZ}:open {ACMZ}:high {ACMZ}:low
            {ACMZ}:close {ACMZ}:volume
            <fromTimestamp> <toTimestamp>
由于键是显式指定的,这类查询不要求标签。在 Redis Cluster 中,所有指定键必须位于同一个哈希槽。命令还支持为不同序列指定各自的聚合器,在同一次查询中采用不同聚合函数。
这让金融分析、监控面板和机器学习特征提取更容易直接消费按时间对齐的数据,减少客户端透视转换。

阻塞等待新增样本

实时面板常常通过反复轮询判断是否有新样本。新增的 TS.READ 提供可选阻塞读取:
TS.READ key timestamp
        [BLOCK milliseconds min_count]
        [MAX_COUNT max_count]
应用可以等待样本达到最小数量,或在指定超时后返回,减少持续发出范围查询的需要。这适用于实时展示、监控、金融、告警和 IoT 等连续消费时间序列的场景。

排除时间范围内没有样本的序列

TS.MRANGE 和 TS.MREVRANGE 可能返回满足标签过滤、但在指定时间范围内没有样本的序列。8.10 增加 EXCLUDEEMPTY:
TS.MRANGE - 500 WITHLABELS EXCLUDEEMPTY FILTER s=1
启用后,这些空结果会被省略,减少无效返回内容和客户端过滤工作。

增量备份与恢复:错开快照,协调完成备份

大型 Redis Cluster 的备份可能产生明显的资源压力。创建 RDB 快照需要 fork,同一节点上的多个分片如果同时执行,CPU 和内存用量会出现峰值,影响工作负载,甚至造成备份失败。
Redis 8.10 围绕新的 BACKUP 命令族提供增量备份与恢复。各分片不必同时创建快照,可以错开执行,同时形成协调一致的备份过程。
每份备份以某一时刻的 RDB 快照 BASE 开始。在备份保持打开期间,Redis 将后续写入记录到增量 INCR AOF 文件中。封存备份时,RDB、增量 AOF 和 Manifest 一起构成完整备份,表示备份窗口结束时的数据集状态。
封存不要求再次 fork。因此,即便各分片在不同时间生成了基础快照,也能够在结束时协调封存,降低同一节点多个分片同时制造资源峰值的压力。
恢复时,新增的 preload-file 启动选项可以加载已封存备份的 Manifest,也可以加载独立 RDB 文件。
Redis 8.10 已在 Redis Open Source 中正式可用,可以从 Redis 下载页获取版本,在自己的数据结构、吞吐和备份负载中验证这些改进。


来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/70026953/viewspace-3186726/ ,如需转载,请注明出处,否则将追究法律责任。

下一篇: 没有了~
请登录后发表评论 登录
全部评论
公众号(ID:艾体宝IT):分享数据存储、网络安全等相关的产品信息、解决方案、应用案例及行业信息,如Redis、ArangoDB、ONEKEY、Lepide等!艾体宝IT官网:https://www.itbigtec.com/ 联系我们:18483658974(同微信)

注册时间:2023-02-21

  • 博文量
    210
  • 访问量
    216490