Производительность иерархии вложенных документов 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?

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

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

Answer 1

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

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

У Рейсона, похоже, нет способа получить боба и тома, указанные выше, с помощью одной команды / fetch.

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

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

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