Was ist ACID: Atomarität, Konsistenz, Isolation, Dauerhaftigkeit

ACID sind die vier Eigenschaften, die ein DBMS bei der Ausführung von Transaktionen garantiert: Atomicity (Atomarität), Consistency (Konsistenz), Isolation und Durability (Dauerhaftigkeit). Zusammen bedeuten sie eines: Den Daten kann man vertrauen — selbst wenn der Server mitten in einer Operation abstürzt und Tausende Clients gleichzeitig auf die Datenbank zugreifen.

Eine Transaktion ist eine Gruppe von SQL-Operationen, die als Einheit ausgeführt wird: Entweder werden alle Operationen erfolgreich abgeschlossen oder keine einzige. Das klassische Beispiel ist eine Überweisung:

MySQL 8.1
START TRANSACTION;

UPDATE accounts SET balance = balance - 1000 WHERE account_id = 1;
UPDATE accounts SET balance = balance + 1000 WHERE account_id = 2;

COMMIT;

Zwischen den beiden UPDATE-Befehlen kann alles Mögliche passieren: Stromausfall, Netzwerkabbruch, Absturz des DBMS-Prozesses. Wird der erste Befehl ausgeführt und der zweite nicht, verschwinden tausend Euro einfach. Genau dafür gibt es die ACID-Eigenschaften: damit solche Geschichten unmöglich sind. Gehen wir sie einzeln durch.

A — Atomicity, Atomarität

Eine Transaktion ist unteilbar: Entweder werden alle ihre Operationen ausgeführt oder keine.

Im Überweisungsbeispiel garantiert die Atomarität: Es gibt keinen Datenbankzustand, in dem das Geld von einem Konto abgebucht, aber dem anderen nicht gutgeschrieben wurde. Geht auf irgendeinem Schritt etwas schief, führt das DBMS einen Rollback aus — es versetzt die Daten in den Zustand zu Beginn der Transaktion zurück, als hätte es sie nie gegeben.

Einen Rollback kann man auch manuell mit dem Befehl ROLLBACK auslösen:

MySQL 8.1
START TRANSACTION;

UPDATE accounts SET balance = balance - 1000 WHERE account_id = 1;
-- umentschieden: alle Änderungen dieser Transaktion verwerfen
ROLLBACK;

Unter der Haube führt das DBMS ein Änderungsjournal: Bevor es Daten ändert, protokolliert es, was es vorhat und wie sich das rückgängig machen lässt. Nach einem Absturz stellt sich die Datenbank anhand des Journals wieder her: Abgeschlossene Transaktionen werden zu Ende geführt, unfertige zurückgerollt.

C — Consistency, Konsistenz

Eine Transaktion überführt die Datenbank von einem korrekten Zustand in einen anderen korrekten Zustand.

Was „korrekt" ist, definieren die im Schema beschriebenen Regeln: NOT NULL-, UNIQUE- und CHECK-Constraints, Fremdschlüssel, Trigger. Wird innerhalb einer Transaktion eine Regel verletzt — etwa ein negativer Kontostand trotz CHECK (balance >= 0) — wird die gesamte Transaktion zurückgerollt.

Eine wichtige Nuance: Das DBMS prüft nur die Regeln, die Sie ihm beschrieben haben. Existiert die Regel „Summe der Abbuchungen gleich Summe der Gutschriften" nur im Kopf des Entwicklers, schützt die Datenbank sie nicht. Konsistenz ist Gemeinschaftsarbeit von DBMS und Schema-Designer.

I — Isolation

Parallele Transaktionen sehen die Zwischenzustände der jeweils anderen nicht.

Während ein Client Geld überweist, summiert ein anderer im selben Moment alle Kontostände. Ohne Isolation könnte der zweite Client die Datenbank „auf halbem Weg" sehen: Geld bereits abgebucht, aber noch nicht gutgeschrieben — die Gesamtsumme wäre um genau tausend Euro falsch.

Idealerweise sollten sich Transaktionen so verhalten, als liefen sie streng nacheinander. Doch vollständige Isolation ist teuer: Transaktionen müssen aufeinander warten. Deshalb bieten DBMS Kompromisse an — Isolationsstufen. Je niedriger die Stufe, desto schneller arbeitet die Datenbank und desto mehr Merkwürdigkeiten können parallele Transaktionen beobachten. Diese Merkwürdigkeiten heißen Leseanomalien:

• Dirty Read. Eine Transaktion sieht Änderungen, die eine andere noch nicht festgeschrieben hat. Rollt diese zurück, haben die gelesenen Daten nie „offiziell" existiert.
• Non-Repeatable Read. Eine Transaktion liest dieselbe Zeile zweimal und erhält unterschiedliche Werte, weil eine andere Transaktion die Zeile zwischendurch geändert und committet hat.
• Phantom Read. Eine Transaktion führt dieselbe Bedingungsabfrage zweimal aus und sieht beim zweiten Mal neue Zeilen, die eine andere Transaktion inzwischen eingefügt hat.

Wie eine Anomalie live aussieht, zeigt am einfachsten ein Zeitstrahl zweier paralleler Sessions. Hier ein Non-Repeatable Read auf der Stufe READ COMMITTED:

Session A hat zwischen Schritt 2 und 4 nichts getan, und doch hat sich die Welt darunter verändert. Auf der Stufe REPEATABLE READ würde Schritt 4 dieselben 100 liefern: Die Transaktion arbeitet mit einem Schnappschuss der Daten vom Zeitpunkt ihres Beginns.

Der SQL-Standard beschreibt vier Isolationsstufen — jede weitere schließt mehr Anomalien aus:

Standardmäßig arbeitet PostgreSQL auf READ COMMITTED, MySQL (InnoDB) auf REPEATABLE READ. In der Praxis reicht das fast immer, aber zu wissen, welche Anomalien auf Ihrer Stufe möglich sind, lohnt sich: „Flackernde" Bugs in Berichten und Zählern wachsen oft genau hier.

Die Stufe lässt sich für eine konkrete Transaktion ändern:

MySQL 8.1
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
START TRANSACTION;
-- Logik, bei der Genauigkeit kritisch ist
COMMIT;

Eine Transaktion hat die Abfrage SELECT COUNT(*) FROM orders WHERE status = 'new' zweimal ausgeführt und unterschiedliche Zahlen erhalten: Dazwischen hat eine andere Transaktion Bestellungen eingefügt. Wie heißt diese Anomalie?

D — Durability, Dauerhaftigkeit

Ist eine Transaktion festgeschrieben, geht ihr Ergebnis nicht verloren.

Sobald das DBMS „COMMIT ausgeführt" meldet, überleben die Änderungen alles: Notabschaltung des Servers, Prozessabsturz, Neustart. Erreicht wird das, indem vor der Bestätigung ein Eintrag über die Transaktion zwingend ins Journal auf der Festplatte geschrieben wird (in PostgreSQL heißt es WAL — Write-Ahead Log, in MySQL InnoDB Redo Log). Selbst wenn die Tabellendaten selbst noch nicht aktualisiert wurden, bringt die Datenbank sie nach dem Neustart anhand des Journals in den richtigen Zustand.

Der Datenbankserver ist genau in dem Moment abgestürzt und neu gestartet, als eine Transaktion das erste ihrer zwei UPDATE-Statements ausgeführt hatte. Was passiert mit dieser Änderung nach dem Neustart?

ACID vs. BASE: Und was ist mit NoSQL

In der Welt verteilter NoSQL-Speicher gilt oft ein anderes Bündel von Kompromissen — BASE: Basically Available, Soft State, Eventually Consistent. Der Kern: Das System antwortet immer, aber die Daten auf verschiedenen Knoten dürfen eine Zeit lang auseinanderlaufen und gleichen sich „irgendwann" an.

Das ist weder „schlechter" noch „besser" als ACID — es ist eine andere Wahl. Ein Zahlungssystem braucht die Strenge von ACID: Eine verlorene Überweisung ist inakzeptabel. Einem Like-Zähler genügt BASE: Es schadet niemandem, wenn die Zahl eine Sekunde hinterherhinkt. Viele moderne Systeme kombinieren beide Ansätze für unterschiedliche Datenbereiche.

Was im Vorstellungsgespräch gefragt wird

ACID ist eines der häufigsten Themen in SQL- und Datenbank-Interviews. Typische Fragen:

• Buchstabieren Sie ACID aus und erklären Sie jede Eigenschaft. Das Überweisungsbeispiel genügt — es deckt alle vier Buchstaben ab.
• Worin unterscheidet sich Atomarität von Konsistenz? Atomarität heißt „alles oder nichts", Konsistenz heißt: Der Endzustand hält die Schemaregeln ein.
• Welche Isolationsstufen kennen Sie, und welche ist Standard? Erwartet werden die Tabelle oben plus die Defaults Ihres DBMS.
• Was ist ein Dirty Read und auf welcher Stufe ist er möglich? Nur auf READ UNCOMMITTED.
• Wie garantiert die Datenbank Dauerhaftigkeit, wenn Daten im Speicher gecacht werden? Das Stichwort ist das Write-Ahead Log (WAL/Redo Log): Vor der Bestätigung landet der Journaleintrag auf der Festplatte, nicht die Datenseiten selbst.

Wie weiter

ACID ist Theorie, die man am besten sofort praktisch festigt:

• wie man Transaktionen erstellt und steuert — in den Lektionen Transaktionen und Transaktionen erstellen;
• wie das DBMS Konflikte paralleler Transaktionen auflöst — in der Lektion Sperren;
• prüfen Sie sich an echten Interviewfragen — im Bereich Interviewfragen.