Remote Dictionary Server, или сокращенно Redis, — это молниеносная база данных в памяти, которая хранит значения в парах ключ-значение. Она в основном используется в качестве механизма кэширования для таких баз данных, как базы данных SQL и документов.
Поскольку Redis является базой данных в памяти, используемое пространство имеет решающее значение и требует тщательного мониторинга. Одной из стратегий улучшения и оптимизации производительности памяти для Redis является использование сжатия.
По умолчанию Redis не обеспечивает сжатие любых хранимых данных. Следовательно, в приложении реализованы методы сжатия.
Давайте обсудим несколько методов, которые вы можете использовать для оптимизации производительности памяти в Redis.
Реализуйте алгоритм сжатия
Поскольку Redis не сжимает сохраненные значения, вы должны сделать это перед их сохранением. Существует несколько алгоритмов сжатия для сжатия строк перед их сохранением.
К таким алгоритмам относятся:
- Сжатие LZO — очень быстрое и обеспечивает более высокую скорость декомпрессии.
- LZ4 — эффективен по скорости и очень легко интегрируется в приложения.
- Snappy — высокая скорость сжатия/распаковки.
Используйте более короткие имена ключей
Хотя разработчикам следует отдавать предпочтение более описательным именам, а не коротким, использование памяти может быстро возрасти, если у вас есть обширная коллекция ключей в базе данных.
Всегда рассмотрите возможность использования коротких имен ключей для ваших данных ключ-значение, чтобы избежать этого.
Пример:
SET this_is_a_very_large_key_name value
Вместо этого вы можете использовать имя ключа:
SET l_key_name value
Это уменьшает количество символов, которые Redis хранит в вашей базе данных.
Сжать имена полей
То же самое можно сказать и об именах полей. И опять же, использование более короткого имени поля может сэкономить несколько байтов или килобайт вашей памяти.
Следовательно, рассмотрите возможность использования коротких имен полей для ваших данных Redis.
Пример показан ниже:
127.0.0.1:6379> HSET user_info id 1 firstname Maki lastname K country "India"
Здесь мы можем сэкономить немного памяти, рефакторинг имен полей следующим образом:
HSET user_info id 1 fname Maki lname country In
Это сжимает имена полей и значения.
Используйте список вместо хеша
Хэш состоит из имен полей и соответствующих значений. Хотя это не является серьезной проблемой, она может быть проблематичной, когда в игру вступают тысячи типов хэшей.
Чтобы решить эту проблему, вы можете выбрать список, как показано ниже:
HSET user_info id 1 fname Maki lname country In
Вы можете преобразовать приведенный выше хеш в список как:
LPUSH ["fname", "Maki", "lname", "K", "country", "In"]
Избегайте динамических скриптов Lua
Чтобы сэкономить еще больше памяти, избегайте использования динамических LUA-скриптов, вызывающих увеличение кэша. Чем больше скриптов вы загружаете, тем больше вы потребляете много памяти.
Включить сжатие списка
Как уже упоминалось, Redis не сжимает хранящиеся в нем значения. Сюда входят элементы внутри списка. Для значений из короткого списка это едва ли проблема. Однако для длинных списков может быть полезно включить сжатие.
В файле Redis.conf найдите строку:
sudo cat /etc/redis/redis.conf | grep list-compress list-compress-depth 0 // change this value
Измените значение list-compress-depth на:
- 1 — сжимает все узлы списка, кроме головы и хвоста.
- 2 — никогда не сжимать голову или голову-> или хвост или хвост->пред.
- 3 – начать сжатие после head->next и tail->-prev
Обновите версию Redis
Еще один шаг, который вы можете предпринять, чтобы улучшить использование памяти на вашем сервере Redis, — это обновить версию Redis.
На момент написания этого руководства версия 4.0 (последняя) имела следующие функции.
- Он поддерживает смешанный формат RDB + AOF.
- Улучшение использования памяти и производительности.
- Введена новая команда памяти.
- Активная дефрагментация памяти.
- Более быстрое создание ключа кластера Redis.
Закрытие
В этой статье обсуждаются различные методы и приемы, которые можно использовать для оптимизации использования памяти в кластере Redis. Однако имейте в виду, что не все формы являются 100% гарантированными.