json - Redis/Rejson 嵌套文档层次结构性能

Question

我将记录存储为 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 ( person 秒)。我很少从单一类型中检索所有记录。

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

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

即使使用 Rejson，以这种方式使用的故意数据层次结构是否应该被视为由于性能损失而导致的不良做法？

Answer 1

What is the performance difference between these two different approaches? Does Rejson make retrieving a subdocument based on a json path ('record' above) roughly as efficient as retrieving the document from the root Redis store?

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

Rejson doesn't appear to have a way to retrieve bob and tom above in a single command/fetch.

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

Even with Rejson, should deliberate data hierarchies used in this way be considered bad practice due to performance penalties?

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