Katalog
concept#Daten#Plattform#Architektur

Datenbank

Ein abstraktes Modell zur strukturierten Speicherung, Abfrage und Verwaltung persistenter Daten über Zeit und Systeme hinweg.

Datenbanken sind strukturierte Systeme zum Speichern, Abfragen und Verwalten persistenter Daten.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Reif

Technischer Kontext

ETL/ELT‑PipelinesBusiness‑Intelligence und Reporting‑ToolsService‑APIs und Applikationsserver

Prinzipien & Ziele

Datenmodell zuerst: klare Entitäten und Beziehungen definierenTrennung von Speicherung und ZugriffsschichtVerfügbarkeit von Konsistenz‑, Backup‑ und Recovery‑Strategien
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Dateninkonsistenzen bei unsauberer Transaktionshandhabung
  • Single Point of Failure bei fehlender Replikation
  • Fehlende Governance führt zu Datenqualitätsproblemen
  • Eindeutige Datenverantwortung und Governance definieren
  • Schemaänderungen kontrolliert und migrationsgestützt durchführen
  • Regelmäßige Backups und Wiederherstellungstests

I/O & Ressourcen

  • Datenmodell und Entity‑Definitionen
  • Workload‑Profile (Lese/Schreib‑Verhältnisse)
  • Sicherheits-, Compliance‑ und Datenschutzanforderungen
  • Persistente, abfragbare Datensätze
  • Backup‑ und Recovery‑Artefakte
  • Monitoring‑Metriken und Betriebskennzahlen

Beschreibung

Datenbanken sind strukturierte Systeme zum Speichern, Abfragen und Verwalten persistenter Daten. Sie bieten Modelle zur Organisation von Datensätzen, sichern Konsistenz und Dauerhaftigkeit und ermöglichen effiziente Zugriffsmuster. Datenbanken bilden die Grundlage für Analysen, transaktionale Anwendungen, Integrationsschichten in modernen Softwaresystemen und Betrieb.

  • Strukturierte, persistente Speicherung mit definierten Zugriffsmechanismen
  • Unterstützung von Transaktionen und Datenintegrität
  • Bessere Grundlage für Analyse, Reporting und Integration

  • Komplexität bei Schemaänderungen und Migrationen
  • Skalierungsgrenzen je nach Modell und Implementierung
  • Betriebsaufwand für Backup, Recovery und Performance‑Tuning

  • Latenz (p95)

    95. Perzentil der Antwortzeiten für typische Abfragen.

  • Durchsatz (TPS)

    Transaktionen oder Abfragen pro Sekunde unter Produktionslast.

  • Wiederherstellungszeit (RTO)

    Zeit bis zur Wiederherstellung nach Ausfall.

Relationale OLTP‑Datenbank (PostgreSQL)

Einsatz einer ACID‑fähigen Datenbank zur Abwicklung von Bestellungen und Zahlungen.

Spaltenorientiertes Data Warehouse

Bereitstellung analytischer Abfragen und Aggregationen für Business Intelligence.

NoSQL‑Key‑Value‑Store für Sitzungsdaten

Speicherung kurzlebiger Sitzungsinformationen mit hoher Lese-/Schreib‑Performance.

1

Anforderungen sammeln und Datenmodell entwerfen

2

Datenbanktyp und Betriebskonzept wählen (Managed vs Self‑hosted)

3

Backup, Replikation, Monitoring und Sicherheitsmaßnahmen einrichten

⚠️ Technische Schulden & Engpässe

  • Alte, nicht migratierte Schemata und redundante Felder
  • Nicht entfernte temporäre Indizes und Abfragen
  • Unzureichend dokumentierte Datenmodelle und Mappings
I/O‑DurchsatzNetzwerk‑LatenzSchema‑Locking
  • Verwendung einer transaktionalen Datenbank als primäres Data‑Warehouse ohne Anpassungen
  • Speichern großer Binärdaten direkt in Tabellen statt in spezialisierten Stores
  • Ignorieren von Indizes und Partitionierung bei wachsendem Datenvolumen
  • Fehlende Planung für Schema‑Migrationen und Downtime
  • Unzureichendes Monitoring führt zu spät entdeckten Performanceproblemen
  • Vertrauen auf Defaults ohne Validierung der Konfiguration
Datenmodellierung und NormalisierungDatenbankadministration und Backup/RecoveryPerformance‑Tuning und Indexierung
Datenkonsistenz und IntegritätSkalierbarkeit und PerformanceBetriebbarkeit, Backup und Recovery
  • Regulatorische Anforderungen an Datenspeicherung und -zugriff
  • Hardware‑ und Infrastrukturgrenzen
  • Kompatibilität mit bestehenden Systemen