Знайомтеся: HotKV

HotKV це багатопотокове сховище даних, сумісне з Redis, написане з нуля на сучасному C++ і створене для того, щоб витискати максимум швидкості з сучасних багатоядерних серверів за найнижчої можливої вартості. Я Norbert E. Boros, засновник і CEO 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. Він також має fuzz-цілі для розбирача протоколу, диспетчеризації команд, завантаження 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. Модулі ШІ та enterprise-функції працюють на ліцензованих планах. Ціни перелічують, що містить кожен план. Актуальне покриття команд дивіться в документації. Понад набір команд 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 на ваших власних серверах.