redis - 迭代 Redis 排序集是个好主意(如何)？

Question

一般来说，Redis 文档和谷歌搜索显示的信息很少，这让我觉得这可能不是一个好主意，或者可能存在一些问题。

基本上，我有一些非常大的带有时间序列数据的排序集(分数是 unix 时间)。我需要查询可能较长的时间间隔，并对数据进行一些后期处理。我想评估它对性能的影响，在不同的负载场景下，以迭代方式查询排序集而不是单个请求/响应。这可能很好，因为:它锁定 Redis 的时间更短(有点像扫描比键更好)，我可以在数据仍在检索时更早地并行地开始进行后处理，而且我不需要在对其进行操作之前将完整的数据集加载到内存中，而不是在处理数据时丢弃数据。

Redis 文档没有展示如何在 ZRANGEBYSCORE 上使用 LIMIT 的示例，我可以想到两种方法:

1)固定范围，可变LIMIT

ZRANGEBYSCORE my-sorted-set 1000000 2000000 LIMIT 0 10000
ZRANGEBYSCORE my-sorted-set 1000000 2000000 LIMIT 10000 10000
ZRANGEBYSCORE my-sorted-set 1000000 2000000 LIMIT 20000 10000
ZRANGEBYSCORE my-sorted-set 1000000 2000000 LIMIT 30000 10000

相同的分数范围，但移动了偏移量

2)可变范围，固定LIMIT

ZRANGEBYSCORE my-sorted-set 1000000 2000000 WITHSCORES LIMIT 0 10000
ZRANGEBYSCORE my-sorted-set 1010000 2000000 WITHSCORES LIMIT 0 10000
ZRANGEBYSCORE my-sorted-set 1020000 2000000 WITHSCORES LIMIT 0 10000
ZRANGEBYSCORE my-sorted-set 1030000 2000000 WITHSCORES LIMIT 0 10000

在这里，我将根据上一次迭代的最高分数调整 min。在这两种情况下，当结果长度小于 COUNT 时，我将停止迭代。

有哪一个比另一个更好吗？是否有我遗漏的问题以及任何或一个坏主意？

谢谢!

Answer 1

从你写的第一个选项来看，实际分数对你来说似乎并不重要。 这意味着您的第二个选项将浪费您一些处理周期并使用不需要的网络。

无论如何，我建议对您使用的 LIMIT 进行一些试验。您可以降低 slowlog 阈值并查看每次调用的 Redis CPU 时间。 (CONFIG SET slowlog-log-slower-than 0 将记录所有传入请求。默认值为 10000 微秒)。

顺便说一句，你应该同时检查 STREAM数据类型和 Time Series module .很可能至少其中之一会给您带来更好的功能。