Redis中使用JSON.SET后为何不支持键的通配符搜索？

你的问题本质是Redis顶层键空间扫描和JSON嵌套存储的逻辑差异，具体原因分两点：

• 存储结构完全不同
  之前存pickle时，source1:20240506:part1:subtype1:1这类字符串是Redis的独立顶层键，每个键对应一份pickle数据。通配符source1:202405*是直接扫描Redis的顶层键空间，自然能匹配到所有符合前缀的键。

  而用JSON.SET时，你大概率是把多份JSON数据存在了同一个顶层键的嵌套JSON路径下，而非每个数据对应独立顶层键。比如你可能只创建了一个顶层键（如source1），然后通过JSON.SET source1 $.20240506.part1.subtype1.1 '{"dataset": "dataset1"}'这种方式存储，此时Redis的顶层键空间里只有source1这一个键，source1:202405*这类通配符根本匹配不到任何顶层键，自然扫不出数据——只有精确匹配source1这个键，才能看到里面嵌套的所有JSON内容。

• 通配符扫描的范围限制
  Redis的KEYS、SCAN这类通配符命令，以及RedisInsights的通配符搜索，都是针对顶层键进行匹配的，不会深入到单个键内部的JSON结构里去搜索路径。所以即使你在同一个顶层键里存了大量嵌套的JSON数据，通配符也无法识别这些内部路径。

验证方法 #

• 执行KEYS source1:202405*命令：存pickle时会返回多个键，用JSON.SET嵌套存储时返回空列表。
• 执行JSON.GET source1（假设你的顶层键是source1）：就能看到所有嵌套在这个键里的JSON数据。

可选解决方向 #

如果想继续用类似的通配符方式查看数据，有两种选择：

1. 回到每个JSON数据对应独立顶层键的模式，比如执行JSON.SET source1:20240506:part1:subtype1:1 $ '{"dataset": "dataset1"}'，这样通配符source1:202405*就能正常扫描到这些键。
2. 借助Redis Stack的RediSearch功能，给JSON数据创建索引，通过索引查询来检索嵌套的JSON内容。

内容的提问来源于stack exchange，提问作者AmitGK