Begriff
ACID
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Das Versprechen einer klassischen Datenbank (SQL): "Deine Daten sind heilig." Es steht für 4 Eigenschaften einer Transaktion (z. B. Geldüberweisung):
- Atomicity (Ganz oder gar nicht): Entweder Geld ist weg UND da, oder nichts passiert. Kein halber Zustand.
- Consistency (Gültigkeit): Die DB verletzt nie Regeln (z. B. "Kontostand darf nicht negativ sein").
- Isolation (Abschottung): Wenn zwei Leute gleichzeitig buchen, kommen sie sich nicht in die Quere.
- Durability (Dauerhaftigkeit): Wenn die DB "OK" sagt, ist das Geld sicher (auch bei Stromausfall).
Merksatz: Ein Akronym für Atomicity, Consistency, Isolation und Durability; die vier Schlüsseleigenschaften, die Transaktionen in relationalen Datenbanken zuverlässig und sicher machen.
BEGIN TRANSACTION;
UPDATE konto SET stand = stand - 100 WHERE id = 1;
UPDATE konto SET stand = stand + 100 WHERE id = 2;
COMMIT;
Das Datenbanksystem (PostgreSQL, MySQL InnoDB) garantiert ACID.
NoSQL-Datenbanken (MongoDB früher, Cassandra) opfern oft ACID für Geschwindigkeit (BASE).
1. Isolation Levels (Das "I")
Der schwierigste Teil. Echte "Serializable" Isolation ist langsam. Deshalb bieten DBs schwächere Level:
- Read Committed: Du siehst keine unfertigen Schreibvorgänge (Standard in PostgreSQL).
- Repeatable Read: Wenn du zweimal liest, siehst du das gleiche (Phantom Reads möglich).
- Snapshot Isolation: Du siehst eine Momentaufnahme der DB beim Start der Transaktion (MVCC).
2. Implementation
- A & D: Durch WAL (Write-Ahead Logging).
- I: Durch Locks (2PL) oder MVCC (Multi-Version Concurrency Control).
- C: Durch Constraints (Foreign Keys, Checks) und Trigger.
1. CAP Theorem vs. PACELC
Das ACID-Modell ist wunderbar auf Single-Node-Systemen. In skalierenden, verteilten Systemen schlägt das CAP-Theorem hart zu (Consistency, Availability, Partition Tolerance — wähle zwei). PACELC baut tiefgreifender darauf auf: If Partition (P), how does the system trade off Availability and Consistency (A and C); Else (E), when running normally, how does it trade off Latency and Consistency (L and C)? Selbst PostgreSQL im synchronen Replika-Modus leidet sofort unter immensen Latenzproblemen (L), weil der WAL (Write-Ahead Log) erst physisch auf der Disk des Standby-Servers bestätigt (C) sein muss, bevor der Commit durchgeht.
2. Jepsen Tests & Anomalien
Es herrschen massive Missverständnisse zu "Isolation Levels". Serializable (höchstes Isolation Level) verhindert die sogenannten klassischen Anomalien (Dirty Reads, Non-Repeatable Reads, Phantoms). Aber verteilt laufende Systeme leiden unter weit komplexeren Problemen: Write Skew, Read Skew oder Lost Updates. Kyle Kingsbury hat mit Jepsen (einem Clojure-basierten Framework) jahrelang etliche "ACID-compliant" und "Linearizable" Datenbanken zerlegt. Er injiziert mittels Chaos Engineering Network Partitions, Clock Skews und node crashes in einen Cluster. Das erschreckende Resultat: Viele moderne Datenbanken hielten unter echten Störfällen ihre eigenen Isolation-Versprechen absolut nicht ein.
3. Calvin und deterministische Transaktionen
Eine architektonische Meisterleistung, um ACID skalierbar zu machen, ist das Calvin-Protokoll (FaunaDB etc.). Klassischerweise laufen Transaktionen an und cachen Locks. Bei Konflikten kommt es zum Deadlock oder Rollback-Stürmen. Calvin ändert das: Transaktionen werden vorkompiliert und durchlaufen eine strikte Deterministik-Sequenz (eine Art global orchestriertes Log). Da jede Node 100% vorhersagbar weiß, in welcher Reihenfolge die Inputs kommen und da Code deterministisch ist, braucht niemand mehr Locks. So erreicht man fehlerfreie, lineare Serialisierbarkeit mit brutal hohem Durchsatz ("Calvin: Fast Distributed Transactions for Partitioned Database Systems", Thomson et al., 2012).
Quick-Check
Gegenteil?
BASE (Basically Available, Soft state, Eventual consistency). Das Modell von NoSQL. Flexibler, aber riskanter.Banken?
Brauchen zwingend ACID. Du willst nicht, dass Geld verschwindet, weil der Server abstürzt.Ist MongoDB ACID?
Seit Version 4.0 ja (Multi-Document Transactions). Aber mit Performance-Kosten.