Arbeiten mit NoSQL-Datenbanken
Bisher haben wir gelernt, wie relationale Datenbanken funktionieren – also Systeme,
die Daten in Tabellen mit festen Spalten speichern (z. B. MySQL, PostgreSQL).
Doch in modernen Anwendungen, z. B. bei großen Webplattformen, sozialen Netzwerken oder IoT-Systemen,
stoßen relationale Modelle oft an ihre Grenzen.
Beispiele:
extrem große, verteilte Datenmengen
stark unterschiedliche Datenstrukturen (z. B. Posts, Likes, Kommentare)
flexible, sich schnell ändernde Formate
Hier kommen NoSQL-Datenbanken ins Spiel.
1. Was bedeutet „NoSQL“?
„NoSQL“ steht ursprünglich für „Not only SQL“ – also nicht nur SQL.
Es bedeutet: Diese Systeme funktionieren ohne klassische Tabellenstrukturen
und ohne starres Schema.
NoSQL-Datenbanken speichern Daten in anderen Formen – z. B.:
| Typ | Struktur | Beispiele |
|---|---|---|
| Dokumentbasiert | JSON-ähnliche Objekte | MongoDB, CouchDB |
| Schlüssel-Wert | Key-Value-Paare | Redis, DynamoDB |
| Spaltenbasiert | Große Spaltenfamilien | Cassandra, HBase |
| Graphbasiert | Knoten und Kanten | Neo4j |
2. Dokumentbasierte Datenbanken (z. B. MongoDB)
Das ist der häufigste Typ von NoSQL-Systemen.
Statt Tabellen gibt es Sammlungen (Collections), und jede Sammlung enthält Dokumente – ähnlich wie JSON-Objekte.
Beispiel:
{
"kundennr": 1001,
"name": "Anna Beispiel",
"ort": "Berlin",
"bestellungen": [
{ "produkt": "T-Shirt", "preis": 19.99 },
{ "produkt": "Hoodie", "preis": 39.99 }
]
}
Hier sind alle Informationen zu einem Kunden in einem Dokument gespeichert –
nicht verteilt auf mehrere Tabellen wie in SQL.
Vorteil: Sehr einfach zu lesen und flexibel.
Ein Kunde kann z. B. beliebig viele Bestellungen haben, ohne dass das Schema geändert werden muss.
3. Vergleich: SQL vs. NoSQL
| Aspekt | Relational (SQL) | Dokumentbasiert (NoSQL) |
|---|---|---|
| Struktur | Tabellen mit festen Spalten | Flexible Dokumente (z. B. JSON) |
| Beziehungen | Fremdschlüssel, JOINs | Eingebettete Daten |
| Skalierung | Vertikal (größerer Server) | Horizontal (mehr Server) |
| Schema | Vorher definiert | Schema-frei |
| Abfragen | SQL-Befehle (SELECT, JOIN) | JSON-ähnliche Syntax |
| Beispiel | SELECT * FROM kunden WHERE ort='Berlin'; | { ort: "Berlin" } |
4. Abfragen in NoSQL (Beispiel: MongoDB)
// Alle Kunden anzeigen
db.kunden.find();
// Kunden aus Berlin
db.kunden.find({ ort: "Berlin" });
// Nur Name und Ort anzeigen
db.kunden.find({}, { name: 1, ort: 1 });
// Einen neuen Kunden hinzufügen
db.kunden.insertOne({
kundennr: 1003,
name: "Lisa Schulz",
ort: "Köln"
});
// Ort aktualisieren
db.kunden.updateOne(
{ kundennr: 1001 },
{ $set: { ort: "München" } }
);
// Kunde löschen
db.kunden.deleteOne({ kundennr: 1002 });
Die Syntax ist objektorientiert – jede Abfrage sieht aus wie ein kleines JavaScript-Objekt.
5. Schemafreiheit – Fluch oder Segen?
Vorteil:
Du kannst Dokumente mit völlig unterschiedlichen Feldern speichern.
Nachteil:
Wenn du keine Regeln vorgibst, kann schnell Chaos entstehen:
Einige Dokumente enthalten z. B. „ort“, andere „city“.
In der Praxis wird Schemafreiheit oft durch Validierungen oder Frameworks begrenzt.
6. Schlüssel-Wert-Datenbanken
Einfachster NoSQL-Typ.
Daten bestehen nur aus einem Schlüssel (Key) und einem Wert (Value) – ähnlich wie ein Wörterbuch.
Beispiel (Redis):
| Key | Value |
|---|---|
user:1001 | { "name": "Anna", "ort": "Berlin" } |
user:1002 | { "name": "Max", "ort": "Hamburg" } |
SET user:1001 "{name:'Anna', ort:'Berlin'}"
GET user:1001
Sehr schnell, aber keine komplexen Beziehungen möglich.
7. Graphdatenbanken
Hier werden Daten als Knoten (Nodes) und Beziehungen (Edges) gespeichert –
ideal für Netzwerke, z. B. soziale Medien oder Empfehlungs-Systeme.
Beispiel (Neo4j-Syntax):
CREATE (a:Person {name:'Anna'})
CREATE (b:Person {name:'Max'})
CREATE (a)-[:FREUNDE_MIT]->(b);
Damit entsteht ein Graph, in dem Anna mit Max befreundet ist.
Solche Systeme können Beziehungen extrem schnell berechnen.
8. Wann nutze ich NoSQL?
| Anwendungsfall | Empfehlung |
|---|---|
| Hochdynamische Datenstrukturen (z. B. JSON-APIs) | Dokumentbasiert |
| Schnelle Zwischenspeicherung / Caching | Key-Value (z. B. Redis) |
| Soziale Netzwerke, Empfehlungslogik | Graphdatenbank |
| Big Data / Zeitreihenanalyse | Spaltenorientiert (z. B. Cassandra) |
| Stark strukturierte Unternehmensdaten | Relational (SQL) bleibt sinnvoll |
Merksatz:
SQL ist präzise und sicher –
NoSQL ist flexibel und skalierbar.
SQL vs. NoSQL – gleiche Daten, andere Struktur
Beide speichern dieselben Informationen – aber völlig unterschiedlich: links relational mit Tabellen, rechts dokumentbasiert in JSON-Struktur.
Relational (SQL)
Tabelle: kunden
---------------
kundennr | name | ort
1001 | Anna Beispiel | Berlin
Tabelle: bestellungen
---------------------
bestellnr | kundennr | produkt | preis
5001 | 1001 | T-Shirt | 19,99 €
5002 | 1001 | Hoodie | 39,99 €
Dokumentbasiert (NoSQL)
{
"kundennr": 1001,
"name": "Anna Beispiel",
"ort": "Berlin",
"bestellungen": [
{ "produkt": "T-Shirt", "preis": 19.99 },
{ "produkt": "Hoodie", "preis": 39.99 }
]
}