Dragonfly 2.0 zielt auf produktive Redis-Workloads
Dragonfly 2.0 ist als neue Hauptversion des quelloffenen In-Memory Data Store erschienen. Die Software hält Daten primär im Arbeitsspeicher, unterstützt die Protokolle von Redis und Memcached und verteilt Last auf mehrere CPU-Kerne.
Das Projekt liefert mit Version 2.0 keine grundlegend neue Architektur. Stattdessen stehen Kompatibilität, Speicherverwaltung und Stabilität im Mittelpunkt. Das Projektteam betrachtet die Veröffentlichung deshalb vor allem als Schritt zur Produktionsreife.
Dragonfly 2.0 soll bestehende Redis- und Valkey-Umgebungen leichter migrierbar machen und gleichzeitig den Speicherbedarf im laufenden Betrieb besser begrenzen.
Valkey 9 und GEOSEARCHSTORE werden unterstützt
Dragonfly kann nun RDB-Dateien aus Valkey 9 einlesen. RDB ist das binäre Snapshot-Format aus dem Redis- und Valkey-Umfeld. Unterstützt werden auch Hashes, die dauerhafte Felder und Felder mit Ablaufzeit kombinieren.
Das erleichtert Migrationen und Wiederherstellungen aus Valkey-9-Installationen. Konkrete Vergleichswerte zur Geschwindigkeit gegenüber Valkey 9 oder aktuellen Redis-Versionen nennt das Projekt allerdings nicht.
Neu ist außerdem der Befehl GEOSEARCHSTORE. Er sucht Einträge innerhalb eines Radius oder Rechtecks und speichert die Ergebnisse unter einem Zielschlüssel. Sortierung, Ergebnislimits, Entfernungswerte, Zugriffsregeln und die Protokollierung der Operation werden berücksichtigt.
Replikationspuffer wird flexibler
Der Replikations-Backlog ist ein Zwischenspeicher, aus dem unterbrochene Replikate fehlende Änderungen nachladen können. Seine Aufbewahrung lässt sich jetzt nach Alter und verfügbarem Speicherbudget konfigurieren. Die bisherige Begrenzung über eine feste Länge gilt als veraltet.
Betreiber können den Puffer damit besser an typische Unterbrechungszeiten und vorhandenen RAM anpassen. Das ist vor allem für Installationen relevant, bei denen Replikate über langsamere oder weniger stabile Verbindungen angebunden sind.
Dragonfly gibt ungenutzten Speicher früher frei
Ein Schwerpunkt des Releases liegt auf dem Speicherverbrauch bei vielen Verbindungen. Telemetriedaten werden nicht mehr nach jedem einzelnen Befehl innerhalb einer Pipeline aktualisiert, sondern einmal pro Parsing-Zyklus. Auch die Speicherabrechnung einer Verbindung arbeitet nun in konstanter Zeit.
| Bereich | Bisheriges Verhalten | Dragonfly 2.0 |
|---|---|---|
| Client-Eingabepuffer | Bis zu 64 KiB nach geringer Auslastung | Standardmäßig maximal 32 KiB |
| RDB-Serialisierungspuffer | Große Puffer konnten dauerhaft reserviert bleiben | Standardmäßig höchstens 4 MiB nach dem Schreiben |
| Replikations-Backlog | Feste Längenbegrenzung | Steuerung nach Alter und Speicherbudget |
Die automatische Verkleinerung ist bei wechselnder Last besonders relevant. Musste ein RDB-Snapshot beispielsweise einmalig einen Wert mit 512 MiB verarbeiten, konnte ein entsprechend großer Puffer zuvor reserviert bleiben. Version 2.0 gibt solche übergroßen Reserven nach dem Schreiben wieder frei.
Für die Speicherbereinigung kommen konfigurierbare Phasen für Lastspitzen und Abkühlzeiten hinzu. Mit MEMORY DEFRAGMENT-SEGMENTS [threshold] lassen sich schwach belegte Speicherbereiche interner Tabellenstrukturen zurückgewinnen und auswerten.
Ein gemeinsamer RESP2-Lesepuffer für viele Verbindungen ist ebenfalls vorbereitet, bleibt standardmäßig jedoch deaktiviert. Die daraus erwartete Speichereinsparung ist bislang nicht beziffert und laut Projekt noch nicht vollständig erreicht.
RESTORE und Clusterbetrieb werden robuster
Der Befehl RESTORE, der serialisierte Werte einspielt, prüft Eingaben nun strenger. Doppelte Hash-Felder werden abgewiesen. Gleiches gilt für deklarierte Datenlängen, die größer als die tatsächlich verbleibende Eingabe sind.
Damit soll verhindert werden, dass präparierte Eingaben übermäßige Speicherbelegung oder Abstürze auslösen. Weitere Fehlerkorrekturen betreffen Consumer Groups und Streams, darunter XREADGROUP, sowie RESP3-Antworten, Cluster-Migrationen und Tiered Storage.
Self-Hosting kann Cloud- und Lizenzkosten begrenzen
In-Memory-Datenbanken verursachen hohe Infrastrukturkosten, weil große RAM-Instanzen bei Hyperscalern teuer sind. Dragonfly adressiert dieses Problem mit Multithreading und einer aggressiveren Freigabe ungenutzter Puffer. Wie groß die Einsparung im Einzelfall ausfällt, muss jedoch mit der eigenen Last getestet werden.
Für Unternehmen im DACH-Raum eröffnet das eine Alternative zu proprietären Redis-Angeboten und vollständig verwalteten Cloud-Diensten. Dragonfly kann auf eigener Infrastruktur oder bei einem regionalen Cloud-Anbieter betrieben werden. Das schafft mehr Kontrolle über Datenstandort, Sicherungen und Kosten, erhöht aber zugleich die Verantwortung für Betrieb, Updates und Ausfallsicherheit.
Die Bedeutung dieser Kontrolle zeigt sich auch bei endgültigem Datenverlust in einer AWS-Region. Gleichzeitig erinnert die Diskussion um den VMware-KI-Lock-in unter Broadcom daran, dass technische Abhängigkeiten schnell zu wirtschaftlichen Abhängigkeiten werden können.
Die Redis-Kompatibilität kann den Wechsel erleichtern, ersetzt aber keine Prüfung der tatsächlich verwendeten Befehle, Clients und Betriebsfunktionen. Besonders Clusterverhalten, Replikation, Wiederherstellung und Lastspitzen sollten vor einer produktiven Migration getestet werden.