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

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

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

然而，（也称为RedisJSON）允许我们从路径高效地查询子文档，因为它将json存储为哈希表的实际哈希表。因此，我可以将我的记录组织在一个实际的层次结构中，这也有助于从根本上适应Redis中不同的键限制

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

我定期检索一个或多个相同类型的记录。例如，我可能希望检索

目标

（a

客户

）或同时检索

鲍勃

和

汤姆

（

个人

s）。我很少从单一类型检索所有记录

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

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

bob

和

tom

mget

获取跨多个根Redis键的公共路径。这与我想要的正好相反，这是我滥用Redis的一个迹象

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

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

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

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

RedisJSON支持多路径，因此您可以调用

JSON.GET customer.bob.tom

。 此外，即将推出的RedisJSON 2.0还包括对JsonPath的完全支持，因此您应该能够运行

JSON.GET customer。[“bob”|“tom”]

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

你应该考虑的是，你是否需要所有的“部件”坐在同一个碎片上，以防你使用ReIIS集群，你需要原子/事务更新那些部分吗？p>