Zum Inhalt springen

Key-Value-Stores

Ein Key-Value-Store ist der Datenbanktyp, den die Konsole als Key-value store aufführt, mit dem Hinweis „Works with Redis clients.“ Anwendungen verbinden sich mit den Redis-Client-Bibliotheken und -Befehlen, die sie bereits verwenden. Externe Key-Value-Verbindungen funktionieren genauso und können auf Redis, Valkey oder einen anderen Server zeigen, der das Redis-Protokoll spricht.

Übersicht eines Key-Value-Stores mit Größe, Arbeitsspeicher, CPU, Latenz, Clients und Operationen pro SekundeÜbersicht eines Key-Value-Stores mit Größe, Arbeitsspeicher, CPU, Latenz, Clients und Operationen pro Sekunde

Neue verwaltete Key-Value-Stores laufen mit Valkey 9.1.2 mit den Modulen JSON, Bloom und Search. Sie werden wie jede verwaltete Datenbank erstellt, in der Größe angepasst, pausiert, veröffentlicht, an Workloads gebunden und gesichert. Das Erstellen erfordert Personal oder höher.

Jedes Binding erhält einen eigenen ACL-Benutzer. Er kann gewöhnliche Daten-, Verbindungs-, Transaktions- und Pub/Sub-Befehle ausführen sowie Skripte laden und ausführen; er kann weder ACLs verwalten noch Skripte leeren oder beenden noch Funktionen verwalten.

Der Explorer durchsucht Schlüssel, zeigt Werte und setzt, löscht und befristet Schlüssel, wenn Sie dazu berechtigt sind; die Konsole führt Redis-Befehle aus.

Ein Key-Value-Store kann in Business und Enterprise auch auf mehreren Servern laufen. Seine Kopien folgen dem Primary immer asynchron.

Vor 2.12 erstellte Stores laufen weiter mit Redis. Sie funktionieren wie bisher; nichts ändert sich, bis Sie sie umziehen.

Move to Valkey auf der Seite des Stores kopiert jeden Schlüssel in Valkey auf demselben Node und stellt den Store darauf um:

  1. Der Dialog prüft zuerst den Store und zeigt die Anzahl der Schlüssel und die erwartete Schreibpause.
  2. Bestätigen Sie. Schreibvorgänge pausieren, während die Schlüssel kopiert werden; Lesevorgänge funktionieren weiter.
  3. Wenn die Schlüsselzahlen übereinstimmen, wechselt der Store zu Valkey. Er behält seine Zugangsdaten, seinen veröffentlichten Port und seine Bindings; verbundene Clients verbinden sich neu.

Die Redis-Daten bleiben auf dem Node, bis die Zahlen übereinstimmen. Schlägt etwas fehl, kehrt der Store zu Redis zurück.

Der Umzug wird abgelehnt, bevor sich etwas ändert, wenn:

  • der Store nicht läuft;
  • sein Node einen Docker-Daemon ausführt, der Valkey nicht unterstützt; aktualisieren Sie zuerst den Daemon;
  • er Schlüssel enthält, die nicht kopiert werden können: Bloom- oder Cuckoo-Filter, Zeitreihen, Vektormengen oder Suchindizes;
  • seine App-Umgebung isoliert ist.

Stream-Consumer-Groups werden mit ihrer zuletzt zugestellten ID umgezogen, aber nicht mit ihren ausstehenden Einträgen. Hat ein Store ausstehende Einträge, nennt der Dialog deren Anzahl, und der Umzug erfordert eine ausdrückliche Bestätigung.

API: GET (Prüfung) und POST /api/databases/managed/{id}/move-to-valkey, mit acceptPendingStreamLoss: true, um den Verlust ausstehender Stream-Einträge zu akzeptieren. MCP: manage_managed_database mit den Aktionen move_to_valkey_check und move_to_valkey. Scope: databases:edit.

Ein Key-Value-Backup lässt sich nur in die Engine wiederherstellen, aus der es erstellt wurde: ein Redis-Backup in einen Store, der Redis ausführt, oder in einen neuen Store, ein Valkey-Backup in einen Store, der Valkey ausführt, oder in einen neuen Store. Erstellen Sie nach Move to Valkey ein neues Backup, damit Ihr neuestes Backup zur Engine passt. Siehe Datenbank-Backups.

Backups lesen den Store über die Replikation, daher benötigt der Benutzer einer externen Key-Value-Verbindung die Replikationsbefehle (REPLCONF, SYNC). Das Speichern einer Backup-Richtlinie und jeder Lauf prüfen dies.