ACID Transaktionen einfach erklärt – mit Beispielen

Du arbeitest mit Datenbanken und willst, dass Änderungen zuverlässig ausgeführt werden. Genau dafür gibt es ACID Transaktionen. Sie stellen sicher, dass Operationen ganz oder gar nicht passieren, dass Daten konsistent bleiben, dass parallele Zugriffe geordnet ablaufen und dass Ergebnisse dauerhaft gespeichert werden. In diesem Leitfaden bekommst du eine einfache Erklärung der ACID Prinzipien und mehrere Praxisbeispiele, damit du sofort verstehst, warum ACID im Alltag so wichtig ist.

Was ist eine Transaktion

Eine Transaktion fasst mehrere Datenbankoperationen zu einer einzigen logischen Einheit zusammen. Du startest sie, führst Schritte aus und bestätigst am Ende mit COMMIT. Geht etwas schief, machst du alles mit ROLLBACK rückgängig. Für dich bedeutet das: Entweder wird alles korrekt übernommen, oder nichts ändert sich. Halb fertige Zustände vermeidest du so von vornherein.

Wofür steht ACID

ACID ist ein Akronym aus vier Eigenschaften. Zusammen garantieren sie korrekte, vorhersehbare und stabile Datenbankänderungen.

A wie Atomicity – Atomarität

Atomarität heißt: Alles oder nichts. Entweder eine Transaktion wird vollständig übernommen, oder gar nicht. Beispiel: Bei einer Überweisung wird Geld beim Sender abgebucht und beim Empfänger gutgeschrieben. Fällt eine der beiden Operationen aus, darf keine verbucht bleiben.

C wie Consistency – Konsistenz

Konsistenz bedeutet: Nach der Transaktion halten die Daten alle Regeln ein. Dazu gehören Primärschlüssel, Fremdschlüssel, Unique Constraints, Trigger und fachliche Regeln. Wenn eine Regel verletzt würde, bricht die Transaktion ab und die Datenbank bleibt im gültigen Zustand.

I wie Isolation

Isolation sorgt dafür, dass gleichzeitige Transaktionen sich nicht in die Quere kommen. Jede Transaktion verhält sich so, als würde sie allein laufen. Isolation verhindert Effekte wie Dirty Reads, Non Repeatable Reads und Phantoms, je nach gewähltem Isolation Level.

D wie Durability – Dauerhaftigkeit

Dauerhaftigkeit garantiert: Was committed wurde, bleibt erhalten, auch bei Stromausfall oder Neustart. Das erreicht die Datenbank durch Transaktionslogs wie WAL und durch sichere Speichermechanismen.

Isolation Levels verständlich

Isolation ist ein Spektrum. Typische Stufen sind Read Committed, Repeatable Read und Serializable.

• Bei Read Committed siehst du nur bestätigte Daten, die sich zwischen zwei Lesevorgängen aber ändern können.
• Repeatable Read stellt sicher, dass dieselbe Zeile innerhalb einer Transaktion gleich bleibt.
• Serializable verhält sich so, als würden Transaktionen nacheinander laufen. Das ist am strengsten, aber auch teurer.

Für Einsteiger reicht oft Read Committed. Wenn Berichte stabile Sichten brauchen, nimm Repeatable Read. Für kritische Konsistenz über mehrere Tabellen kann Serializable nötig sein.

Praxisbeispiel 1 – Banküberweisung

Angenommen, du überträgst 50 Euro von Konto A zu Konto B. Beide Updates gehören zusammen. Mit ACID sieht das so aus:

BEGIN;
UPDATE konto SET saldo = saldo - 50 WHERE id = 'A';
UPDATE konto SET saldo = saldo + 50 WHERE id = 'B';
COMMIT;

Fällt eine Zeile oder die Verbindung aus, wird ROLLBACK ausgeführt und beide Konten bleiben unverändert. Das ist Atomarität in Reinform, kombiniert mit Konsistenz durch Regeln wie saldo >= 0.

Praxisbeispiel 2 – Warenkorb und Lagerbestand

Ein Kunde legt eine Bestellung an und der Lagerbestand sinkt. Ohne Transaktion riskierst du Doppelverkäufe oder negative Bestände.

BEGIN;
INSERT INTO bestellung(kunde_id, summe) VALUES (42, 129.90) RETURNING id;
UPDATE artikel SET bestand = bestand - 1 WHERE id = 1001 AND bestand > 0;
COMMIT;

Die zweite Zeile sorgt dafür, dass nur bei positivem Bestand reduziert wird. Greifen mehrere Nutzer gleichzeitig zu, schützt ein passender Isolation Level vor Rennen um die letzte Einheit.

Praxisbeispiel 3 – Tickets mit Sitzplatzwahl

Stell dir vor, zwei Personen wählen gleichzeitig denselben Sitzplatz. Mit Serializable oder mit Sperren stellst du sicher, dass der Platz nur einmal vergeben wird. Eine Transaktion gewinnt, die andere erhält eine Konfliktmeldung und kann den Nutzer neu wählen lassen. Das verhindert Doppelbuchungen.

Wie Datenbanken ACID umsetzen

Unter der Haube protokolliert die DB Änderungen im Transaktionslog. Erst wenn die Logeinträge sicher geschrieben sind, ist ein COMMIT gültig. Bei Rollback liest die DB das Log und macht Änderungen rückgängig. Constraints stellen Konsistenz sicher, Sperren und MVCC liefern Isolation, und Recovery nach Absturz bringt die DB in einen konsistenten Zustand zurück.

Best Practices für deinen Code

Halte Transaktionen kurz. Je länger sie laufen, desto höher die Chance auf Sperrkonflikte. Wähle den Isolation Level passend zur Aufgabe. Fange Fehler ab und reagiere mit Rollback plus verständlicher Fehlermeldung. Nutze Constraints statt alles nur im Anwendungscode zu prüfen. Schreibe idempotente Operationen, damit ein Retry nach Timeout nicht doppelt bucht. Logge Trace-IDs, um Probleme sauber nachzuvollziehen.

Häufige Missverständnisse

ACID ist kein Performance-Killer. Richtig eingesetzt reduziert es Fehler, Reparaturen und Datensalat. Ein weiteres Missverständnis: ACID gilt nur für relationale Datenbanken. Viele NoSQL Systeme bieten inzwischen Transaktionen oder ACID-ähnliche Garantien in Teilbereichen. Wichtig ist, die Garantien deiner konkreten Datenbank zu kennen und sie bewusst zu nutzen.

ACID vs BASE – kurzer Blick über den Tellerrand

In hoch verteilten Systemen begegnet dir BASE als Gegenentwurf zu ACID. BASE setzt auf eventuelle Konsistenz und hohe Verfügbarkeit. Für Finanzen, Bestände und kritische Stammdaten ist ACID meist die richtige Wahl. Für Analysen oder Feed-Updates kann BASE genügen. Entscheidend ist die fachliche Anforderung.

Fazit

ACID Transaktionen sind die Basis für zuverlässige Anwendungen. Mit Atomarität, Konsistenz, Isolation und Dauerhaftigkeit vermeidest du halbe Zustände, Datenfehler und Rennbedingungen. Nutze Transaktionen bewusst, wähle einen passenden Isolation Level, setze Constraints ein und halte Prozesse kurz. So bleiben deine Daten richtig, robust und nachvollziehbar.