Как работают базы данных типа «ключ-значение» (например, Redis, Memcached)
Ваше frontend-приложение работает быстро. Пользователи кликают, данные появляются, страницы загружаются мгновенно. За этим опытом часто стоит база данных типа «ключ-значение», которая выполняет основную работу — перехватывая запросы ещё до того, как они достигнут вашей основной базы данных. Понимание того, как работают эти системы, помогает принимать более обоснованные решения относительно кеширования, сессий и архитектуры backend.
Ключевые выводы
- Базы данных типа «ключ-значение» хранят и извлекают данные, используя уникальный ключ в паре со значением, жертвуя гибкостью запросов ради исключительной скорости.
- Хранение в памяти (RAM) обеспечивает поиск за константное время через хеш-таблицы, часто в 100–1000 раз быстрее, чем чтение с диска.
- Redis предлагает богатые структуры данных, опциональную персистентность и встроенную кластеризацию, в то время как Memcached превосходен как простой, многопоточный кеш специального назначения.
- Типичные сценарии использования включают управление сессиями, кеширование ответов API и ограничение частоты запросов — все ситуации, где низкая задержка имеет первостепенное значение.
- Хранилища типа «ключ-значение» дополняют реляционные базы данных, а не заменяют их. Используйте их как слой производительности, а не как основное хранилище данных.
Что такое база данных типа «ключ-значение»?
База данных типа «ключ-значение» — это тип NoSQL-хранилища, которое сохраняет и извлекает данные, используя простую двухчастную структуру: уникальный ключ и связанное с ним значение.
Представьте это как JavaScript-объект или хеш-карту:
"session:user:4821" → { userId: 4821, role: "admin", expires: 1720000000 }
"product:sku:9001" → { name: "Wireless Keyboard", price: 49.99 }Вы ищете данные по ключу. Вот и всё. Здесь нет языка запросов, нет JOIN, нет схемы. Именно это ограничение делает хранилища типа «ключ-значение» такими быстрыми.
Как хранение в памяти ускоряет поиск
Большинство баз данных типа «ключ-значение» — включая Redis и Memcached — хранят данные в оперативной памяти (RAM), а не на диске. Чтение с диска измеряется в миллисекундах. Чтение из памяти происходит за микросекунды, часто в 100–1000 раз быстрее.
Внутри эти системы используют хеш-таблицу: ключ хешируется в адрес памяти, и значение извлекается напрямую. Нет сканирования, нет индексации, нет планирования запросов. Время поиска фактически составляет O(1) — константа независимо от размера набора данных.
Вот почему хранилища типа «ключ-значение» являются выбором по умолчанию для слоёв кеширования, хранения сессий и любого backend-сервиса, где время отклика напрямую влияет на пользовательский опыт.
Базовые операции: SET, GET и истечение срока действия
Фундаментальные операции минимальны по дизайну:
- SET
key value— сохранить значение - GET
key— получить значение - DEL
key— удалить значение - EXPIRE
key seconds— автоматически удалить после истечения времени жизни (TTL)
TTL особенно полезен для кеширования. Вы сохраняете ответ API или отрендеренный HTML-фрагмент с 60-секундным сроком действия. Ваше приложение сначала читает из кеша. Если ключ отсутствует или истёк, оно обращается к базе данных и заново заполняет кеш. Этот паттерн — cache-aside — один из самых распространённых паттернов в веб-архитектуре.
Discover how at OpenReplay.com.
Redis vs. Memcached: ключевые архитектурные различия
Оба являются хранилищами типа «ключ-значение» в памяти. Оба обеспечивают производительность с задержками менее миллисекунды. Но они делают разные компромиссы.
| Характеристика | Redis | Memcached |
|---|---|---|
| Типы данных | Строки, списки, множества, хеши, упорядоченные множества, потоки и другие | Только строки |
| Ограничение размера значения | До 512 МБ | До 1 МБ |
| Персистентность | Опционально (RDB-снимки или append-only файл) | Отсутствует — полностью volatile |
| Многопоточность | Однопоточный event loop (I/O threading добавлен в 6.0+) | Полностью многопоточный |
| Освобождение памяти | Возвращает освобождённую память ОС | Удерживает выделенную память через slab allocator до перезапуска |
| Встроенная кластеризация | Да (Redis Cluster, Sentinel) | Требует клиентского шардинга |
Memcached — это специализированный кеш. Он простой, быстрый и предсказуемый. Его slab-based аллокатор памяти поддерживает низкую фрагментацию, делая использование памяти очень стабильным — полезно, когда вам нужен жёсткий потолок памяти. Это отличный выбор, когда вы кешируете простые строки и не хотите ничего большего.
Redis — это более широкое хранилище структур данных в памяти. Помимо кеширования, он поддерживает упорядоченные множества для таблиц лидеров, pub/sub-обмен сообщениями, атомарные счётчики и опциональную персистентность. Современный Redis используется как кеш, хранилище сессий, брокер сообщений и лёгкая база данных — иногда всё сразу. Стоит отметить: лицензирование Redis изменилось начиная с 2024 года, что привело некоторые команды к оценке Valkey — совместимого open-source форка, поддерживаемого Linux Foundation под пермиссивной лицензией.
Где базы данных типа «ключ-значение» используются в системах, ориентированных на frontend
С точки зрения frontend-разработчика, хранилище типа «ключ-значение» обычно появляется в трёх местах:
- Управление сессиями — хранение токенов аутентификации, состояния пользователя и настроек на стороне сервера
- Кеширование ответов API — снижение нагрузки на базу данных и ускорение повторяющихся запросов
- Ограничение частоты запросов (rate limiting) — отслеживание количества запросов на пользователя или IP с использованием атомарных операций инкремента
Каждый из этих случаев напрямую выигрывает от того, что базы данных типа «ключ-значение» делают лучше всего: быстрое чтение, быстрая запись и простая логика истечения срока действия.
Когда не следует использовать хранилище типа «ключ-значение»
Базы данных типа «ключ-значение» не являются заменой реляционных баз данных. У них есть реальные ограничения:
- Большинство запросов основаны на ключах, с ограниченной поддержкой фильтрации или сортировки по сравнению с реляционными базами данных.
- Нет встроенных связей между записями
- Не подходят для сложной отчётности или аналитики
- Моделирование данных требует тщательного проектирования ключей заранее
Если ваши данные имеют связи или требуют гибких запросов, выбирайте PostgreSQL или документную базу данных. Используйте хранилище типа «ключ-значение» как слой производительности поверх вашего основного хранилища данных, а не как его замену.
Заключение
Базы данных типа «ключ-значение» работают потому, что они обменивают сложность на скорость. Они делают одну вещь — хранят и извлекают значения по ключу, в основном в памяти — и делают это исключительно хорошо. Независимо от того, выберете ли вы Redis за его гибкость или Memcached за его простоту, понимание базовой модели помогает использовать эти инструменты там, где они действительно нужны: как быстрый, целенаправленный слой, который поддерживает отзывчивость ваших приложений.
Часто задаваемые вопросы
Redis поддерживает два опциональных механизма персистентности: RDB-снимки, которые сохраняют набор данных через настроенные интервалы, и append-only файл (AOF), который логирует каждую операцию записи. Вы можете использовать один или оба механизма. Без включённой персистентности данные теряются при перезапуске, как и в Memcached. Для чистого кеширования персистентность часто не нужна.
Memcached — хороший выбор, когда вам нужен простой, многопоточный кеш для простых строковых значений и вы хотите предсказуемое использование памяти с минимальной конфигурацией. Если вам не нужны богатые структуры данных, персистентность или встроенная кластеризация, простота Memcached и эффективный slab-based аллокатор памяти делают его надёжным, лёгким вариантом.
И Redis, и Memcached используют политики вытеснения для управления лимитами памяти. Memcached использует LRU (least recently used — наименее недавно использованный) по умолчанию. Redis предлагает несколько настраиваемых политик, включая LRU, LFU (least frequently used — наименее часто использованный), случайное вытеснение и режим no-eviction, который возвращает ошибки при записи, когда память заполнена.
Redis может функционировать как основное хранилище данных для специфических сценариев использования, таких как управление сессиями, счётчики или таблицы лидеров в реальном времени, особенно с включённой персистентностью. Однако ему не хватает реляционных запросов, принудительных схем и зрелой поддержки транзакций. Для большинства приложений он лучше всего работает как дополнительный слой производительности наряду с реляционной или документной базой данных.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
