Redis中SCAN与KEYS的性能

包括官方Redis文档在内的许多资料都指出,KEYS由于可能会阻塞,在生产环境中使用该命令是一个坏主意。如果已知数据集的大致大小,相对于而言,是否SCAN有任何优势KEYS

例如,考虑一个数据库,该数据库最多具有100个以下形式的键:data:number:X其中,X是整数。如果要检索所有这些,可以使用命令KEYS

data:number:*。这会比使用慢得多SCAN 0 MATCH data:number:* COUNT

100吗?还是在这种情况下这两个命令基本相同?可以说这SCAN是更好的选择,KEYS因为它可以防止出现意外的大集合返回的情况,这是否更可取?

回答:

您不必在乎当前命令的执行,而在乎对其他所有命令的影响,因为Redis使用单个线程来处理命令(即,在执行命令时,所有其他命令都需要等待直到执行一个结束)。

虽然keys还是scan可能会提供你的情况,单独执行你相似或相同的性能,几毫秒阻挡的Redis会显著降低整体I / O。

这是keys用于开发目的和scan生产环境的主要原因。

OP说:

“虽然键或扫描可能会为您提供单独执行的相似或相同的性能,但阻塞Redis的几毫秒会大大降低总体I / O。”

-这句话似乎表明一个命令阻止了Redis,而另一个则没有,这不是事实。如果可以保证我从KEYS呼叫中获得100条结果,那么哪种方式比SCAN糟糕?为什么您觉得一个命令更容易阻塞?

可以分页搜索时,应该会有很大的不同。被迫一次获得100个按键与能够实现分页并以10乘10(或50和50)的方式获得100个键并不相同。

。查看Redis官方文档对此有何评论:

由于这些命令允许增量迭代,每个调用仅返回少量元素,因此可以在生产中使用它们,而不会受到诸如KEYS或SMEMBERS之类的命令的不利影响,这些命令在被调用时可能会长时间(甚至几秒钟)阻塞服务器大量的键或元素集合

以上是 Redis中SCAN与KEYS的性能 的全部内容, 来源链接: utcz.com/qa/434941.html

回到顶部