ACID

ACID ist ein Akronym für vier grundlegende Eigenschaften, die zuverlässige Datenbanktransaktionen garantieren: Atomicity (Atomarität), Consistency (Konsistenz), Isolation und Durability (Dauerhaftigkeit). Diese Prinzipien stellen sicher, dass Datenbanken auch bei Systemausfällen, Stromausfällen oder gleichzeitigen Zugriffen in einem konsistenten Zustand bleiben.

Das ACID-Konzept wurde erstmals 1983 von den Informatikern Theo Haerder und Andreas Reuter in ihrem Artikel "Principles of Transaction-Oriented Database Recovery" formalisiert. Seitdem bildet es das Fundament für die Zuverlässigkeit relationaler Datenbanksysteme wie MySQL, PostgreSQL und Oracle.

Die vier ACID-Eigenschaften

Jede der vier ACID-Eigenschaften erfüllt eine spezifische Aufgabe bei der Sicherstellung der Datenintegrität. Erst das Zusammenspiel aller vier Eigenschaften garantiert zuverlässige Transaktionen.

Atomicity (Atomarität)

Atomicity bedeutet, dass eine Transaktion als unteilbare Einheit behandelt wird - entweder werden alle Operationen erfolgreich ausgeführt (Commit), oder keine einzige (Rollback). Es gibt keine Zwischenzustände, in denen nur ein Teil der Änderungen gespeichert ist.

Stell dir eine Banküberweisung vor: Du möchtest 100 Euro von Konto A auf Konto B überweisen. Diese Operation besteht aus zwei Schritten - dem Abbuchen von Konto A und dem Gutschreiben auf Konto B. Atomarität stellt sicher, dass niemals Geld "verschwindet", weil nur der erste Schritt ausgeführt wurde.

-- Beispiel: Atomare Banküberweisung
START TRANSACTION;

UPDATE konten SET saldo = saldo - 100 WHERE konto_id = 1;
UPDATE konten SET saldo = saldo + 100 WHERE konto_id = 2;

-- Bei Erfolg: Beide Änderungen werden gespeichert
COMMIT;

-- Bei Fehler: Beide Änderungen werden verworfen
-- ROLLBACK;

Consistency (Konsistenz)

Consistency garantiert, dass eine Transaktion die Datenbank von einem gültigen Zustand in einen anderen gültigen Zustand überführt. Alle definierten Regeln und Constraints - wie Primärschlüssel, Fremdschlüssel, CHECK-Constraints oder Trigger - müssen vor und nach der Transaktion erfüllt sein.

Wenn in einer E-Commerce-Datenbank festgelegt ist, dass der Lagerbestand nie negativ werden darf, verhindert die Konsistenz-Eigenschaft, dass eine Bestellung mehr Artikel verkauft, als auf Lager sind. Die Transaktion wird abgebrochen, bevor ein ungültiger Zustand entstehen kann.

-- Beispiel: Constraint verhindert negativen Lagerbestand
CREATE TABLE lagerbestand (
    artikel_id INT PRIMARY KEY,
    menge INT CHECK (menge >= 0)  -- Constraint
);

-- Diese Transaktion schlaegt fehl, wenn menge negativ würde
UPDATE lagerbestand 
SET menge = menge - 10 
WHERE artikel_id = 42;

Isolation

Isolation sorgt dafür, dass parallel laufende Transaktionen sich nicht gegenseitig beeinflussen. Jede Transaktion arbeitet so, als wäre sie die einzige im System. Die Änderungen einer Transaktion werden erst nach dem Commit für andere sichtbar.

Ohne Isolation könnten verschiedene Anomalien auftreten: Ein Dirty Read bedeutet, dass eine Transaktion Daten liest, die noch nicht committed wurden. Bei einem Non-Repeatable Read liefert dieselbe Abfrage unterschiedliche Ergebnisse, weil eine andere Transaktion dazwischen Daten geändert hat.

Datenbanken bieten verschiedene Isolationslevel, die einen Kompromiss zwischen Sicherheit und Performance ermöglichen:

Je höher das Isolationslevel, desto sicherer sind die Daten, aber desto mehr wird die parallele Verarbeitung eingeschränkt. In der Praxis ist Read Committed der Standardwert bei den meisten Datenbanksystemen.

Durability (Dauerhaftigkeit)

Durability garantiert, dass erfolgreich committete Transaktionen permanent gespeichert bleiben - auch bei Systemabstürzen, Stromausfällen oder Hardware-Defekten. Sobald das Datenbanksystem den Commit bestätigt hat, sind die Daten sicher.

Datenbanken erreichen Dauerhaftigkeit durch Write-Ahead Logging (WAL): Bevor eine Änderung in die eigentlichen Datenbankdateien geschrieben wird, landet sie zuerst in einem Transaction Log. Bei einem Systemausfall kann die Datenbank anhand dieses Logs alle committeten Transaktionen wiederherstellen.

Praktisches Beispiel: Online-Bestellung

Ein typisches Szenario, in dem alle ACID-Eigenschaften zusammenspielen, ist eine Online-Bestellung. Hier müssen mehrere Tabellen gleichzeitig aktualisiert werden - und das zuverlässig.

START TRANSACTION;

-- 1. Neue Bestellung anlegen
INSERT INTO bestellungen (kunde_id, datum, status) 
VALUES (42, NOW(), 'offen');

-- 2. Bestellpositionen hinzufügen
INSERT INTO bestellpositionen (bestell_id, artikel_id, menge) 
VALUES (LAST_INSERT_ID(), 101, 2);

-- 3. Lagerbestand reduzieren
UPDATE lagerbestand 
SET menge = menge - 2 
WHERE artikel_id = 101;

-- 4. Kundenpunkte gutschreiben
UPDATE kunden 
SET treuepunkte = treuepunkte + 50 
WHERE id = 42;

COMMIT;

Durch ACID ist sichergestellt, dass niemals eine Bestellung ohne Lagerbestandsänderung existiert, keine Punkte ohne Bestellung gutgeschrieben werden, und alle Änderungen auch nach einem Serverausfall erhalten bleiben.

ACID vs. BASE

Während relationale Datenbanken auf ACID setzen, verfolgen viele NoSQL-Datenbanken einen anderen Ansatz namens BASE (Basically Available, Soft state, Eventually consistent). BASE akzeptiert temporäre Inkonsistenzen zugunsten höherer Verfügbarkeit und Skalierbarkeit.

Die Wahl zwischen ACID und BASE hängt vom Anwendungsfall ab. Für Banktransaktionen, medizinische Daten oder E-Commerce-Bestellungen ist ACID unverzichtbar. Für Social-Media-Feeds oder Echtzeit-Analytics kann BASE die bessere Wahl sein.

ACID in der Praxis

Fast alle relationalen Datenbanksysteme implementieren die ACID-Eigenschaften, allerdings mit unterschiedlichen Standardeinstellungen und Optimierungen. Als Entwickler solltest du wissen, wie dein DBMS Transaktionen handhabt.

• MySQL/MariaDB: ACID-konform mit InnoDB-Storage-Engine (Standard seit MySQL 5.5)
• PostgreSQL: Vollständige ACID-Unterstützung mit MVCC (Multi-Version Concurrency Control)
• Microsoft SQL Server: ACID-konform mit verschiedenen Isolationslevels
• Oracle Database: Vollständige ACID-Implementierung mit umfangreichen Recovery-Optionen
• SQLite: ACID-konform, auch bei eingebetteten Anwendungen

Bei der Entwicklung von Anwendungen mit Java, C# oder anderen Sprachen nutzt du oft Frameworks, die die Transaktionsverwaltung abstrahieren. Spring in Java oder Entity Framework in .NET bieten deklarative Transaktionen per Annotation.

Quellen und weiterführende Links

• Wikipedia: ACID - Ausführliche Erklärung des Konzepts
• PostgreSQL: Transaction Isolation - Offizielle Dokumentation zu Isolationslevels
• MySQL: ACID Compliance - MySQL-spezifische ACID-Implementierung
• IBM: ACID Properties - IBM-Dokumentation zu Transaktionseigenschaften