Valkeys 1. Jahrestag: Wie der Community-Fork Redis überholt hat

• Redis Inc erschütterte mit der Entscheidung zur Quellschließung (Wechsel zu SSPL) das Vertrauen der Community, doch rund um den Fork Valkey sammelte sich die Entwickler-Community und trieb aktiv Innovationen und Beiträge voran
• Redis 8.0 ist wieder zu Open Source zurückgekehrt, und auch der Gründer Antirez ist zurück und arbeitet an neuen Funktionen und Optimierungen mit – beide Lager entwickeln sich schnell weiter
• Laut aktuellen Benchmark-Ergebnissen erzielt Valkey 8.1.1 in einer 8-vCPU-Umgebung bei SET eine um 37 % höhere Leistung als Redis 8.0, bei zugleich geringerer p99-Latenz (auch bei GET mit 16 % Vorsprung)
• Mit praxisnahen Tuning-Methoden wie IO-Threads und Core-Pinning erreicht Valkey in Multithreading-Umgebungen mehr als die dreifache Verarbeitungskapazität bei minimierter Latenz
• Es werden zudem Benchmarks unter realitätsnahen Einsatzbedingungen sowie Tuning-Know-how geteilt, inklusive Hinweisen zur Interpretation der Ergebnisse und zur Anwendung in Produktionsumgebungen

---

Die Quellschließung von Redis und das Auftreten von Valkey

• Vor einem Jahr verschlechterte sich das Vertrauensverhältnis zur Community, nachdem Redis Inc (früher Garantia Data) die Open-Source-Lizenz geändert und SSPL eingeführt hatte
• Der als Lösung entstandene offene Fork Valkey wurde zu einem breit genutzten Technologie-Baustein für verteilte Systeme, Caching und Echtzeit-Datenverarbeitung
• Auch Redis versucht seitdem, Vertrauen zurückzugewinnen – mit der Rückkehr von Antirez (dem Gründer), dem Ausbau von Leistung und Funktionsumfang sowie der erneuten Open-Source-Freigabe von Redis 8.0

Valkey 8.1 vs. Redis 8.0: Leistungsvergleich

• SET-Benchmark unter identischen Bedingungen: 8-vCPU-AWS-c8g.2xl-Instanz, 1-KB-Items, 3M-Keyspace, 500 Verbindungen
  • Valkey 8.1.1: 999.8K RPS (p99 0.8ms)
  • Redis 8.0: 729.4K RPS (p99 0.99ms)
  • Valkey liegt bei SET um 37 % und bei GET um 16 % vorn; bei SET ist p99 um 30 %, bei GET p99 um 60 % schneller
• Mit 6 IO-Threads steigt Valkey von 239K auf 678K RPS (2,8x), p99 sinkt von 1.68ms auf 0.93ms (44 %↓)
• Auch Redis profitiert von IO-Threads: von 235K auf 563K RPS, p99 von 1.35ms auf 0.84ms (40 %↓)

Wirkung von Multithreading- und Core-Tuning

• Ab 3 IO-Threads zeigt sich der Effekt deutlich; bei Valkey wird der Abstand zu Redis ab 4 Threads noch größer
• Wenn IRQ-Kerne auf 2 begrenzt und Redis/Valkey auf die verbleibenden 6 Kerne fixiert werden (Pinning), steigt die Leistung weiter
  • Valkey: 832K → 999.8K RPS (Core-/IRQ-Pinning, 80 % CPU-Auslastung)
  • Die Trennung von IRQ- und Anwendungs-Kernen verbessert die Cache-Effizienz und minimiert die Tail Latency
  • Konkrete Beispiele mit Docker und Optionen wie cpuset-cpus, --io-threads werden bereitgestellt

Benchmark-Reproduzierbarkeit und Praxistipps

• Einsatz einer aktuellen AWS Graviton4 (c8g.2xlarge)-Instanz mit Cluster Placement Group
• Maximale Leistung durch Core-Pinning / IRQ-Trennung / Anpassung der Verbindungszahl (Bereich 400–500)
• Auch Keyspace- und Item-Größe sollten abgestimmt werden; kleinere Werte und kleinerer Keyspace erhöhen die L3-Cache-Trefferquote
• Der aktive Einsatz von Multithreading-Benchmark-Tools wie valkey-benchmark oder rpc-perf (ein Rust-basiertes Tool, näher an realen Workloads) wird empfohlen

  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  
  

Grenzen und Hinweise zur Leistungsmessung

• Benchmark-Ergebnisse können von realen Produktionsumgebungen abweichen

  • Reale Workloads umfassen gemischte SET:GET-Muster, Lastschwankungen, TPS-Ziele, Netzwerklatenzen und weitere Faktoren
  • Bei stark steigender Verbindungszahl wurden auch Queueing-Latenz, sinkender Throughput und höhere Tail Latency beobachtet
  • Je nach Benchmark-Tool/Optionen und Netzwerk-Topologie können die Ergebnisse stark variieren

Zentrale Entwicklungsschritte und Community-Fortschritt

Das Valkey-Projekt hat sich im vergangenen Jahr in vielerlei Hinsicht dynamisch weiterentwickelt

• Auf GitHub und anderswo wurden unter Zusammenarbeit vieler Entwickler und Unternehmen Funktionen ergänzt, Bugs behoben und die Sicherheit verbessert
• Auch in Dokumentation und Nutzer-Support wurde investiert, um die Einstiegshürden für neue Nutzer zu senken
• Im Projektbetrieb wurden transparente Entscheidungen und Community-Abstimmungen besonders betont

Bedeutung für Branche und Technik

Valkey bietet unter anderem folgende Stärken

• Ohne Lizenzbeschränkungen nutzbar und daher eine attraktive Option für Cloud-Service-Anbieter und große Web-Service-Unternehmen
• Hohe Kompatibilität mit Redis, wodurch Migrationen einfach bleiben
• Community-getriebene Entwicklung, die vielfältige Anforderungen aufgreifen und schnelle kontinuierliche Updates ermöglichen kann

Fazit und Erkenntnisse

• Valkey hat ein Jahr nach dem Redis-Fork in technischer Hinsicht, bei der Leistung und in der Community-Entwicklung Ergebnisse gezeigt, die Redis übertreffen
• Praxisnahes Tuning mit IO-Threads, Core-/IRQ-Trennung und Verbindungssteuerung sowie die passenden Tools sind entscheidend
• Leistung kommt nicht automatisch; kontinuierliche Optimierung passend zu System, Workload und Infrastruktur ist unverzichtbar
• In realen Service-Umgebungen ist ein praxisnaher Ansatz nötig: nicht nur auf Benchmark-Zahlen vertrauen, sondern unterschiedliche Situationen selbst testen

[ethanhur]

Redis hat zwar viele falsche Entscheidungen getroffen, aber es ist schade, wenn am Ende der Bär die Kunststücke macht und der Dompteur das Geld kassiert.

[kgcrom]

In der Facebook-"Redis User Group" gepostetes
Material, das zusammenfasst, welche Verbesserungen in Valkey 8 vorgenommen wurden.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Wenn Sie es zusammen mit dem obigen Inhalt lesen, dürfte es beim Verständnis helfen.

[ndrgrd]

Eigentlich weniger, weil Valkey selbst etwas Besonderes geleistet hätte … eher, weil die andere Seite ganz von allein abgestürzt ist …

[GN⁺]

Hacker-News-Kommentare

• Ich freue mich, dass Valkey im Bereich I/O-Threading tolle Fortschritte gemacht hat und zuletzt auch einige der interessantesten Änderungen einzuführen begonnen hat. Großen Dank an die Valkey-Mitwirkenden. Ich denke aber, dass dieser Artikel etwas irreführend ist. Ursprünglich war die Shared-Nothing-Architektur in Redis eine sehr wichtige Philosophie, und ich war 2020 selbst derjenige, der I/O-Threading eingeführt hat. Ohne den Sinn von Shared Nothing zu verletzen, habe ich unter Berücksichtigung dessen, dass write(2)/read(2)-Syscalls beim Verlassen des Event Loops sehr langsam sein können, eine Struktur eingeführt, bei der in diesem Moment nur I/O im Zustand ohne Contention auf N Threads parallelisiert wird und danach sofort wieder zum Single-Thread zurückgekehrt wird. Ich bin dankbar, dass das Valkey-Team dieses System weiterentwickelt hat. Dieses System funktionierte schon früher, und es stört mich, dass die Presse Daten, die sich in der Realität nicht verändert haben, einfach übertreibt. Solche Funktionen interessieren in der Praxis eher Enterprise-Nutzer oder Cloud-Anbieter (Amazon, Google usw.) als die meisten normalen Redis-Nutzer. Wenn man nicht zwangsläufig enorme Last oder sehr viele Nutzer gleichzeitig bedienen muss, ist die CPU-Auslastung von Redis meist niedrig, sodass man es nicht extra aktivieren muss. Während in Redis zuletzt der Datentyp vector set entwickelt wird, ist Threading dort standardmäßig vorgesehen, und auch das Schreiben von Vector Sets über VADD kann per Threading erfolgen. Datenstrukturen wie HNSW haben erstmals in der Geschichte von Redis enorme konstante Laufzeiten, wodurch sich der gesamte Designraum verändert. In der Vergangenheit hatte ich auch bereits Thread-Unterstützung für Module implementiert. Ob man Threads verwendet, ist eine situationsabhängige Entscheidung.
  • Es wird angemerkt, dass nuancierte Sichtweisen keine Klicks bringen
  • Ich habe das Gefühl, dass solche kritischen Beiträge jeden Monat auf der HN-Startseite landen, und ich wollte antirez immer unterstützen. Dem technischen Kern stimme ich zu, aber ich denke, dass solche Kritik oft eher mit dem klassischen Tall-Poppy-Syndrom zu tun hat – also der Tendenz, sehr erfolgreiche Menschen anzugreifen – als mit konkreten Inhalten. Da man die Reaktionen anderer nicht kontrollieren kann, wäre es vielleicht gesünder, solche Kritiken als indirekte Anerkennung dafür zu sehen, wie groß deine Leistung ist. Ich freue mich auch darüber, auf LinkedIn vernetzt zu sein Tall-Poppy-Syndrom ansehen
• Ich erinnere mich daran, dass antirez angekündigt hatte, Redis wieder zu Open Source zu machen verwandter Beitrag. Früher wäre Node.js durch die Io.js-Fork-Affäre beinahe zusammengebrochen, aber die Community hat es wieder aufgebaut. Ich frage mich, ob Redis eine ähnliche Erholung schaffen kann. Früher habe ich Redis oft verwendet, aber in den letzten Jahren habe ich die Community-Entwicklung nicht gut verfolgt.
  • Als ich zuletzt nachgesehen habe, verlangt Redis immer noch ein CLA (Contributor License Agreement). Das bedeutet, dass weiterhin ein exklusives Recht besteht, den Source Code jederzeit wieder zu schließen. Wenn Mitwirkende solchen Bedingungen zustimmen müssen, gibt es keinen Grund zu vertrauen, dass man nicht noch einmal dasselbe tut.
  • Redis wird unter der AGPL verteilt, Valkey unter der BSD-Lizenz (BSD war die frühere Redis-Lizenz). Beides sind offizielle Open-Source-Lizenzen, aber BSD ist deutlich freier.
  • Ehrlich gesagt ist es 99 % der Nutzer egal, wem es gehört, solange ein kostenloser Key-Value-Store ordentlich läuft. Aus Business-Sicht hat Redis eine besondere Position: Es bietet sehr viele Funktionen, aber reale Nutzer verwenden nur 5 % davon, und an komplexen Features wie Sentinel/Streams besteht kein Interesse. Wenn monetarisiert werden soll, haben Nutzer viele Optionen: „einfach nicht mehr verwenden“, „zur Konkurrenz wechseln“, „nur die wirklich nötigen Funktionen selbst bauen“, „die letzte Open-Source-Version forken und intern pflegen, um Kosten zu sparen“ usw. Im Vergleich zu PostgreSQL ist die einfache Variante von Redis (Hashmap + Netzwerk-Interface) leicht selbst nachzubauen, weshalb für viele Unternehmen Forken oder Eigenbau die bessere Wahl ist.
  • Ich denke auch, dass es schon zu spät ist. Durch den abrupten Politikwechsel von Redis ist Redis für mich nun ein Gegenstand des Misstrauens, und künftig ist Valkey die Standardwahl. Einmal betrogen, kein zweites Mal.
  • Es wird die Frage gestellt, wie man Redis nach dem, was passiert ist, noch vertrauen kann
• Ich denke, Valkey sollte in den Paketmanager der Standard-Distributionen aufgenommen werden. Wenn man es etwa auf einem GitHub-Action-Runner installieren will, ist es lästig, jedes Mal Schlüssel hinzuzufügen und die Distribution zu aktualisieren.
  • Ich frage mich, in welcher Distribution es fehlt. Laut Repology-Daten ist es bereits in nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL usw. enthalten. Bei Debian allerdings erst ab 13 oder 12+backports.
  • Zur Info: Unter Arch Linux hat Valkey Redis bereits ersetzt.
  • Wenn in CI der erste Schritt nach dem Holen eines Container-Images ohnehin die Installation diverser Dinge ist, ist es vermutlich besser, das Image selbst zu bauen.
• Ich freue mich sehr, dass dieser Wandel stattfindet und Valkey weiterhin konstant gut läuft. Hoffentlich verschwindet Redis bald.
  • Ein ironischer Tonfall darüber, dass Open Source für Monopolkonzerne da sei; AWS und andere Hyperscaler verdienen mit Redis Hunderte Millionen Dollar, während die eigentlichen Entwickler und Mitwirkenden davon nichts haben. Deshalb sollten DB-Startups von Anfang an mit Fair-Source-Lizenzen starten (Lizenzen mit Anti-Hyperscaler-Klauseln), damit zwar jeder den Code frei nutzen kann, AWS oder Google aber zahlen müssen, wenn sie ihn als Managed Service anbieten wollen. Bei Redis und Elasticsearch, die bereits mit einer extrem permissiven Lizenz gestartet sind, sei dieses Schicksal kaum noch umkehrbar.
• In letzter Zeit stellen viele dotnet-Projekte auf Kommerzialisierung um. Für Entwickler fühlt sich so ein Wandel oft wie ein Rug Pull an – also wie ein plötzlicher Vertrauensbruch durch eine abrupte Richtungsänderung. Diese Stimmung könnte sich auch negativ auf die Verbreitung anderer Open-Source-.NET-Bibliotheken auswirken.
  • Im .NET-Umfeld ist diese Tendenz zur Kommerzialisierung nichts Neues; dort hingen Freeware/Open-Core und Business schon immer eng zusammen.
• Ich habe schon seit dem letzten Jahr von Valkey gehört und freue mich, dass es immer noch gut läuft.
• Ich frage mich, ob Valkey eigene Client-Bibliotheken anbietet. Derzeit nutze ich in einer GCP-Umgebung sowohl Memorystore als auch selbstverwaltete Setups und verwende dabei sowohl Redis als auch Redis Cluster. Die offizielle C-Bibliothek war bei Redis Cluster + TLS enttäuschend, sodass ich einen inoffiziellen Client namens hiredis-cluster (https://github.com/Nordix/hiredis-cluster) verwenden musste. Auch mit GCP Memorystore bin ich nicht besonders zufrieden. Ich erwäge einen Wechsel zu Scylla.
  • Es gibt einen offiziellen Fork namens libvalkey, der hiredis und hiredis-cluster kombiniert und von den bisherigen Maintainern von hiredis/hiredis-cluster betreut wird libvalkey ansehen
• Jetzt, wo Redis seine Richtlinie geändert hat, frage ich mich, ob Valkey und Redis miteinander sprechen und sich wieder zusammenschließen können.
  • Es wird darauf hingewiesen, dass es kein echter U-Turn ist, weil die Lizenz nicht wiederhergestellt, sondern auf die AGPL umgestellt wurde.
• Es wird ein Link zu einem hervorragenden Beitrag geteilt, der das erwartbare GPL-bezogene FUD (Fear, Uncertainty, Doubt) erklärt verwandter Beitrag
  • Ich halte die Behauptung im Beitrag, Copyleft-Lizenzen seien freier, für etwas zu einfach. Je mehr Verpflichtungen es gibt, desto geringer wird in gewisser Weise die Freiheit, daher sollte die Diskussion darüber, welcher Stil „freier“ ist, tiefer geführt werden.
• Ich verwende Redis in Dutzenden von Anwendungen. Als AWS Valkey zu einem rabattierten Preis angeboten hat, habe ich es vor zwei Monaten ausprobiert und keinen Leistungsunterschied gespürt. Dann ist Valkey plötzlich hängen geblieben; AWS hielt es weiterhin für laufend, aber die Verbindung war vollständig unterbrochen. Mehr als 12 Stunden lang wurde es nicht wiederhergestellt, und dann passierte es erneut. AWS hat zwei Wochen lang untersucht, konnte die Ursache aber nicht finden. Für mission-kritische Umgebungen wird es dadurch für mich schwer, Valkey weiter zu verwenden. Danach habe ich bei derselben Workload wieder auf Redis gewechselt, und dort gab es keine Probleme.
  • Das könnte ein AWS-Problem sein. Wir hatten in einem produktiven RDS-Postgres-Cluster etwas Ähnliches. Das Netzwerk reagierte nicht mehr, und obwohl wir AWS Enterprise Support hatten, mussten wir am Ende selbst aus einem Backup einen neuen Cluster wiederherstellen; das dauerte vier Stunden. Seitdem meiden wir gekapselte AWS-Services und setzen stattdessen auf normales EC2 mit Replikation, Snapshots, S3-Replikation usw.
  • Es könnte auch ein betriebsseitiges AWS-Problem sein; ich habe Redis nur selbst betrieben, aber es muss nicht unbedingt ein Problem von Valkey selbst sein.
  • Es wird gefragt, warum nicht direkt eine eigene Valkey-Instanz gestartet wird
  • Es wird gefragt, welcher Instanztyp verwendet wurde, als Referenzfrage