Dragonfly senkt Speicherbedarf und prüft Importe strenger
Version 2.0 lädt Valkey-9-Snapshots und senkt den Default des Client-Puffers. Interner Betrieb bleibt zulässig, der Verkauf als fremder Cloud-Dienst nicht.
Dragonfly hat am 16. September 2026 die Hauptversion 2.0 veröffentlicht, die laut GitHub-Notiz auf Performance und Produktionsreife zielt. Cache-Teams können damit Valkey-9-Snapshots laden, benötigen weniger Platz für den Client-Puffer und erhalten strengere Prüfungen beim Import serialisierter Werte.
Das Wichtigste in Kürze
- Der Major markiert Produktionsreife. Dieses Release trägt keine große neue Funktion.
- Valkey-9-RDB und GEOSEARCHSTORE binden Snapshots und Geo-Abfragen an Redis. Bestehende Clients laufen über Redis- und Memcached-Protokoll weiter.
- Speicherabrechnung und Eingabepuffer brauchen im Betrieb weniger Platz. RESTORE lehnt kaputte oder präparierte Payloads härter ab.
Verwandt:Google koppelt TPU-Payback an fünfjährige Verträge / HashiCorp gibt Machine Images einen Herkunftsnachweis
Was ist Dragonfly? Dragonfly ist ein In-Memory-Datenspeicher, der Redis- und Memcached-Protokoll spricht und Last über CPU-Kerne im Shared-Nothing-Modell verteilt. Die Shards halten die Datenverarbeitung getrennt und vermeiden einen gemeinsamen zentralen Zustand.
Dragonfly ordnet den Major als Reifestufe ein
Die GitHub-Notiz beschreibt v2.0.0 als Meilenstein für Reife, Leistung und Produktionsbetrieb. Der Schwerpunkt liegt auf gebündelten Änderungen an Snapshots, Puffern, GEOSEARCHSTORE und RESTORE. Produktionsreife bezieht sich damit auf den Gesamtstand des Dienstes: Datenimport, Verbindungsverwaltung und Prüfungen beim Wiederherstellen.
Dragonfly ist eine Neuimplementierung. Redis bleibt eine eigene Marke mit eigener Lizenz. Valkey steht unter der Linux Foundation. Valkey folgt einer anderen Lizenzlinie als Dragonfly: Der Fork steht unter BSD, während Dragonfly BSL 1.1 beibehält. Bestehende Clients bleiben anschlussfähig; die Änderungen greifen direkt in Import, Pufferung und Restore ein.
Dragonfly lädt Snapshots aus Valkey 9
Version 2.0 lädt Valkey-9-RDB, auch Hashes mit dauerhaften und ablaufenden Feldern gemischt. RDB ist das binäre Snapshot-Format aus Redis und Valkey. Der Import unterstützt damit weitere Valkey-Snapshots. Ablaufzeiten von Hash-Feldern werden dabei von Millisekunden in Dragonflys Sekundenauflösung übertragen.
Neu ist GEOSEARCHSTORE. Der Befehl sucht in Geo-Daten und schreibt das Ergebnis in einen Zielschlüssel. Dragonfly zieht den Redis-Befehl nach, inklusive Radius oder Rechteck, Sortierung, Limits und Distanz. Die Release-Notiz nennt für GEOSEARCHSTORE außerdem ACL und Journaling.
Die Replikation hält den Backlog nach Alter und Speicherbudget. Die feste Längengrenze gilt als veraltet. Fällt eine Replika weg, kann sie nachziehen, solange das Budget reicht.
RESTORE lehnt doppelte Hash-Felder und deklarierte Längen ab, die größer sind als der Rest der Eingabe. Die GitHub-Notiz begründet das mit präparierten Payloads, die sonst den Speicher des Nodes sprengen. Die härtere Prüfung greift bei RESTORE, wenn ein Schlüssel aus einem serialisierten Wert wiederhergestellt wird.
XREADGROUP prüft alle Streams, bevor sich der Zustand der Consumer Group ändert.
Die Release-Notiz führt daneben Korrekturen für RESP3-Null-Antworten, Cluster-Migration, Tiered Storage und komprimierte Listen auf. Diese Einzelkorrekturen ergänzen den Schwerpunkt der Hauptversion: Dragonfly verbessert den Betrieb und die Kompatibilität; eine neue Kernfunktion steht dabei nicht im Vordergrund.
Client-Puffer schrumpft auf 32 KiB
Version 2.0 aktualisiert die Telemetrie zum Speicherverbrauch je Verbindung einmal je Parsing-Zyklus. Zuvor lief sie nach jedem Pipeline-Befehl. Die Erfassung des Verbindungsspeichers arbeitet in konstanter Zeit, unabhängig von der Zahl der Abonnements und überwachten Schlüssel.
Nach geringer Last schrumpft der Client-Eingabepuffer. Der RDB-Serializer gibt übergroße Puffer nach dem Schreiben frei. Auch nach einem großen Dump behält er damit keinen Puffer in der Größe des Werts zurück; die neuen Standardwerte stehen in der Tabelle.
| Puffer | Bisher | Jetzt |
|---|---|---|
| Client-Eingabepuffer, Default-Maximum | 64 KiB | 32 KiB |
| RDB-Serializer, Restkapazität nach dem Schreiben | bis zur Größe des Werts, Beispiel 512 MiB | 4 MiB Default |
Quelle: GitHub-Release Dragonfly v2.0.0 vom 16. September 2026.
RESP ist das Textprotokoll von Redis. Ein optionaler gemeinsamer Lesepuffer für dieses Protokoll ist vorbereitet und standardmäßig aus. Version 2.0.0 liefert diese Einsparung noch nicht.
Die GitHub-Notiz nennt für diesen gemeinsamen Lesepuffer künftig eine Senkung von rund 800 MB auf unter 1 MB. Die Rechnung gilt für viele gleichzeitige Verbindungen auf einem stark bestückten Host.
Der Befehl MEMORY DEFRAGMENT-SEGMENTS gibt schwach belegte Seiten der internen Hashtabelle frei. Die Hintergrund-Defragmentierung erhält Burst- und Cool-down-Limits. Die GitHub-Notiz nennt als Beispiel rund ein Prozent eines CPU-Kerns.
Wer Dragonfly als eigenen Dienst verkauft, braucht einen anderen Vertrag
Die Lizenz bleibt Business Source License 1.1. Internes Selbst-Hosting bleibt zulässig. Die BSL begrenzt die Angebotsform: Managed-Anbieter, die einen Redis-kompatiblen Store als eigenes Produkt verkaufen wollen, brauchen einen anderen Vertrag.
Häufige Fragen
Warum hebt Dragonfly die Major-Version ohne große neue Funktion?
Die Notiz setzt die Hauptversion als Signal für den Reifegrad und bündelt dafür Änderungen an Kompatibilität, Pufferung und Restore. Der Versionsmarker bündelt den Gesamtstand des Projekts und benennt diese Bereiche als sichtbare Änderungen.
Was ändert sich für Redis- und Valkey-Workloads beim Snapshot?
Der Import umfasst Valkey-9-RDB und gemischte Hash-Felder; bestehende Redis- und Memcached-Clients können weiterlaufen. Der Unterschied liegt im Datenbestand: RDB ist das Snapshot-Format, während die Protokollkompatibilität bei der laufenden Verbindung erhalten bleibt.
Dürfen Anbieter Dragonfly als eigenen In-Memory-Cloud-Dienst verkaufen?
Die BSL begrenzt die Angebotsform: Managed-Anbieter, die einen Redis-kompatiblen Store als eigenes Produkt verkaufen wollen, brauchen einen anderen Vertrag. Die interne Nutzung bleibt davon getrennt und fällt unter Selbst-Hosting.
Lesetipps der Redaktion
cloudmagazinAWS nimmt keine neuen 1U-Outposts-Kunden ancloudmagazinKubernetes bindet GPU-Jobs erst, wenn alle Pods passencloudmagazinKarmada mit höchstem CNCF-Siegel: Bloomberg fährt mitMehr aus dem MBF Media Netzwerk
MyBusinessFutureDestatis meldet 12.812 Insolvenzen, Höchststand seit 2013Digital ChiefsSAP knüpft KI-Agenten an Cloud-Wechsel und S/4HANASecurityTodayN-central bleibt ohne Patch aus der Ferne übernehmbarQuelle Titelbild: Pressefoto / Dragonfly
