Что такое Redis
Предпосылки: ACID, базовые структуры данных (массив, хеш-таблица, связный список), TCP (клиент-серверное соединение).
Структуры данных с сетевым доступом
Программисты привыкли к структурам данных внутри процесса: хеш-таблица для быстрого поиска по ключу, список для очереди задач, множество для проверки уникальности. Проблема в том, что такие структуры живут в памяти одного процесса — другие процессы и серверы к ним доступа не имеют, а при рестарте приложения данные пропадают.
Redis — это именно такие структуры данных (строки, хеш-таблицы, списки, множества, упорядоченные множества), но вынесенные в отдельный сервер с сетевым интерфейсом. Любой процесс может подключиться к Redis по TCP и работать с ними. Данные переживают рестарт приложения, хотя не обязательно переживут рестарт самого Redis — это зависит от настроек персистентности (механизмов сохранения данных на диск).
Определение «Redis — это NoSQL база данных» формально верно, но создаёт неправильные ожидания. Redis не хранит данные в таблицах, не поддерживает SQL, не даёт JOIN и rollback. Точнее думать о нём как о сервере структур данных в оперативной памяти.
Почему Redis быстрый
Раз данные живут в оперативной памяти, Redis не нужно делать то, что делает дисковая СУБД для каждой операции. Сравним одно и то же действие — инкремент счётчика.
PostgreSQL при UPDATE counter SET value = value + 1 делает много работы ради durability и изоляции: берёт блокировку, создаёт новую версию строки для параллельных транзакций, фиксирует изменение в журнале на диске, обновляет индексы. Каждый шаг защищает данные от потери или повреждения, но каждый стоит времени.
Redis при INCR counter находит значение в хеш-таблице прямо в оперативной памяти, увеличивает число и возвращает результат. Нет версий строк, нет журналирования каждой операции, нет блокировок.
На горячем счётчике (просмотры страницы, rate limiting, метрика) это даёт разницу в 1–2 порядка пропускной способности: условно сотни тысяч INCR/сек против тысяч–десятков тысяч UPDATE+COMMIT/сек в PostgreSQL. Точные цифры зависят от конфигурации, но порядок величин устойчив.
Компромиссы: что Redis отдаёт за скорость
Все шаги, которые Redis пропускает (журналирование, блокировки, версионность), существовали в PostgreSQL не просто так — они обеспечивали гарантии сохранности данных. Без них данные в Redis менее защищены: при падении сервера часть последних операций может потеряться.
Но не все данные одинаково ценны. Оформленный заказ или платёжная транзакция — потеря приводит к финансовым последствиям. Кеш тяжёлого запроса, онлайн-статус пользователя, счётчик непрочитанных уведомлений — при потере всё пересчитается за секунды. Вопрос «что произойдёт, если эти данные исчезнут?» определяет выбор хранилища.
Redis можно запускать на нескольких серверах (репликация и кластер, обзор — в разделе распределения). Копирование данных между серверами происходит асинхронно — мастер не ждёт подтверждения от копий. Это означает, что при падении мастера несколько последних операций могут потеряться. Подробнее о компромиссах распределённой конфигурации — в разделе распределения и в CAP-теореме.
Поэтому Redis и PostgreSQL не конкурируют, а дополняют друг друга: каждый работает с данными той ценности, для которой спроектирован.
Однопоточная модель исполнения обеспечивает атомарность команд без блокировок — подробно об этом в event loop.
Sources
- Redis Documentation: Introduction. https://redis.io/docs/about/
- Eric Brewer, «CAP Twelve Years Later», 2012. https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/