Was ist Redis?
Redis ist ein Datenspeicher im Arbeitsspeicher. Die Daten liegen im RAM statt auf der Platte, weshalb Antworten deutlich unter einer Millisekunde kommen und sehr hohe Operationsraten möglich sind. Genutzt wird es als Cache, als Sessionspeicher, als Message Queue und als Speicher für Auswertungen in Echtzeit, und es hält mehr als blosse Strings: Listen, Sets, sortierte Sets, Hashes, Streams und HyperLogLog.
Das Denkmodell, das am weitesten trägt: es ist keine kleinere relationale Datenbank. Es ist eine Sammlung von Datenstrukturen, die sich über das Netz zwischen Prozessen teilen lassen, und sein Nutzen entsteht daraus, für das Problem die richtige zu wählen.
Worin es wirklich gut ist
Caching. Der ursprüngliche Einsatz, und weiterhin der, der sich am schnellsten rechnet. Ein Ergebnis, das deine Anwendung teuer berechnet hat, lohnt sich aufzuheben, bis es veraltet.
Sessionzustand. Web-Sessions wollen schnelle Lesezugriffe, ein Ablaufdatum und einen Speicher, den sich mehrere Instanzen der Anwendung teilen. Genau das bietet Redis.
Rate Limiting und Zähler. Atomare Inkremente mit Ablauf sind wenige Zeilen und bleiben unter Nebenläufigkeit korrekt, was in einer relationalen Datenbank schwieriger ist, als es aussieht.
Queues und Streams. Listen ergeben eine einfache Arbeitsqueue, Streams bringen Consumer Groups und Bestätigungen und kommen damit einem Message Broker nahe. Sobald die Queue tragend wird, ist RabbitMQ dafür gebaut.
Ranglisten und Ranking. Sortierte Sets machen genau das, und es in SQL zu tun ist ein schlechter Tausch.
Was es nicht ist
Es ist nicht dauerhaft in dem Sinn, in dem eine Datenbank es ist. Es gibt Optionen zur Persistenz, und sie sind ein Sicherheitsnetz und keine Garantie. Daten, deren Verlust du nicht verkraften könntest, gehören in etwas, das zum Aufbewahren gebaut wurde, etwa PostgreSQL.
Es ist kein Primärspeicher für relationale Daten. Keine Joins, kein Schema, keine Constraints. Ein relationales Problem darin zu modellieren ist möglich und unerfreulich.
Der Arbeitsspeicher ist das Budget. Der Datenbestand liegt im RAM, die Kapazität kostet also pro Gigabyte Arbeitsspeicher statt pro Gigabyte Platte. Alles zu cachen ist ein verbreiteter und teurer Reflex.
Wenn du nur einen Cache willst, sieh dir zuerst Memcached an
Redis wird oft allein fürs Caching eingeführt, und für diese Aufgabe gibt es einen kleineren Mitbewerber, den man kennen sollte. Memcached beschreibt sich selbst als verteiltes System zum Zwischenspeichern von Objekten im Arbeitsspeicher: ein Key-Value-Store für kleine Datenstücke beliebiger Art, gedacht, um dynamische Webanwendungen zu beschleunigen, indem Last von der Datenbank genommen wird. Sein eigenes Argument ist, dass der einfache Aufbau das Feature ist.
Das ist der Tausch in einem Satz. Memcached macht eine Sache, Redis macht diese Sache plus die Datenstrukturen, die Optionen zur Persistenz, Streams und Replikation von oben.
Die Frage lautet also, ob du den Rest nutzen wirst. Wenn die Antwort tatsächlich lautet "wir wollen Datenbankergebnisse cachen und sonst nichts", ist Memcached weniger zu lernen und weniger zu betreiben. Wenn sortierte Sets, Rate Limiting, Session-Semantik oder eine Queue irgendwo auf der Roadmap stehen, erspart der Griff zu Redis jetzt den Betrieb von zwei Dingen später.
Die Lizenzfrage, und das ist die eigentliche Neuigkeit
Diesen Teil brauchen Lernende am meisten und finden ihn am seltensten, deshalb hier klar gesagt.
Redis stand den grössten Teil seines Lebens unter BSD. Redis Ltd. hat das geändert. Redis Open Source wird ab Redis 8 unter einer Wahl aus drei Lizenzen angeboten: der Redis Source Available License v2, der Server Side Public License v1 oder der GNU Affero General Public License v3. Die Lizenzseite von Redis hält selbst fest, dass RSALv2 keine quelloffene Lizenz ist, AGPLv3 hingegen schon.
Als Antwort auf die frühere Änderung wurde Valkey von Redis abgezweigt und unter das Dach der Linux Foundation gestellt. Es steht unter BSD, und das Projekt sagt klar, dass genau diese Trägerschaft es dabei hält. Es sind dieselben Datenstrukturen und dasselbe Protokoll.
Was das praktisch bedeutet:
- Wenn du heute wählst, wählst du zwischen einem Projekt, dessen Lizenz sein eigener Anbieter einmal geändert hat, und einem Fork unter einer Stiftung, dessen Lizenz der Grund für seine Existenz ist.
- Wenn du Redis bereits betreibst, ist nichts kaputtgegangen. Ältere Versionen behalten ihre alte Lizenz, und deine Anwendung merkt nichts davon.
- Wenn bei euch eine Compliance-Stelle Lizenzen prüft, wird dieses Gespräch stattfinden, und es läuft vor dem Rollout besser als danach.
Wir haben kein Interesse daran, dir eine Richtung vorzugeben. Wir haben ein Interesse daran, dass du weisst, dass die Frage existiert, denn erstaunlich viele Teams greifen zu einem der beiden, ohne zu bemerken, dass hier überhaupt eine Entscheidung ansteht.
Was der produktive Betrieb verlangt
- Speichergrenze und Eviction Policy. Setze beides. Eine Redis-Instanz ohne Eviction Policy, die ihre Grenze erreicht, weist Schreibzugriffe ab, und das während einer Lastspitze zu lernen ist der übliche Weg.
- Bewusst gewählte Persistenz. Snapshots und Append-only-Logging wiegen Schreibkosten gegen möglichen Verlust unterschiedlich ab. Der Standardwert ist auch dann eine Entscheidung, wenn niemand sie getroffen hat.
- Failover. Eine einzelne Instanz ist ein einzelner Ausfallpunkt für jeden Dienst, der darin cached. Replikation mit automatischer Übernahme ist das Minimum für alles, was Nutzende sehen.
- Die richtigen Zahlen überwachen. Belegter Speicher gegen die Grenze, Eviction-Rate und Trefferquote des Caches. Ein Cache mit niedriger Trefferquote kostet Geld und liefert nichts.
- Es vom öffentlichen Internet fernhalten. Es ist auch deshalb schnell, weil es einfach ist, und seine Standardwerte setzen ein vertrauenswürdiges Netz voraus.
Wo VSHN ins Bild kommt
VSHN betreibt Redis auf Schweizer Cloud-Infrastruktur ab CHF 60 pro Monat, mit einem SLA von bis zu 99,99 Prozent, mit Backups, Monitoring und Incident Response rund um die Uhr, auf Cloudscale, Exoscale und weiteren Anbietern. Servala nimmt Bestellungen in Selbstbedienung entgegen, wenn du lieber ohne Gespräch startest.
Wenn die Lizenzfrage oben bei euch aktuell ist, lohnt es sich, sie im ersten Gespräch anzusprechen und nicht im letzten. Denn sie ändert, was wir ausrollen, und nicht, wie wir es betreiben.