The Jerusalem PostMoscow summons British envoy over weapons supplies to UkraineESPNVikings to start Wentz with Murray on the mendESPN DeportesBayern toma ventaja sobre Union BerlínRTP DesportoLiga das Nações. Sportinguista Doumbia chamado pela primeira vez à seleção italianaוואלהאישה פלסטינית הותקפה באזור חירבת מרכז; המשטרה פתחה בחקירהBillboardKarol G Dazzles at MetLife Stadium, Brings Tainy, Judeline & rusowsky for ‘BbY WOW’: 5 Best MomentsCollider6 Flawless Miniseries With No Weak Episodes, RankedABC News'Foreign actors' targeted small, private water providers in Colorado: GovernorInquirerHabagat returns, brings rains to parts of Luzon, VisayasANSAScoppia il caso Aspides, Roma chiede all'Ue più navi e fondiVarietyCanada’s BetterHalf Films Joins Indonesia’s Studio Amarana on Animated Film ‘Galeo of the Seawalkers’ (EXCLUSIVE)BBC NewsMcIlroy in mix heading into weekend at Wentworth
The Daily Newsstand · Free, Always
Friday, September 18, 2026

Redis und Valkey im Visier: Dragonfly 2.0 ist da

Translate

Dragonfly 2.0 erweitert die Kompatibilität zu Redis und Valkey, senkt an mehreren Stellen den Aufwand für die Verbindungs- und Speicherverwaltung und behebt zahlreiche Fehler in Clustern, Streams und Tiered Storage. Neue große Funktionen umfasst die neue Version trotz Major Release laut Projektteam zwar nicht, sie soll aber einen Reifegrad für den produktiven Einsatz markieren.

Bei Dragonfly handelt es sich um einen quelloffenen In-Memory Data Store, der als kompatible Alternative zu Redis und Memcached gedacht ist. Er richtet sich laut GitHub-Projektseite vor allem an Betreiber und Entwickler, die bestehende Clients und Protokolle weiterverwenden, aber Last auf mehrere CPU-Kerne verteilen wollen.

Mit Version 2.0 kann Dragonfly RDB-Dateien aus Valkey 9 einlesen, auch wenn Hashes darin sowohl dauerhafte als auch mit Ablaufzeit versehene Felder enthalten. RDB ist das binäre Snapshot-Format aus dem Redis- und Valkey-Umfeld. Die Neuerung erleichtert folglich Migrationen oder Wiederherstellungen aus Valkey-9-Installationen.

Neu ist außerdem GEOSEARCHSTORE. Der Befehl sucht Mitglieder eines Geodatensatzes innerhalb eines Radius oder eines Rechtecks und schreibt das Resultat in einen Zielschlüssel. Dragonfly unterstützt dabei Sortierung, Limits, Entfernungswerte, ACL-Prüfungen und das Journaling der Operation.

Auch die Replikation erhält neue Optionen: Einträge im Replikations-Backlog lassen sich nun nach Alter und Speicherbudget aufbewahren. Die bisherige feste Längenbegrenzung wurde dagegen als veraltet markiert. Damit können Betreiber den Puffer für nachziehende Replikate stärker an verfügbarem Speicher und erwarteten Unterbrechungszeiten ausrichten.

Mehrere Änderungen haben einen geringeren Overhead bei vielen Verbindungen und großen Datenmengen zum Ziel. Dragonfly aktualisiert Telemetriedaten zum Speicherverbrauch einer Verbindung nicht mehr nach jedem einzelnen Befehl einer Pipeline, sondern nur noch pro Parsing-Zyklus. Zudem arbeitet die Speicherabrechnung für Verbindungen jetzt in konstanter Zeit statt abhängig von der Zahl verwalteter Elemente.

Client-Eingabepuffer schrumpft Dragonfly künftig nach längerer geringer Auslastung. Standardmäßig sinkt die maximale zurückbehaltene Größe von 64 auf 32 KiB. Beim Serialisieren von RDB-Snapshots gibt die Software übergroße Puffer nach dem Schreiben wieder frei; standardmäßig bleiben höchstens 4 MiB Kapazität erhalten. So soll etwa ein einmalig verarbeiteter 512-MiB-Wert nicht dauerhaft einen ebenso großen Puffer reservieren.

Für die Defragmentierung kommen konfigurierbare Phasen für Lastspitzen und Abkühlzeiten hinzu. Mit MEMORY DEFRAGMENT-SEGMENTS [threshold] kann Dragonfly zudem schwach belegte Seiten interner Tabellenstrukturen zurückgewinnen und deren Auslastung ausgeben. Ein optionaler, standardmäßig deaktivierter gemeinsamer RESP2-Lesepuffer legt außerdem die Grundlage für niedrigeren Speicherbedarf bei sehr vielen Verbindungen; die dazu genannte Einsparung ist nach Angaben des Projekts allerdings noch nicht mit diesem Commit erreicht.

Das Release härtet insbesondere den Befehl RESTORE ab, der serialisierte Werte einspielt. Dragonfly weist nun unter anderem doppelte Hash-Felder zurück. Außerdem lehnt das System deklarierte Datenlängen ab, die größer als die verbleibende Eingabe sind. Letzteres soll Abstürze durch übermäßige Speicherbelegung nach präparierten RESTORE-Eingaben verhindern.

Weitere Korrekturen gibt es bei Streams und ihren Consumer Groups, etwa XREADGROUP. Dragonfly prüft bei mehreren Streams ab sofort alle Argumente, bevor es den Zustand einer Consumer Group verändert, und behandelt Fälle wie abgelaufene, gelöschte oder in einen anderen Datentyp umgewandelte Streams konsistenter. Auch bei RESP3-Antworten, Cluster-Migrationen, ausgelagerten Daten im Tiered Storage und komprimierten Listen gibt es in Version 2.0.0 zahlreiche Bugfixes.

Die vollständige Liste der Änderungen findet sich in den Release Notes zu Dragonfly 2.0.

View the original on heise online

KioskNews shows a cleaned-up reading view extracted from the publisher’s page — the original always lives on their site, not ours.

Redis und Valkey im Visier: Dragonfly 2.0 ist da — KioskNews