Redis SCAN - 优化可能性？答案

【问题标题】：Redis SCAN - optimization possibilites?Redis SCAN - 优化可能性？
【发布时间】：2020-07-04 20:11:06
【问题描述】：

我对 Redis 很陌生，最初使用 KEYS 来遍历我的数据集，但从我在文档 Redis worst practices 中可以看到的内容来看，实际上不建议这样做 - 特别是在包含许多键的较大数据集中，因为 KEYS 遍历整个数据集，阻塞 long 时间，而 SCAN 迭代数据集中的数据块，因此阻塞时间比 KEYS 短。如果理解正确，我想知道是否有任何方法可以优化 SCAN 迭代，这样它就不会随机迭代（比如说）10.000 个数据，而是从给定点迭代。 p>

例子：

a1
a2
a3
b1 < --- start iterating from here instead of from a1
b2
b3

这样可以为“我们”节省很多性能？

【问题讨论】：

你需要重新思考一下才能解决这个问题。与其扫描自然键，不如对键使用无意义的随机或顺序值。为了进行智能查找，您应该使用字典排序集，其作用类似于关系数据库中的 btree 索引。您的自然键应该成为这些索引中的值，并在末尾附加 id。如果您非常仔细地阅读this article，尤其是。从“在索引中添加辅助信息”部分，它将变得具有启发性，只要相信它解决了您的用例即可。

标签： database sorting redis key

【解决方案1】：

SCAN 命令遍历数据库哈希映射表，按哈希值排序。

您可以使用游标参数控制 SCAN 的起始位置，但您最多可以控制它在散列排序的 hashmap 表中的起始位置。见Redis `SCAN`: how to maintain a balance between newcomming keys that might match and ensure eventual result in a reasonable time?。

但这是相当不切实际的，因为键的哈希值可以被认为是对键本身的伪随机。这不像他们遵循字典顺序或任何类型的任何逻辑有用的顺序。哈希的目的正是为了均匀分布哈希表中的键。

所以，即使你尝试 SCAN 0 MATCH b1*，实现仍然需要遍历哈希表的所有条目来进行全扫描，因此你需要多次调用 SCAN 直到返回的游标返回为零。

【讨论】：