A HotKV egy többszálú, Redis-kompatibilis adattároló, amelyet a nulláról írtam modern C++-ban, azzal a céllal, hogy a modern, sokmagos szerverekből a lehető legtöbb sebességet hozza ki a lehető legalacsonyabb költségen. Boros E. Norbert vagyok, a HotKV Ltd alapítója és vezérigazgatója. Ez a bejegyzés elmagyarázza, miért építettem, mit tud ma, és hogyan mértünk vele.
Röviden. A HotKV a parancsokat egyetlen folyamaton belül, egyszerre sok szálon hajtja végre, és beszéli a RESP2-t és a RESP3-at, a Redis protokollját. A 2026. októberi, 160 vCPU-n futó egypéldányos benchmarkunkban a mért 12 parancsból 11-nél ez érte el a legmagasabb áteresztőképességet, a tizenkettediknél pedig a Dragonfly volt vele egyenlő. A felállás és a korlátai lent vannak leírva.
Miért építettem a HotKV-t
Mindenben, amit építek, fontos a sebesség. Egy weboldalnak, egy eszköznek vagy egy szervernek azonnal válaszolnia kell, és ha nem teszi, tudni akarom, miért. Ez a szokás azóta formálja a munkámat, hogy szoftvert írok.
A C és a C++ évek óta a fő nyelveim. Közel tíz évig dolgoztam játékokhoz készült csalásvédelmi szoftveren, amely játékosok ezreinek számítógépén futott. A memóriát kellett csalóprogramok után kutatnia, miközben a lehető legkevesebb CPU-t és memóriát használta, mert minden ciklus, amelyet elhasznált, a játéktól vett el. Ez a munka megtanított mindent megmérni, a hardver köré tervezni, és az alacsony erőforrás-használatot önálló funkciónak tekinteni.
Emellett a Redist és a Valkey-t sok olyan projektben használtam, amelyhez gyors gyorsítótár kellett: munkamenet-tárolókban, tűzfal által blokkolt IP-címek listáiban, és több száz millió SQL Server-rekord előtti gyorsítótárban. Kiváló eszközök. Ugyanakkor kíváncsivá is tettek, mire lenne képes egy kulcs-érték tároló, ha kezdettől fogva a ma üzemeltetett sokmagos szerverekre tervezték volna.
A HotKV a válasz, amelyre jutottam. A nulláról írtam modern C++-ban, hogy a hardverből a lehető legtöbb sebességet hozzam ki, a lehető legalacsonyabb költségen. Az alábbi benchmark megmutatja, hol tart ma, és arra számítok, hogy van még hová javulni.
Az AI költsége
Volt egy második ok is. Az AI-alkalmazások üzemeltetése drágává vált, nekem is, és abból ítélve, amit a fejlesztők online megosztottak, sokaknak másoknak is. Ennek a költségnek nagy része gyakran onnan ered, hogy olyan kérdéseket küldünk egy modellnek, amelyekre az már válaszolt. Egy gyors tároló, amely felismeri az ismétlődő vagy hasonló kérdést, és a gyorsítótárból válaszol rá, az egyik legközvetlenebb módja ennek a számlának a csökkentésére, ezért az AI-munkaterhelések gyorsítótárazása a HotKV központi része.
Mire való a HotKV
A HotKV Ltd azért létezik, hogy ezt a fajta szoftvert teljesítményesebbé és megfizethetőbbé tegye. A modern szervereknek sok magjuk van, és egy adattárolónak ki kell használnia őket, hogy a lehető legtöbb sebességet kapja a lehető legalacsonyabb költségen.
A második gondolat az, hogy a stack több részét egy helyen tartsuk. Az LLM-ekre építő csapatok gyakran végül gyorsítótárat, vektoradatbázist és az ügynökmemória számára egy helyet üzemeltetnek, rengeteg ragasztókóddal közöttük. Azt szeretném, ha a gyorsítótárazás és a körülötte lévő AI-munka egyetlen motorban élne, közvetlenül az adatai mellett: a modellhívások pontos és szemantikus gyorsítótárazása, vektorkeresés, ügynökmemória és tokenkeretek. Kevesebb üzemeltetendő rendszer kevesebb mozgó alkatrészt és alacsonyabb számlát jelentsen. Az AI oldal felsorolja, mi érhető el ma, a tokenmegtakarítási benchmark pedig megmutatja, mennyit takarított meg a modellhívások gyorsítótárazása a tesztünkben.
A HotKV megtartja a Redis protokollt és az ismert klienskönyvtárakat.
A probléma
Egyetlen parancsvégrehajtó szál szűk keresztmetszetté válhat egy sokmagos gépen. Az egyetlen végrehajtó szál köré épített adattároló általában úgy éri el a gép többi részét, hogy több példányt vagy egy klasztert üzemeltetnek, és ez telepítési döntésekkel és üzemeltetési munkával jár. Azt akartam, hogy a HotKV a másik végéről induljon, a parancsok egy példányon belül egyidejűleg fussanak, így egyetlen folyamat az egész gépet kihasználhatja.
Miben más a HotKV
A HotKV™ C++20-ban íródott, és arra tervezték, hogy a parancsokat egyszerre sok magon hajtsa végre, így egyetlen példány egy egész gépet ki tud használni. A Dragonfly, amelyet lent benchmarkolunk, szintén többszálú megközelítést alkalmaz.
- Sok mag, egy példány. A parancsok egyidejűleg futnak a gép magjain, így egyetlen példány egy nagy szervert tud kihasználni több kisebb helyett.
- Ismert kliensek és protokoll. A HotKV támogatja a RESP2-t és a RESP3-at, így az ismert klienskönyvtárak csatlakozhatnak hozzá. A tranzakciók (
MULTI/EXEC) és a Lua-szkriptelés támogatottak. A támogatott parancsokat és az esetleges eltéréseket lásd a parancsdokumentációban.
Hogyan épül és hogyan tesztelik
A HotKV-t magam építem, és AI-segítséget használok, ahol az hasznos. Fontosabb annál, hogyan készült egy sor, hogy kiállja-e a próbát, ezért a motort keményen tesztelik. Több mint 2000 automatizált tesztje van, és AddressSanitizerrel, ThreadSanitizerrel és UndefinedBehaviorSanitizerrel is lefordítják. Emellett fuzz-célpontjai vannak a protokollelemzőre, a parancselosztásra, az RDB és az AOF betöltésére, a replikációs folyamra és a klaszterbuszra.
A benchmark felállása, korlátai és a teljes eredmények a Teljesítmény oldalon találhatók, hogy a számokat Ön is megítélhesse.
Benchmark-pillanatkép
Frissítve 2026 októberében: a bejegyzésben eredetileg közzétett számok olyan benchmarkfuttatásokból származtak, amelyekről később kiderült, hogy hibásak (többek között minden terhelésgenerátor ugyanazt a véletlenszám-magot használta), ezért az újjáépített benchmarkunk eredményeire cseréltük őket.
2026. október: HotKV, Redis, Valkey és Dragonfly
Ezt a benchmarkot a HotKV Ltd futtatta. A forrásból épített HotKV-t mértük a Redis 8.10.2, a Valkey 9.1.2 és a Dragonfly 2.0.2 ellen. Minden szerver egyedül futott, egyetlen példányként egy Azure D160alds_v7 (AMD EPYC 9V45) mind a 160 vCPU-ján, kikapcsolt perzisztenciával. Három külön, 64 vCPU-s gép generálta a terhelést a memtier_benchmark-kal: 256 bájtos értékekkel, 30-as pipeline-mélységgel és 5 000 000 előre feltöltött kulccsal. Minden érték három, egyenként 10 másodperces futtatás mediánja.
A HotKV-nak volt a legmagasabb áteresztőképessége a 12 parancs közül 11-nél. A Redishez vagy a Valkey-hez képest azok áteresztőképességének 8,6-szerese és legalább 69,7-szerese között mért, a parancstól és a szervertől függően, a Dragonflyhoz képest e 11 parancson 1,97-szerese és 4,41-szerese között, ezek közül több alsó határ. A PING-en a Dragonfly 0,6 százalékkal volt előrébb. Ezt döntetlennek tekintjük, mert a terhelésgenerátorok közel jártak a saját korlátjukhoz. Egy adatparancson a legmagasabb érték másodpercenként 90,8 millió INCR-művelet volt. Az INCR és a PING kevés adatot mozgat, és a terhelésgenerátorok korlátozzák őket, így a HotKV saját értéke ezeknél magasabb lehet.
| Parancs | HotKV (millió művelet/mp) | HotKV vs. Redis | HotKV vs. Valkey | HotKV vs. Dragonfly |
|---|---|---|---|---|
| SET | 50,5 | ≥ 14,80x | ≥ 17,51x | ≥ 3,36x |
| GET | 36,6 | ≥ 32,34x | ≥ 22,46x | ≥ 2,73x |
| MGET | 4,6 | 16,61x | 8,60x | 1,97x |
| SETNX | 55,3 | ≥ 39,58x | ≥ 29,73x | ≥ 3,83x |
| APPEND | 25,1 | 16,37x | 19,41x | 2,83x |
| INCR | 90,8 | 43,15x | 47,33x | 4,41x |
| LPUSH | 31,6 | 25,34x | 37,55x | 2,99x |
| RPUSH | 43,8 | ≥ 69,67x | ≥ 49,83x | ≥ 3,97x |
| SADD | 50,6 | ≥ 24,65x | ≥ 56,60x | ≥ 4,20x |
| HSET | 29,0 | ≥ 54,05x | ≥ 37,09x | ≥ 2,96x |
| MSET | 11,3 | ≥ 29,78x | ≥ 24,26x | ≥ 3,83x |
| PING | 125,2 | ≥ 38,70x | ≥ 35,98x | 0,99x (döntetlen) |
A táblázat olvasása
Az MGET parancsonként nyolc kulcsot olvas, az MSET pedig négy kulcs-érték párt ír, az áteresztőképesség pedig parancsokat számol. A jelentés hét HotKV-értéket jelöl meg (a GET-et és hat író parancsot), mert elérték a 85%-os hálózathasználati küszöbét, a PING-et pedig azért, mert a terhelésgenerátorok CPU-használata 85% fölött volt. Az ezekre épülő arányok alsó határok, ≥ jellel jelölve. A GET és a PING valódi korlátok. A hat író parancsnál a jelentés hálózathasználati értéke a bejövő és a kimenő forgalmat összeadja, és a kimenő korláthoz hasonlítja, így eltúlozza, mennyire jártak egy korlát közelében. A legnehezebb, a SETNX, a mért bejövő plafon legfeljebb nagyjából 80%-át használta. A ≥ jelet náluk konzervatív konvencióként megtartjuk. A teljes táblázatok, jelölések és módszertani megjegyzések a Teljesítmény oldalon találhatók.
A benchmark hatóköre
- Build és hangolás. A HotKV-t a tesztelt CPU-ra
-march=nativekapcsolóval fordították, a többi szerver pedig az alapértelmezett kiadási buildje volt. - Szálbeállítások. Minden szerver megkapta a gép összes magját: HotKV
--threads 160, Dragonfly 160 proactor-szál, Valkeyio-threads 160és Redisio-threads 128, a maximuma. A Redis és a Valkey a parancsokat egy szálon futtatja, és kevesebb I/O-szállal magasabb áteresztőképességet érhet el, így az értékeik a legjobbjuk alatt lehetnek. Klasztereket vagy több példányt belőlük nem futtattunk. - Hatókör. Tizenkét parancs, egy értékméret, egy pipeline-mélység, nincs TLS és nincs perzisztencia. A
LPOPés azRPOPnem lett mérve, mert ilyen sebességnél egy romboló olvasás 10 másodpercen belül kiüríti bármely, a memóriába férő listát. A jelentés rögzíti a késleltetést és a memóriahasználatot, de ezeket itt nem hasonlítjuk össze. A szerverek nagyon eltérő mennyiségű munkát végeztek az egyes 10 másodperces futtatásokban, így a memóriaértékek nem összehasonlíthatók. Vegyes munkaterheléseket nem mértünk. - Szórás. A Redis több parancsnál nagyon ingadozott a három futtatása között, a
HSET-nél a leggyorsabb és a leglassabb futtatás között akár 7,2-szeresen, és a medián ezt elrejti. Ha az egyes versenytársak mediánja helyett a leggyorsabb futtatásukhoz hasonlítunk, a HotKV mind a 11 parancson továbbra is vezetett.
A Redis, a Valkey és a Dragonfly a megfelelő tulajdonosaik védjegyei. Csak a mért szoftver azonosítására említjük őket, és ez nem jelent támogatást, jóváhagyást vagy kapcsolatot.
Mit tartalmaz ma
Az alap parancscsaládok közé tartoznak a sztringek, listák, halmazok, hash-ek, rendezett halmazok, streamek, térinformatikai indexek, bittérképek, a HyperLogLog, a pub/sub és a Lua-szkriptelés. Az AI-modulok és az enterprise funkciók licencelt csomagokon futnak. Az Árak oldal felsorolja, mit tartalmaz az egyes csomag. Az aktuális parancslefedettséget lásd a dokumentációban. A Redis parancskészletén túl:
- Kulcscímkézés: a kulcsok tetszőleges címkékkel láthatók el, és címke szerint lekérdezhetők (
TAG.SET,TAG.MEMBERSés további öt parancs). - Nanoszekundumos TTL: a
NEXPIRE, azNTTLés aNEXPIREATnanoszekundumban állítja be és olvassa a lejáratot, így a határidők finomabbak lehetnek egy ezredmásodpercnél. A lejárt kulcsokat háttérbeli söprés és elérésük pillanata szabadítja fel. - Opcionális értéktömörítés: egy méretküszöb feletti értékekhez (alapértelmezés szerint 512 bájt), kikapcsolva, amíg be nem kapcsolja.
- Pillanatképek fork nélkül: a
BGSAVEháttérszálon ír elágaztatott folyamat helyett. A pillanatkép nem időponthoz kötött másolat. Minden kulcs olyan állapotban kerül mentésre, amilyenben a pillanatkép elérte. A hozzáfűzéses fájl átírása viszont forkol. - Prometheus-metrikák: beépített HTTP-végpont, alapból kikapcsolva, a
metrics-portmegadásával engedélyezhető, így nincs szükség külső exporterre.
A HotKV beépített vektorkeresést is tartalmaz HNSW-indexekkel (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). A Redis 8 ellen mértük a Vektorkeresés: HotKV vs. Redis 8 vektorhalmazok, 1-től 100 kliensig cikkben.
Kezdje a HotKV Cloudon, vagy beszéljen az értékesítéssel arról, hogyan futtathatja a HotKV-t a saját szerverein.
Folytassa a beszélgetést
Hozzászólások
Kérdése van a módszerről? Más eredményt kapott a saját hardverén? Ossza meg, mit talált. A hozzászólások megjelenés előtt ellenőrzésen esnek át.