Présentation de HotKV

HotKV est un magasin de données multithread compatible Redis, écrit de zéro en C++ moderne, conçu pour tirer le maximum de vitesse des serveurs multicœurs modernes au coût le plus bas possible. Je suis Norbert E. Boros, fondateur et CEO de HotKV Ltd. Cet article explique pourquoi je l’ai créé, ce qu’il fait aujourd’hui et ce que donnent ses mesures.

En bref. HotKV exécute les commandes sur de nombreux threads à la fois dans un seul processus et parle RESP2 et RESP3, le protocole de Redis. Dans notre benchmark d’octobre 2026 sur une seule instance avec 160 vCPU, il a obtenu le débit le plus élevé sur 11 des 12 commandes que nous avons mesurées, et Dragonfly était à égalité avec lui sur la douzième. La configuration et ses limites sont décrites ci-dessous.

Pourquoi j’ai créé HotKV

La vitesse compte pour moi dans tout ce que je construis. Un site web, un outil ou un serveur devrait répondre instantanément, et quand ce n’est pas le cas, je veux savoir pourquoi. Cette habitude façonne mon travail depuis que j’écris du logiciel.

Le C et le C++ sont mes langages principaux depuis de nombreuses années. Pendant près de dix ans, j’ai travaillé sur un logiciel anti-triche pour jeux vidéo qui tournait sur les PC de milliers de joueurs. Il devait analyser la mémoire à la recherche de triches en utilisant le moins de CPU et de mémoire possible, car chaque cycle qu’il consommait était pris au jeu. Ce travail m’a appris à tout mesurer, à concevoir en fonction du matériel et à considérer une faible consommation de ressources comme une fonctionnalité à part entière.

En parallèle, j’ai utilisé Redis et Valkey dans de nombreux projets qui avaient besoin d’un cache rapide : des magasins de sessions, des listes d’adresses IP bloquées par un pare-feu et un cache placé devant des centaines de millions d’enregistrements SQL Server. Ce sont d’excellents outils. Ils m’ont aussi donné envie de savoir ce que pourrait faire un magasin clé-valeur conçu dès le départ pour les serveurs multicœurs que nous utilisons aujourd’hui.

HotKV est la réponse à laquelle je suis arrivé. Je l’ai écrit de zéro en C++ moderne pour tirer le maximum de vitesse du matériel, au coût le plus bas possible. Le benchmark ci-dessous montre où il en est aujourd’hui, et je pense qu’il reste encore à gagner.

Le coût de l’IA

Il y avait une seconde raison. Faire tourner des applications d’IA devenait coûteux, pour moi et, à en juger par ce que partageaient les développeurs en ligne, pour beaucoup d’autres aussi. Une grande partie de ce coût vient souvent du fait d’envoyer à un modèle des questions auxquelles il a déjà répondu. Un magasin rapide qui reconnaît une question répétée ou similaire et y répond depuis le cache est l’un des moyens les plus directs de réduire cette facture. C’est pourquoi la mise en cache pour les charges de travail d’IA est au cœur de HotKV.

À quoi sert HotKV

HotKV Ltd existe pour rendre ce type de logiciel plus performant et plus abordable. Les serveurs modernes ont beaucoup de cœurs, et un magasin de données devrait les utiliser, afin que vous obteniez le plus de vitesse possible au coût le plus bas possible.

La seconde idée est de garder une plus grande partie de la stack au même endroit. Les équipes qui construisent sur des LLM finissent souvent par exploiter un cache, une base de données vectorielle et un endroit où conserver la mémoire des agents, avec un tas de code de liaison entre eux. Je veux que la mise en cache et le travail d’IA construit autour vivent dans un seul moteur, à côté de vos données : cache exact et sémantique des appels aux modèles, recherche vectorielle, mémoire d’agent et budgets de tokens. Moins de systèmes à exploiter devrait signifier moins de pièces mobiles et une facture plus basse. La page IA liste ce qui est disponible aujourd’hui, et le benchmark d’économies de tokens montre ce que la mise en cache des appels aux modèles a fait économiser dans notre test.

HotKV conserve le protocole Redis et les bibliothèques clientes habituelles.

Le problème

Un seul thread d’exécution des commandes peut devenir un goulot d’étranglement sur une machine dotée de nombreux cœurs. Un magasin de données construit autour d’un seul thread d’exécution exploite généralement le reste de la machine en faisant tourner plusieurs instances ou un cluster, ce qui entraîne des choix de déploiement et un travail d’exploitation. Je voulais que HotKV parte de l’autre extrémité, avec des commandes qui s’exécutent simultanément au sein d’une seule instance, pour qu’un seul processus puisse utiliser toute la machine.

Ce que HotKV fait différemment

HotKV™ est écrit en C++20 et conçu pour exécuter des commandes sur de nombreux cœurs à la fois, de sorte qu’une seule instance puisse exploiter toute une machine. Dragonfly, que nous testons plus bas, adopte lui aussi une approche multithread.

• Plusieurs cœurs, une seule instance. Les commandes s’exécutent simultanément sur les cœurs de la machine : une seule instance peut ainsi utiliser un grand serveur plutôt que plusieurs plus petits.
• Clients et protocole familiers. HotKV prend en charge RESP2 et RESP3 : les bibliothèques clientes habituelles peuvent donc s’y connecter. Les transactions (MULTI/EXEC) et les scripts Lua sont pris en charge. Consultez la documentation des commandes pour connaître les commandes prises en charge et les éventuelles différences.

Comment il est construit et testé

Je construis HotKV moi-même et j’utilise l’assistance de l’IA là où elle aide. Ce qui compte plus que la façon dont une ligne a été écrite, c’est qu’elle tienne le coup ; le moteur est donc testé de façon intensive. Il compte plus de 2 000 tests automatisés et se compile avec AddressSanitizer, ThreadSanitizer et UndefinedBehaviorSanitizer. Il dispose aussi de cibles de fuzzing pour le parseur de protocole, la distribution des commandes, le chargement RDB et AOF, le flux de réplication et le bus de cluster.

La configuration du benchmark, ses limites et les résultats complets se trouvent sur la page Performance, pour que vous puissiez juger les chiffres vous-même.

Aperçu du benchmark

Mise à jour d’octobre 2026 : les chiffres publiés initialement dans cet article provenaient d’exécutions de benchmark que nous avons ensuite jugées entachées de défauts (entre autres, tous les générateurs de charge utilisaient la même graine aléatoire) ; nous les avons donc remplacés par les résultats de notre benchmark reconstruit.

Octobre 2026 : HotKV, Redis, Valkey et Dragonfly

HotKV Ltd a réalisé ce benchmark. Nous avons mesuré HotKV, compilé depuis les sources, face à Redis 8.10.2, Valkey 9.1.2 et Dragonfly 2.0.2. Chaque serveur a tourné seul, en instance unique sur les 160 vCPU d’une machine Azure D160alds_v7 (AMD EPYC 9V45), avec la persistance désactivée. Trois machines distinctes de 64 vCPU ont généré la charge avec memtier_benchmark : des valeurs de 256 octets, une profondeur de pipeline de 30 et 5 000 000 de clés préremplies. Chaque chiffre est la médiane de trois exécutions de 10 secondes.

HotKV a obtenu le débit le plus élevé sur 11 des 12 commandes. Face à Redis ou Valkey, il a mesuré entre 8,6 et au moins 69,7 fois leur débit, selon la commande et le serveur ; face à Dragonfly, entre 1,97 et 4,41 fois sur ces 11 commandes, plusieurs de ces valeurs étant des bornes inférieures. Sur PING, Dragonfly a mesuré 0,6 % de plus. Nous comptons cela comme une égalité, car les générateurs de charge étaient proches de leur propre limite. Le chiffre le plus élevé sur une commande de données était de 90,8 millions d’opérations INCR par seconde. INCR et PING déplacent peu de données et sont limités par les générateurs de charge ; le chiffre propre de HotKV pour ces commandes peut donc être plus élevé.

Lire le tableau

MGET lit huit clés et MSET écrit quatre paires clé-valeur par commande, et le débit compte des commandes. Le rapport signale sept chiffres de HotKV (GET et six commandes d’écriture) parce qu’ils ont atteint son seuil d’utilisation du réseau de 85 %, et PING parce que les générateurs de charge dépassaient 85 % de CPU. Les rapports qui s’appuient sur ces chiffres sont des bornes inférieures, marquées par ≥. GET et PING sont les vraies limites. Pour les six commandes d’écriture, le chiffre d’utilisation du réseau du rapport additionne le trafic entrant et sortant et le compare au plafond sortant ; il surestime donc leur proximité d’une limite. La plus lourde, SETNX, a utilisé au plus environ 80 % du plafond entrant mesuré. Nous gardons le ≥ sur ces chiffres, par convention prudente. Les tableaux complets, les indicateurs et les notes de méthode se trouvent sur la page Performance.

Périmètre du benchmark

• Build et réglages. HotKV a été compilé avec -march=native pour le CPU de test, alors que les autres serveurs étaient leurs builds de release standard.
• Réglages des threads. Chaque serveur a reçu tous les cœurs de la machine : HotKV --threads 160, Dragonfly 160 threads proactor, Valkey io-threads 160 et Redis io-threads 128, son maximum. Redis et Valkey exécutent les commandes sur un seul thread et peuvent atteindre un débit plus élevé avec moins de threads d’E/S ; leurs chiffres peuvent donc être inférieurs à leur meilleur résultat. Nous n’avons pas exécuté de clusters ni plusieurs instances de ces serveurs.
• Périmètre. Douze commandes, une seule taille de valeur, une seule profondeur de pipeline, sans TLS et sans persistance. LPOP et RPOP n’ont pas été mesurées, car à ces débits une lecture destructive vide en 10 secondes n’importe quelle liste qui tient en mémoire. Le rapport consigne la latence et l’utilisation de la mémoire, mais nous ne les comparons pas ici. Les serveurs ont effectué des quantités de travail très différentes pendant chaque exécution de 10 secondes, de sorte que les chiffres de mémoire ne sont pas comparables à conditions égales. Les charges de travail mixtes n’ont pas été mesurées.
• Variation. Redis a beaucoup varié entre ses trois exécutions sur plusieurs commandes, jusqu’à 7,2 fois entre sa plus rapide et sa plus lente sur HSET, et la médiane masque cela. En comparant à la meilleure exécution de chaque concurrent plutôt qu’à sa médiane, HotKV restait en tête sur les 11 commandes.

Redis, Valkey et Dragonfly sont des marques de leurs propriétaires respectifs. Ils ne sont nommés que pour identifier les logiciels que nous avons mesurés, et cela n’implique aucun parrainage, aucune approbation ni aucune affiliation.

Ce qui est livré aujourd’hui

Les familles de commandes de base comprennent les chaînes, les listes, les ensembles, les hachages, les ensembles triés, les streams, les index géospatiaux, les bitmaps, HyperLogLog, le pub/sub et les scripts Lua. Les modules d’IA et les fonctionnalités enterprise fonctionnent avec des offres sous licence. Les tarifs indiquent ce que comprend chaque offre. Consultez la documentation pour la couverture actuelle des commandes. Au-delà du jeu de commandes Redis :

• Étiquetage de clés : étiquetez les clés avec des tags arbitraires et interrogez-les par tag (TAG.SET, TAG.MEMBERS et cinq autres commandes).
• TTL en nanosecondes : NEXPIRE, NTTL et NEXPIREAT définissent et lisent l’expiration en nanosecondes, de sorte que les échéances peuvent être plus fines qu’une milliseconde. Les clés expirées sont récupérées par un balayage en arrière-plan et lorsqu’on y accède.
• Compression facultative des valeurs : pour les valeurs dépassant un seuil de taille (512 octets par défaut), désactivée sauf si vous l’activez.
• Snapshots sans fork : BGSAVE écrit sur un thread d’arrière-plan plutôt que dans un processus issu d’un fork. Un snapshot n’est pas une copie à un instant donné. Chaque clé est enregistrée telle qu’elle était lorsque le snapshot l’a atteinte. La réécriture du fichier en ajout seul, elle, utilise un fork.
• Métriques Prometheus : un point d’accès HTTP intégré, désactivé par défaut et activé avec metrics-port : aucun exporteur externe n’est donc nécessaire.

HotKV propose aussi une recherche vectorielle intégrée avec des index HNSW (VSIM.CREATEINDEX, VSIM.SET, VSIM.SEARCH). Nous l’avons mesurée face à Redis 8 dans Recherche vectorielle : HotKV face aux vector sets de Redis 8, de 1 à 100 clients.

Commencez sur HotKV Cloud, ou contactez les ventes pour exécuter HotKV sur vos propres serveurs.