Логические базы Redis (SELECT)

Предпосылки: Что такое Redis.

Pipelining | String

Когда один неймспейс тесен

Один Redis-сервер, одно пространство ключей. Тестовый код пишет в ключ session:123 — и перезаписывает данные production-приложения, работающего с тем же Redis. Или часть команды использует ключи cache:*, другая часть — тоже cache:* для совсем других данных. Нужен способ разделить ключи, не поднимая отдельные Redis-серверы.

Несколько пространств ключей

В одном экземпляре Redis может быть несколько логических баз (db 0, 1, …, по умолчанию до 15). Это не отдельные процессы и не отдельные файлы — это несколько независимых пространств ключей внутри одного сервера.

Практический эффект: один и тот же ключ может существовать в разных db с разными значениями.

redis-cli -n 0 SET env prod
redis-cli -n 1 SET env test
 
redis-cli -n 0 GET env  # prod
redis-cli -n 1 GET env  # test

Как выбирается db

Выбор базы — часть состояния соединения:

  • можно выполнить SELECT 1;
  • или сразу указать базу при подключении (например, redis-cli -n 1).

Зачем это используют (и когда это плохая идея)

Логические базы используют как простой «неймспейс» внутри одного Redis: отделить тестовые ключи от продовых, временные ключи от постоянных, разные части приложения друг от друга.

Но db не дают изоляции ресурсов. Это всё ещё один Redis-процесс со своей общей памятью и общими настройками. Если нужна изоляция (лимиты, политики, доступы), обычно поднимают отдельные экземпляры Redis. Если нужно просто логически разделить ключи, часто достаточно префиксов в ключах (например, app1:user:123).

Что меняется в Redis Cluster

Когда Redis работает в кластерном режиме (ключи распределены по нескольким серверам — подробности в разделе Cluster), логических баз нет: всегда используется db 0, а команда SELECT запрещена. Если приложение опирается на db != 0, при переходе на Cluster этот приём нужно заменить префиксами ключей или разделением на разные кластеры.

Sources


Pipelining | String