Zum Inhalt springen
≈ 3 minNeuDatenbankModellierungSQLArchitekturAzure

Persistenzschicht und Datenbankwahl

Die Persistenzschicht speichert Daten dauerhaft – mit Schema, Schlüsseln, Constraints, Indizes und Migrationen in einem Datenspeicher, der zu den Zugriffsmustern passt.

In 30 Sekunden

  1. 01

    SQL-Datenbanken speichern Tabellen mit festem Schema und garantieren ACID, NoSQL-Datenbanken tauschen Joins und strenge Konsistenz gegen Flexibilität und horizontale Skalierung.

  2. 02

    Standard für Geschäftsdaten ist relational, etwa PostgreSQL oder Azure SQL. NoSQL lohnt sich, wenn ein Zugriffsmuster es verlangt.

  3. 03

    Daneben gibt es Spezialisten wie NewSQL, Data Warehouses für Analysen, Vektor-Datenbanken für KI und Object Storage für Dateien.

Was gehört in die Persistenzschicht?

Schema & Tabellen

Struktur der Daten mit Spaltentypen. In Dokument-DBs implizit, aber trotzdem vorhanden.

Schlüssel

Primärschlüssel identifizieren Zeilen, Fremdschlüssel sichern Beziehungen ab.

Constraints

NOT NULL, UNIQUE, CHECK – Regeln, die auch bei Bugs im Code gelten.

Indizes

Machen die häufigsten Abfragen schnell, kosten aber Schreibleistung und Speicher.

Migrationen

Versionierte Skripte, die das Schema reproduzierbar weiterentwickeln.

Transaktionen

Mehrere Änderungen gelingen gemeinsam oder gar nicht (ACID).

SQL vs. NoSQL

SQL (relational) heißt: Daten in Tabellen mit festem Schema, Beziehungen über Fremdschlüssel, Abfragen per SQL. NoSQL ist ein Sammelbegriff für alles Nicht-Relationale – Dokumente, Key-Value, Wide-Column, Graphen. Der Kernunterschied liegt im Modellieren: SQL fragt „Welche Daten gibt es?“, NoSQL fragt „Wie werden sie gelesen?“.

Datenmodell

SQL (relational)Tabellen mit Zeilen und Spalten

NoSQLDokumente, Schlüssel-Werte, Spalten-Familien oder Graphen

Schema

SQL (relational)fest, vorab definiert („schema on write“)

NoSQLflexibel, pro Datensatz verschieden („schema on read“)

Modellieren nach

SQL (relational)Entitäten – normalisiert, ohne Redundanz

NoSQLZugriffsmustern – zusammen, was zusammen gelesen wird

Beziehungen

SQL (relational)Fremdschlüssel und Joins

NoSQLeingebettet oder per Referenz, Joins selten

Abfragen

SQL (relational)SQL – standardisiert, beliebig kombinierbar

NoSQLproduktspezifische APIs, auf bekannte Abfragen optimiert

Konsistenz

SQL (relational)ACID – sofort konsistent

NoSQLoft BASE – „irgendwann“ konsistent, einstellbar

Skalierung

SQL (relational)vertikal (größerer Server) + Read-Replicas

NoSQLhorizontal (mehr Knoten), Partitionierung eingebaut

Vertreter

SQL (relational)PostgreSQL, Azure SQL, MySQL, Oracle

NoSQLMongoDB, Cosmos DB, Redis, Cassandra, Neo4j

KriteriumSQL (relational)NoSQL
DatenmodellTabellen mit Zeilen und SpaltenDokumente, Schlüssel-Werte, Spalten-Familien oder Graphen
Schemafest, vorab definiert („schema on write“)flexibel, pro Datensatz verschieden („schema on read“)
Modellieren nachEntitäten – normalisiert, ohne RedundanzZugriffsmustern – zusammen, was zusammen gelesen wird
BeziehungenFremdschlüssel und Joinseingebettet oder per Referenz, Joins selten
AbfragenSQL – standardisiert, beliebig kombinierbarproduktspezifische APIs, auf bekannte Abfragen optimiert
KonsistenzACID – sofort konsistentoft BASE – „irgendwann“ konsistent, einstellbar
Skalierungvertikal (größerer Server) + Read-Replicashorizontal (mehr Knoten), Partitionierung eingebaut
VertreterPostgreSQL, Azure SQL, MySQL, OracleMongoDB, Cosmos DB, Redis, Cassandra, Neo4j
Die Grenzen verschwimmen: PostgreSQL kann JSON (JSONB), MongoDB kann Transaktionen über mehrere Dokumente.

Warum NoSQL bei der Konsistenz nachgibt, erklärt das CAP-Theorem: Fällt das Netz zwischen Knoten aus, muss ein verteiltes System zwischen Konsistenz und Verfügbarkeit wählen.

Dieselben Daten, drei Speicher

PostgreSQL

Normalisiert in Tabellen, zusammengesetzt per Join:

SELECT t.id, t.title, t.due_date, array_agg(g.name) AS tags
FROM task AS t
LEFT JOIN task_tag AS tt ON tt.task_id = t.id
LEFT JOIN tag AS g ON g.id = tt.tag_id
WHERE t.user_id = 42 AND NOT t.done
GROUP BY t.id
ORDER BY t.due_date;

MongoDB

Ein Dokument enthält alles, was zusammen gelesen wird – die Tags eingebettet:

db.tasks.insertOne({
  userId: 42,
  title: "Steuererklärung",
  due: ISODate("2026-11-30"),
  done: false,
  tags: ["privat", "finanzen"],
});

db.tasks.createIndex({ userId: 1, done: 1, due: 1 });
db.tasks.find({ userId: 42, done: false }).sort({ due: 1 });

Redis

Kein Ersatz für die Datenbank, sondern Ergänzung – schnelle, oft ablaufende Werte:

# Session für eine Stunde
SET session:8f3a2c '{"userId":42}' EX 3600

# Rate Limit: Zähler pro User und Minute
INCR ratelimit:user:42:202610101945
EXPIRE ratelimit:user:42:202610101945 60

# Cache für die Task-Liste, wird beim Ändern gelöscht
SET cache:tasks:user:42 '[{"id":1,"title":"Steuererklärung"}]' EX 300

Welcher Speicher wann?

Relational

BeispielePostgreSQL, Azure SQL, MySQL

Stark beiTransaktionen, Joins, Konsistenz

Sinnvoll fürGeschäftsdaten mit Beziehungen – der Standard

Dokument

BeispieleMongoDB, Azure Cosmos DB, Firestore

Stark beiverschachtelte JSON-Objekte, flexible Struktur

Sinnvoll fürKataloge, Profile, Inhalte, die als Ganzes gelesen werden

Key-Value

BeispieleRedis, Azure Cache for Redis

Stark beiZugriff per Schlüssel in unter 1 ms

Sinnvoll fürCache, Sessions, Rate Limits, Locks

Wide-Column

BeispieleApache Cassandra, ScyllaDB

Stark beiriesige Schreiblast, verteilt über viele Knoten

Sinnvoll fürIoT, Events, Logs mit bekannten Abfragen

Graph

BeispieleNeo4j, Cosmos DB (Gremlin)

Stark beiBeziehungen über viele Ebenen

Sinnvoll fürEmpfehlungen, Netzwerke, Berechtigungen

Zeitreihen

BeispieleTimescaleDB, InfluxDB, Azure Data Explorer

Stark beizeitgestempelte Werte, Aggregation

Sinnvoll fürMetriken, Sensordaten, Monitoring

Suche

BeispieleElasticsearch, OpenSearch, Azure AI Search

Stark beiVolltext, Relevanz, Facetten

Sinnvoll fürProduktsuche – ergänzend zur Haupt-DB

Object Storage

BeispieleAzure Blob Storage, Amazon S3

Stark beigroße Dateien, sehr günstig

Sinnvoll fürUploads, Bilder, Backups, Exporte

KriteriumBeispieleStark beiSinnvoll für
RelationalPostgreSQL, Azure SQL, MySQLTransaktionen, Joins, KonsistenzGeschäftsdaten mit Beziehungen – der Standard
DokumentMongoDB, Azure Cosmos DB, Firestoreverschachtelte JSON-Objekte, flexible StrukturKataloge, Profile, Inhalte, die als Ganzes gelesen werden
Key-ValueRedis, Azure Cache for RedisZugriff per Schlüssel in unter 1 msCache, Sessions, Rate Limits, Locks
Wide-ColumnApache Cassandra, ScyllaDBriesige Schreiblast, verteilt über viele KnotenIoT, Events, Logs mit bekannten Abfragen
GraphNeo4j, Cosmos DB (Gremlin)Beziehungen über viele EbenenEmpfehlungen, Netzwerke, Berechtigungen
ZeitreihenTimescaleDB, InfluxDB, Azure Data Explorerzeitgestempelte Werte, AggregationMetriken, Sensordaten, Monitoring
SucheElasticsearch, OpenSearch, Azure AI SearchVolltext, Relevanz, FacettenProduktsuche – ergänzend zur Haupt-DB
Object StorageAzure Blob Storage, Amazon S3große Dateien, sehr günstigUploads, Bilder, Backups, Exporte
Viele Projekte kombinieren mehrere Speicher („Polyglot Persistence“) – aber erst, wenn es nötig ist.

Was es sonst noch gibt

SQL + horizontal

NewSQL

SQL und ACID, aber über viele Knoten verteilt: CockroachDB, Google Spanner, YugabyteDB.

Ein System, viele Modelle

Multi-Model

Azure Cosmos DB spricht Dokument, Key-Value, Graph und Cassandra. Auch PostgreSQL wird mit JSONB und Extensions vielseitig.

Alles im RAM

In-Memory & spaltenbasiert

SAP HANA hält Daten spaltenweise im Arbeitsspeicher und kann Transaktionen und Analysen zugleich.

Analyse statt Betrieb

Data Warehouse & Lakehouse

Für Auswertungen über Millionen Zeilen (OLAP): Databricks, Snowflake, Microsoft Fabric, BigQuery.

Für KI

Vektor-Datenbanken

Finden ähnliche Embeddings, etwa für RAG: pgvector, Qdrant, Azure AI Search.

Ohne Server

Embedded

Läuft als Bibliothek in der App: SQLite für Mobile und Tests, DuckDB für lokale Analysen.

Fragen für die Entscheidung

  1. 01

    Müssen mehrere Änderungen gemeinsam gelingen?

    → relational

    Bestellung + Zahlung + Lagerbestand: Transaktionen und Fremdschlüssel sind hier unverzichtbar.

  2. 02

    Wird ein Datensatz fast immer als Ganzes gelesen?

    → Dokument

    Ein Produkt mit wechselnden Attributen oder ein Benutzerprofil mit Einstellungen.

  3. 03

    Reicht der Zugriff per Schlüssel, darf es flüchtig sein?

    → Key-Value

    Session-Daten, zwischengespeicherte API-Antworten, Zähler für Rate Limits.

  4. 04

    Geht es um Beziehungsketten?

    → Graph

    „Freunde von Freunden“, „wer hat über welche Gruppe Zugriff auf was?“

  5. 05

    Willst du auswerten statt betreiben?

    → Warehouse / Lakehouse

    Berichte und Dashboards über Jahre an Daten, getrennt von der Produktionsdatenbank.

  6. 06

    Sind es große Binärdateien?

    → Object Storage

    PDFs, Bilder, Videos – in der Datenbank nur der Verweis.

Merksatz

„Starte mit einer relationalen Datenbank – und füge einen Spezialspeicher erst hinzu, wenn ein konkretes Zugriffsmuster ihn verlangt.“

Selbsttest

Erst selbst überlegen, dann aufklappen.

01Was ist der wichtigste Unterschied zwischen SQL und NoSQL beim Modellieren?

SQL normalisiert die Daten in Tabellen und setzt sie per Join wieder zusammen. NoSQL modelliert nach Zugriffsmuster und speichert zusammen, was zusammen gelesen wird – oft auch redundant.

02Ein Shop speichert Bestellungen mit Positionen, Zahlungen und Lagerbestand. Welcher Speicher?

Relational (z. B. PostgreSQL). Bestellung, Zahlung und Bestandsänderung müssen in einer Transaktion gemeinsam gelingen oder scheitern.

03Warum rechnet man Umsatzberichte über fünf Jahre nicht direkt auf der Produktionsdatenbank?

Die Produktionsdatenbank ist für viele kleine Schreib- und Lesezugriffe (OLTP) optimiert. Große Auswertungen (OLAP) gehören in ein Data Warehouse oder Lakehouse mit spaltenorientierter Speicherung, damit sie den Betrieb nicht ausbremsen.

04Wo speicherst du hochgeladene Profilbilder?

In Object Storage (z. B. Azure Blob Storage). In der Datenbank steht nur die URL bzw. der Blob-Name.

Quellen & Weiterlesen

Verwandt

Weiter in Grundlagen

IDE – Integrated Development Environment