NoSQL-Typen: Dokument, Key-Value, Column, Graph
„NoSQL" ist kein einzelner Typ Datenbank, sondern eine Sammelbezeichnung für sehr unterschiedliche Systeme. Wer alle NoSQL-DBs in einen Topf wirft, missversteht die Idee. Tatsächlich gibt es vier große Familien, die sich darin unterscheiden, wie sie Daten organisieren: Key-Value, Dokument, Spalten-orientiert (Wide-Column) und Graph. Jede Familie löst andere Probleme und hat andere Stärken.
Diese Lektion gibt dir einen Überblick über alle vier Typen, ihre Anwendungsfälle und die wichtigsten Vertreter. In den späteren Lektionen vertiefen wir dann MongoDB (Dokument) und Redis (Key-Value) als die zwei in der IHK-Prüfung relevantesten Vertreter.
1) Die vier Familien im Überblick
Klick eine Familie an, um Konzept, Beispiel-Daten und typische Vertreter zu sehen. Die Reihenfolge geht von „einfachstes Datenmodell" zu „komplexestes":
2) Direkter Vergleich
Die vier Familien nebeneinander, mit den zentralen Unterschieden auf einen Blick:
| Familie | Datenstruktur | Typische Anwendung | Beispiele |
|---|---|---|---|
| Key-Value | Schlüssel → Wert (oft binär) | Cache, Session-Store, Counter | Redis, Memcached, DynamoDB |
| Dokument | JSON/BSON-Dokumente in Collections | Kataloge, CMS, User-Profile | MongoDB, CouchDB, Firestore |
| Wide Column | Spalten in Familien gruppiert, Sparse Tables | Time-Series, sehr große Tabellen | Cassandra, HBase, BigTable |
| Graph | Knoten + Kanten mit Properties | Soziale Netze, Empfehlungen, Routen | Neo4j, Amazon Neptune, ArangoDB |
3) Detail: Key-Value-Stores
Das einfachste Datenmodell überhaupt: zu einem Schlüssel wird ein Wert gespeichert. Wie ein Wörterbuch oder eine HashMap in Programmiersprachen – nur persistent und netzwerkfähig. Lookups erfolgen mit GET key, Schreibvorgänge mit SET key value. Mehr braucht es nicht.
Diese Einfachheit ist die Stärke: Key-Value-Stores sind extrem schnell, oft mit Sub-Millisekunden-Latenz, weil keine komplexe Verarbeitung nötig ist. Der Wert kann ein einfacher String sein oder eine komplexe Struktur (Liste, Hash, Set) – je nach DB. Klassischer Vertreter: Redis (Lektion 7).
4) Detail: Dokument-Datenbanken
Hier werden Daten als Dokumente gespeichert – meist im JSON-Format (oder einer binären Variante wie BSON). Ein Dokument ist eine Sammlung von Feldern mit Werten, kann verschachtelt sein, Arrays enthalten und unterschiedliche Felder pro Eintrag haben. Dokumente werden in Collections gruppiert – das Äquivalent zu SQL-Tabellen, aber ohne erzwungenes Schema.
Der große Vorteil: das natürliche Daten-Format von Web-APIs ist JSON. Dokument-DBs speichern dieses Format ohne Übersetzung. Wenn deine Anwendung mit JSON-Objekten arbeitet, sparst du dir das Objekt-relationale Mapping (ORM), das in SQL-Welten oft Tortur ist. Klassischer Vertreter: MongoDB (Lektion 4).
5) Detail: Wide-Column-Stores
Die wohl missverständlichste Familie – „spaltenorientiert" klingt nach Excel-Tabellen, ist aber etwas grundlegend anderes als SQL-Tabellen. Wide-Column-DBs speichern Daten in Spaltenfamilien: jede Zeile kann andere Spalten haben, sehr viele (Millionen) sind möglich, und nur tatsächlich vorhandene Werte werden gespeichert (sparse). Das Modell stammt aus Googles BigTable-Paper von 2006.
Stärke: Schreiben von Massendaten und Lesen vereinzelter Spalten ist extrem effizient. Das macht diesen Typ ideal für Time-Series-Daten (Sensorwerte, Logs, Metriken), wo man oft Milliarden Datenpunkte pro Tag schreibt und meist nur einzelne Spalten ausliest. Cassandra und HBase sind die bekanntesten Vertreter. Für die IHK-Prüfung reicht ein konzeptionelles Verständnis – die Detail-Konfiguration ist Senior-Niveau.
6) Detail: Graph-Datenbanken
Hier werden Daten als Graph modelliert: Daten sind Knoten (Nodes), und Beziehungen sind Kanten (Edges) zwischen ihnen. Beide können Eigenschaften (Properties) tragen. Die Stärke liegt darin, Beziehungen schnell zu traversieren – „Wer sind Freunde meiner Freunde, die in Berlin wohnen?" wird in SQL zur JOIN-Hölle, in Neo4j zu einer einfachen Pfad-Abfrage.
Anwendungen: soziale Netze, Empfehlungssysteme („Kunden die X kauften, kauften auch Y"), Betrugserkennung (Geld-Flüsse zwischen Konten), Wissensgraphen, Logistik (Routenoptimierung). Wo immer die Beziehungen zwischen Daten wichtiger sind als die Daten selbst, ist eine Graph-DB die richtige Wahl. Klassische Vertreter: Neo4j (Marktführer), Amazon Neptune.
7) Welche Familie passt zu welchem Problem?
Sechs typische Szenarien – welche NoSQL-Familie wäre die beste Wahl? Klick deine Antwort:
8) Multi-Modell-Datenbanken
Eine moderne Tendenz: Multi-Modell-Datenbanken, die mehrere der oben genannten Paradigmen in einem System kombinieren. Beispiele:
- ArangoDB – Dokument + Graph + Key-Value in einer Engine.
- OrientDB – Multi-Modell mit Schwerpunkt Graph + Dokument.
- PostgreSQL – eigentlich relational, kann aber via
JSONB-Spalte Dokument-DB spielen. Auch via hstore Key-Value. - Cosmos DB (Azure) – kombiniert mehrere APIs in einem Service.
Das ist verlockend – „eine DB für alles!" – kommt aber mit dem Trade-off, dass keiner der Modi so optimiert ist wie der jeweils spezialisierte Champion. Für kleinere Projekte sehr praktisch, für Massendaten greift man eher zu spezialisierten Lösungen.
Zusammenfassung
NoSQL gliedert sich in vier Hauptfamilien: Key-Value (Schlüssel→Wert, ultra-schnell, ideal für Cache und Session – z.B. Redis), Dokument (JSON-Dokumente in Collections, flexibles Schema, ideal für CMS und Web-APIs – z.B. MongoDB), Wide Column (spaltenorientiert mit Spaltenfamilien, ideal für Time-Series und Massendaten – z.B. Cassandra), Graph (Knoten + Kanten, ideal für Beziehungen und Empfehlungen – z.B. Neo4j). Diese Familien sind keine starren Schubladen – moderne Multi-Modell-DBs kombinieren mehrere. Für die IHK relevant sind primär Dokument und Key-Value (MongoDB, Redis). Wahl-Faustregel: nach Datenform und dominanten Operationen entscheiden. Wenn die Daten relational sind und ACID nötig ist: bleib bei SQL. Sonst die NoSQL-Familie wählen, die zur Datenform passt – mehr dazu in Lektion 9.