SQL & NoSQL
SQL- und NoSQL-Systeme bieten unterschiedliche Datenmodelle und Zusagen. Die Auswahl folgt Zugriffen, Konsistenzbedarf und Betriebsbedingungen.
- ZugriffsmusterWie gelesen und geschrieben wird.
- DatenmodellWie ein Speicher Daten ordnet.
- NormalfallRelational zuerst, NoSQL mit Grund.
Einordnung
Warum das wichtig ist
Das Speichermodell folgt dem Zugriff, nicht der Gewohnheit. Relational ist der Normalfall: Tabellen, Beziehungen und Transaktionen decken viele Anforderungen ab. NoSQL, gelesen als „Not only SQL“, braucht einen belegten Grund, etwa einen Zugriff, den das relationale Modell schlecht bedient. Das Kombinieren mehrerer Speicher ist Polyglot Persistence.
Dieser Baustein erklärt die Wahl eines Speichermodells. Für den bewussten Einsatz mehrerer Modelle siehe Polyglot Persistence.
Auf einen Blick · Zugriff bestimmt das Datenmodell
Welches Datenmodell passt zu diesem Zugriff?
Bestellungen benötigen atomare Status- und Positionsänderungen. Die Produktsuche braucht flexible Volltextabfragen über Beschreibungen und Kategorien.
So liest du das Bild
- Zugriffsmuster Die vier Zugriffe, zwischen denen du oben wählst.
- Datenmodell Die fünf Karten, jeweils mit passt gut, geht oder passt schlecht.
- Normalfall Bei der Bestellung passt nur das relationale Modell gut.
RelationalTabellen, Beziehungen, Transaktionen
passt gut · beste Wahl
Transaktionen ändern Bestellung und Positionen gemeinsam oder gar nicht.
DokumentVerschachtelte Dokumente, flexible Struktur
geht
Die Bestellung passt als ein Dokument; Querbezüge zu anderen Daten sind schwerer.
Schlüssel-WertZugriff direkt über einen Schlüssel
passt schlecht
Der Wert ist undurchsichtig; Positionen einzeln prüfen oder ändern ist umständlich.
SpaltenorientiertSpaltenweise Ablage für Auswertungen
passt schlecht
Ausgelegt auf große Lesevorgänge, nicht auf viele kleine Änderungen.
GraphKnoten und Beziehungen im Mittelpunkt
passt schlecht
Beziehungen sind hier nicht der Kern; eine Bestellung ist eine einfache Struktur.
Graph passt zu Beziehungsabfragen wie Empfehlungsnetzen, die der Shop heute nicht hat.
Nutzen & Grenzen
Hilft, wenn
- Bekannte Zugriffsmuster und Transaktionsbedarfe führen zu einem Datenmodell, das Abfragen und Invarianten passend unterstützt.
- Unterschiede bei Abfrageformen, Wachstum und Konsistenz lassen sich anhand der Anforderungen sachlich vergleichen.
- Ein Team mit verlässlicher Sicherung, Wiederherstellung und Beobachtung kann eine zusätzliche Speicherart verantwortbar betreiben.
Grenzen
- Wahl nach Trend statt Zugriff erzeugt teure Umwege; teste repräsentative Abfragen und Datenmengen vor der Festlegung.
- Ein falsch geschnittenes Dokumentmodell verteilt Invarianten, die zusammengehören; prüfe die Transaktionsgarantie, siehe Transaktionsgrenzen.
- Jede weitere Speicherart kostet Betrieb: Sicherung, Wiederherstellung und Wissen im Team.
In der Praxis
- Erfasse Abfrageformen, Schreibmuster, Invarianten und Wachstumsannahmen. So vergleichst du Speichertechnologien anhand tatsächlicher Zugriffe und Anforderungen.
- Prüfe Transaktionsgarantien und Wiederherstellungsweg mit repräsentativen Daten. Eine Modellwahl ist erst tragfähig, wenn Betrieb und Migration ebenfalls abgedeckt sind.
- Miss Abfragen und Rückfallverhalten unter erwarteter Last. Transaktionsgrenzen vertieft Atomarität; Polyglot Persistence behandelt mehrere Speicher.
Ausführliche Erklärung lesen
Speichertechnologien unterscheiden sich in Datenmodell, Transaktionsmöglichkeiten, Abfrageformen und Betrieb. Relationale, dokumentorientierte, Schlüsselwert-, spaltenorientierte und Graphmodelle passen zu unterschiedlichen Zugriffen. Die Eignung folgt aus Zugriffsmustern, Invarianten und Betriebszielen.
Die Auswahl folgt den erforderlichen Lese- und Schreibmustern, Invarianten, Größenordnungen und Wiederherstellungszielen. Mehrere Speicher können zusammenarbeiten, wenn eine verbindliche Quelle und der Weg zu abgeleiteten Sichten klar bleiben. Backups, Monitoring und Betriebswissen gehören zur Entscheidung.
Transaktionsgrenzen klären, welche Änderungen ein Speicher gemeinsam absichern muss; Polyglot Persistence beschreibt die zusätzlichen Kosten mehrerer Speichermodelle.
Ein Speicher kann oft mehr, als man denkt: PostgreSQL bietet mit JSONB Dokumente und eine eingebaute Volltextsuche. Oft genügt daher ein Speicher, bevor Polyglot Persistence nötig wird. Ein verbreiteter Irrtum ist, NoSQL heiße ohne Transaktionen; viele Dokumentdatenbanken unterstützen sie inzwischen.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welches Modell passt laut Bild am besten zur atomaren Änderung einer Bestellung mit Positionen?
Lösung mit Begründung ansehen
Das relationale Modell: Transaktionen ändern Bestellung und Positionen gemeinsam. Ein Dokument geht, passt aber weniger gut.
AnwendenAuf eine neue Lage übertragen
Die Produktsuche soll Tippfehler tolerieren. Reicht die relationale Datenbank noch?
Lösung mit Begründung ansehen
Für einfache Volltextsuche oft ja, etwa mit PostgreSQL. Für Tippfehlertoleranz und Facetten lohnt ein Suchindex; wäge den zusätzlichen Betrieb gegen den Nutzen ab, die Bestellungen bleiben relational.
BewertenEine Alternative abwägen
Das Team will Bestellungen in eine Dokumentdatenbank verlegen, weil sie modern ist. Wie bewertest du das?
Lösung mit Begründung ansehen
Modernität ist kein Zugriffsargument. Vorteil: flexible Struktur. Nachteil: Migration, neue Betriebslast und Invarianten, die über Dokumente verteilt sein können. Empfehlung: relational bleiben, bis ein belegter Zugriff dagegen spricht.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft · Data Store Models (öffnet in neuem Tab)Vergleicht Datenmodelle und typische Einsatzbedingungen von Speichern.
- Martin Fowler · Polyglot Persistence (öffnet in neuem Tab)Begründet unterschiedliche Datenspeicher anhand verschiedener Zugriffsbedürfnisse.
- PostgreSQL · Transactions (öffnet in neuem Tab)Erklärt atomare Änderungen, Commit und Rollback.