Představujeme HotKV

HotKV je multithreadové datové úložiště kompatibilní s Redisem, napsané od nuly v moderním C++ a postavené tak, aby z moderních serverů s mnoha jádry dostalo co nejvíc rychlosti při co nejnižších nákladech. Jsem Norbert E. Boros, zakladatel a CEO společnosti HotKV Ltd. Tento článek vysvětluje, proč jsem ho vytvořil, co dnes umí a jak dopadlo měření.

Stručně. HotKV provádí příkazy na mnoha vláknech najednou v jediném procesu a mluví RESP2 a RESP3, tedy protokolem Redisu. V našem říjnovém benchmarku z roku 2026 s jednou instancí na 160 vCPU dosáhlo nejvyšší propustnosti u 11 z 12 měřených příkazů a u dvanáctého s ním byl Dragonfly na stejné úrovni. Nastavení testu a jeho meze jsou popsány níže.

Proč jsem vytvořil HotKV

Na rychlosti mi záleží u všeho, co stavím. Web, nástroj nebo server by měl reagovat okamžitě, a když ne, chci vědět proč. Tento přístup formuje mou práci od doby, co píšu software.

C a C++ jsou mými hlavními jazyky už mnoho let. Téměř deset let jsem pracoval na anticheatovém softwaru pro hry, který běžel na počítačích tisíců hráčů. Musel prohledávat paměť kvůli podvodníkům a přitom spotřebovat co nejméně procesoru a paměti, protože každý cyklus, který spotřeboval, chyběl hře. Ta práce mě naučila všechno měřit, navrhovat s ohledem na hardware a brát nízkou spotřebu zdrojů jako samostatnou přednost.

Vedle toho jsem Redis a Valkey používal v mnoha projektech, které potřebovaly rychlou cache: úložiště relací, seznamy IP adres blokovaných firewallem a cache před stovkami milionů záznamů v SQL Serveru. Jsou to výborné nástroje. Zároveň ve mně ale vzbudily zvědavost, co by úložiště klíč-hodnota dokázalo, kdyby bylo od začátku navrženo pro servery s mnoha jádry, které dnes provozujeme.

HotKV je odpověď, ke které jsem dospěl. Napsal jsem ho od nuly v moderním C++, abych z hardwaru dostal co nejvíc rychlosti při co nejnižších nákladech. Benchmark níže ukazuje, kde dnes stojí, a očekávám, že je co zlepšovat.

Cena AI

Byl tu i druhý důvod. Provozovat aplikace s AI se stávalo drahé, pro mě i, soudě podle toho, co vývojáři sdíleli na internetu, pro mnoho dalších. Velká část těchto nákladů často vzniká tím, že modelu posíláte otázky, na které už odpověděl. Rychlé úložiště, které pozná opakovanou nebo podobnou otázku a odpoví na ni z cache, je jedním z nejpřímějších způsobů, jak tento účet snížit, a proto je cachování pro zátěže AI základní součástí HotKV.

K čemu HotKV je

HotKV Ltd existuje proto, aby tento druh softwaru byl výkonnější a dostupnější. Moderní servery mají hodně jader a datové úložiště by je mělo využívat, abyste dostali co nejvíc rychlosti při co nejnižších nákladech.

Druhou myšlenkou je držet víc z technologického stacku na jednom místě. Týmy, které staví na LLM, často skončí s provozem cache, vektorové databáze a místa pro paměť agentů, s hromadou propojovacího kódu mezi nimi. Chci, aby cachování a práce s AI kolem něj žily v jednom jádru, přímo vedle vašich dat: cachování volání modelů s přesnou i sémantickou shodou, vektorové vyhledávání, paměť agentů a rozpočty tokenů. Méně systémů k provozu by mělo znamenat méně pohyblivých částí a nižší účet. Stránka o AI uvádí, co je dnes k dispozici, a benchmark úspor tokenů ukazuje, kolik cachování volání modelů v našem testu ušetřilo.

HotKV zachovává protokol Redisu a známé klientské knihovny.

Problém

Jediné vlákno pro provádění příkazů se může na stroji s mnoha jádry stát úzkým hrdlem. Datové úložiště postavené kolem jednoho vlákna pro provádění obvykle zbytek stroje využije spuštěním několika instancí nebo clusteru, což s sebou nese rozhodování o nasazení a provozní práci. Chtěl jsem, aby HotKV vycházelo z opačného konce, s příkazy probíhajícími souběžně uvnitř jedné instance, takže jediný proces dokáže využít celý stroj.

Čím se HotKV liší

HotKV™ je napsáno v C++20 a navrženo tak, aby provádělo příkazy na mnoha jádrech najednou, takže jediná instance dokáže využít celý stroj. Dragonfly, s nímž se níže porovnáváme, také používá multithreadový přístup.

• Mnoho jader, jedna instance. Příkazy běží souběžně napříč jádry stroje, takže jedna instance dokáže využít velký server místo několika menších.
• Známí klienti a protokol. HotKV podporuje RESP2 a RESP3, takže se k němu mohou připojit známé klientské knihovny. Podporovány jsou transakce (MULTI/EXEC) a skriptování v Lua. Podporované příkazy a případné rozdíly najdete v dokumentaci příkazů.

Jak je sestaveno a testováno

HotKV si stavím sám a tam, kde to pomáhá, využívám pomoc AI. Důležitější než to, jak byl řádek napsán, je, zda obstojí, takže jádro je testováno důkladně. Má více než 2 000 automatizovaných testů a sestavuje se pod AddressSanitizer, ThreadSanitizer a UndefinedBehaviorSanitizer. Má také fuzzovací cíle pro parser protokolu, rozesílání příkazů, načítání RDB a AOF, replikační stream a sběrnici clusteru.

Nastavení benchmarku, jeho meze a úplné výsledky jsou na stránce Výkon, abyste mohli čísla posoudit sami.

Přehled benchmarku

Aktualizováno v říjnu 2026: čísla původně zveřejněná v tomto článku pocházela z běhů benchmarku, u nichž jsme později zjistili vady (mimo jiné používal každý generátor zátěže stejný náhodný seed), proto jsme je nahradili výsledky z našeho přestavěného benchmarku.

Říjen 2026: HotKV, Redis, Valkey a Dragonfly

Tento benchmark provedla společnost HotKV Ltd. Změřili jsme HotKV, sestavené ze zdrojových kódů, proti Redisu 8.10.2, Valkey 9.1.2 a Dragonfly 2.0.2. Každý server běžel sám, jako jediná instance na všech 160 vCPU stroje Azure D160alds_v7 (AMD EPYC 9V45), s vypnutou perzistencí. Zátěž generovaly tři samostatné stroje o 64 vCPU pomocí memtier_benchmark: hodnoty o velikosti 256 bajtů, hloubka pipeline 30 a 5 000 000 předvyplněných klíčů. Každé číslo je medián ze tří 10sekundových běhů.

HotKV mělo nejvyšší propustnost u 11 z 12 příkazů. Oproti Redisu nebo Valkey naměřilo podle příkazu a serveru mezi 8,6násobkem a nejméně 69,7násobkem jejich propustnosti, oproti Dragonfly u těchto 11 příkazů mezi 1,97násobkem a 4,41násobkem, přičemž několik z nich jsou dolní meze. U PING byl Dragonfly o 0,6 procenta před. Počítáme to jako remízu, protože generátory zátěže byly blízko svého vlastního limitu. Nejvyšší číslo u datového příkazu bylo 90,8 milionu operací INCR za sekundu. INCR a PING přesouvají málo dat a omezují je generátory zátěže, takže vlastní číslo HotKV pro ně může být vyšší.

Jak číst tabulku

MGET čte osm klíčů a MSET zapisuje čtyři dvojice klíč-hodnota na příkaz a propustnost počítá příkazy. Report označuje sedm čísel HotKV (GET a šest zápisových příkazů), protože dosáhla jeho prahu 85 % využití sítě, a PING, protože generátory zátěže byly nad 85 % CPU. Poměry, které na nich stojí, jsou dolní meze, označené ≥. U GET a PING jde o skutečné limity. U šesti zápisových příkazů údaj reportu o využití sítě sčítá příchozí a odchozí provoz a porovnává ho s odchozím stropem, takže nadhodnocuje, jak blízko byly limitu. Nejnáročnější, SETNX, využil nanejvýš asi 80 % změřeného příchozího stropu. Znak ≥ u nich ponecháváme jako konzervativní konvenci. Úplné tabulky, označení a poznámky k metodice jsou na stránce Výkon.

Rozsah benchmarku

• Build a ladění. HotKV bylo zkompilováno s -march=native pro testovací procesor, zatímco ostatní servery byly jejich standardní vydané buildy.
• Nastavení vláken. Každý server dostal všechna jádra stroje: HotKV --threads 160, Dragonfly 160 vláken proactor, Valkey io-threads 160 a Redis io-threads 128, jeho maximum. Redis a Valkey provádějí příkazy na jednom vlákně a s menším počtem I/O vláken mohou dosáhnout vyšší propustnosti, takže jejich čísla mohou být pod jejich optimem. Nespouštěli jsme clustery ani několik jejich instancí.
• Rozsah. Dvanáct příkazů, jedna velikost hodnoty, jedna hloubka pipeline, bez TLS a bez perzistence. LPOP a RPOP se neměřily, protože při těchto rychlostech destruktivní čtení vyprázdní jakýkoli seznam, který se vejde do paměti, během 10 sekund. Report zaznamenává latenci a využití paměti, ale zde je neporovnáváme. Servery vykonaly v každém 10sekundovém běhu velmi rozdílné množství práce, takže čísla paměti nejsou srovnatelná. Smíšené zátěže se neměřily.
• Variabilita. Redis se mezi svými třemi běhy u několika příkazů značně lišil, až 7,2krát mezi nejrychlejším a nejpomalejším během u HSET, a medián to skrývá. Při porovnání s nejrychlejším během každého konkurenta místo s mediánem HotKV stále vedlo u všech 11 příkazů.

Redis, Valkey a Dragonfly jsou ochranné známky svých příslušných vlastníků. Jsou uvedeny jen pro označení softwaru, který jsme měřili, a neimplikují žádné sponzorství, podporu ani spojení.

Co je k dispozici dnes

Základní rodiny příkazů zahrnují řetězce, seznamy, množiny, hashe, seřazené množiny, streamy, geoprostorové indexy, bitmapy, HyperLogLog, pub/sub a skriptování v Lua. Moduly AI a enterprise funkce běží v licencovaných plánech. Ceník uvádí, co každý plán obsahuje. Aktuální pokrytí příkazů najdete v dokumentaci. Nad rámec sady příkazů Redisu:

• Značkování klíčů: označujte klíče libovolnými tagy a dotazujte se podle tagu (TAG.SET, TAG.MEMBERS a dalších pět příkazů).
• TTL v nanosekundách: NEXPIRE, NTTL a NEXPIREAT nastavují a čtou expiraci v nanosekundách, takže lhůty mohou být jemnější než milisekunda. Expirované klíče se uvolňují úklidem na pozadí a při přístupu k nim.
• Volitelná komprese hodnot: pro hodnoty nad prahem velikosti (ve výchozím stavu 512 bajtů), vypnutá, dokud ji nezapnete.
• Snapshoty bez forku: BGSAVE zapisuje na vlákně na pozadí místo forkovaného procesu. Snapshot není kopie k určitému okamžiku. Každý klíč se uloží tak, jak vypadal, když k němu snapshot dorazil. Přepis append-only souboru fork provádí.
• Metriky Prometheus: vestavěný HTTP endpoint, ve výchozím stavu vypnutý a zapínaný pomocí metrics-port, takže není potřeba externí exportér.

HotKV má také vestavěné vektorové vyhledávání s indexy HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Změřili jsme ho proti Redisu 8 v článku Vektorové vyhledávání: HotKV vs vektorové množiny Redisu 8, od 1 do 100 klientů.

Začněte na HotKV Cloud, nebo kontaktujte prodej kvůli provozu HotKV na vlastních serverech.