Débit en confrontation directe
Dans le test de HotKV Ltd portant sur HotKV, Redis, Valkey et Dragonfly sur une instance cloud, HotKV a enregistré le débit médian le plus élevé pour 11 commandes sur 12. Sur PING, Dragonfly a mesuré 0,6 % de plus, ce qui reste dans la limite des générateurs de charge : nous le comptons comme une égalité. Ces résultats valent pour les versions et les réglages testés. Voir la méthodologie ci-dessous.
- Même machineChaque serveur tourne sur la même instance, un à la fois.
- Générateurs de charge séparésDes machines clientes dédiées génèrent la charge, jamais la machine du serveur lui-même.
- Mêmes réglagesChaque serveur reçoit le même nombre de threads et aucun autre réglage.
- Médiane de 3 exécutionsChaque commande est exécutée 3 fois. La médiane est affichée.
- Limites signaléesLes résultats déterminés par le réseau ou par les générateurs de charge sont signalés.
- La méthode en détailChaque réglage, limite et réserve est détaillé sous les résultats.
- CPU:
- AMD EPYC 9V45 (Turin)
- vCPU:
- 160
- Architecture:
- x86_64
- RAM:
- 314,8 GB
- Réseau:
- 78 Gbps en sortie, 132+ Gbps en entrée
- Threads:
- 160 par serveur (Redis 128, son maximum)
- Mesuré:
- 9 octobre 2026
Opérations par seconde, médiane de 3 exécutions. Chaque barre est mise à l’échelle sur le serveur le plus rapide pour cette commande.
- Résultat le plus élevé pour cette commande.
- Limité par le réseau : le réseau de l’instance a déterminé ce résultat, la limite propre du serveur est donc plus élevée.
- Limité par les générateurs de charge : les machines servant de générateurs de charge ont dépassé 85 % de CPU, ce résultat correspond donc à leur plafond, et non à celui du serveur.
- Azure plafonne le trafic sortant : iperf3 a mesuré 78 Gbps en sortie et au moins 132 Gbps en entrée avec trois machines clientes. GET et MGET envoient des valeurs vers l’extérieur. Le GET de HotKV a utilisé 88 % du plafond sortant : c’est donc un plancher fixé par l’instance, et non une limite du serveur, et son MGET, à 83 %, suit de près. Les lectures de Dragonfly ont utilisé au plus 44 % du plafond.
- Les écritures arrivent en entrée : les résultats d’écriture sont donc des chiffres du serveur. Le plus lourd, SETNX à environ 106 Gbps, a utilisé environ 80 % du plafond entrant ; il faut donc considérer les chiffres d’écriture de HotKV comme de légères bornes inférieures.
- Sur PING, les générateurs de charge ont atteint 86 % de CPU avec HotKV et 82 % avec Dragonfly. Les 0,6 % qui les séparent se situent dans cette limite : PING est donc une égalité.
Valeurs exactes pour Azure D160alds_v7
| Commande | HotKV | Redis | Valkey | Dragonfly | HotKV vs Redis | HotKV vs Valkey | HotKV vs Dragonfly |
|---|---|---|---|---|---|---|---|
| SET | Valeur la plus élevée : 50,480,621 | 3,409,794 | 2,882,486 | 15,042,258 | 14.80x | 17.51x | 3.36x |
| GET | Valeur la plus élevée : 36,643,656(Limité par le réseau) | 1,132,934 | 1,631,573 | 13,446,228 | 32.34x | 22.46x | 2.73x |
| MGET | Valeur la plus élevée : 4,617,382 | 277,956 | 536,872 | 2,348,137 | 16.61x | 8.60x | 1.97x |
| SETNX | Valeur la plus élevée : 55,333,360 | 1,397,967 | 1,860,919 | 14,442,422 | 39.58x | 29.73x | 3.83x |
| APPEND | Valeur la plus élevée : 25,050,648 | 1,530,680 | 1,290,421 | 8,858,165 | 16.37x | 19.41x | 2.83x |
| INCR | Valeur la plus élevée : 90,783,545 | 2,104,069 | 1,918,073 | 20,603,259 | 43.15x | 47.33x | 4.41x |
| LPUSH | Valeur la plus élevée : 31,617,779 | 1,247,914 | 842,106 | 10,579,641 | 25.34x | 37.55x | 2.99x |
| RPUSH | Valeur la plus élevée : 43,776,706 | 628,324 | 878,476 | 11,014,977 | 69.67x | 49.83x | 3.97x |
| SADD | Valeur la plus élevée : 50,626,647 | 2,053,737 | 894,438 | 12,044,417 | 24.65x | 56.60x | 4.20x |
| HSET | Valeur la plus élevée : 28,997,514 | 536,527 | 781,768 | 9,797,534 | 54.05x | 37.09x | 2.96x |
| MSET | Valeur la plus élevée : 11,275,369 | 378,641 | 464,801 | 2,941,342 | 29.78x | 24.26x | 3.83x |
| PING | 125,232,520(Limité par les générateurs de charge) | 3,235,600 | 3,480,446 | Valeur la plus élevée : 126,033,542 | 38.70x | 35.98x | 0.99x |
Plus rapide que les vector sets de Redis 8 dans notre test
Nous avons chargé les mêmes embeddings OpenAI dans HotKV et Redis 8 et exécuté les mêmes 1 000 requêtes sur chacun, avec 1 à 100 connexions client simultanées, sur une seule machine. Les deux conservaient des vecteurs en pleine précision, avec les mêmes réglages d’index.
Requêtes par seconde à rappel égal
Les deux moteurs stockaient des vecteurs float32 en pleine précision. Après le chargement de 999 000 vecteurs, le processus HotKV occupait 6,77 GB et Redis 7,01 GB.
Non mesuré : le mode quantifié 8 bits par défaut de Redis, le Redis Query Engine, d’autres jeux de données et d’autres matériels. Le build HotKV est un build de développement qui n’a pas été publié. Redis a été chargé épinglé sur quatre vCPU et interrogé sur un index rechargé (voir l’article).
Tous les chiffres : 999 000 vecteurs, 50 clients
| ef | Rappel HotKV | Rappel Redis | Requêtes/s HotKV | Requêtes/s Redis | Rapport |
|---|---|---|---|---|---|
| 40 | 0,940 | 0,923 | 63 897 | 8 061 | 7,9x |
| 80 | 0,970 | 0,962 | 37 508 | 6 825 | 5,5x |
| 150 | 0,987 | 0,980 | 21 912 | 5 241 | 4,2x |
| 300 | 0,993 | 0,990 | 12 393 | 3 454 | 3,6x |
| 500 | 0,997 | 0,994 | 7 688 | 2 483 | 3,1x |
Build HotKV c8dafd37 et Redis 8.10.2, similarité cosinus, HNSW avec M=16 et ef_construction=200 sur les deux, float32 sur les deux (Redis NOQUANT). Le rappel est le rappel@10 par rapport aux résultats exacts d’une recherche exhaustive (brute force). Médiane de 3 exécutions sur Azure Standard_D160alds_v7, AMD EPYC 9V45, 160 vCPUs. Les serveurs se partageaient 128 vCPU et les générateurs de charge tournaient sur 32 autres, avec le même code client pour les deux.
Jeu de données : embeddings dbpedia-entities-openai-1M (OpenAI text-embedding-ada-002, 1 536 dimensions) par Kumar Shivendu and Nirant Kasliwal, sous licence MIT, plus 1 000 requêtes mises de côté. Méthode complète, scripts et résultats bruts. Mesuré le 14 octobre 2026.
Prêt à mettre HotKV au travail ?
Obtenez un accès anticipé et explorez HotKV pour votre charge de travail.
Accès anticipé