Vă prezentăm HotKV

HotKV este un store de date multi-thread, compatibil Redis, scris de la zero în C++ modern și construit pentru a scoate cât mai multă viteză din serverele moderne cu multe nuclee, la cel mai mic cost posibil. Sunt Norbert E. Boros, fondator și CEO al HotKV Ltd. Această postare explică de ce l-am construit, ce face astăzi și cum a ieșit la măsurători.

Pe scurt. HotKV execută comenzi pe mai multe thread-uri deodată, într-un singur proces, și vorbește RESP2 și RESP3, protocolul Redis. În benchmark-ul nostru cu o singură instanță din octombrie 2026, pe 160 de vCPU, a avut cel mai mare debit la 11 din cele 12 comenzi măsurate, iar Dragonfly a fost la egalitate cu el la a douăsprezecea. Configurația și limitele ei sunt descrise mai jos.

De ce am construit HotKV

Țin la viteză în tot ce construiesc. Un site, o unealtă sau un server ar trebui să răspundă instantaneu, iar când nu o fac, vreau să știu de ce. Obiceiul acesta mi-a marcat munca de când scriu software.

C și C++ sunt limbajele mele principale de mulți ani. Aproape zece ani am lucrat la software anti-cheat pentru jocuri, care rula pe PC-urile a mii de jucători. Trebuia să scaneze memoria în căutare de cheaturi folosind cât mai puțin procesor și memorie, pentru că fiecare ciclu consumat de el era luat de la joc. Munca aceea m-a învățat să măsor tot, să proiectez în jurul hardware-ului și să tratez consumul redus de resurse ca pe o calitate în sine.

În paralel, am folosit Redis și Valkey în multe proiecte care aveau nevoie de un cache rapid: store-uri de sesiuni, liste de adrese IP blocate de un firewall și un cache în fața a sute de milioane de înregistrări SQL Server. Sunt unelte excelente. Dar m-au făcut și curios ce ar putea face un store cheie-valoare dacă ar fi proiectat de la început pentru serverele cu multe nuclee pe care le rulăm astăzi.

HotKV este răspunsul la care am ajuns. L-am scris de la zero în C++ modern, ca să scot din hardware cât mai multă viteză, la cel mai mic cost posibil. Benchmark-ul de mai jos arată unde se află astăzi, iar eu cred că mai e de câștigat.

Costul IA

Mai exista un motiv. Rularea aplicațiilor IA devenea scumpă, pentru mine și, judecând după ce împărtășeau dezvoltatorii online, pentru mulți alții. O mare parte din acest cost vine adesea din trimiterea către un model a unor întrebări la care a răspuns deja. Un store rapid care recunoaște o întrebare repetată sau similară și răspunde din cache este una dintre cele mai directe căi de a reduce factura, motiv pentru care caching-ul pentru sarcinile IA este o parte esențială din HotKV.

Pentru ce există HotKV

HotKV Ltd există ca să facă acest tip de software mai performant și mai accesibil. Serverele moderne au multe nuclee, iar un store de date ar trebui să le folosească, ca să obțineți cât mai multă viteză la cel mai mic cost posibil.

A doua idee este să păstrăm mai mult din stack într-un singur loc. Echipele care construiesc pe LLM-uri ajung adesea să ruleze un cache, o bază de date vectorială și un loc unde să țină memoria agenților, cu o grămadă de cod de legătură între ele. Vreau ca caching-ul și munca IA construită în jurul lui să trăiască într-un singur motor, lângă datele dvs.: caching exact și semantic al apelurilor către model, căutare vectorială, memorie pentru agenți și bugete de tokeni. Mai puține sisteme de rulat ar trebui să însemne mai puține piese mobile și o factură mai mică. Pagina IA listează ce este disponibil astăzi, iar benchmark-ul de economisire a tokenilor arată cât a economisit în testul nostru caching-ul apelurilor către model.

HotKV păstrează protocolul Redis și bibliotecile client cunoscute.

Problema

Un singur thread de execuție a comenzilor poate deveni un blocaj pe o mașină cu multe nuclee. Un store de date construit în jurul unui singur thread de execuție ajunge de obicei la restul mașinii rulând mai multe instanțe sau un cluster, iar asta aduce cu sine alegeri de implementare și muncă operațională. Am vrut ca HotKV să pornească de la celălalt capăt, cu comenzi care rulează concurent în interiorul unei singure instanțe, astfel încât un singur proces să poată folosi întreaga mașină.

Ce face HotKV diferit

HotKV™ este scris în C++20 și proiectat să execute comenzi pe mai multe nuclee deodată, astfel încât o singură instanță poate folosi o mașină întreagă. Dragonfly, cu care facem comparația mai jos, adoptă și el o abordare multi-thread.

• Multe nuclee, o singură instanță. Comenzile rulează concurent pe nucleele mașinii, deci o instanță poate folosi un server mare în loc de mai multe, mai mici.
• Clienți și protocol cunoscute. HotKV acceptă RESP2 și RESP3, deci bibliotecile client cunoscute se pot conecta la el. Tranzacțiile (MULTI/EXEC) și scriptingul Lua sunt acceptate. Vedeți documentația comenzilor pentru comenzile acceptate și eventualele diferențe.

Cum este construit și testat

Construiesc HotKV singur și folosesc asistență IA acolo unde ajută. Mai important decât felul în care a fost scrisă o linie este dacă rezistă, așa că motorul este testat intens. Are peste 2.000 de teste automate și se compilează cu AddressSanitizer, ThreadSanitizer și UndefinedBehaviorSanitizer. Are și ținte de fuzzing pentru parserul de protocol, dirijarea comenzilor, încărcarea RDB și AOF, fluxul de replicare și magistrala de cluster.

Configurația benchmark-ului, limitele ei și rezultatele complete sunt pe pagina Performanță, ca să puteți judeca singuri cifrele.

Imagine de ansamblu a benchmark-ului

Actualizat în octombrie 2026: cifrele publicate inițial în această postare proveneau din rulări de benchmark pe care le-am găsit ulterior defectuoase (printre altele, fiecare generator de încărcare folosea același seed aleatoriu), așa că le-am înlocuit cu rezultate din benchmark-ul nostru reconstruit.

Octombrie 2026: HotKV, Redis, Valkey și Dragonfly

HotKV Ltd a rulat acest benchmark. Am măsurat HotKV, compilat din sursă, față de Redis 8.10.2, Valkey 9.1.2 și Dragonfly 2.0.2. Fiecare server a rulat singur, ca instanță unică pe toate cele 160 de vCPU ale unui Azure D160alds_v7 (AMD EPYC 9V45), cu persistența oprită. Trei mașini separate de câte 64 de vCPU au generat încărcarea cu memtier_benchmark: valori de 256 de octeți, o adâncime de pipeline de 30 și 5.000.000 de chei prepopulate. Fiecare cifră este mediana a trei rulări de câte 10 secunde.

HotKV a avut cel mai mare debit la 11 din cele 12 comenzi. Față de Redis sau Valkey, a măsurat între 8,6 și cel puțin 69,7 ori debitul lor, în funcție de comandă și de server; față de Dragonfly, între 1,97 și 4,41 ori la acele 11 comenzi, mai multe dintre ele fiind limite inferioare. La PING, Dragonfly a măsurat cu 0,6 la sută mai mult. Îl socotim egalitate, pentru că generatoarele de încărcare erau aproape de propria limită. Cea mai mare cifră la o comandă de date a fost de 90,8 milioane de operații INCR pe secundă. INCR și PING mută puține date și sunt limitate de generatoarele de încărcare, deci cifra proprie a HotKV pentru ele poate fi mai mare.

Cum se citește tabelul

MGET citește opt chei, iar MSET scrie patru perechi cheie-valoare pe comandă, iar debitul numără comenzi. Raportul marchează șapte cifre HotKV (GET și șase comenzi de scriere) pentru că au atins pragul lui de 85% de utilizare a rețelei, și PING pentru că generatoarele de încărcare au depășit 85% CPU. Rapoartele construite pe ele sunt limite inferioare, marcate cu ≥. GET și PING sunt limitele reale. Pentru cele șase comenzi de scriere, cifra de utilizare a rețelei din raport adună traficul de intrare și cel de ieșire și o compară cu plafonul de ieșire, deci exagerează cât de aproape au fost de o limită. Cea mai grea, SETNX, a folosit cel mult aproximativ 80% din plafonul de intrare măsurat. Păstrăm ≥ la ele ca pe o convenție prudentă. Tabelele complete, semnalizările și notele despre metodă sunt pe pagina Performanță.

Domeniul benchmark-ului

• Build și optimizare. HotKV a fost compilat cu -march=native pentru CPU-ul de test, în timp ce celelalte servere au fost build-urile lor standard de release.
• Setări de thread-uri. Fiecare server a primit toate nucleele mașinii: HotKV --threads 160, Dragonfly 160 de thread-uri proactor, Valkey io-threads 160 și Redis io-threads 128, maximul lui. Redis și Valkey execută comenzile pe un singur thread și ar putea atinge un debit mai mare cu mai puține thread-uri I/O, deci cifrele lor pot fi sub cele mai bune ale lor. Nu am rulat clustere sau mai multe instanțe ale lor.
• Domeniu. Douăsprezece comenzi, o dimensiune de valoare, o adâncime de pipeline, fără TLS și fără persistență. LPOP și RPOP nu au fost măsurate, pentru că la aceste ritmuri o citire distructivă golește în 10 secunde orice listă care încape în memorie. Raportul înregistrează latența și consumul de memorie, dar nu le comparăm aici. Serverele au făcut cantități foarte diferite de muncă în fiecare rulare de 10 secunde, deci cifrele de memorie nu sunt comparabile. Sarcinile mixte nu au fost măsurate.
• Variație. Redis a variat mult între cele trei rulări la mai multe comenzi, până la de 7,2 ori între cea mai rapidă și cea mai lentă rulare la HSET, iar mediana ascunde asta. Comparat cu cea mai rapidă rulare a fiecărui concurent în loc de mediana lui, HotKV a condus în continuare la toate cele 11 comenzi.

Redis, Valkey și Dragonfly sunt mărci comerciale ale proprietarilor respectivi. Sunt menționate doar pentru a identifica software-ul pe care l-am măsurat și nu implică nicio sponsorizare, susținere sau afiliere.

Ce se livrează astăzi

Familiile de comenzi de bază includ șiruri, liste, mulțimi, hash-uri, sorted set-uri, streamuri, indexuri geospațiale, bitmap-uri, HyperLogLog, pub/sub și scriptingul Lua. Modulele IA și funcțiile enterprise rulează în planurile cu licență. Prețurile listează ce include fiecare plan. Vedeți documentația pentru acoperirea curentă a comenzilor. Dincolo de setul de comenzi Redis:

• Etichetarea cheilor: marcați cheile cu etichete arbitrare și interogați după etichetă (TAG.SET, TAG.MEMBERS și încă cinci comenzi).
• TTL în nanosecunde: NEXPIRE, NTTL și NEXPIREAT setează și citesc expirarea în nanosecunde, deci termenele pot fi mai fine de o milisecundă. Cheile expirate sunt recuperate de o curățare în fundal și când sunt accesate.
• Comprimare opțională a valorilor: pentru valorile peste un prag de dimensiune (512 octeți implicit), oprită dacă nu o porniți.
• Snapshoturi fără fork: BGSAVE scrie pe un thread de fundal în loc de un proces bifurcat. Un snapshot nu este o copie la un moment exact. Fiecare cheie este salvată așa cum era când a ajuns snapshotul la ea. Rescrierea fișierului append-only face fork.
• Metrici Prometheus: un endpoint HTTP încorporat, oprit implicit și activat cu metrics-port, deci nu este nevoie de un exporter extern.

HotKV are și căutare vectorială încorporată cu indexuri HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Am măsurat-o față de Redis 8 în Căutare vectorială: HotKV vs seturile vectoriale Redis 8, de la 1 la 100 de clienți.

Începeți pe HotKV Cloud sau vorbiți cu echipa de vânzări despre rularea HotKV pe propriile servere.