redis hscan key 使用通配符时的效率如何?

i00i   (烟灰·独孤求胖)2019-04-15 11:25:24
在设计key的时候打算把一些id或keyword编码进去,以便大多数查询通过key即可解决。
不过不清楚redis的hscan在处理key通配符时是否存在特定的瓶颈呢?
chenjinyuan   (心梦如水)2019-04-15 12:01:44
这复杂度n了吧。。。
【 在 i00i 的大作中提到: 】
: 在设计key的时候打算把一些id或keyword编码进去,以便大多数查询通过key即可解决。
i00i   (烟灰·独孤求胖)2019-04-15 12:06:35
不知道redis怎么实现的,有没有做优化。
没能力看它的源代码,只好先问问大家咯。
从爬文的结果来看这种用法还是比较普遍的,不过没看到有人提及算法开销的问题。
【 在 chenjinyuan 的大作中提到: 】
: 这复杂度n了吧。。。
chenjinyuan   (心梦如水)2019-04-15 12:09:17
我也不知道,哈哈
不过我觉得应该不会优化这个吧
【 在 i00i 的大作中提到: 】
: 不知道redis怎么实现的,有没有做优化。
i00i   (烟灰·独孤求胖)2019-04-15 12:11:37
why not?
普遍应用场景啊。。至于优化到什么份上那是另一码事。。
话说回来,更复杂的场景可以用lua。
【 在 chenjinyuan 的大作中提到: 】
: 我也不知道,哈哈
chenjinyuan   (心梦如水)2019-04-15 12:15:01
redis明明是key value数据库为啥优化key上的遍历。。。
【 在 i00i 的大作中提到: 】
: why not?
i00i   (烟灰·独孤求胖)2019-04-16 08:50:42
20190416追记:
问题在于,除了scan和keys,并没有其他方法可用,所以没得选择。
这两者也有显著区别,scan是增量迭代,提供了游标实现“分页查询”这样的特性,
而keys会一次性返回所有匹配的key,在目标查询结果数据量不可控时可能拖垮redis。
所以他们建议在生产环境是使用scan代替keys。
两者在匹配key字符串的算法上应该不存在显著差别。
【 在 i00i 的大作中提到: 】
: 在设计key的时候打算把一些id或keyword编码进去,以便大多数查询通过key即可解决。

水木社区