Redis / Rejson 嵌套文档层次结构性能答案

【问题标题】：Redis / Rejson nested document hierarchy performanceRedis / Rejson 嵌套文档层次结构性能
【发布时间】：2020-09-16 15:29:49
【问题描述】：

我将记录存储为 json 文档，根据记录类型组织成层次结构。将这些存储在 Redis 中的传统方法是：

customer:walmart   = {...}
customer:target    = {...}
order:po123        = {...}
person:bob         = {...]
person:tom         = {...}

但是，Rejson（又名 RedisJSON）让我们可以有效地从路径中查询子文档，因为它将 json 存储为哈希表的实际哈希表。因此，我可以将我的记录组织在一个实际的层次结构中，这也有助于在根目录中适应 Redis 中不同的键限制。

["customer"]    = {"walmart": {...}, "target": {...}, "amazon": {...}}
["order"]       = {"po1": {...}, "po2": {...}, "po3": {...}}
["transaction"] = {"uuid1": {...}, "uuid2": {...}, "uuid3": {...}}
["person"]      = {"bob": {...}, "tom": {...}, "dave": {...}}
["widget"]      = {"this": {...}, "that": {...}, "other": {...}}

我会定期检索一条或多条相同类型的记录。例如，我可能想要检索target（customer）或bob 和tom（persons）。我很少从单一类型中检索所有条记录。

这两种不同方法之间的性能差异是什么？ Rejson 是否使基于 json 路径（上面的“记录”）检索子文档的效率与从根 Redis 存储中检索文档的效率大致相同？

Rejson 似乎没有办法在单个命令/获取中检索上面的 bob 和 tom。 mget 获取跨多个根 Redis 键的公共路径。这与我想要的相反，是我在滥用 Redis 的标志。

即使使用 Rejson，以这种方式使用的蓄意数据层次结构是否应该因为性能损失而被视为不好的做法？

【问题讨论】：

标签： json redis redisjson

【解决方案1】：

这两种不同方法之间的性能差异是什么？ Rejson 是否使基于 json 路径（上面的“记录”）检索子文档的效率与从根 Redis 存储中检索文档的效率大致相同？

RedisJSON 正在基于 JsonPath 检索子文档部分，因此显然 JsonPath 越复杂，它会增加更多开销。但是像你上面提到的简单路径不应该带来很大的开销。

Rejson 似乎没有办法在单个命令/获取中检索上面的 bob 和 tom。

RedisJSON json.get 支持多路径，因此您可以调用JSON.GET customer .bob .tom。此外，即将推出的 RedisJSON 2.0 包括对 JsonPath 的全面支持，因此您应该能够运行 JSON.GET customer .["bob"|"tom"]

即使使用 Rejson，以这种方式使用的蓄意数据层次结构是否应该因为性能损失而被视为不好的做法？

您应该考虑的是，如果您使用 Redis 集群，您是否需要将所有“部分”放在同一个分片中，您是否需要原子/事务更新这些部分？

【讨论】：