NoSQL Überblick

NoSQL-Datenbanken sind anders als SQL-Datenbanken. Sie verzichten auf feste Tabellen und Schemas und bieten dafür mehr Flexibilität. In diesem Artikel lernst du die verschiedenen Arten von NoSQL-Datenbanken kennen und erfährst, wann sie eingesetzt werden.

Note

Diese Artikelserie konzentriert sich auf SQL-Datenbanken. Dieser Artikel gibt dir nur einen kurzen Überblick über NoSQL, damit du den Unterschied verstehst.

Die vier Haupttypen von NoSQL

Anders als SQL gibt es bei NoSQL nicht nur ein Konzept. NoSQL-Datenbanken lassen sich in vier Hauptkategorien einteilen, die jeweils unterschiedlich funktionieren:

Dokumenten-Datenbanken
Key-Value-Datenbanken
Spaltenorientierte Datenbanken
Graphen-Datenbanken

Schauen wir uns jede Kategorie genauer an.

1. Dokumenten-Datenbanken

Dokumenten-Datenbanken speichern Daten als JSON-ähnliche Dokumente. Jedes Dokument kann unterschiedliche Felder haben.

Wie funktioniert es?

Ein Dokument sieht aus wie ein JSON-Objekt:

JSON

{
  "_id": "12345",
  "name": "Anna Müller",
  "email": "anna@beispiel.de",
  "adresse": {
    "strasse": "Hauptstraße 1",
    "stadt": "Berlin",
    "plz": "10115"
  },
  "bestellungen": [
    {
      "produktID": "A1",
      "menge": 2,
      "datum": "2024-01-15"
    },
    {
      "produktID": "B3",
      "menge": 1,
      "datum": "2024-02-03"
    }
  ]
}

Du kannst verschachtelte Strukturen erstellen. Adresse und Bestellungen sind direkt im Dokument eingebettet. In SQL würdest du dafür drei separate Tabellen brauchen.

Bekannte Systeme

MongoDB: Die beliebteste Dokumenten-Datenbank
CouchDB: Mit eingebautem HTTP-API
Amazon DocumentDB: MongoDB-kompatibel in AWS

Vorteile

Sehr flexibel - Struktur kann jederzeit ändern
Natürliche Darstellung von Objekten (wie in JavaScript, Python)
Keine JOINs nötig - alles in einem Dokument
Schnell bei Lese-Operationen ganzer Dokumente

Nachteile

Daten-Duplikation (gleiche Daten an mehreren Stellen)
Komplexe Abfragen über mehrere Dokumente schwieriger
Keine garantierte Konsistenz über mehrere Dokumente

Typische Einsatzgebiete

Content Management Systeme
Produktkataloge mit variablen Eigenschaften
Benutzerverwaltung und Profile
Blogs und Social Media
Mobile Apps

2. Key-Value-Datenbanken

Key-Value-Datenbanken sind die einfachste Form von NoSQL. Sie funktionieren wie ein riesiges Dictionary oder eine HashMap: Zu jedem Schlüssel (Key) gibt es einen Wert (Value).

Wie funktioniert es?

Text

Key: "user:12345:name"
Value: "Anna Müller"

Key: "user:12345:email"
Value: "anna@beispiel.de"

Key: "session:abc123"
Value: "{\"userID\": 12345, \"loginTime\": \"2024-01-15\"}"

Die Datenbank speichert nur Paare aus Schlüssel und Wert. Es gibt keine Tabellen, keine Spalten, keine Struktur. Der Wert kann ein einfacher String sein oder ein komplexes JSON-Objekt.

Bekannte Systeme

Redis: Sehr schnell, oft für Caching
Memcached: Einfaches Caching-System
Amazon DynamoDB: Managed Service in AWS
Riak: Für verteilte Systeme

Vorteile

Extrem schnell - oft nur Millisekunden
Sehr einfaches Konzept
Hervorragend skalierbar
Perfekt für Caching

Nachteile

Keine Abfragen möglich - nur direkter Zugriff über Key
Keine Beziehungen zwischen Daten
Keine Suche nach Werten

Typische Einsatzgebiete

Caching (Zwischenspeicher für oft benötigte Daten)
Session-Verwaltung
Warteschlangen (Message Queues)
Temporäre Daten
Zähler und Statistiken

Tip

Key-Value-Datenbanken werden oft zusätzlich zu SQL-Datenbanken eingesetzt. Redis vor MySQL kann die Performance dramatisch verbessern.

3. Spaltenorientierte Datenbanken

Spaltenorientierte Datenbanken (Column-Family Stores) speichern Daten nicht zeilen-, sondern spaltenweise. Das klingt klein, macht aber einen großen Unterschied.

Der Unterschied zu SQL

SQL (Zeilenorientiert): Speichert Datensätze komplett zusammen

Text

Zeile 1: [1, "Anna", "anna@beispiel.de", "Berlin"]
Zeile 2: [2, "Tom", "tom@beispiel.de", "Hamburg"]

Spaltenorientiert: Speichert alle Werte einer Spalte zusammen

Text

Spalte ID: [1, 2]
Spalte Name: ["Anna", "Tom"]
Spalte Email: ["anna@beispiel.de", "tom@beispiel.de"]
Spalte Stadt: ["Berlin", "Hamburg"]

Bekannte Systeme

Apache Cassandra: Für massive Datenmengen
HBase: Auf Hadoop basierend
ScyllaDB: Schnellere Cassandra-Alternative

Vorteile

Extrem schnell bei Aggregationen (Summen, Durchschnitte)
Sehr gut komprimierbar (gleichartige Daten)
Perfekt für analytische Abfragen
Kann mit Petabytes an Daten umgehen

Nachteile

Langsam beim Schreiben einzelner Datensätze
Updates sind teuer
Komplex in der Verwaltung

Typische Einsatzgebiete

Big Data Analysen
Data Warehouses
Zeitreihen-Daten (Logs, Sensordaten)
Finanzmarktdaten
IoT-Anwendungen mit Millionen Geräten

4. Graphen-Datenbanken

Graphen-Datenbanken speichern Daten als Knoten (Nodes) und Beziehungen (Edges). Sie sind perfekt für stark vernetzte Daten.

Wie funktioniert es?

Stell dir ein soziales Netzwerk vor:

Knoten: Personen (Anna, Tom, Lisa)
Kanten: Beziehungen ("ist befreundet mit", "folgt", "hat geliked")

Text

(Anna) -[IST_BEFREUNDET_MIT]-> (Tom)
(Tom) -[IST_BEFREUNDET_MIT]-> (Lisa)
(Anna) -[FOLGT]-> (Lisa)
(Lisa) -[HAT_GEPOSTET]-> (Beitrag123)

Die Datenbank speichert nicht nur Daten, sondern auch wie sie miteinander verbunden sind.

Bekannte Systeme

Neo4j: Die bekannteste Graphen-Datenbank
Amazon Neptune: Managed Service in AWS
ArangoDB: Multi-Model (Graph + Document)

Vorteile

Perfekt für vernetzte Daten
Beziehungen sind "First-Class Citizens"
Komplexe Beziehungs-Abfragen sehr schnell
Natürliche Darstellung von Netzwerken

Nachteile

Schwer zu skalieren
Komplexer zu verstehen
Spezielle Abfragesprache (z.B. Cypher)

Typische Einsatzgebiete

Soziale Netzwerke (Freunde, Follower)
Empfehlungssysteme ("Kunden, die X kauften, kauften auch Y")
Wissensgrafen (wie Google Knowledge Graph)
Betrugs-Erkennung (verdächtige Netzwerke)
Netzwerk- und IT-Management

Vergleichstabelle NoSQL-Typen

Typ	Datenmodell	Beispiel	Beste für
Dokumenten-DB	JSON-ähnliche Dokumente	MongoDB	Flexible Datenstrukturen, CMS
Key-Value-DB	Schlüssel → Wert	Redis	Caching, Sessions, schneller Zugriff
Spaltenorientiert	Spalten-Familien	Cassandra	Big Data, Analysen, Zeitreihen
Graphen-DB	Knoten + Beziehungen	Neo4j	Vernetzte Daten, soziale Netzwerke

SQL vs. NoSQL: Noch einmal zusammengefasst

Nach diesem Überblick über beide Welten noch einmal die wichtigsten Unterschiede:

Aspekt	SQL	NoSQL
Struktur	Tabellen mit festen Spalten	Flexibel (Dokumente, Key-Value, etc.)
Schema	Muss vorher definiert werden	Dynamisch, kann ändern
Beziehungen	Stark (JOINs)	Schwach oder eingebettet
Skalierung	Vertikal (größerer Server)	Horizontal (mehr Server)
Konsistenz	ACID (streng)	Eventual Consistency (lockerer)
Abfragesprache	SQL (standardisiert)	System-spezifisch
Am besten für	Strukturierte, verknüpfte Daten	Flexible, große, verteilte Daten

Wann NoSQL, wann SQL?

Eine letzte Entscheidungshilfe:

Wähle SQL wenn:

Deine Daten klar strukturiert sind
Du viele Verknüpfungen brauchst
Datenkonsistenz kritisch ist (Banking, Buchungen)
Du komplexe Abfragen mit Filtern und Aggregationen hast
Dein Team SQL bereits kennt

Wähle NoSQL wenn:

Deine Datenstruktur sich häufig ändert
Du massive Datenmengen hast (Big Data)
Du horizontal skalieren musst
Geschwindigkeit wichtiger ist als Konsistenz
Deine Daten natürlich dokumentenbasiert sind (z.B. CMS-Artikel)

Important

Die meisten Anwendungen nutzen SQL. NoSQL ist für spezielle Anforderungen. Im Zweifelsfall: Starte mit SQL und wechsle nur, wenn du konkrete Gründe dafür hast.

Zusammenfassung

NoSQL-Datenbanken bieten Alternativen zu SQL für spezielle Anforderungen:

Dokumenten-DBs (MongoDB): Flexible JSON-ähnliche Dokumente
Key-Value-DBs (Redis): Einfachste Form, perfekt für Caching
Spaltenorientiert (Cassandra): Für Big Data und Analysen
Graphen-DBs (Neo4j): Für stark vernetzte Daten

Jeder Typ hat eigene Stärken für bestimmte Anwendungsfälle. SQL bleibt jedoch für die meisten Standard-Anwendungen die beste Wahl.

Ab dem nächsten Artikel konzentrieren wir uns vollständig auf SQL und MySQL. Du lernst Schritt für Schritt, wie du Datenbanken entwirfst, Tabellen erstellst und Daten abfragst.