Redis / Re json производительность иерархии вложенных документов

Question

Я храню записи как json документов, организованных в иерархию на основе типа записи. Традиционный способ хранить их в Redis - иметь что-то вроде:

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

Однако Re json (он же Redis JSON) позволяет нам эффективно запрашивать вложенные документы из пути. , поскольку он хранит json как фактические хэш-таблицы хэш-таблиц. Поэтому я мог бы вместо этого организовать свои записи в фактическую иерархию, что также помогло бы учесть отдельные ограничения ключей в Redis на root.

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

Я регулярно получаю одну или несколько записей одного и того же типа. Например, я могу получить target (a customer) или оба bob и tom (person s). Я редко получаю все записи из одного типа.

В чем разница в производительности между этими двумя разными подходами? Делает ли Re json получение поддокумента на основе пути json («запись» выше) примерно таким же эффективным, как получение документа из хранилища root Redis?

Re json не похоже, есть способ получить bob и tom, указанные выше, с помощью одной команды / fetch. mget выбирает общий путь для нескольких ключей root Redis. Это противоположно тому, что я хочу, и является признаком того, что я злоупотребляю Redis.

Даже с Re json, следует ли считать использование преднамеренных иерархий данных таким образом плохой практикой из-за снижения производительности?

Answer 1

В чем разница в производительности между этими двумя разными подходами? Делает ли Re json получение поддокумента на основе пути json («запись» выше) примерно таким же эффективным, как получение документа из хранилища root Redis?

Redis JSON извлекает части вложенного документа на основе JsonPath, поэтому очевидно, что чем сложнее JsonPath, тем больше накладных расходов он добавит. Но простые пути, подобные упомянутым выше, не должны вызывать больших накладных расходов.

Re json похоже, не имеет способа получить боб и том выше в одной команде / fetch.

Redis JSON json .get поддерживает несколько путей, поэтому вы можете вызывать JSON.GET customer .bob .tom. Также грядущий Redis JSON 2.0 включает полную поддержку JsonPath, поэтому вы должны иметь возможность запускать JSON.GET customer .["bob"|"tom"]

Даже с Re json, следует учитывать преднамеренные иерархии данных, используемые таким образом плохая практика из-за снижения производительности?

Здесь следует учесть следующее: нужно ли, чтобы все «части» находились в одном сегменте, если вы используете Redis Cluster, нужно ли атомарно / транзакция обновить те часть?