NoSQL-Datenbanken

KAPITEL 06 · DATENBANKEN

NoSQL-Datenbanken

Die moderne Alternative zu relationalen Datenbanken – flexibel, skalierbar und perfekt für unstrukturierte Daten. Lernen Sie die vier NoSQL-Typen, das CAP-Theorem und populäre Datenbanken wie MongoDB, Cassandra, Redis und Neo4j kennen.

Document Stores Key-Value Column-Family Graph DB

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über NoSQL-Datenbanken:

  • Definition: Was ist NoSQL und warum wurde es entwickelt?
  • SQL vs. NoSQL: Der direkte Vergleich
  • Die 4 NoSQL-Typen: Document, Key-Value, Column-Family, Graph
  • CAP-Theorem: Die Grenzen verteilter Systeme
  • ACID vs. BASE: Transaktionsmodelle im Vergleich
  • Populäre Datenbanken: MongoDB, Cassandra, Redis, Neo4j
  • Use Cases: Wann NoSQL die bessere Wahl ist
  • FAQ: Häufige Fragen zu NoSQL

1. Was ist NoSQL?

Definition

NoSQL (auch "Not Only SQL") ist ein Oberbegriff für nicht-relationale Datenbanksysteme, die im Gegensatz zu SQL-Datenbanken kein festes Schema verwenden und Daten in anderen Formaten als Tabellen speichern. NoSQL-Datenbanken wurden entwickelt, um die Herausforderungen moderner Anwendungen zu bewältigen: Big Data, hohe Skalierbarkeit, flexible Datenstrukturen und verteilte Systeme.

Der Begriff "Not Only SQL" betont, dass NoSQL-Datenbanken SQL nicht vollständig ersetzen, sondern ergänzen. Viele Unternehmen nutzen heute eine Kombination aus SQL- und NoSQL-Datenbanken (Polyglot Persistence), je nach Anwendungsfall.

Die vier Haupttypen von NoSQL-Datenbanken: Document Stores (MongoDB), Key-Value Stores (Redis), Column-Family Stores (Cassandra) und Graph-Datenbanken (Neo4j).

Warum NoSQL?

Traditionelle SQL-Datenbanken stoßen bei modernen Anwendungen an Grenzen:

  • Horizontale Skalierung: SQL-DBs skalieren vertikal (stärkere Hardware), NoSQL horizontal (mehr Server)
  • Flexible Schemata: Datenstrukturen ändern sich häufig – NoSQL passt sich an
  • Hohe Schreiblast: Social Media, IoT, Logging – NoSQL ist dafür optimiert
  • Unstrukturierte Daten: JSON, Bilder, Videos – NoSQL kann sie nativ speichern
  • Cloud-Native: NoSQL ist für verteilte Cloud-Umgebungen designed

2. SQL vs. NoSQL – Der Vergleich

Beide Datenbanktypen haben ihre Daseinsberechtigung – die Wahl hängt vom Anwendungsfall ab.

SQL (Relational)

Strukturiert, konsistent, bewährt
  • Tabellen mit Zeilen und Spalten
  • Festes Schema (Schema-on-Write)
  • ACID-Transaktionen (Atomar, Konsistent, Isoliert, Dauerhaft)
  • SQL-Abfragesprache (standardisiert)
  • Joins zwischen Tabellen
  • Vertikale Skalierung (stärkere Hardware)
  • Ideal für: Finanzdaten, ERP, CRM
VS

NoSQL (Nicht-relational)

Flexibel, skalierbar, modern
  • Verschiedene Modelle (Document, Key-Value, etc.)
  • Dynamisches Schema (Schema-on-Read)
  • BASE-Eigenschaften (Basically Available, Soft State, Eventually Consistent)
  • Eigene Abfragesprachen (MQL, CQL, etc.)
  • Denormalisierte Daten (weniger Joins)
  • Horizontale Skalierung (mehr Server)
  • Ideal für: Big Data, IoT, Social Media

Faustregel: Wann welche Datenbank?

  • SQL wählen bei: Strukturierten Daten, komplexen Joins, ACID-Anforderungen, Finanzdaten, kleinen bis mittleren Datenmengen
  • NoSQL wählen bei: Unstrukturierten Daten, hoher Skalierbarkeit, flexiblen Schemata, Big Data, Cloud-Umgebungen, Echtzeit-Anwendungen
  • Beide kombinieren (Polyglot Persistence): SQL für Transaktionen, NoSQL für Caching, Suche oder Graphen

3. Die 4 NoSQL-Typen

NoSQL-Datenbanken werden in vier Hauptkategorien unterteilt – jede mit spezifischen Stärken.

Document Store

JSON/BSON-Dokumente

Speichert Daten als Dokumente (meist JSON oder BSON). Jedes Dokument kann eine andere Struktur haben – extrem flexibel.

  • Schema-los, flexibel
  • Verschachtelte Strukturen möglich
  • Indizes auf Dokumentenfelder
  • Aggregation-Pipelines
{ "name": "Max Mustermann", "age": 30, "address": { "city": "Berlin", "zip": "10115" }, "hobbies": ["lesen", "wandern"] }
Beispiele: MongoDB, CouchDB, Amazon DocumentDB

Key-Value Store

Einfach & extrem schnell

Speichert Daten als einfache Schlüssel-Wert-Paare. Das einfachste NoSQL-Modell – dafür extrem schnell und skalierbar.

  • O(1) Zugriffszeit
  • In-Memory oder persistent
  • Ideal für Caching
  • Session-Storage
"session:abc123" → { "user": "max", "expires": 1699999999 } "cart:user42" → ["item1", "item2"]
Beispiele: Redis, Memcached, Amazon DynamoDB, etcd

Column-Family Store

Für massive Datenmengen

Speichert Daten in Spaltenfamilien statt Zeilen. Optimiert für Schreiboperationen und große Datenmengen über viele Server.

  • Hohe Schreibgeschwindigkeit
  • Horizontale Skalierung
  • Time-Series-Daten
  • Eventual Consistency
Row Key: "user42" ├── Column Family "profile" │ ├── name: "Max" │ └── age: 30 └── Column Family "orders" ├── order1: {item: "Laptop"} └── order2: {item: "Maus"}
Beispiele: Apache Cassandra, HBase, Google Bigtable

Graph Database

Beziehungen im Fokus

Speichert Daten als Knoten (Nodes) und Kanten (Edges). Ideal für stark vernetzte Daten wie soziale Netzwerke oder Empfehlungssysteme.

  • Schnelle Traversierung
  • Beziehungsorientiert
  • Empfehlungssysteme
  • Betrugserkennung
(Max) -[:FOLLOWS]→ (Anna) (Max) -[:LIVES_IN]→ (Berlin) (Anna) -[:WORKS_AT]→ (Firma X) (Firma X) -[:LOCATED_IN]→ (München)
Beispiele: Neo4j, Amazon Neptune, JanusGraph

4. Das CAP-Theorem

CAP-Theorem (auch Brewer-Theorem) beschreibt die fundamentalen Grenzen verteilter Datenbanksysteme. In einem verteilten System können maximal zwei der drei Eigenschaften gleichzeitig vollständig gewährleistet werden. Da Partition Tolerance in verteilten Systemen unverzichtbar ist, muss man sich zwischen Consistency und Availability entscheiden.

Die drei Eigenschaften

C
Consistency
A
Availability
P
Partition Tolerance
Consistency (Konsistenz)

Jede Leseoperation erhält den neuesten Schreibwert oder einen Fehler. Alle Knoten sehen dieselben Daten zur selben Zeit.

Availability (Verfügbarkeit)

Jede Anfrage erhält eine Antwort (kein Timeout), auch wenn einige Knoten ausgefallen sind. Das System ist immer erreichbar.

Partition Tolerance

Das System funktioniert trotz Netzwerk-Partitionen weiter – also wenn Knoten die Kommunikation untereinander verlieren.

CP (Konsistenz + Partition)

Bei Netzwerkproblemen werden Anfragen abgelehnt, um Konsistenz zu wahren.
z.B. MongoDB, HBase, ZooKeeper

AP (Verfügbarkeit + Partition)

Bei Netzwerkproblemen werden evtl. veraltete Daten geliefert, aber das System bleibt erreichbar.
z.B. Cassandra, CouchDB, DynamoDB

CA (Konsistenz + Verfügbarkeit)

Nur in nicht-verteilten Systemen möglich (Single Node). In der Praxis nicht realisierbar.
z.B. Einzelne RDBMS-Instanz

BASE vs. ACID

  • ACID (SQL): Atomicity, Consistency, Isolation, Durability – starke Garantien für Transaktionen
  • BASE (NoSQL): Basically Available, Soft State, Eventual Consistency – das System wird irgendwann konsistent
  • Eventual Consistency: Nach einer Schreiboperation können verschiedene Knoten kurzzeitig unterschiedliche Daten haben – sie gleichen sich aber automatisch ab

5. ACID vs. BASE – Transaktionsmodelle

Die beiden grundlegenden Modelle für Transaktionen in Datenbanksystemen.

ACID

Strong Consistency (SQL)
  • A
    Atomicity: Transaktionen sind atomar – entweder ganz oder gar nicht
  • C
    Consistency: Datenbank ist vor und nach der Transaktion konsistent
  • I
    Isolation: Gleichzeitige Transaktionen beeinflussen sich nicht
  • D
    Durability: Nach Commit sind Daten dauerhaft gespeichert

BASE

Eventual Consistency (NoSQL)
  • B
    Basically Available: Das System ist immer verfügbar (auch bei Fehlern)
  • A
    Soft State: Der Zustand kann sich ohne Eingabe ändern (durch Replikation)
  • E
    Eventually Consistent: Irgendwann sind alle Knoten konsistent – aber nicht sofort

Wann welches Modell?

  • ACID (SQL): Finanztransaktionen, Buchungssysteme, Bestellungen – wo jeder Fehler teuer ist
  • BASE (NoSQL): Social Media, IoT-Daten, Caching, Session-Storage – wo Verfügbarkeit wichtiger ist als sofortige Konsistenz
  • Hybrid: Moderne NoSQL-DBs wie MongoDB bieten mittlerweile auch ACID-Transaktionen (seit Version 4.0)

6. Entscheidungshilfe – Welche NoSQL-DB?

Die Wahl der richtigen Datenbank hängt von deinem Use Case ab. Folgende Fragen helfen bei der Entscheidung:

Schritt-für-Schritt-Entscheidung

1
Brauchst du einfache Key-Lookups mit extrem niedriger Latenz?
Caching, Sessions, Rate Limiting
Redis
2
Hast du flexible, verschachtelte Daten (JSON)?
CMS, Produktkataloge, Benutzerprofile
MongoDB
3
Musst du Milliarden von Events/Zeitreihen schreiben?
IoT, Logging, Sensordaten, Messaging
Cassandra
4
Geht es um Beziehungen und Netzwerke?
Social Graph, Betrugserkennung, Empfehlungssysteme
Neo4j
5
Brauchst du Volltextsuche und Log-Analyse?
Suchmaschine, ELK-Stack, Monitoring
Elasticsearch
6
Brauchst du ACID-Transaktionen und strenge Konsistenz?
Finanzen, Buchhaltung, Bestellungen
SQL (PostgreSQL)

Typische Einsatzszenarien

E-Commerce

Produktkataloge mit variablen Attributen (Farbe, Größe, Material). Flexible Schemata für verschiedene Produkttypen.

Empfehlung: MongoDB (Katalog) + Redis (Warenkorb/Cache)

Social Network

Freundschaften, Follower, Likes, Kommentare. Komplexe Beziehungsabfragen ("Freunde von Freunden").

Empfehlung: Neo4j (Graph) + Redis (Feeds/Cache)

IoT & Sensordaten

Millionen von Sensoren, die sekündlich Daten liefern. Massive Schreiblast, Zeitreihen-Abfragen.

Empfehlung: Cassandra (Daten) + Redis (aktuelle Werte)

Gaming

Leaderboards, Spieler-Profile, Matchmaking, Inventare. Echtzeit-Anforderungen.

Empfehlung: Redis (Leaderboards/Sessions) + MongoDB (Profile)

Suchmaschine

Volltextsuche mit Ranking, Filterung, Facetten. Log-Analyse und Monitoring.

Empfehlung: Elasticsearch (Suche) + MongoDB (Datenquelle)

Betrugserkennung

Transaktions-Netzwerke analysieren, verdächtige Muster erkennen, Verbindungen zwischen Konten aufdecken.

Empfehlung: Neo4j (Graph-Analyse) + Cassandra (Transaktions-Log)

7. Populäre NoSQL-Datenbanken

Die wichtigsten NoSQL-Datenbanken im Überblick – mit Stärken und typischen Einsatzgebieten.

Document Store

MongoDB

Die populärste NoSQL-Datenbank. Speichert Daten als BSON-Dokumente (Binary JSON). Sehr flexibel und einfach zu bedienen.

  • JSON/BSON-Dokumente
  • Flexible Schemata
  • Replica Sets für HA
  • Sharding für Skalierung
  • Aggregation Framework
  • ACID ab Version 4.0
Typische Einsatzgebiete: Content-Management, User-Profile, Produktkataloge, Mobile Apps, IoT
Column-Family Store

Apache Cassandra

Entwickelt von Facebook für massive Datenmengen. Masterless-Architektur – kein Single Point of Failure. Ideal für zeitbasierte Daten.

  • Masterless Design
  • Lineare Skalierung
  • Hohe Schreibgeschwindigkeit
  • Tunable Consistency
  • Time-Series optimiert
  • CQL (Cassandra Query Language)
Typische Einsatzgebiete: Zeitreihendaten, Logging, IoT-Sensoren, Activity-Feeds, große Schreiblasten
Key-Value Store

Redis

In-Memory Key-Value Store – extrem schnell (µs-Bereich). Unterstützt komplexe Datentypen wie Listen, Sets, Sorted Sets und Hashes.

  • In-Memory (mit Persistenz)
  • Sub-Millisekunde Latenz
  • Reichhaltige Datentypen
  • Pub/Sub Messaging
  • Lua-Scripting
  • Redis Sentinel (HA)
Typische Einsatzgebiete: Caching, Session-Storage, Leaderboards, Echtzeit-Analytics, Message Queues
Graph Database

Neo4j

Die führende Graph-Datenbank. Speichert Daten als Knoten und Beziehungen. Cypher-Abfragesprache ist intuitiv und mächtig.

  • Native Graph-Storage
  • Cypher Query Language
  • ACID-Transaktionen
  • Index-Free Adjacency
  • Visualisierung integriert
  • Clustering (Enterprise)
Typische Einsatzgebiete: Soziale Netzwerke, Empfehlungssysteme, Betrugserkennung, Wissensgraphen, Netzwerk-Analyse
Key-Value / Document

Amazon DynamoDB

Managed NoSQL-Datenbank von AWS. Vollständig serverless, automatische Skalierung. Perfekt für AWS-Cloud-Umgebungen.

  • Vollständig managed
  • Automatische Skalierung
  • Single-digit ms Latenz
  • Global Tables (Multi-Region)
  • On-Demand oder Provisioned
  • DAX (In-Memory Cache)
Typische Einsatzgebiete: AWS-Apps, Mobile Backends, Gaming, IoT, Serverless-Architekturen
Search Engine / Document

Elasticsearch

Verteilte Such- und Analyse-Engine auf Basis von Lucene. Ideal für Volltextsuche, Log-Analyse und Echtzeit-Suche.

  • Volltextsuche
  • RESTful API
  • Near-Realtime Search
  • Kibana (Visualisierung)
  • ELK-Stack (Elastic, Logstash, Kibana)
  • Aggregationen
Typische Einsatzgebiete: Website-Suche, Log-Analyse, SIEM, Monitoring, Produktsuche

8. NoSQL Use Cases

Typische Anwendungsfälle, bei denen NoSQL-Datenbanken ihre Stärken ausspielen.

Produktkataloge

Produkte haben unterschiedliche Attribute (Größe, Farbe, Material). Document Stores wie MongoDB sind perfekt für flexible Produktstrukturen.

Empfohlen: MongoDB

Session-Storage & Caching

Web-Sessions und häufig genutzte Daten müssen extrem schnell abrufbar sein. Key-Value Stores sind ideal.

Empfohlen: Redis, Memcached

Zeitreihendaten & Analytics

IoT-Sensoren, Logs, Metriken – riesige Datenmengen mit Zeitstempel. Column-Family Stores skalieren hier hervorragend.

Empfohlen: Cassandra, InfluxDB

IoT & Sensor-Daten

Millionen von Geräten senden kontinuierlich Daten. NoSQL kann diese Schreiblast bewältigen und horizontal skalieren.

Empfohlen: Cassandra, MongoDB

Volltextsuche

Produktsuche, Dokumentensuche, Log-Analyse – Suchmaschinen wie Elasticsearch sind darauf spezialisiert.

Empfohlen: Elasticsearch

9. FAQ – Häufige Fragen & Antworten

Häufige Fragen zu NoSQL-Datenbanken

Ersetzt NoSQL traditionelle SQL-Datenbanken?

Nein, NoSQL ersetzt SQL nicht – es ergänzt es. Beide Datenbanktypen haben ihre Daseinsberechtigung:

  • SQL ist ideal für strukturierte Daten, komplexe Joins und ACID-Transaktionen (z.B. Finanzdaten)
  • NoSQL ist ideal für unstrukturierte Daten, hohe Skalierbarkeit und flexible Schemata (z.B. Social Media)

Viele Unternehmen nutzen heute Polyglot Persistence – eine Kombination aus SQL und NoSQL, je nach Anwendungsfall.

Was bedeutet "Eventual Consistency"?

Eventual Consistency bedeutet, dass alle Knoten eines verteilten Systems irgendwann die gleichen Daten sehen – aber nicht sofort.

Wenn Sie einen Datensatz schreiben, kann es einige Millisekunden bis Sekunden dauern, bis alle Replikate aktualisiert sind. In dieser Zeit können Leseoperationen veraltete Daten zurückgeben.

Beispiel: Sie posten auf Facebook. Ihr Freund sieht den Post eventuell erst nach 1-2 Sekunden. Das ist für Social Media akzeptabel – für Banküberweisungen nicht.

Was ist der Unterschied zwischen horizontaler und vertikaler Skalierung?

Vertikale Skalierung (Scale-Up): Sie machen einen einzelnen Server stärker (mehr CPU, RAM, SSD). Einfach, aber teuer und hat physikalische Grenzen.

Horizontale Skalierung (Scale-Out): Sie fügen weitere Server hinzu und verteilen die Last. Günstiger, theoretisch unbegrenzt, aber komplexer.

NoSQL-Datenbanken sind für horizontale Skalierung designed (Sharding, Replica Sets). SQL-Datenbanken skalieren primär vertikal.

Kann ich Joins in NoSQL-Datenbanken verwenden?

Jein. Die meisten NoSQL-Datenbanken unterstützen keine klassischen Joins wie SQL, aber es gibt Alternativen:

  • Denormalisierung: Daten werden redundant gespeichert (z.B. Bestelldetails direkt im User-Dokument)
  • Application-side Joins: Die Anwendung führt mehrere Queries durch und kombiniert die Ergebnisse
  • $lookup (MongoDB): MongoDB bietet eine Art Join in Aggregation-Pipelines
  • Graph-Traversierung (Neo4j): In Graph-DBs sind "Joins" über Beziehungen sehr effizient

Wenn Sie viele Joins benötigen, ist SQL wahrscheinlich die bessere Wahl.

Welche NoSQL-Datenbank sollte ich für mein Projekt wählen?

Die Wahl hängt von Ihrem Anwendungsfall ab:

  • Flexible Dokumente (JSON): MongoDB – ideal für Content, User-Profile, Kataloge
  • Extrem schnelles Caching: Redis – ideal für Sessions, Leaderboards, Echtzeit-Daten
  • Massive Schreiblast / Zeitreihen: Cassandra – ideal für IoT, Logs, Analytics
  • Beziehungen & Netzwerke: Neo4j – ideal für Social Networks, Empfehlungen, Betrugserkennung
  • Volltextsuche: Elasticsearch – ideal für Suchmaschinen, Log-Analyse
  • AWS-Cloud: DynamoDB – ideal für serverless Apps auf AWS
Sind NoSQL-Datenbanken sicher?

Ja, aber Sicherheit muss aktiv konfiguriert werden. NoSQL-Datenbanken bieten:

  • Authentifizierung: Benutzer/Passwort, LDAP, Kerberos
  • Autorisierung: Rollenbasierte Zugriffskontrolle (RBAC)
  • Verschlüsselung: TLS für Datenübertragung, Encryption-at-Rest
  • Auditing: Protokollierung aller Zugriffe

Wichtig: Viele NoSQL-DBs sind standardmäßig ohne Authentifizierung installiert – das muss aktiviert werden! Bekannte Sicherheitsvorfälle (z.B. offene MongoDB-Instanzen) waren meist auf Fehlkonfiguration zurückzuführen.

Was ist Sharding?

Sharding ist die horizontale Aufteilung einer Datenbank auf mehrere Server (Shards). Jeder Shard enthält einen Teil der Daten.

Beispiel: Eine User-Datenbank mit 1 Milliarde Usern wird auf 100 Server verteilt. Jeder Server speichert ~10 Millionen User.

Sharding-Strategien:

  • Range-based: User A-M auf Shard 1, N-Z auf Shard 2
  • Hash-based: Hash(User-ID) % Anzahl-Shards
  • Directory-based: Lookup-Table weist User Shards zu

Sharding ermöglicht theoretisch unbegrenzte Skalierung, macht Queries aber komplexer (Cross-Shard-Queries sind teuer).

Unterstützen NoSQL-Datenbanken Transaktionen?

Ja, aber mit Einschränkungen. Traditionell waren NoSQL-DBs auf Einzel-Dokument-Transaktionen beschränkt. Moderne Datenbanken bieten jedoch mehr:

  • MongoDB (ab 4.0): Multi-Dokument ACID-Transaktionen
  • Cassandra: Lightweight Transactions (LWT) mit Paxos
  • Redis: Transaktionen mit MULTI/EXEC (aber keine Rollbacks)
  • Neo4j: Vollständige ACID-Transaktionen

Wenn Sie komplexe, verteilte Transaktionen benötigen (z.B. Banküberweisungen), ist SQL oft noch die bessere Wahl.

Zusammenfassung

Die wichtigsten Punkte

  • NoSQL = "Not Only SQL" – nicht-relationale Datenbanken für flexible, skalierbare Anwendungen
  • 4 Haupttypen: Document (MongoDB), Key-Value (Redis), Column-Family (Cassandra), Graph (Neo4j)
  • CAP-Theorem: Nur 2 von 3 Eigenschaften (Consistency, Availability, Partition Tolerance) gleichzeitig möglich
  • ACID vs. BASE: SQL setzt auf starke Konsistenz, NoSQL auf Verfügbarkeit und Eventual Consistency
  • Horizontale Skalierung: NoSQL skaliert durch mehr Server, SQL durch stärkere Hardware
  • Use Cases: Big Data, IoT, Caching, Social Networks, Echtzeit-Anwendungen
  • Polyglot Persistence: SQL und NoSQL kombinieren – je nach Anwendungsfall

Enterprise-Tipps

  • Nicht blind NoSQL einsetzen: SQL ist für viele Anwendungsfälle immer noch die bessere Wahl
  • Datenmodell sorgfältig planen: NoSQL-Datenmodelle sind anwendungsspezifisch – spätere Änderungen sind teuer
  • Monitoring einrichten: NoSQL-Cluster benötigen sorgfältige Überwachung (Lag, Replikation, Sharding)
  • Security aktivieren: Authentifizierung und Verschlüsselung sind oft nicht standardmäßig aktiviert
  • Backup-Strategie: Auch NoSQL-Datenbanken brauchen regelmäßige Backups

Weiterführende Themen

SQL-Datenbanken

MySQL, PostgreSQL, MS SQL Server – die klassischen relationalen Datenbanken.

Zu SQL-Datenbanken
Datenbank-Grundlagen

Was sind Datenbanken? Normalisierung, Entity-Relationship-Modelle und mehr.

Zu Datenbank-Grundlagen
SQL-Befehle

SELECT, INSERT, UPDATE, DELETE – die wichtigsten SQL-Commands im Überblick.

Zu SQL-Befehlen
Datenbank-Optimierung

Indexing, Query-Optimierung, Caching – Performance-Tuning für Datenbanken.

Zur Optimierung