Как использовать Valkey^™: три практических сценария для приложений и ИИ

Valkey хранит данные в оперативной памяти и подходит для сценариев, где важны низкая задержка и быстрый доступ. В статье разберём ограничения технологии, изменения в версии 9.1 и три практических сценария: кеш, распределённые блокировки и поиск для ИИ-агента.

Что такое Valkey

Valkey — свободная база данных типа key-value, которая преимущественно хранит информацию в оперативной памяти. Технология появилась как форк Redis^®. В Yandex Cloud она доступна в виде управляемого сервиса Yandex Managed Service for Valkey^™.

Проект Valkey появился после изменения лицензии Redis в марте 2024 года и сохраняет обратную совместимость с последней версией Redis под лицензией BSD — Redis 7.2. Поэтому во многих системах Valkey можно использовать вместо Redis без переработки интеграции.

Хранение данных в оперативной памяти обеспечивает быстрый доступ, но одновременно определяет сильные стороны и ограничения технологии.

Классические сценарии применения Valkey:

• Кеширование часто запрашиваемых данных перед основной базой или хранилищем.
• Хранение рассчитанных агрегатов, чтобы не выполнять одинаковые вычисления повторно.
• Очереди и Pub/Sub для обмена событиями между приложениями.
• Распределённые блокировки и координация микросервисов.
• Ограничение частоты запросов и другие сценарии, реализованные с помощью встроенного скриптового движка.
• Векторный поиск с модулем Valkey-Search.
• Работа с JSON и другими структурами данных с помощью подключаемых модулей.

Когда выбирать Valkey, а когда — другую систему

Valkey особенно полезен, когда приложению нужен максимально быстрый доступ к небольшому объёму данных. В контексте хранилища в оперативной памяти это могут быть гигабайты, десятки или даже сотни гигабайт. Хранить терабайты и петабайты таким способом дорого, хотя для отдельных задач предельная скорость может и оправдывать этот подход.

Технология хорошо подходит для кеша, промежуточных результатов обработки и координации множества сервисов. Но она не заменяет все остальные базы данных.

Главное ограничение связано с надёжностью хранения. В Yandex Managed Service for Valkey^™ используется асинхронная репликация: сначала результат запроса фиксируется на хосте-мастере, после чего данные передаются на реплики. Запись на диск также может происходить с задержкой. Подробнее этот механизм описан в разделе документации о репликации и персистентности.

Что изменилось в Valkey 9.1

Версия 9.1 развивает совместимость с Redis 7.2, но одновременно добавляет новые возможности управления доступом, команды, оптимизации, а также инструменты наблюдаемости.

Гранулярное управление доступом

В Valkey появились списки контроля доступа (ACL) на уровне базы данных. Раньше можно было управлять доступом пользователя к командам и ключам, но нельзя было ограничить его одной конкретной базой данных внутри экземпляра. В версии 9.1 пользователя можно привязать к определённой базе.

Новые атомарные операции

В версии добавили команды для работы с хешами и несколькими ключами. Они позволяют за одну атомарную операцию получить и удалить значение, установить значение вместе со сроком жизни или обработать несколько пар ключей и значений с экспирацией.

Для кластерного режима появилась возможность просканировать ключевое пространство всего кластера одной командой. Раньше каждую ноду приходилось обходить отдельно.

Изменения в Lua-движке

Lua-движок перенесли в модуль. Это позволило в Yandex Cloud создать модуль с тем же API, что у Lua 5.1, и повысить производительность до двух раз в отдельных сценариях.

Работа с сертификатами и зонами доступности

В версии 9.1 расширили возможности работы с TLS-сертификатами: автоматическое обновление, проверка при загрузке и контроль за сроком действия.

В кластерные команды добавили информацию о зонах доступности, чтобы вы могли точнее маршрутизировать запросы и снижать задержку.

Производительность и расход памяти

Valkey обрабатывает пользовательские команды в одном основном потоке, поэтому даже относительно быстрые системные вызовы могут влиять на производительность. В новой версии по умолчанию используются процессорные часы, а точное системное время при необходимости кешируется и корректируется по разнице показаний.

Разработчики также оптимизировали внутреннее хранение небольших значений. Для данных размером до 128 байт эффективность использования памяти в отдельных случаях выросла до 30%.

Кроме того, разработчики доработали механизм Copy Avoidance, который уменьшает количество лишних копирований данных при отправке клиенту, и снизили задержки во время рехеширования хеш-таблицы.

Наблюдаемость

В версии 9.1 появились:

• метрики загрузки основного потока;
• JSON-логи;
• контроль срока действия TLS-сертификатов;
• метрики объёма трафика между нодами кластера.

Эти данные помогают отличить реальную нагрузку на Valkey от особенностей работы системных утилит и быстрее находить «узкие места».

Как создать кластер в Yandex Managed Service for Valkey^™

Во всех трёх практических сценариях мы используем похожую базовую конфигурацию кластера. Подробная последовательность действий — в инструкции по созданию кластера Valkey.

1. В консоли Yandex Cloud выберите создание ресурса и перейдите в Yandex Managed Service for Valkey^™.
2. Задайте понятное имя, которое отражает назначение кластера. Это снижает риск перепутать тестовый и рабочий ресурс.
3. Выберите версию 9.1.
4. При необходимости включите использование FQDN вместо IP-адресов.
5. Настройте персистентность. Для кеша на вебинаре мы включали её только на репликах.
6. Задайте пароль пользователя.
7. Проверьте распределение хостов по зонам доступности.
8. Для кеширующего сценария настройте политику вытеснения ключей. Когда память закончится, Valkey сможет удалять старые значения вместо отказа при записи.
9. Оставьте включённым доступ из Yandex WebSQL, если планируете проверять ключи через интерфейс.

Изменить параметры уже созданного кластера можно по отдельной инструкции.

Конкретные ресурсы, сеть, группы безопасности и окно обслуживания зависят от среды. Для тестового стенда часть параметров можно оставить по умолчанию, а для рабочего кластера их нужно выбирать с учётом нагрузки и требований безопасности.

Сценарий № 1. Valkey как кеш для «1С-Битрикс»

В первом примере — типичный сценарий: приложение продолжает работать с основной базой данных, а Valkey хранит часто используемые данные и снижает количество повторных обращений к ней.

Шаг 1. Разворачиваем тестовый «1С-Битрикс»

На вебинаре мы развернули на виртуальной машине готовый образ «1С-Битрикс» из Yandex Cloud Marketplace вместе с необходимой базой данных.

Для доступа к машине настраиваем пользователя и SSH-ключ, а для рабочего окружения — отдельно проверяем сеть и группы безопасности.

Шаг 2. Создаём кластер Valkey для кеша

Кластер получил понятное имя, версию 9.1 и FQDN. Персистентность включаем на репликах, а в расширенных настройках задаём политику вытеснения ключей.

Это важно для кеша: при заполнении памяти сервис должен освобождать место под новые данные, а не прекращать запись.

Шаг 3. Подключаем кеш в конфигурации «1С-Битрикс»

Настройки добавляем в отдельный файл дополнительных параметров, не меняя основной конфигурационный файл. В качестве типа кеша указываем Redis и передаём адрес созданного кластера Valkey.

Благодаря совместимости с Redis 7.2 приложение подключается к Valkey через штатную настройку Redis без изменения прикладной логики.

Шаг 4. Проверяем интеграцию

В том, что кеш используется, можно убедиться несколькими способами:

• открыть панель производительности «1С-Битрикс» и проверить, что кеширование включено;
• посмотреть в разделе мониторинга Yandex Managed Service for Valkey^™ количество клиентов, объём данных, использование памяти, сетевой трафик и активность диска;
• подключиться через Yandex WebSQL и проверить появившиеся ключи.

В тестовом кластере выполняем команды для просмотра ключей и открываем отдельные значения через интерфейс. Команду KEYS не стоит запускать в рабочем кластере без оценки количества ключей и возможного влияния операции на сервер.

В результате «1С-Битрикс» сохраняет данные в Valkey после изменения конфигурации — без отдельной переработки приложения.

Сценарий № 2. Распределённые блокировки для 1С

Во втором примере Valkey будет координировать работу нескольких клиентов 1С. Задача — не позволить двум пользователям одновременно редактировать один и тот же элемент справочника.

Прямого коннектора к Valkey в демонстрационной конфигурации нет, поэтому между 1С и кластером мы разместили небольшой HTTP-сервис.

Схема взаимодействия такая: Клиент 1С → HTTP API блокировок → Valkey.

HTTP-сервис предоставляет методы для получения, освобождения и продления блокировки, проверки её статуса и просмотра списка активных блокировок.

Как получить блокировку

Для этого сервис выполняет команду SET с условием NX и сроком жизни ключа. Запись создаётся только в том случае, если ключ ещё не существует.

Экспирация защищает от ситуации, когда работа завершается аварийно, а блокировка остаётся навсегда. Ключ формируется из полного пути к объекту и его идентификатора. Значение содержит токен, по которому можно проверить владельца блокировки.

Как освободить или продлить блокировку

Освобождение выполняют Lua-скриптом через команду EVAL. Скрипт атомарно читает текущее значение ключа, сравнивает его с ожидаемым токеном и удаляет блокировку только при совпадении. Это не позволяет одному клиенту случайно освободить блокировку другого.

Продление построено по тому же принципу, но вместо удаления увеличивает TTL. На вебинаре клиент 1С обновлял блокировку каждые 30 секунд. Если продление не сработало, приложение понимает, что больше не имеет права изменять объект.

Как это выглядит в 1С

В модуле 1С реализованы HTTP-запросы к сервису блокировок. При открытии формы клиент пытается получить блокировку, во время работы периодически её продлевает, а при закрытии — освобождает.

На форме можно вывести статус, оставшееся время, владельца и токен блокировки.

Сценарий № 3. Valkey-Search и RAG для ИИ-агента

В третьем примере показываем, как использовать Valkey не только как key-value-хранилище, но и как поисковый компонент ИИ-приложения.

На вебинаре архитектура выглядела так: Данные приложения → Valkey-Search → RAG → MCP → ИИ-агент → модель в Yandex AI Studio.

Приложение генерирует записи о людях, загружает их в Valkey и индексирует с помощью модуля Valkey-Search.

Затем ИИ-агент через MCP обращается к поисковому компоненту, получает подходящие записи и формирует итоговый ответ с помощью модели из Yandex AI Studio. Подробнее об этом механизме — в документации о ИИ-агентах и MCP Hub.

Как подготовить кластер

При создании кластера нужно подключить модуль Valkey-Search. После этого становятся доступны дополнительные настройки, в том числе количество потоков чтения и записи.

Модуль можно подключить как при создании, так и в уже существующем кластере. Порядок действий мы описывали в инструкции по работе с модулями Valkey.

В вебинаре мы использовали версию 9.1, персистентность на репликах и доступ через Yandex WebSQL. Данные Valkey находятся в оперативной памяти, поэтому архитектура должна учитывать возможность их потери при отказах.

Как проходит запрос

После загрузки и индексации данных пользователь задаёт агенту вопрос о конкретном человеке. Системный промпт инструктирует модель обратиться к MCP-инструменту. Агент выполняет вызов, получает найденную запись и формулирует ответ.

В примере о Джеймсе Брауне, который мы показывали на вебинаре, запрос успешно отработал и на английском, и на русском языках. Через Yandex WebSQL можно дополнительно проверить, что исходные записи действительно находятся в хешах Valkey.

В этом сценарии Valkey-Search играет роль быстрого поискового слоя. Модуль индексирует прикладные данные, а ИИ-агент использует найденный контекст при подготовке ответа.

Чек-лист перед использованием Valkey

Перед созданием кластера проверьте несколько условий.

• Нужен ли приложению быстрый доступ к данным?
  Если низкая задержка не критична, хранение всего рабочего набора в оперативной памяти может быть неоправданно дорогим.

• Можно ли восстановить данные?
  Для кеша потеря части данных обычно допустима, а для единственного реестра транзакций — нет.

• Какой объём нужно будет хранить?
  Архитектура и стоимость кластера напрямую зависят от объёма оперативной памяти.

• Как приложение переживёт отказ мастера?
  Нужно учитывать асинхронную репликацию и возможную потерю последних записей.

• Как будет освобождаться память?
  Для кеша нужно заранее выбрать подходящую политику вытеснения ключей.

• Какие метрики нужно отслеживать?
  В первую очередь — загрузку основного потока, использование памяти, количество клиентов и сетевой трафик.

Вопросы и ответы

Заключение

Valkey стоит выбирать для конкретных задач, в которых важен быстрый доступ к данным: кеширования, координации нескольких клиентов или поиска контекста для ИИ-агента. При проектировании решения важно учитывать стоимость оперативной памяти, политику вытеснения ключей и допустимый риск потери последних изменений при отказе.