Presentiamo HotKV

HotKV è un data store multithread compatibile con Redis, scritto da zero in C++ moderno e pensato per ricavare la massima velocità dai server moderni con molti core al costo più basso possibile. Sono Norbert E. Boros, fondatore e CEO di HotKV Ltd. In questo articolo spiego perché l'ho creato, cosa fa oggi e come si è comportato nelle misurazioni.

In breve. HotKV esegue i comandi su molti thread contemporaneamente all'interno di un unico processo e parla RESP2 e RESP3, il protocollo di Redis. Nel nostro benchmark a istanza singola di ottobre 2026 su 160 vCPU ha registrato il throughput più alto su 11 dei 12 comandi misurati, e Dragonfly era alla pari sul dodicesimo. La configurazione e i suoi limiti sono descritti più sotto.

Perché ho creato HotKV

In tutto ciò che costruisco tengo alla velocità. Un sito web, uno strumento o un server dovrebbe rispondere all'istante, e quando non lo fa voglio capire perché. Questa abitudine ha plasmato il mio lavoro da quando scrivo software.

C e C++ sono da molti anni i miei linguaggi principali. Per quasi dieci anni ho lavorato su software anti-cheat per videogiochi che girava sui PC di migliaia di giocatori. Doveva analizzare la memoria alla ricerca di cheat usando meno CPU e memoria possibile, perché ogni ciclo che consumava veniva sottratto al gioco. Quel lavoro mi ha insegnato a misurare tutto, a progettare in funzione dell'hardware e a considerare il basso consumo di risorse una qualità a sé stante.

Parallelamente ho usato Redis e Valkey in molti progetti che avevano bisogno di una cache veloce: archivi di sessione, elenchi di indirizzi IP bloccati da un firewall e una cache davanti a centinaia di milioni di record di SQL Server. Sono strumenti eccellenti. Mi hanno anche fatto nascere la curiosità di capire cosa potrebbe fare un key-value store progettato fin dall'inizio per i server con molti core che usiamo oggi.

HotKV è la risposta a cui sono arrivato. L'ho scritto da zero in C++ moderno per ricavare dall'hardware la massima velocità possibile, al costo più basso possibile. Il benchmark qui sotto mostra a che punto è oggi, e mi aspetto che ci sia ancora margine per migliorare.

Il costo dell'IA

C'era anche un secondo motivo. Far girare applicazioni di IA stava diventando costoso, per me e, a giudicare da ciò che gli sviluppatori condividevano online, anche per molti altri. Una parte importante di quel costo deriva spesso dall'inviare a un modello domande a cui ha già risposto. Uno store veloce che riconosce una domanda ripetuta o simile e risponde dalla cache è uno dei modi più diretti per ridurre quel conto, ed è per questo che il caching per i carichi di lavoro di IA è una parte centrale di HotKV.

A cosa serve HotKV

HotKV Ltd esiste per rendere questo tipo di software più performante e più conveniente. I server moderni hanno moltissimi core e un data store dovrebbe usarli, in modo da ottenere la massima velocità possibile al costo più basso possibile.

La seconda idea è tenere più parti dello stack in un unico posto. I team che sviluppano su LLM finiscono spesso per gestire una cache, un database vettoriale e un posto dove conservare la memoria degli agenti, con un mucchio di codice di collegamento in mezzo. Voglio che la cache e il lavoro di IA costruito attorno ad essa vivano in un solo motore, accanto ai tuoi dati: caching esatto e semantico delle chiamate ai modelli, ricerca vettoriale, memoria degli agenti e budget di token. Meno sistemi da gestire dovrebbero significare meno parti in movimento e un conto più basso. La pagina sull'IA elenca ciò che è disponibile oggi, e il benchmark sul risparmio di token mostra quanto ha fatto risparmiare il caching delle chiamate ai modelli nel nostro test.

HotKV mantiene il protocollo Redis e le librerie client familiari.

Il problema

Un singolo thread di esecuzione dei comandi può diventare un collo di bottiglia su una macchina con molti core. Un data store costruito attorno a un solo thread di esecuzione di solito raggiunge il resto della macchina eseguendo più istanze o un cluster, e questo comporta scelte di deployment e lavoro operativo. Volevo che HotKV partisse dalla direzione opposta, con i comandi eseguiti in modo concorrente all'interno di una sola istanza, così che un singolo processo possa usare l'intera macchina.

Cosa fa HotKV di diverso

HotKV™ è scritto in C++20 e progettato per eseguire i comandi su molti core contemporaneamente, così una singola istanza può sfruttare un'intera macchina. Anche Dragonfly, che includiamo nel benchmark più sotto, adotta un approccio multithread.

• Molti core, una sola istanza. I comandi vengono eseguiti in modo concorrente sui core della macchina, quindi una sola istanza può usare un server grande invece di diversi server più piccoli.
• Client e protocollo familiari. HotKV supporta RESP2 e RESP3, quindi le librerie client già note possono connettersi. Le transazioni (MULTI/EXEC) e lo scripting Lua sono supportati. Consulta la documentazione dei comandi per i comandi supportati e le eventuali differenze.

Come è costruito e testato

Sviluppo HotKV personalmente e uso l'assistenza dell'IA dove serve. Conta più il fatto che il codice regga alla prova che il modo in cui è stata scritta una riga, quindi il motore viene testato a fondo. Ha più di 2.000 test automatici e viene compilato con AddressSanitizer, ThreadSanitizer e UndefinedBehaviorSanitizer. Ha anche target di fuzzing per il parser del protocollo, il dispatch dei comandi, il caricamento di RDB e AOF, il flusso di replica e il cluster bus.

La configurazione del benchmark, i suoi limiti e i risultati completi sono nella pagina Performance, così puoi giudicare i numeri da solo.

Istantanea del benchmark

Aggiornato a ottobre 2026: i dati pubblicati inizialmente in questo articolo derivavano da esecuzioni del benchmark che in seguito abbiamo scoperto essere difettose (tra l'altro, tutti i generatori di carico usavano lo stesso seed casuale), quindi li abbiamo sostituiti con i risultati del nostro benchmark ricostruito.

Ottobre 2026: HotKV, Redis, Valkey e Dragonfly

Questo benchmark è stato eseguito da HotKV Ltd. Abbiamo misurato HotKV, compilato dal codice sorgente, a confronto con Redis 8.10.2, Valkey 9.1.2 e Dragonfly 2.0.2. Ogni server è stato eseguito da solo, come singola istanza su tutte le 160 vCPU di una macchina Azure D160alds_v7 (AMD EPYC 9V45), con la persistenza disattivata. Tre macchine separate da 64 vCPU hanno generato il carico con memtier_benchmark: valori da 256 byte, una profondità della pipeline di 30 e 5.000.000 di chiavi precaricate. Ogni valore è la mediana di tre esecuzioni da 10 secondi.

HotKV ha registrato il throughput più alto su 11 dei 12 comandi. Rispetto a Redis o Valkey ha misurato un throughput tra 8,6 e almeno 69,7 volte il loro, a seconda del comando e del server; rispetto a Dragonfly, tra 1,97 e 4,41 volte su quegli 11 comandi, diversi dei quali sono limiti inferiori. Su PING Dragonfly ha registrato lo 0,6 per cento in più. Lo consideriamo un pareggio, perché i generatori di carico erano vicini al proprio limite. Il valore più alto su un comando che opera sui dati è stato di 90,8 milioni di operazioni INCR al secondo. INCR e PING spostano pochi dati e sono limitati dai generatori di carico, quindi il valore di HotKV per questi due comandi potrebbe essere più alto.

Come leggere la tabella

MGET legge otto chiavi e MSET scrive quattro coppie chiave-valore per comando, e il throughput conta i comandi. Il report contrassegna sette valori di HotKV (GET e sei comandi di scrittura) perché hanno raggiunto la soglia di utilizzo della rete dell'85% del report, e PING perché i generatori di carico superavano l'85% di utilizzo della CPU. I rapporti calcolati su di essi sono limiti inferiori, segnati con ≥. GET e PING sono i veri limiti. Per i sei comandi di scrittura, il valore di utilizzo della rete del report somma il traffico in ingresso e in uscita e lo confronta con il tetto in uscita, quindi sovrastima quanto si fossero avvicinati a un limite. Il più pesante, SETNX, ha usato al massimo circa l'80% del tetto in ingresso misurato. Manteniamo il ≥ su questi comandi come convenzione prudenziale. Le tabelle complete, i contrassegni e le note sul metodo sono nella pagina Performance.

Ambito del benchmark

• Build e tuning. HotKV è stato compilato con -march=native per la CPU del test, mentre gli altri server erano le loro build di release standard.
• Impostazioni dei thread. A ogni server sono stati assegnati tutti i core della macchina: HotKV --threads 160, Dragonfly 160 thread proactor, Valkey io-threads 160 e Redis io-threads 128, il suo massimo. Redis e Valkey eseguono i comandi su un solo thread e potrebbero raggiungere un throughput più alto con meno thread di I/O, quindi i loro valori potrebbero essere inferiori al loro meglio. Non abbiamo eseguito cluster né più istanze di questi server.
• Ambito. Dodici comandi, una sola dimensione dei valori, una sola profondità della pipeline, nessun TLS e nessuna persistenza. LPOP e RPOP non sono stati misurati, perché a queste velocità una lettura distruttiva svuota entro 10 secondi qualsiasi lista che stia in memoria. Il report registra latenza e utilizzo della memoria, ma qui non li confrontiamo. I server hanno svolto quantità di lavoro molto diverse in ciascuna esecuzione da 10 secondi, quindi i valori di memoria non sono confrontabili alla pari. I workload misti non sono stati misurati.
• Variabilità. Redis ha mostrato ampie variazioni tra le sue tre esecuzioni su diversi comandi, fino a 7,2 volte tra l'esecuzione più veloce e quella più lenta su HSET, e la mediana lo nasconde. Confrontando HotKV con l'esecuzione più veloce di ciascun concorrente invece che con la mediana, HotKV era comunque in testa su tutti gli 11 comandi.

Redis, Valkey e Dragonfly sono marchi dei rispettivi proprietari. Sono citati solo per identificare il software che abbiamo misurato e ciò non implica alcuna sponsorizzazione, approvazione o affiliazione.

Cosa include oggi

Le famiglie di comandi principali comprendono stringhe, liste, set, hash, sorted set, stream, indici geospaziali, bitmap, HyperLogLog, pub/sub e scripting Lua. I moduli di IA e le funzionalità enterprise girano sui piani con licenza. La pagina Prezzi elenca cosa include ciascun piano. Consulta la documentazione per la copertura attuale dei comandi. Oltre al set di comandi di Redis:

• Tagging delle chiavi: etichetta le chiavi con tag arbitrari e interroga per tag (TAG.SET, TAG.MEMBERS e altri cinque comandi).
• TTL al nanosecondo: NEXPIRE, NTTL e NEXPIREAT impostano e leggono la scadenza in nanosecondi, quindi le scadenze possono essere più fini di un millisecondo. Le chiavi scadute vengono recuperate da una scansione in background e quando vi si accede.
• Compressione opzionale dei valori: per i valori sopra una soglia di dimensione (512 byte per impostazione predefinita), disattivata a meno che tu non la attivi.
• Snapshot senza fork: BGSAVE scrive su un thread in background invece che in un processo creato con fork. Uno snapshot non è una copia in un istante preciso. Ogni chiave viene salvata così com'era quando lo snapshot l'ha raggiunta. La riscrittura dell'append-only file esegue un fork.
• Metriche Prometheus: un endpoint HTTP integrato, disattivato per impostazione predefinita e abilitato con metrics-port, quindi non serve alcun exporter esterno.

HotKV ha anche la ricerca vettoriale integrata con indici HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). L'abbiamo misurata rispetto a Redis 8 in Ricerca vettoriale: HotKV contro i vector set di Redis 8, da 1 a 100 client.

Inizia su HotKV Cloud, oppure contatta le vendite per eseguire HotKV sui tuoi server.