Wie Key-Value-Datenbanken (z. B. Redis, Memcached) funktionieren
Ihre Frontend-App fühlt sich schnell an. Benutzer klicken, Daten erscheinen, Seiten laden sofort. Hinter dieser Erfahrung steckt oft eine Key-Value-Datenbank, die die Hauptarbeit leistet – sie fängt Anfragen ab, bevor sie überhaupt Ihre Hauptdatenbank erreichen. Das Verständnis der Funktionsweise dieser Systeme hilft Ihnen, intelligentere Entscheidungen über Caching, Sessions und Backend-Architektur zu treffen.
Die wichtigsten Erkenntnisse
- Key-Value-Datenbanken speichern und rufen Daten mithilfe eines eindeutigen Schlüssels ab, der mit einem Wert gepaart ist, und tauschen Abfrageflexibilität gegen außergewöhnliche Geschwindigkeit ein.
- In-Memory-Speicherung (RAM) ermöglicht Lookups mit konstanter Zeitkomplexität über Hash-Tabellen, oft 100–1000x schneller als festplattenbasierte Lesevorgänge.
- Redis bietet umfangreiche Datenstrukturen, optional Persistenz und integriertes Clustering, während Memcached als einfacher, multi-threaded, zweckgebundener Cache glänzt.
- Typische Anwendungsfälle umfassen Session-Management, API-Response-Caching und Rate Limiting – alles Szenarien, in denen niedrige Latenz am wichtigsten ist.
- Key-Value-Stores ergänzen relationale Datenbanken, anstatt sie zu ersetzen. Verwenden Sie sie als Performance-Schicht, nicht als primären Datenspeicher.
Was ist eine Key-Value-Datenbank?
Eine Key-Value-Datenbank ist eine Art NoSQL-Datenspeicher, der Daten mithilfe einer einfachen zweiteiligen Struktur speichert und abruft: ein eindeutiger Schlüssel (Key) und sein zugehöriger Wert (Value).
Stellen Sie es sich wie ein JavaScript-Objekt oder eine Hash-Map vor:
"session:user:4821" → { userId: 4821, role: "admin", expires: 1720000000 }
"product:sku:9001" → { name: "Wireless Keyboard", price: 49.99 }Sie suchen Daten nach Schlüssel. Das war’s. Es gibt keine Abfragesprache, keine JOINs, kein Schema. Diese Einschränkung ist genau das, was Key-Value-Stores so schnell macht.
Wie In-Memory-Speicherung Lookups beschleunigt
Die meisten Key-Value-Datenbanken – einschließlich Redis und Memcached – speichern Daten im RAM, nicht auf der Festplatte. Festplatten-Lesevorgänge werden in Millisekunden gemessen. Speicher-Lesevorgänge erfolgen in Mikrosekunden, oft 100–1000x schneller.
Intern verwenden diese Systeme eine Hash-Tabelle: Der Schlüssel wird zu einer Speicheradresse gehasht, und der Wert wird direkt abgerufen. Es gibt kein Scannen, keine Indizierung, keine Abfrageplanung. Die Lookup-Zeit ist effektiv O(1) – konstant, unabhängig von der Datensatzgröße.
Deshalb sind Key-Value-Stores die Standardwahl für Caching-Schichten, Session-Speicherung und jeden Backend-Service, bei dem die Antwortzeit die Benutzererfahrung direkt beeinflusst.
Grundlegende Operationen: SET, GET und Ablauf
Die grundlegenden Operationen sind bewusst minimal gehalten:
- SET
key value— einen Wert speichern - GET
key— einen Wert abrufen - DEL
key— einen Wert entfernen - EXPIRE
key seconds— automatisches Löschen nach einer Time-to-Live (TTL)
TTL ist besonders nützlich für Caching. Sie speichern eine API-Antwort oder ein gerendertes HTML-Fragment mit einem 60-Sekunden-Ablauf. Ihre App liest zuerst aus dem Cache. Wenn der Schlüssel fehlt oder abgelaufen ist, greift sie auf die Datenbank zurück und füllt den Cache neu. Dieses Muster – Cache-Aside – ist eines der häufigsten Muster in der Webarchitektur.
Discover how at OpenReplay.com.
Redis vs. Memcached: Wichtige architektonische Unterschiede
Beide sind In-Memory-Key-Value-Stores. Beide liefern Sub-Millisekunden-Performance. Aber sie treffen unterschiedliche Kompromisse.
| Merkmal | Redis | Memcached |
|---|---|---|
| Datentypen | Strings, Listen, Sets, Hashes, Sorted Sets, Streams und mehr | Nur Strings |
| Wertgrößenlimit | Bis zu 512 MB | Bis zu 1 MB |
| Persistenz | Optional (RDB-Snapshots oder Append-Only-File) | Keine – rein flüchtig |
| Multi-Threading | Single-threaded Event-Loop (I/O-Threading ab 6.0+ hinzugefügt) | Vollständig multi-threaded |
| Speicherrückgewinnung | Gibt freigegebenen Speicher an das Betriebssystem zurück | Hält zugewiesenen Speicher über Slab-Allocator bis zum Neustart |
| Integriertes Clustering | Ja (Redis Cluster, Sentinel) | Erfordert clientseitiges Sharding |
Memcached ist ein zweckgebundener Cache. Er ist einfach, schnell und vorhersehbar. Sein Slab-basierter Speicher-Allocator hält die Fragmentierung niedrig und macht die Speichernutzung sehr konsistent – nützlich, wenn Sie eine harte Speicherobergrenze benötigen. Er ist eine gute Wahl, wenn Sie einfache Strings cachen und nichts weiter wollen.
Redis ist ein umfassenderer In-Memory-Datenstrukturspeicher. Über das Caching hinaus unterstützt er Sorted Sets für Bestenlisten, Pub/Sub-Messaging, atomare Zähler und optionale Persistenz. Modernes Redis wird als Cache, Session-Store, Message-Broker und leichtgewichtige Datenbank verwendet – manchmal alles gleichzeitig. Erwähnenswert: Die Redis-Lizenzierung änderte sich ab 2024, was einige Teams dazu veranlasste, Valkey zu evaluieren, einen kompatiblen Open-Source-Fork, der von der Linux Foundation unter einer permissiven Lizenz gepflegt wird.
Wo Key-Value-Datenbanken in Frontend-orientierten Systemen eingesetzt werden
Aus Sicht eines Frontend-Entwicklers taucht Key-Value-Speicherung typischerweise an drei Stellen auf:
- Session-Management — serverseitige Speicherung von Auth-Tokens, Benutzerstatus und Präferenzen
- API-Response-Caching — Reduzierung der Datenbanklast und Beschleunigung wiederholter Anfragen
- Rate Limiting — Verfolgung von Anfragezählern pro Benutzer oder IP mithilfe atomarer Inkrement-Operationen
Jeder dieser Bereiche profitiert direkt von dem, was Key-Value-Datenbanken am besten können: schnelle Lesevorgänge, schnelle Schreibvorgänge und einfache Ablauflogik.
Wann Sie keinen Key-Value-Store verwenden sollten
Key-Value-Datenbanken sind kein Ersatz für relationale Datenbanken. Sie haben echte Einschränkungen:
- Die meisten Abfragen sind schlüsselbasiert, mit eingeschränkter Unterstützung für Filterung oder Sortierung im Vergleich zu relationalen Datenbanken.
- Keine integrierten Beziehungen zwischen Datensätzen
- Nicht geeignet für komplexe Berichte oder Analysen
- Datenmodellierung erfordert sorgfältiges Key-Design im Voraus
Wenn Ihre Daten Beziehungen haben oder flexible Abfragen benötigen, greifen Sie stattdessen zu PostgreSQL oder einer Dokumentendatenbank. Verwenden Sie Key-Value-Speicherung als Performance-Schicht zusätzlich zu Ihrem primären Datenspeicher, nicht als Ersatz dafür.
Fazit
Key-Value-Datenbanken funktionieren, weil sie Komplexität gegen Geschwindigkeit eintauschen. Sie tun eine Sache – Werte nach Schlüssel speichern und abrufen, hauptsächlich im Speicher – und sie tun es außergewöhnlich gut. Ob Sie Redis wegen seiner Flexibilität oder Memcached wegen seiner Einfachheit wählen, das Verständnis des zugrunde liegenden Modells hilft Ihnen, diese Tools dort einzusetzen, wo sie tatsächlich hingehören: als schnelle, fokussierte Schicht, die Ihre Anwendungen reaktionsschnell hält.
Häufig gestellte Fragen (FAQs)
Redis unterstützt zwei optionale Persistenzmechanismen: RDB-Snapshots, die den Datensatz in konfigurierten Intervallen speichern, und das Append-Only-File (AOF), das jede Schreiboperation protokolliert. Sie können entweder einen oder beide verwenden. Ohne aktivierte Persistenz gehen Daten beim Neustart verloren, genau wie bei Memcached. Für reines Caching ist Persistenz oft unnötig.
Memcached ist eine gute Wahl, wenn Sie einen unkomplizierten, multi-threaded Cache für einfache String-Werte benötigen und eine vorhersehbare Speichernutzung mit minimaler Konfiguration wünschen. Wenn Sie keine umfangreichen Datenstrukturen, Persistenz oder integriertes Clustering benötigen, machen Memcacheds Einfachheit und effizienter Slab-basierter Speicher-Allocator es zu einer zuverlässigen, leichtgewichtigen Option.
Sowohl Redis als auch Memcached verwenden Eviction-Policies (Verdrängungsrichtlinien), um Speicherlimits zu handhaben. Memcached verwendet standardmäßig LRU-Eviction (Least Recently Used). Redis bietet mehrere konfigurierbare Richtlinien, einschließlich LRU, LFU (Least Frequently Used), zufällige Verdrängung und No-Eviction-Modus, der bei vollem Speicher Fehler bei Schreibvorgängen zurückgibt.
Redis kann für spezifische Anwendungsfälle wie Session-Management, Zähler oder Echtzeit-Bestenlisten als primärer Datenspeicher fungieren, insbesondere mit aktivierter Persistenz. Es fehlen jedoch relationale Abfragen, erzwungene Schemas und ausgereifte Transaktionsunterstützung. Für die meisten Anwendungen funktioniert es am besten als ergänzende Performance-Schicht neben einer relationalen oder Dokumentendatenbank.
Gain control over your UX
See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.
