Katalog
concept#Daten#Zuverlässigkeit#Architektur#Integration

ACID

ACID beschreibt vier Eigenschaften (Atomicity, Consistency, Isolation, Durability) für Datenbanktransaktionen, die Datenintegrität und vorhersehbares Verhalten bei Fehlern gewährleisten.

ACID ist ein grundlegendes Prinzip für Transaktionen in Datenbanksystemen; es fasst Atomicity, Consistency, Isolation und Durability zusammen, um Integrität und Wiederherstellbarkeit sicherzustellen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Reif

Technischer Kontext

Relationale Datenbanken (z. B. PostgreSQL, Oracle)ORMs und Transaktionsframeworks (z. B. Hibernate, Spring TX)Verteilte Transaktionskoordinatoren (XA, Two-Phase Commit)

Prinzipien & Ziele

Transaktionen sind unteilbare Operationen mit klaren Commit- oder Rollback-Ergebnissen.Konsistenz wird durch definierte Integritätsbedingungen und atomare Änderungen gewährleistet.Isolation reduziert Nebenläufigkeitsprobleme durch Sperr- oder Multiversionierungsstrategien.
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Deadlocks und Sperrkonflikte bei hoher Parallelität.
  • Fehlinterpretation als alleinige Garantie für korrekte Geschäftslogik.
  • Versteckte Performance-Probleme durch ungeeignete Isolationseinstellungen.
  • Transaktionen kurz halten und nur notwendige Änderungen einschließen.
  • Geeignete Isolationen wählen; nicht automatisch das stärkste Level setzen.
  • Idempotente Operationen und Kompensationslogik für verteilte Fälle vorbereiten.

I/O & Ressourcen

  • Transaktionsgrenzen (BEGIN/COMMIT/ROLLBACK)
  • Definierte Integritätsbedingungen und Constraints
  • Persistenter Speicher mit Crash-Recovery-Mechanismus
  • Zustandsänderungen entweder vollständig angewendet oder verworfen
  • Persistente Transaktionslogs für Recovery
  • Eindeutige Transaktionsmetadaten und Status

Beschreibung

ACID ist ein grundlegendes Prinzip für Transaktionen in Datenbanksystemen; es fasst Atomicity, Consistency, Isolation und Durability zusammen, um Integrität und Wiederherstellbarkeit sicherzustellen. Es leitet Erwartungen an Fehlerszenarien, Nebenläufigkeit und Persistenz her und macht typische Design- und Performance-Trade-offs beim Systementwurf sichtbar.

✔

  • Sicherstellung der Datenintegrität auch bei Systemfehlern.
  • Vereinfachte Fehlerbehandlung durch klare Commit-/Rollback-Semantik.
  • Verbesserte Auditierbarkeit durch persistente Transaktionsprotokolle.

✖

  • Performance-Overhead durch Sperrverwaltung und Log-Schreiboperationen.
  • Schwierigkeiten bei Skalierung über verteilte Systeme ohne zusätzliche Mechanismen.
  • Nicht immer kompatibel mit eventual-consistency-Architekturen.

  • Transaktionen pro Sekunde (TPS)

    Misst den Durchsatz erfolgreicher Transaktionen pro Zeiteinheit.

  • Durchschnittliche Transaktionslatenz

    Zeit zwischen Transaktionsbeginn und Commit oder Rollback.

  • Abgebrochene/fehlgeschlagene Transaktionen

    Anteil oder Anzahl der Transaktionen, die zurückgerollt wurden.

PostgreSQL: Transaktionen und WAL

PostgreSQL verwendet Write-Ahead-Logging und unterstützt ACID-Eigenschaften für relationale Transaktionen in Einzelinstanzen.

Bankensystem mit ACID-gesicherten Transfers

Ein Kernbankensystem setzt atomare Transaktionen ein, um Kontoüberträge konsistent und auditierbar zu gestalten.

E-Commerce: Bestell- und Lagertransaktionen

E‑Commerce-Plattformen kombinieren ACID-Transaktionen für Bestellabschluss mit asynchronen Prozessen für Skalierung.

1

Identifizieren Sie kritische Domänen, die strikte Konsistenz benötigen; definieren Sie Transaktionsgrenzen.

2

Wählen und konfigurieren Sie geeignete Isolationsebenen im DBMS.

3

Implementieren Sie Logging und Durability-Strategien (WAL, fsync, Replikation).

4

Überwachen Sie Sperrstatistiken und Transaktionslatenzen; optimieren Sie lange Transaktionen.

5

Bei verteilten Szenarien: Bewerten Sie Two-Phase-Commit vs. Kompensation/Idempotenz-Strategien.

6

Dokumentieren Sie Betriebs- und Wiederherstellungsprozeduren sowie Testfälle für Fehlerszenarien.

⚠️ Technische Schulden & Engpässe

  • Monolithische Transaktionen koppeln mehrere Geschäftsbereiche und verhindern Skalierung.
  • Fehlende Kompensationspfade für gescheiterte verteilte Operationen.
  • Unzureichende Metriken und Tracing für transaktionale Latenzen.
lange-transaktionensperr-konflikteverteilte-koordination
  • Verwendung von Transaktionen zur Steuerung von Batch-Analysen mit langen Laufzeiten.
  • Verlassen auf Autocommit-Semantik für zusammenhängende Geschäftsprozesse.
  • Annahme, dass ACID verteilt automatisch möglich ist ohne Koordination.
  • Verborgene Retries können Seiteneffekte duplizieren.
  • Implizite Locks führen zu unerwarteten Timeouts unter Last.
  • Annahmen über Durability ohne Überprüfung der Storage-Stack-Settings.
Datenbankgrundlagen und TransaktionstheorieKenntnis von Isolationsebenen und SperrmechanismenFähigkeit zur Fehleranalyse und Recovery-Planung
Datenintegrität und Compliance-AnforderungenBetriebliche Verfügbarkeit und AusfallsicherheitLeistungs- und Skalierungsanforderungen
  • • Notwendigkeit durabler Speicherebenen (WAL/Commit-Log)
  • • Begrenzte Skalierbarkeit ohne zusätzliche Muster (Sharding, CQRS)
  • • Abhängigkeit von DBMS-Unterstützung für Transaktionsisolation