Представляем HotKV

HotKV - это многопоточное Redis-совместимое хранилище данных, написанное с нуля на современном C++ и созданное для того, чтобы выжимать максимум скорости из современных многоядерных серверов при минимально возможной стоимости. Я Норберт Э. Борош, основатель и генеральный директор HotKV Ltd. В этой статье я объясняю, почему создал его, что оно умеет сегодня и как показало себя в измерениях.

Коротко. HotKV выполняет команды на многих потоках одновременно внутри одного процесса и понимает RESP2 и RESP3, протокол Redis. В нашем бенчмарке одного экземпляра на 160 vCPU в октябре 2026 года он показал наибольшую пропускную способность на 11 из 12 измеренных команд, а на двенадцатой Dragonfly был на одном уровне с ним. Условия теста и его ограничения описаны ниже.

Почему я создал HotKV

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

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

Параллельно я использовал Redis и Valkey во многих проектах, которым нужен был быстрый кеш: хранилища сеансов, списки IP-адресов, заблокированных межсетевым экраном, и кеш перед сотнями миллионов записей в SQL Server. Это отличные инструменты. Но они же заставили меня задуматься, на что было бы способно хранилище «ключ - значение», если бы его с самого начала проектировали для многоядерных серверов, которые мы используем сегодня.

HotKV - это ответ, к которому я пришёл. Я написал его с нуля на современном C++, чтобы получить из железа как можно больше скорости при минимально возможной стоимости. Бенчмарк ниже показывает, где он находится сегодня, и я ожидаю, что можно выиграть ещё больше.

Стоимость ИИ

Была и вторая причина. Запуск ИИ-приложений становился дорогим, для меня и, судя по тому, чем делились разработчики в сети, для многих других. Значительная часть этих затрат часто возникает из-за того, что модели отправляют вопросы, на которые она уже отвечала. Быстрое хранилище, которое узнаёт повторяющийся или похожий вопрос и отвечает на него из кеша, - один из самых прямых способов сократить этот счёт, поэтому кеширование для ИИ-нагрузок - основная часть HotKV.

Для чего нужен HotKV

HotKV Ltd существует для того, чтобы такое программное обеспечение стало производительнее и доступнее. У современных серверов много ядер, и хранилище данных должно ими пользоваться, чтобы вы получали как можно больше скорости при минимально возможной стоимости.

Вторая идея - держать больше частей стека в одном месте. Команды, строящие продукты на LLM, часто в итоге запускают кеш, векторную базу данных и место для памяти агентов, а между ними гору связующего кода. Я хочу, чтобы кеширование и построенная вокруг него работа с ИИ жили в одном движке, рядом с вашими данными: точное и семантическое кеширование вызовов моделей, векторный поиск, память агентов и бюджеты токенов. Меньше систем в эксплуатации должно означать меньше подвижных частей и меньший счёт. Страница об ИИ перечисляет то, что доступно сегодня, а бенчмарк экономии токенов показывает, что кеширование вызовов моделей сэкономило в нашем тесте.

HotKV сохраняет протокол Redis и привычные клиентские библиотеки.

Проблема

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

Чем HotKV отличается

HotKV™ написан на C++20 и рассчитан на выполнение команд сразу на многих ядрах, поэтому один экземпляр может использовать всю машину. Dragonfly, который мы тоже сравниваем ниже, также применяет многопоточный подход.

• Много ядер, один экземпляр. Команды выполняются одновременно на ядрах машины, поэтому один экземпляр может использовать большой сервер вместо нескольких маленьких.
• Привычные клиенты и протокол. HotKV поддерживает RESP2 и RESP3, поэтому к нему могут подключаться привычные клиентские библиотеки. Поддерживаются транзакции (MULTI/EXEC) и скрипты Lua. Поддерживаемые команды и различия см. в документации по командам.

Как он построен и протестирован

Я создаю HotKV сам и использую помощь ИИ там, где она полезна. Важнее того, как написана строка, то, выдерживает ли она проверку, поэтому движок тестируется жёстко. У него более 2 000 автоматизированных тестов, и он собирается с AddressSanitizer, ThreadSanitizer и UndefinedBehaviorSanitizer. Есть также цели фаззинга для разборщика протокола, диспетчеризации команд, загрузки RDB и AOF, потока репликации и шины кластера.

Условия бенчмарка, его ограничения и полные результаты приведены на странице «Производительность», чтобы вы могли оценить цифры сами.

Краткий итог бенчмарка

Обновлено в октябре 2026 года: цифры, впервые опубликованные в этой статье, получены в запусках бенчмарка, которые мы позже признали ошибочными (среди прочего, все генераторы нагрузки использовали одно и то же случайное зерно), поэтому мы заменили их результатами из нашего перестроенного бенчмарка.

Октябрь 2026: HotKV, Redis, Valkey и Dragonfly

Этот бенчмарк провела HotKV Ltd. Мы измерили HotKV, собранный из исходного кода, в сравнении с Redis 8.10.2, Valkey 9.1.2 и Dragonfly 2.0.2. Каждый сервер работал отдельно, как один экземпляр на всех 160 vCPU Azure D160alds_v7 (AMD EPYC 9V45), с отключённым сохранением данных. Три отдельные машины по 64 vCPU создавали нагрузку с помощью memtier_benchmark: значения по 256 байт, глубина конвейера 30 и 5 000 000 предварительно заполненных ключей. Каждое значение - медиана трёх 10-секундных запусков.

HotKV показал наибольшую пропускную способность на 11 из 12 команд. По сравнению с Redis или Valkey он показал от 8,6 до не менее чем 69,7 их пропускной способности, в зависимости от команды и сервера; по сравнению с Dragonfly - от 1,97 до 4,41 на этих 11 командах, причём несколько значений являются нижними границами. На PING Dragonfly оказался на 0,6 процента впереди. Мы считаем это ничьей, потому что генераторы нагрузки были близки к собственному пределу. Наибольший показатель на команде работы с данными - 90,8 миллиона операций INCR в секунду. INCR и PING перемещают мало данных и ограничены генераторами нагрузки, поэтому собственный показатель HotKV для них может быть выше.

Как читать таблицу

MGET читает восемь ключей, а MSET записывает четыре пары «ключ - значение» за команду, и пропускная способность считает команды. Отчёт помечает семь показателей HotKV (GET и шесть команд записи), потому что они достигли его порога использования сети в 85%, а PING - потому что генераторы нагрузки работали при загрузке процессора выше 85%. Отношения, построенные на них, являются нижними границами и помечены ≥. GET и PING - настоящие пределы. Для шести команд записи показатель использования сети в отчёте складывает входящий и исходящий трафик и сравнивает его с исходящим лимитом, поэтому он завышает близость к пределу. Самая тяжёлая из них, SETNX, использовала не более примерно 80% измеренного входного предела. Мы сохраняем ≥ для них как консервативное соглашение. Полные таблицы, пометки и примечания к методике - на странице «Производительность».

Область применимости бенчмарка

• Сборка и настройка. HotKV был скомпилирован с -march=native под тестовый процессор, тогда как остальные серверы были стандартными релизными сборками.
• Настройки потоков. Каждому серверу выделили все ядра машины: HotKV --threads 160, Dragonfly 160 потоков proactor, Valkey io-threads 160 и Redis io-threads 128, его максимум. Redis и Valkey выполняют команды в одном потоке и могут достичь большей пропускной способности с меньшим числом потоков ввода-вывода, поэтому их показатели могут быть ниже наилучших. Кластеры или несколько их экземпляров мы не запускали.
• Охват. Двенадцать команд, один размер значения, одна глубина конвейера, без TLS и без сохранения данных. LPOP и RPOP не измерялись, потому что при таких скоростях разрушающее чтение опустошает любой список, помещающийся в память, за 10 секунд. Отчёт фиксирует задержку и расход памяти, но мы не сравниваем их здесь. Серверы выполняли очень разный объём работы в каждом 10-секундном запуске, поэтому показатели памяти несопоставимы. Смешанные нагрузки не измерялись.
• Разброс. Redis сильно различался между тремя запусками на нескольких командах, до 7,2 раза между самым быстрым и самым медленным запуском на HSET, и медиана это скрывает. При сравнении с самым быстрым запуском каждого конкурента вместо медианы HotKV всё равно лидировал на всех 11 командах.

Redis, Valkey и Dragonfly являются товарными знаками соответствующих владельцев. Они названы только для обозначения измеренного программного обеспечения, и это не подразумевает спонсорства, одобрения или связи.

Что доступно сегодня

Основные семейства команд включают строки, списки, множества, хеши, отсортированные множества, потоки, геопространственные индексы, битовые карты, HyperLogLog, pub/sub и скрипты Lua. Модули ИИ и корпоративные возможности работают на лицензируемых тарифах. Цены перечисляют, что включает каждый тариф. Актуальный охват команд см. в документации. Помимо набора команд Redis:

• Теги ключей: помечайте ключи произвольными тегами и делайте запросы по тегам (TAG.SET, TAG.MEMBERS и ещё пять команд).
• TTL в наносекундах: NEXPIRE, NTTL и NEXPIREAT задают и читают срок жизни в наносекундах, поэтому сроки могут быть точнее миллисекунды. Истёкшие ключи освобождаются фоновой очисткой и при обращении к ним.
• Необязательное сжатие значений: для значений выше порога размера (по умолчанию 512 байт), выключено, пока вы его не включите.
• Снимки без fork: BGSAVE записывает в фоновом потоке, а не в разветвлённом процессе. Снимок не является копией на момент времени. Каждый ключ сохраняется таким, каким он был, когда до него дошёл снимок. Перезапись файла только для добавления выполняет fork.
• Метрики Prometheus: встроенная HTTP-конечная точка, по умолчанию выключена и включается через metrics-port, поэтому внешний экспортёр не нужен.

В HotKV также есть встроенный векторный поиск с индексами HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Мы сравнили его с Redis 8 в статье Векторный поиск: HotKV против векторных наборов Redis 8, от 1 до 100 клиентов.

Начните с HotKV Cloud или свяжитесь с отделом продаж, чтобы запустить HotKV на собственных серверах.