Le premier anniversaire de Valkey : comment le fork communautaire a dépassé Redis

 (gomomento.com)
8 points par GN⁺ 2025-06-01 | 4 commentaires | Partager sur WhatsApp
  • La décision de Redis Inc de fermer son code source (passage à la SSPL) a ébranlé la confiance de la communauté, mais celle-ci s’est rassemblée autour du fork Valkey, entraînant une vague soutenue d’innovations et de contributions.
  • Redis 8.0 est revenu à l’open source, et son créateur Antirez a fait son retour pour participer à de nouvelles fonctionnalités et optimisations ; les deux camps progressent donc rapidement.
  • Selon les benchmarks les plus récents, Valkey 8.1.1 affiche, sur un environnement 8 vCPU, des performances SET supérieures de 37 % à Redis 8.0, avec une latence p99 plus faible (et un avantage de 16 % sur GET).
  • Grâce à des techniques de tuning en conditions réelles comme les threads d’E/S et le core pinning, Valkey obtient plus de 3 fois plus de débit en environnement multithread tout en minimisant la latence.
  • L’article partage aussi des benchmarks proches d’un usage réel et des conseils de tuning pratiques, en expliquant comment interpréter les résultats et les appliquer en production.

Fermeture du code source de Redis et arrivée de Valkey

  • Il y a un an, Redis Inc (anciennement Garantia Data) a détérioré sa relation de confiance avec la communauté en changeant sa licence open source (adoption de la SSPL).
  • Né comme réponse à ce problème, le fork ouvert Valkey est devenu un actif technologique largement utilisé pour les systèmes distribués, le cache et le traitement de données en temps réel.
  • De son côté, Redis a tenté de rétablir la confiance avec le retour d’Antirez (le fondateur), le renforcement des performances et des fonctionnalités, ainsi que le retour de Redis 8.0 à l’open source.

Valkey 8.1 vs Redis 8.0 : comparaison des performances

  • Benchmark SET sur la même instance AWS c8g.2xl à 8 vCPU, avec des objets de 1 KB, un keyspace de 3 M et 500 connexions
    • Valkey 8.1.1 : 999.8K RPS (p99 0.8ms)
    • Redis 8.0 : 729.4K RPS (p99 0.99ms)
    • Valkey est supérieur de 37 % sur SET et de 16 % sur GET, avec un p99 plus rapide de 30 % sur SET et de 60 % sur GET
  • Avec 6 threads d’E/S, Valkey passe de 239K à 678K RPS (x2,8), et le p99 de 1.68ms à 0.93ms (-44 %)
  • Redis progresse aussi avec les threads d’E/S, de 235K à 563K RPS, et le p99 de 1.35ms à 0.84ms (-40 %)

Effets du multithreading et du tuning des cœurs

  • Les threads d’E/S commencent à produire un effet important à partir de 3 threads, et Valkey creuse davantage l’écart avec Redis au-delà de 4 threads.
  • En limitant les cœurs IRQ (interruptions) à 2, puis en fixant Redis/Valkey sur les 6 cœurs restants (pinning), on obtient un gain supplémentaire
    • Valkey : 832K → 999.8K RPS (pinning des cœurs/IRQ, utilisation CPU à 80 %)
    • La séparation entre cœurs IRQ et cœurs applicatifs améliore l’efficacité du cache et réduit la tail latency au minimum.
    • Des exemples concrets sont fournis avec Docker via cpuset-cpus, --io-threads, etc.

Reproduire les benchmarks et conseils pratiques

  • Utilisation des dernières instances AWS Graviton4 (c8g.2xlarge), avec un cluster placement group
  • Obtention des performances maximales via le core pinning / l’isolement des IRQ / l’ajustement du nombre de connexions (autour de 400 à 500)
  • La taille du keyspace et des objets doit aussi être ajustée : des valeurs plus petites et un keyspace plus réduit améliorent le taux de hit du cache L3.
  • Recommandation d’utiliser activement des outils de benchmark multithread comme valkey-benchmark ou rpc-perf (outil en Rust plus proche d’un usage réel) 
    docker run --network="host" --rm --cpuset-cpus="2-7" \  
valkey/valkey:8.0.1 valkey-benchmark \  
-h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
-r 3000000 --threads 6 -d 1024

Limites et points d’attention dans la mesure des performances

  • Les résultats de benchmark peuvent différer des environnements de production réels

    • Les charges réelles combinent plusieurs facteurs : mélange SET:GET, variations de charge, objectifs de TPS, latence réseau, etc.
    • Lors d’une forte hausse du nombre de connexions, on peut aussi observer davantage de latence en file d’attente, une baisse du throughput et une hausse de la tail latency.
    • Les résultats peuvent varier fortement selon l’outil de benchmark, ses options et la topologie réseau.

Principales étapes de croissance et évolution de la communauté

Le projet Valkey a connu, au cours de l’année écoulée, des progrès soutenus sur plusieurs plans.

  • Sur GitHub et ailleurs, de nombreux développeurs et entreprises ont collaboré pour ajouter des fonctionnalités, corriger des bugs et renforcer la sécurité.
  • Des efforts ont aussi été menés sur la documentation et le support utilisateur afin de réduire la barrière à l’entrée pour les nouveaux utilisateurs.
  • Le fonctionnement du projet met l’accent sur une prise de décision transparente et sur des votes communautaires.

Valeur sectorielle et technique

Valkey présente les atouts suivants :

  • Tout le monde peut l’utiliser sans contrainte de licence, ce qui en fait une option attractive pour les fournisseurs de services cloud et les grandes entreprises du web.
  • Sa forte compatibilité avec Redis facilite les migrations.
  • Son développement piloté par la communauté permet d’intégrer des besoins variés et de publier rapidement des mises à jour continues.

Conclusion et enseignements

  • Valkey a montré, en un an seulement comme fork de Redis, qu’il pouvait dépasser Redis sur les plans technique, des performances et de la communauté.
  • Les conseils pratiques de tuning et les outils comme les threads d’E/S, la séparation cœurs/IRQ et l’ajustement des connexions sont déterminants.
  • Les performances ne s’améliorent pas automatiquement : une optimisation continue adaptée au système, à la charge et à l’infrastructure reste indispensable.
  • En environnement réel, il faut éviter de se fier uniquement aux chiffres de benchmark et adopter une approche pragmatique fondée sur des tests dans des situations variées.

À lire aussi

4 commentaires

 
ethanhur 2025-06-02

Redis a certes pris beaucoup de mauvaises décisions, mais c’est dommage de voir que celui qui fait tout le travail n’est pas celui qui en récolte les bénéfices.
 
kgcrom 2025-06-02

Publié dans le « Redis User Group » sur Facebook
Il s’agit d’un document qui résume les améliorations apportées à Valkey 8.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Le lire en parallèle du contenu ci-dessus devrait aider à mieux comprendre.
 
ndrgrd 2025-06-01

En réalité, ce n’est pas tant que Valkey ait fait quelque chose… c’est plutôt que l’autre côté s’est effondré tout seul…
 
GN⁺ 2025-06-01
Avis Hacker News
  • Je suis heureux de voir que Valkey a réalisé de beaux progrès dans le domaine de l’I/O threading, et a commencé à introduire certains des changements les plus intéressants de ces derniers temps ; un grand merci aux contributeurs de Valkey. Mais je pense que cet article a tendance à être quelque peu trompeur. À l’origine, l’architecture shared nothing était une philosophie très importante dans Redis, et c’est moi qui ai introduit l’I/O threading en 2020. Sans trahir l’esprit du shared nothing, j’ai pris en compte le fait que les appels système write(2)/read(2) peuvent être très lents au moment du retour de l’event loop, et j’ai donc introduit une structure où seul l’I/O est traité en parallèle sur N threads, sans contention, à cet instant précis, avant de revenir immédiatement à un modèle single-thread. Je remercie l’équipe Valkey d’avoir fait évoluer ce système davantage. Ce système fonctionnait déjà depuis longtemps, et je suis gêné par la tendance de la presse à exagérer des données qui, en pratique, n’ont pas changé. En réalité, ces fonctionnalités intéressent davantage les utilisateurs en entreprise ou les fournisseurs cloud (Amazon, Google, etc.) que la majorité des utilisateurs classiques de Redis. Sauf à devoir gérer une charge énorme ou un très grand nombre d’utilisateurs en même temps, Redis consomme généralement peu de CPU, donc il n’est pas vraiment nécessaire d’activer cela. Récemment, en développant le type de données vector set dans Redis, nous faisons du threading le comportement par défaut et permettons aussi des écritures de vector set via VADD de manière threadée. Des structures de données comme HNSW introduisent pour la première fois dans l’histoire de Redis un coût constant énorme, ce qui change complètement l’espace de conception. Par le passé, nous avions déjà implémenté la prise en charge des threads pour les modules. L’usage des threads est une décision qui dépend du contexte.
    • Mentionner une nuance ne génère pas de clics
    • J’ai l’impression que ce genre de billet critique arrive chaque mois en une de HN, et j’ai toujours eu envie de soutenir antirez. Je suis d’accord avec le fond technique, mais je pense que ces critiques relèvent souvent moins du concret que du classique tall poppy syndrome, c’est-à-dire la tendance à rabaisser quelqu’un qui a beaucoup réussi. Comme on ne peut pas contrôler la réaction des autres, il serait peut-être plus sain de considérer ce type de billet comme une reconnaissance indirecte de l’ampleur de vos accomplissements. Et merci aussi d’être connecté sur LinkedIn. Voir le tall poppy syndrome
  • Je me souviens qu’antirez avait annoncé que Redis redeviendrait open source article lié. Node.js avait autrefois failli s’effondrer avec le fork Io.js, mais la communauté l’avait remis sur pied. Je me demande si Redis peut connaître le même rétablissement. J’utilisais souvent Redis avant, mais je ne suis plus très bien l’évolution de la communauté ces dernières années.
    • La dernière fois que j’ai vérifié, Redis exigeait toujours une CLA (Contributor License Agreement). Cela signifie qu’ils conservent un droit exclusif leur permettant de refermer la source à tout moment. Si les contributeurs doivent accepter ce genre de clause, il n’y a aucune raison de croire qu’ils ne recommenceront pas.
    • Redis est distribué sous AGPL, Valkey sous licence BSD (qui était l’ancienne licence de Redis). Ce sont deux licences open source officielles, mais BSD est bien plus permissive.
    • Honnêtement, 99 % des utilisateurs se moquent du propriétaire tant qu’ils ont un magasin clé-valeur gratuit qui fonctionne correctement. D’un point de vue business, Redis occupe une position particulière : il offre énormément de fonctionnalités, mais les utilisateurs n’en exploitent que 5 %. Les fonctionnalités complexes comme Sentinel ou Streams n’intéressent même pas grand monde. Quand vient le moment de monétiser, les utilisateurs ont plusieurs options : « simplement ne plus l’utiliser », « migrer chez un concurrent », « développer eux-mêmes uniquement les fonctions indispensables », ou « forker la dernière version open source et en assurer la maintenance en interne pour économiser ». Comparé à PostgreSQL, une version simple de Redis (hashmap + interface réseau) est assez facile à recréer soi-même ; pour beaucoup d’entreprises, forker ou réimplémenter est donc un meilleur choix.
    • À mon avis aussi, il est déjà trop tard. Avec le changement brutal de politique de Redis, Redis est désormais pour moi un acteur non fiable, et Valkey sera le choix par défaut à l’avenir. Trompé une fois, pas deux.
    • Comment peut-on encore leur faire confiance après ce que Redis a fait ?
  • Je pense que Valkey devrait être présent dans le gestionnaire de paquets des distributions par défaut. Par exemple, quand on veut l’installer sur un GitHub Action runner, devoir ajouter une clé et mettre à jour la distribution à chaque fois est pénible.
    • Je me demande dans quelle distribution il manque. D’après les données de repology, il est déjà présent dans nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL, etc. En revanche, pour Debian, c’est à partir de la 13 ou de la 12+backports.
    • Pour information, sur Arch Linux, Valkey a déjà remplacé Redis.
    • Si, dans votre CI, la toute première chose après avoir récupéré une image de conteneur est d’installer toutes sortes de choses, il vaut mieux créer votre propre image.
  • Je suis très heureux de voir ce changement se produire et Valkey continuer à bien avancer. J’espère que Redis disparaîtra bientôt.
    • Ton ironiquement sarcastique : l’open source serait au service des entreprises monopolistiques. Des hyperscalers comme AWS gagnent des centaines de millions de dollars avec Redis, mais ni les développeurs ni les contributeurs n’en tirent vraiment profit. C’est pourquoi les startups de base de données devraient dès le départ choisir une fair source, avec des clauses anti-hyperscaler, afin que n’importe qui puisse utiliser librement le code, mais qu’AWS ou Google doivent payer s’ils veulent le proposer en Managed Service. Redis et Elasticsearch, partis avec une licence ultra permissive, auraient désormais un destin difficile à inverser.
  • On voit de plus en plus de projets dotnet passer au commercial ces derniers temps. Pour les développeurs, ce genre de changement ressemble à un rug pull, une rupture brutale de confiance. Cette ambiance risque aussi de freiner la diffusion d’autres bibliothèques open source en dotnet.
    • Dans l’écosystème .NET, cette tendance à la commercialisation ne date pas d’hier ; il y a toujours eu une affinité entre freeware/open-core et business.
  • J’avais entendu parler de Valkey l’an dernier, et je suis heureux de voir qu’il continue à bien se porter.
  • Je me demande si Valkey fournit ses propres bibliothèques clientes. En ce moment, dans l’environnement GCP, j’utilise Redis/Redis Cluster à la fois sur MemoryStore et en environnement autogéré. La bibliothèque C officielle m’a déçu avec Redis Cluster+TLS, au point que je dois utiliser un client non officiel, hiredis-cluster (https://github.com/Nordix/hiredis-cluster). Et je ne suis pas non plus très satisfait de Memorystore sur GCP. J’envisage de migrer vers Scylla.
    • Il existe un fork officiel appelé libvalkey, qui combine hiredis et hiredis-cluster, maintenu par les responsables actuels de hiredis/hiredis-cluster voir libvalkey
  • Maintenant que Redis a changé de politique, je me demande si Valkey et Redis pourraient dialoguer et fusionner.
    • Ce n’est pas un vrai retour en arrière, puisque la licence n’est pas revenue à l’état d’origine mais a été déplacée vers l’AGPL.
  • Partage d’un excellent billet expliquant le FUD attendu autour de la GPL article lié
    • Je trouve que l’idée, dans ce billet, selon laquelle une licence copyleft serait plus libre est un peu facile. Plus il y a d’obligations, moins il y a de liberté ; la discussion sur ce qui est « plus libre » mérite donc, à mon avis, plus de profondeur.
  • J’utilise Redis dans des dizaines d’applications. AWS proposait Valkey à prix réduit, donc je l’ai essayé il y a deux mois, sans percevoir de différence de performance. Mais Valkey s’est soudainement figé : AWS le considérait toujours comme en fonctionnement, mais toute connexion était coupée. Le problème n’a pas été résolu pendant plus de 12 heures, puis il s’est reproduit. AWS a enquêté pendant deux semaines sans en trouver la cause. Il m’est désormais difficile d’utiliser Valkey dans un environnement critique. Ensuite, je l’ai remplacé par Redis avec la même charge de travail, et je n’ai plus eu de problème.
    • C’est peut-être un problème AWS. Nous avons eu une expérience similaire sur un cluster RDS Postgres en production : plus aucune réponse réseau, support AWS Enterprise mobilisé, mais au final nous avons dû recréer un nouveau cluster nous-mêmes à partir d’une sauvegarde, ce qui a pris 4 heures. Depuis, nous évitons les services encapsulés d’AWS et sommes revenus à de l’EC2 classique avec réplication, snapshots et réplication S3.
    • Cela peut aussi être un problème d’exploitation côté AWS ; je n’ai fait tourner Redis qu’en direct, mais cela ne signifie pas forcément que Valkey lui-même est en cause.
    • Pourquoi ne pas lancer directement une instance Valkey vous-même ?
    • Quel type d’instance avez-vous utilisé ? Je demande pour référence.