Redis: Key-Value-Store

Redis ist die zweite NoSQL-Datenbank, die für die IHK-Prüfung relevant ist – und in der Praxis möglicherweise sogar wichtiger als MongoDB. Der Name steht für „REmote DIctionary Server". Wenn MongoDB die Dokument-orientierte NoSQL-DB ist, ist Redis der König der Key-Value-Stores: ein In-Memory-Datenspeicher mit Sub-Millisekunden-Latenz.

Charakteristisch: Redis hält Daten primär im RAM, nicht auf der Platte. Das macht es extrem schnell – Operationen liegen oft im Bereich von 50 Mikrosekunden – aber kostet auch: Daten passen nur in den verfügbaren Arbeitsspeicher, und ohne Persistenz-Konfiguration sind sie bei einem Neustart weg. Genau diese Eigenschaften machen Redis zum idealen Werkzeug für Cache, Sessions, Counter, Queues, Leaderboards – die Use Cases sind Thema von Lektion 8.

1) Die Grundidee: Key → Value

Das Konzept ist simpel: zu einem Key (String) wird ein Value gespeichert. Das kennst du als HashMap aus Java oder als Dictionary aus Python – Redis ist im Prinzip eine solche Datenstruktur, nur persistent gemacht und übers Netzwerk erreichbar.

Konvention für Schlüssel-Namen: Doppelpunkt-getrennte „Pfade" wie user:1001:profile oder cache:product:42. Das ist keine Sprach-Regel, sondern eine Konvention die KEYS-Filter und das Organisieren erleichtert. Redis selbst kümmert sich nicht darum, was im Schlüsselnamen steht.

2) Mehr als nur Strings: die Datentypen

Was Redis von simpleren Key-Value-Stores wie Memcached unterscheidet: der Value kann verschiedene Datentypen haben. Nicht nur Strings, sondern auch Listen, Hashes, Sets und mehr. Jeder Typ hat eigene Operationen. Klick eine Karte für Details:

3) Beispiele für jeden Typ

Die Befehle für die wichtigsten Datentypen, mit Beispiel-Ausgaben:

4) TTL – Auto-Ablauf von Schlüsseln

Ein Killer-Feature von Redis: jeder Schlüssel kann eine Time-To-Live (TTL) bekommen – nach Ablauf wird er automatisch gelöscht. Genau das ist die Grundlage für Caches, Sessions und Rate-Limiting. Du musst nicht manuell aufräumen.

5) Atomare Operationen – ohne Race Conditions

Ein wichtiger Vorteil von Redis: viele Operationen sind atomar. INCR counter erhöht den Wert um eins, ohne dass Race Conditions möglich sind – auch wenn 1000 Klienten parallel inkrementieren. Im Gegensatz zu „lese, addiere, schreibe" auf Anwendungsseite, das das klassische Lost-Update-Problem hat.

Auch für komplexere Operationen gibt es Lösungen: MULTI / EXEC für „Mini-Transaktionen" mit mehreren Befehlen als Block, WATCH für optimistic locking, EVAL für Lua-Skripte die atomar ausgeführt werden. Diese atomare Garantie ist einer der Gründe warum Redis für Counter und Rate-Limiting so beliebt ist.

6) Persistenz: was passiert beim Neustart?

Wenn Redis im Default-Modus läuft, sind alle Daten beim Neustart weg – das ist eine In-Memory-DB. Für viele Use Cases (Cache, Session) ist das okay – die Daten lassen sich neu generieren oder die User loggen sich halt nochmal ein. Für andere Use Cases (Counter, Queue) wäre das katastrophal. Redis bietet deshalb zwei Persistenz-Modi:

7) Sandbox-Konsole

Probier die wichtigsten Redis-Befehle aus – simulierte Konsole:

8) Redis vs. SQL-Cache

Manche fragen: warum nicht einfach Daten in der relationalen DB cachen? Drei harte Gründe sprechen für Redis:

• Geschwindigkeit: Redis liegt bei 50-100 µs pro Operation, SQL-DBs bei 1-10 ms – ein Faktor 100. Bei Cache-Lookups vor jeder Anfrage merkt man das spürbar.
• Skalierbarkeit: Redis hält den ganzen Datensatz im RAM und vermeidet Disk-I/O. Eine moderne Redis-Instanz schafft Hunderttausende Operationen pro Sekunde – pro Knoten.
• Spezialisierte Strukturen: Sorted Sets für Leaderboards, Sets für Mengenoperationen, Pub/Sub für Messaging. Solche Operationen sind in SQL teuer oder unmöglich.

Trade-off: Daten sind im RAM, also begrenzt durch den verfügbaren Speicher (typisch 16 GB bis ein paar hundert GB pro Knoten). Wer Petabytes speichern muss, kann das mit Redis nicht – dafür sind Wide-Column-Stores wie Cassandra da.

Zusammenfassung

Redis (REmote DIctionary Server) ist ein In-Memory-Key-Value-Store mit Sub-Millisekunden-Latenz. Die Schlüssel sind Strings, die Werte können verschiedene Datentypen haben: String (mit atomarem INCR), List (Queues, Stacks), Hash (Objekte), Set (eindeutige Mengen), Sorted Set (mit Score, ideal für Rankings), Stream (Log-artig). TTL ermöglicht automatischen Ablauf von Schlüsseln – Grundlage für Cache, Session, Rate-Limiting. Atomare Operationen wie INCR vermeiden Race Conditions. Persistenz: RDB (Snapshots) und AOF (Append-Only File) lassen Daten Neustarts überleben. In Produktion oft beide kombiniert. Gegenüber SQL-Caches: ca. Faktor 100 schneller, mit spezialisierten Datenstrukturen für Use Cases wie Leaderboards oder Mengenoperationen. Trade-off: RAM-Limit – typisch 16 GB bis hunderte GB pro Knoten. Konkrete Use-Cases (Cache, Session, Pub/Sub, Rate-Limiting) folgen in Lektion 8.