Throughput a confronto diretto
Nel test di HotKV Ltd su HotKV, Redis, Valkey e Dragonfly su un'istanza cloud, HotKV ha registrato il throughput mediano più alto su 11 comandi su 12. Su PING Dragonfly è risultato avanti di 0,6%, un margine entro il limite dei generatori di carico, quindi lo consideriamo un pareggio. Questi risultati valgono per le build e le impostazioni testate. Vedi la metodologia più sotto.
- Stessa macchinaOgni server gira sulla stessa istanza, uno alla volta.
- Generatori di carico separatiIl carico è generato da macchine client dedicate, mai dalla macchina del server stesso.
- Stesse impostazioniOgni server riceve lo stesso numero di thread e nessun altro tuning.
- Mediana di 3 esecuzioniOgni comando viene eseguito 3 volte. Viene mostrata la mediana.
- Limiti segnalatiI risultati determinati dalla rete o dai generatori di carico sono segnalati.
- Il metodo completoOgni impostazione, limite e avvertenza è descritto per esteso sotto i risultati.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- Arch.:
- x86_64
- RAM:
- 314,8 GB
- Rete:
- 78 Gbps in uscita, 132+ Gbps in ingresso
- Thread:
- 160 per server (Redis 128, il suo massimo)
- Misurato:
- 9 ottobre 2026
Operazioni al secondo, mediana di 3 esecuzioni. Ogni barra è scalata sul server più veloce per quel comando.
- Risultato più alto su quel comando.
- Limitato dalla rete: la rete dell'istanza ha determinato questo risultato, quindi il limite reale del server è più alto.
- Limitato dal generatore di carico: le macchine generatrici di carico hanno superato l'85% di utilizzo della CPU, quindi questo è il loro limite massimo, non quello del server.
- Azure applica un limite al traffico in uscita: iperf3 ha misurato 78 Gbps in uscita e almeno 132 Gbps in ingresso con tre macchine client. GET e MGET inviano i valori verso l'esterno. Il GET di HotKV ha usato l'88% del tetto in uscita, quindi è un valore minimo imposto dall'istanza, non un limite del server, e il suo MGET, all'83%, è subito dietro. Le letture di Dragonfly hanno usato al massimo il 44% del tetto.
- Le scritture arrivano in ingresso, quindi i risultati di scrittura sono valori del server. Quella più pesante, SETNX a circa 106 Gbps, ha usato circa l'80% del massimo in ingresso, quindi i valori di scrittura di HotKV vanno letti come lievi limiti inferiori.
- Su PING i generatori di carico hanno raggiunto l'86% di CPU con HotKV e l'82% con Dragonfly. Lo 0,6% di differenza tra i due rientra in quel limite, quindi PING è un pareggio.
Valori esatti per Azure D160alds_v7
| Comando | HotKV | Redis | Valkey | Dragonfly | HotKV vs Redis | HotKV vs Valkey | HotKV vs Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Più alto: 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Più alto: 36,643,656(Limitato dalla rete) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Più alto: 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Più alto: 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Più alto: 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Più alto: 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Più alto: 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Più alto: 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Più alto: 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Più alto: 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Più alto: 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Limitato dal generatore di carico) | 3,235,600 | 3,480,446 | Più alto: 126,033,542 | 38.70x | 35.98x | 0.99x |
Più veloce dei vector set di Redis 8 nel nostro test
Abbiamo caricato gli stessi embedding OpenAI in HotKV e in Redis 8 ed eseguito le stesse 1000 query su ciascuno, con da 1 a 100 connessioni client simultanee, su una sola macchina. Entrambi mantenevano vettori a piena precisione, con le stesse impostazioni di indice.
Query al secondo a parità di recall
Entrambi i motori hanno memorizzato vettori float32 a piena precisione. Dopo il caricamento di 999.000 vettori, il processo HotKV occupava 6,77 GB e Redis 7,01 GB.
Non misurati: la modalità quantizzata a 8 bit predefinita di Redis, il Redis Query Engine, altri dataset e altro hardware. La build di HotKV è una build di sviluppo non ancora rilasciata. Redis è stato caricato vincolato a quattro vCPU e interrogato su un indice ricaricato (vedi l'articolo).
Tutti i numeri: 999.000 vettori, 50 client
| ef | Recall HotKV | Recall Redis | Query/s HotKV | Query/s Redis | Rapporto |
|---|---|---|---|---|---|
| 40 | 0,940 | 0,923 | 63.897 | 8061 | 7,9x |
| 80 | 0,970 | 0,962 | 37.508 | 6825 | 5,5x |
| 150 | 0,987 | 0,980 | 21.912 | 5241 | 4,2x |
| 300 | 0,993 | 0,990 | 12.393 | 3454 | 3,6x |
| 500 | 0,997 | 0,994 | 7688 | 2483 | 3,1x |
Build HotKV c8dafd37 e Redis 8.10.2, similarità coseno, HNSW con M=16 ed ef_construction=200 su entrambi, float32 su entrambi (Redis NOQUANT). Il recall è recall@10 rispetto ai risultati esatti della ricerca brute-force. Mediana di 3 esecuzioni su Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. I server condividevano 128 vCPU e i generatori di carico giravano su altre 32, usando lo stesso codice client per entrambi.
Dataset: embedding di dbpedia-entities-openai-1M (OpenAI text-embedding-ada-002, 1536 dimensioni) di Kumar Shivendu and Nirant Kasliwal, con licenza MIT, più 1000 query riservate. Metodo completo, script e risultati grezzi. Misurato il 14 ottobre 2026.
Pronto a mettere HotKV al lavoro?
Richiedi l'accesso anticipato ed esplora HotKV per il tuo workload.
Accesso anticipato