Настройка NoSQL базы данных Redis

Redis - резидентная программа, предоставляющая функции и интерфейс для хранения разнородных структур данных в оперативной памяти, чем обеспечивается максимально быстрая работа с ними. Все данные Redis хранит в виде словаря, в котором ключи связаны со своими значениями. Одно из существенных отличий Redis от других подобных хранилищ данных заключается в том, что значениями ключей могут быть абстрактные типы данных (строки, списки, множества, хеш-таблицы, упорядоченные множества и др.). Таким образом Redis может быть использован в качестве базы данных, кэша, брокера сообщений... Также следует отметить, что Redis имеет встроенную репликацию, поддержку сетевых протоколов, сценариев на Lua, различных политик удаления ключей (key eviction), транзакций и многих других плюшек, а также легковесен и тащит за собой минимум зависимостей.

На своих серверах я применяю Redis в основном в качестве хранилища временных данных (т.е. кеша) для разностороннего софта. Итак, установка Redis производится очень просто:

pkg install redis

Конфигурационный файл располагается по пути /usr/local/etc/redis.conf, в нем содержатся все возможные параметры с подробными комментариями и допустимыми значениями. В файле написано более 1200 строк текста, поэтому его содержимое я здесь приводить не буду. 

Во FreeBSD возможен запуск нескольких демонов Redis, которые будут управлять различными базами данных и иметь изолированную среду со своими индивидуальными параметрами. Для этого стартовый скрипт /usr/local/etc/rc.d/redis предлагает использовать директиву redis_profiles. В случае ее применения скрипт будет запускать демон с конфигом /usr/local/etc/redis-NAME.conf, где вместо NAME подставляются названия из redis_profiles. Использование множества независимых экземпляров Redis предполагает задание разных файлов с логами, PID-файла, иного порта для подключения удаленных клиентов, а также других "уникальных" директив.

Удобно, что конфигурационный файл Redis можно расширять с помощью директивы include, причем параметры могут повторяться и актуальным будет последний. С учетом большого количества параметров в конфиге, в ходе использования Redis наиболее удобной является практика создания основного конфигурационного файла сервера, подключаемого в других файлах, в которых после директивы include будут заданы специфичные значения для каждого конкретного случая применения. Например, возможно не менять дефолтный конфиг Redis (т.к. в целом он оптимален), а сделать так:

# cat /usr/local/etc/redis-rstats.conf

include /usr/local/etc/redis.conf

protected-mode yes
port 0
unixsocket /var/run/redis/redis-rstats.sock
unixsocketperm 770

timeout 0

daemonize yes
supervised no
pidfile /var/run/redis/rstats.pid

loglevel notice
logfile /var/log/redis/redis-rstats.log

dbfilename rstats.rdb
maxmemory 500MB
maxmemory-policy volatile-ttl

Таким образом файл /etc/rc.conf будет выглядеть следующим образом:

redis_enable="YES"
redis_profiles="rstats"

Очень  удобно. После запуска можно проверить работоспособность сервиса командой redis-cli:

# redis-cli -s /var/run/redis/redis-rstats.sock ping
PONG

Если сервер работает, то он ответит PONG. После этого можно использовать сервис по назначению в сторонних программах. 

Наиболее важными параметрами для каждого экземпляра Redis являются настройка безопасности и использования памяти. Стоит отметить, что в Redis отсутствуют надежные механизмы защиты данных, в связи с чем целесообразно максимально ограничивать доступ к нему, например, в случае локального использования Unix-сокетами, в случае удаленного - задавать длинный пароль и передавать данные посредством TLS. Также можно сделать запрет на исполнение некоторых команд во время сессии с базой. Что касается использования памяти, то:

• Параметр maxmemory определяет максимальный объем памяти в байтах, который может использоваться Redis. Можно задать директиву в конфигурационном файле или в сессии к базе с помощью команды CONFIG SET  (естественно, если она не запрещена настройками). Установка maxmemory в "ноль" будет означать - отсутствие ограничений памяти. Такое поведение по умолчанию применяется для 64-разрядных систем, в то время как в 32-разрядных системах используется неявное ограничение памяти в объеме 3 ГБ. При исчерпании выделенного объема памяти Redis будет вести себя согласно политике чистки ключей, заданной в maxmemory-policy. 
• Параметр maxmemory-policy определяет политику вытеснения ключей при заполнении выделенного объема памяти. Возможные значения:
  • noeviction — не вытеснять данные, то есть если память закончилась, то при попытке записи вылезет ошибка (по умолчанию);
  • allkeys-lru — сохранить недавно использованные ключи, удалить давно использованные ключи (т.е. по времени);
  • allkeys-lfu — сохранить часто используемые ключи, удалить редко используемые ключи (т.е. по частоте);
  • volatile-lru — удалить давно использованные ключи, у которых поле expire имеет значение true;
  • volatile-lfu — удалить редко используемые ключи, у которых поле expire имеет значение true;
  • allkeys-random — случайным образом выбрать и удалить ключ, чтобы освободить место для добавленных новых данных;
  • volatile-random — случайным образом выбрать и удалить ключ из множества ключей, у которых поле expire имеет значение true, чтобы освободить место для добавленных новых данных;
  • volatile-ttl — удалить ключи, у которых поле expire имеет значение true и самый малый срок "жизни" (TTL).

Политики volatile-lru, volatile-lfu, volatile-random и volatile-ttl ведут себя как noeviction, если нет ключей для удаления, соответствующих предварительным условиям (т.е. нет с полем expire=true). Важно выбрать правильную политику чистки ключей в зависимости от условий  использования Redis. Политику удаления можно перенастроить во время сессии к базе, а значит, играясь данным параметром и отслеживая количество промахов и попаданий в кэш (команда INFO) возможно подобрать оптимальный вариант.

Согласно документации Redis целесообразно придерживаться следующего правила:

• allkeys-lru следует использовать, если ожидается, что к подмножеству элементов будут обращаться гораздо чаще в отдельном временном промежутке. Оптимальный параметр, если не знаете, что выбрать.
• allkeys-random, если осуществляется циклический доступ, при котором все ключи сканируются непрерывно, или когда ожидается, что распределение запросов к ключам будет равномерным.
• volatile-ttl, например, когда база данных используется просто для кэша.

Политики volatile-lru и volatile-random в основном полезны в случае, если необходимо использовать один экземпляр Redis для кэширования и одновременно для получения набора постоянных ключей. В тоже время, обычно для решения такой проблемы лучше запустить два экземпляра Redis. Также стоит отметить, что установка для ключа значения expire требует дополнительной памяти, поэтому использование политики, подобной allkeys-lru, более эффективно на системах с дефицитом оперативной памяти.