Redis - что лучше много коротких документов или один большой

Речь именно о производительности.
Есть возможность хранить раздробленными хешами по группам под разными ключами или запихнуть всю инфу в один большой хеш под одним единым ключом. Кто-то вкурсе как оптимальнее поступить?

Думаю искать по ключу он будет примерно одинаково, а передавать инфу дольше при одном хеше т.к. её тупо больше.
Не вижу особого смысла использовать Redis для одного ключа, на это есть другие инструменты - разделяемая память например или тупо файл (лучше на ssd или ram-диске).

S_Flash писал:

Речь именно о производительности. Есть возможность хранить раздробленными хешами по группам под разными ключами или запихнуть всю инфу в один большой хеш под одним единым ключом. Кто-то вкурсе как оптимальнее поступить?

если хранить все по 1 ключу - придется постоянно сериализовывать и десериализовывать при каждой необходимости изменения или чтения. это получается как memcache

а если данные не меняются или меняются не часто - лучше тогда сделать var_export в php файл и подключать через include - тогда через opcache само все будет оптимально работать и кешироваться без всяких redis.

Кеш страниц отдельно. Речь именно про реализации параллельных страницам метрик в хеши.
Просто есть вариант плодить подобный хеш с метриками для каждой страницы отдельно, а есть вариант реализации, при котором метрики страниц группируются по определённому признаку и могут спокойно обслуживаться одинм общим хешем для группы. Серелизовать ничего не приходится, так как операция hincrby решает все реалтайм операции в этих хешах-метриках.

S_Flash писал:

Серелизовать ничего не приходится, так как операция hincrby решает все реалтайм операции в этих хешах-метриках.

Используя hincrby ты два поиска получается делаешь - по хешу и по полю, а там один только по ключу.
Несложно протестировать так и так, может вообще разницы в скорости не заметишь на своих данных.

Последний раз редактировалось: DF™ (23/09/17 в 15:34), всего редактировалось 1 раз

DF™ писал:

Используя hincrby ты два поиска получается делаешь - по хешу и по полю, а там один только по хешу. Несложно протестировать так и так, может вообще разницы в скорости не заметишь на своих данных.

Чёт не уловил мысль про второй вариант.
hincrby - использую на случай, чтоб избежать наслоения данных на случай, если два события одновременно спровоцируют инкремент моей метрики. В случае с серилизацией и текстовым полем есть хоть и маловероятный, но возможный вариант, когда в одно и то же время скриптом будут взяты устаревшие данные, а в случае hincrby инкремент всегда добавляется в очередь и отрабатывает коректно в синхронных вызовах.

Я понял про hincrby
Когда ты хранишь в одном хеше используешь типа: HINCRBY myhash field 1
Когда много ключей типа: INCRBY mykey 5
Два поиска и один!

Если выбор оптимального решения действительно важен, то сгенери данные более-менее отражающие реальные, и напиши бенчмарк.