Master-X
Регистрация
|
Вход
Форум
|
Новости
|
Статьи
Главная
»
Форум
»
Программинг, Скрипты, Софт, Сервисы
»
Тема:
Redis - что лучше много коротких документов или один большой
Новая тема
Ответить
цитата
22/09/17 в 21:06
S_Flash
Речь именно о производительности.
Есть возможность хранить раздробленными хешами по группам под разными ключами или запихнуть всю инфу в один большой хеш под одним единым ключом. Кто-то вкурсе как оптимальнее поступить?
цитата
22/09/17 в 22:05
DF™
Думаю искать по ключу он будет примерно одинаково, а передавать инфу дольше при одном хеше т.к. её тупо больше.
Не вижу особого смысла использовать Redis для одного ключа, на это есть другие инструменты - разделяемая память например или тупо файл (лучше на ssd или ram-диске).
цитата
23/09/17 в 07:45
rickdeckard
S_Flash писал:
Речь именно о производительности.
Есть возможность хранить раздробленными хешами по группам под разными ключами или запихнуть всю инфу в один большой хеш под одним единым ключом. Кто-то вкурсе как оптимальнее поступить?
если хранить все по 1 ключу - придется постоянно сериализовывать и десериализовывать при каждой необходимости изменения или чтения. это получается как memcache
а если данные не меняются или меняются не часто - лучше тогда сделать var_export в php файл и подключать через include - тогда через opcache само все будет оптимально работать и кешироваться без всяких redis.
цитата
23/09/17 в 10:55
S_Flash
Кеш страниц отдельно. Речь именно про реализации параллельных страницам метрик в хеши.
Просто есть вариант плодить подобный хеш с метриками для каждой страницы отдельно, а есть вариант реализации, при котором метрики страниц группируются по определённому признаку и могут спокойно обслуживаться одинм общим хешем для группы. Серелизовать ничего не приходится, так как операция hincrby решает все реалтайм операции в этих хешах-метриках.
цитата
23/09/17 в 12:23
DF™
S_Flash писал:
Серелизовать ничего не приходится, так как операция hincrby решает все реалтайм операции в этих хешах-метриках.
Используя hincrby ты два поиска получается делаешь - по хешу и по полю, а там один только по ключу.
Несложно протестировать так и так, может вообще разницы в скорости не заметишь на своих данных.
Последний раз редактировалось: DF™ (
23/09/17 в 15:34
), всего редактировалось 1 раз
цитата
23/09/17 в 14:15
S_Flash
DF™ писал:
Используя hincrby ты два поиска получается делаешь - по хешу и по полю, а там один только по хешу.
Несложно протестировать так и так, может вообще разницы в скорости не заметишь на своих данных.
Чёт не уловил мысль про второй вариант.
hincrby - использую на случай, чтоб избежать наслоения данных на случай, если два события одновременно спровоцируют инкремент моей метрики. В случае с серилизацией и текстовым полем есть хоть и маловероятный, но возможный вариант, когда в одно и то же время скриптом будут взяты устаревшие данные, а в случае hincrby инкремент всегда добавляется в очередь и отрабатывает коректно в синхронных вызовах.
цитата
23/09/17 в 15:30
DF™
Я понял про hincrby
Когда ты хранишь в одном хеше используешь типа: HINCRBY myhash field 1
Когда много ключей типа: INCRBY mykey 5
Два поиска и один!
цитата
23/09/17 в 21:10
Mika
Если выбор оптимального решения действительно важен, то сгенери данные более-менее отражающие реальные, и напиши бенчмарк.
Новая тема
Ответить
Эта страница в полной версии