Transaktionen, ACID und Isolationsebenen

Was eine Transaktion verspricht

Eine Transaktion fasst mehrere Lese- und Schreibvorgänge zu einer Einheit zusammen, die entweder vollständig wirksam wird (Commit) oder gar nicht (Abbruch und Rollback). Kapitel 0 hat die Idee mit einer Banküberweisung eingeführt. In diesem Abschnitt geht es um den Teil, den die meisten Entwicklungsteams missverstehen: was passiert, wenn viele Transaktionen gleichzeitig laufen, welche Garantien Datenbanken wirklich geben und wie man wählt. Die Beispiele verwenden SQL, aber die Überlegungen gelten für jeden Speicher, der Transaktionen anbietet.

Transaktionen sind architektonisch wichtig, weil sie entscheiden, wo sich Geschäftsregeln günstig durchsetzen lassen. Innerhalb einer Datenbank kann eine Transaktion mit wenigen Zeilen Code ein Kontobuch ausgeglichen halten oder verhindern, dass ein Tisch doppelt gebucht wird. Über Services hinweg gibt es kein solches Werkzeug, weshalb Datenhoheit und Sagas so wichtig sind. Wer genau weiß, was eine einzelne Datenbank garantiert, weiß auch, welche Regeln innerhalb der Grenze eines einzigen Eigentümers liegen sollten.

ACID im Detail

ACID wurde 1983 von Theo Härder und Andreas Reuter geprägt, aufbauend auf früheren Arbeiten von Jim Gray. Jeder Buchstabe ist enger gefasst, als er klingt. Atomarität betrifft Fehler, nicht Nebenläufigkeit: Geht unterwegs etwas schief (ein Absturz, eine Constraint-Verletzung, ein Deadlock, die Anwendung entscheidet sich zum Abbruch), wird jede bis dahin vorgenommene Änderung rückgängig gemacht, sodass die Anwendung gefahrlos wiederholen kann. Abbrechbarkeit wäre ein treffenderer Name.

Konsistenz bedeutet, dass eine Transaktion die Datenbank von einem gültigen Zustand in einen anderen überführt, wobei gültig heißt, dass Ihre Invarianten gelten: Soll gleich Haben, der Bestand ist nie negativ, jede Bestellung hat einen Kunden. Manche Invarianten kann die Datenbank selbst durchsetzen (Schlüssel, Fremdschlüssel, CHECK-Constraints, eindeutige Indizes), die meisten aber sind Geschäftsregeln, die nur die Transaktionen der Anwendung einhalten. Konsistenz ist daher eine Eigenschaft davon, wie die Anwendung Atomarität und Isolation nutzt, nicht etwas, das die Datenbank allein liefert. Sie hat auch nichts mit dem C in CAP zu tun, das Linearisierbarkeit bedeutet (Kapitel 6).

Isolation bedeutet, dass gleichzeitig laufende Transaktionen einander nicht stören. In ihrer strengsten Form, der Serialisierbarkeit, ist das Ergebnis nebenläufig ausgeführter Transaktionen dasselbe, als wären sie in irgendeiner Reihenfolge nacheinander gelaufen. Schwächere Ebenen erlauben im Tausch gegen Performance eine gewisse Beeinflussung, und der Rest dieses Abschnitts handelt genau davon, welche. Dauerhaftigkeit bedeutet, dass die Daten Abstürze überstehen, sobald ein Commit bestätigt ist. Datenbanken auf einem Knoten erreichen das mit einem Write-Ahead-Log, das auf die Platte geschrieben wird, bevor der Commit zurückkehrt; replizierte Datenbanken fügen Kopien auf anderen Maschinen hinzu. Dauerhaftigkeit ist nie absolut: Eine Platte kann ein Flush nur vortäuschen, und asynchrone Replikation kann die letzten bestätigten Schreibvorgänge verlieren, wenn der Leader ausfällt (siehe Replikation).

Was ohne Isolation schiefgeht

Nebenläufigkeitsfehler sind schwer zu finden, weil sie vom Timing abhängen: Sie bestehen jeden Test auf einem ruhigen Entwicklerrechner und tauchen zur Spitzenzeit am Abend auf. Am klarsten versteht man Isolationsebenen über die konkreten Anomalien (auch Phänomene genannt), die sie zulassen oder verhindern. Das Lost Update unten ist im Geschäftscode die häufigste.

Die Isolationsebenen des SQL-Standards

Der SQL-Standard (ab SQL-92) definiert vier Isolationsebenen danach, welche von drei Phänomenen sie verbieten: Dirty Reads, Non-Repeatable Reads und Phantome. Der Standard macht Serializable zur Voreinstellung, doch kaum ein gängiges Produkt hält sich daran; die meisten verwenden aus Performancegründen standardmäßig Read Committed oder Repeatable Read.

1995 veröffentlichten Hal Berenson, Phil Bernstein, Jim Gray, Jim Melton, Elizabeth O'Neil und Patrick O'Neil A Critique of ANSI SQL Isolation Levels. Sie zeigten, dass die englischsprachigen Definitionen des Standards mehrdeutig waren, dass das Verbot der drei Phänomene allein noch keine Serialisierbarkeit ergibt und dass die Ebenen des Standards die Isolationsebenen realer Produkte nicht beschrieben. Sie ergänzten Phänomene, die der Standard übersehen hatte, namentlich Dirty Write, Lost Update, Read Skew und Write Skew, und definierten Snapshot Isolation: Jede Transaktion liest aus einem konsistenten Snapshot der festgeschriebenen Daten zum Zeitpunkt ihres Starts, und eine Transaktion kann keinen Schreibvorgang auf eine Zeile festschreiben, die eine nebenläufige Transaktion bereits geändert und festgeschrieben hat (First Committer Wins). Snapshot Isolation verhindert Dirty Reads, Non-Repeatable Reads, Read Skew und Lost Updates sowie die Phantome, die Lesevorgänge betreffen, lässt aber Write Skew zu und ist daher nicht serialisierbar. Sie passt nur schlecht zwischen die Ebenen des Standards, weshalb Produkte sie unterschiedlich benennen.

MVCC: wie Snapshots funktionieren

Die meisten modernen Datenbanken setzen Snapshot-Lesevorgänge mit Multi-Version Concurrency Control (MVCC) um. Statt eine Zeile an Ort und Stelle zu überschreiben, erzeugt ein Schreibvorgang eine neue Version, die mit der Kennung der schreibenden Transaktion versehen ist, und die alte Version bleibt erhalten, bis keine laufende Transaktion sie mehr brauchen kann. Jeder Leser erhält einen Snapshot, im Wesentlichen eine Liste der Transaktionen, die bei seinem Start festgeschrieben waren, und sieht nur die Versionen, die diese Transaktionen erzeugt haben. Der große Vorteil: Leser warten nie auf Schreiber und Schreiber nie auf Leser; nur zwei Schreiber auf dieselbe Zeile geraten in Konflikt.

Der Preis ist Aufräumarbeit. Alte Versionen müssen entfernt werden: PostgreSQL hält sie in der Tabelle und entfernt sie mit Vacuum, Oracle und MySQL InnoDB halten Before-Images in Undo-Logs. Eine stundenlang offene Transaktion hält alte Versionen fest, sodass Tabellen und Undo-Logs anwachsen und die Performance sinkt. Lang laufende Transaktionen sind daher in jeder MVCC-Datenbank ein betriebliches Warnsignal und ein Grund, analytische Abfragen von der operativen Datenbank fernzuhalten. Unter Read Committed mit MVCC erhält jede Anweisung einen frischen Snapshot; bei Snapshot Isolation verwendet die ganze Transaktion einen einzigen.

Echte Standardwerte und warum die Namen in die Irre führen

Namen von Isolationsebenen sind nicht portabel. Dasselbe Wort kann in verschiedenen Produkten unterschiedliche Garantien bedeuten, und die Standardwerte unterscheiden sich. Martin Kleppmanns Projekt Hermitage hat das tatsächliche Verhalten vieler Datenbanken gegen die obigen Anomalien getestet; die Herstellerdokumentation bestätigt die Standardwerte. Betrachten Sie diese Tabelle als Ausgangspunkt und prüfen Sie die Dokumentation der Version, die Sie betreiben.

Serialisierbarkeit erreichen

Datenbanken mit echter Serialisierbarkeit verwenden eine von drei Techniken. Tatsächlich serielle Ausführung lässt Transaktionen nacheinander auf einem einzigen Thread laufen, was schnell ist, wenn jede Transaktion kurz ist und die Daten im Arbeitsspeicher liegen (VoltDB sowie Redis-Skripte und -Transaktionen arbeiten so). Two-Phase Locking (2PL), verwendet von den Serializable-Ebenen von SQL Server und MySQL, lässt Leser gemeinsame Sperren und Schreiber exklusive Sperren nehmen, einschließlich Bereichssperren gegen Phantome, und hält sie bis zum Ende der Transaktion; das ist korrekt, aber Leser und Schreiber blockieren einander, der Durchsatz sinkt bei Konkurrenz, und Deadlocks sind häufig. Serializable Snapshot Isolation (SSI), 2008 von Michael Cahill, Uwe Röhm und Alan Fekete beschrieben und in PostgreSQL seit Version 9.1 verwendet (CockroachDB nutzt eine verwandte optimistische Technik), führt Transaktionen ohne Blockieren auf Snapshots aus, verfolgt Lese-Schreib-Abhängigkeiten zwischen ihnen und bricht eine Transaktion ab, wenn ein gefährliches Muster auftritt.

Welche Technik auch verwendet wird: Serialisierbare Transaktionen können mit einem Serialisierungsfehler (SQLSTATE 40001 in PostgreSQL und CockroachDB) oder einem Deadlock scheitern, und die Anwendung muss die ganze Transaktion wiederholen. Das sind die versteckten Kosten der stärksten Ebene: Jeder transaktionale Codepfad braucht eine Wiederholungsschleife, die gefahrlos wiederholbar ist, also keine Nebenwirkungen wie den Versand von E-Mails oder Aufrufe von Zahlungsanbietern innerhalb der Transaktion.

Pessimistische und optimistische Nebenläufigkeitskontrolle

In der Praxis laufen die meisten Anwendungen mit Read Committed oder Repeatable Read und schützen bestimmte Read-Modify-Write-Pfade explizit. Dafür gibt es drei Werkzeuge. Das beste, wenn möglich, ist ein atomares Update, bei dem die Datenbank Rechnung und Prüfung in einer Anweisung erledigt, etwa UPDATE accounts SET balance = balance - 30 WHERE id = 7 AND balance >= 30, und bei dem man danach prüft, dass genau eine Zeile geändert wurde. Unter Read Committed in PostgreSQL lässt ein nebenläufiges Update die zweite Anweisung warten und ihre Bedingung dann gegen die neue Zeile neu auswerten, sodass kein Update verloren geht.

Braucht die Entscheidung Logik, die die Datenbank nicht ausdrücken kann, verwenden Sie pessimistisches Sperren: Sperren Sie die gelesenen Zeilen mit SELECT ... FOR UPDATE, sodass nebenläufige Transaktionen, die sie brauchen, bis zu Ihrem Commit warten. Das ist einfach und passt zu kurzen, stark umkämpften Operationen (einen Kurier einer Bestellung zuweisen). Die Kosten sind Wartezeit, das Risiko von Deadlocks (sperren Sie Zeilen in einer festen Reihenfolge, etwa nach aufsteigender id) und geringerer Durchsatz. Varianten sind NOWAIT, das sofort scheitert, statt zu warten, und SKIP LOCKED, das bereits gesperrte Zeilen überspringt und der übliche Weg ist, eine zuverlässige Job-Queue auf einer relationalen Tabelle zu bauen.

BEGIN;
-- Lock the row: other FOR UPDATE readers and writers must wait
SELECT balance FROM accounts WHERE id = 7 FOR UPDATE;
-- application checks: balance (100) >= 30, so allow it
UPDATE accounts SET balance = 70 WHERE id = 7;
INSERT INTO ledger (account_id, amount, kind)
  VALUES (7, -30, 'withdrawal');
COMMIT;  -- lock released; the waiting transaction now sees 70

Optimistische Nebenläufigkeitskontrolle nimmt keine Sperren, während der Nutzer oder der Code nachdenkt. Jede Zeile trägt eine Versionsnummer (oder einen Zeitstempel oder Hash). Der Schreiber ändert nur, wenn die Version noch die gelesene ist, und erhöht sie. Ändert sich keine Zeile, war jemand anderes schneller, und die Anwendung lädt neu und wiederholt oder informiert den Nutzer. Das passt zu Daten mit wenig Konkurrenz und langer Denkzeit: Eine Restaurantleiterin, die fünf Minuten lang im Browser eine Speisekarte bearbeitet, darf nicht so lange eine Datenbanksperre halten. HTTP hat dieselbe Idee eingebaut, mit ETags und dem Header If-Match.

-- Read (no lock); remember version = 12
SELECT id, name, price, version FROM menu_items WHERE id = 501;

-- Later, write only if the version is unchanged
UPDATE menu_items
   SET price = 11.00, version = version + 1
 WHERE id = 501 AND version = 12;

-- Rows affected = 1: success.
-- Rows affected = 0: a concurrent edit won; reload and retry
-- or show the user the other change.

Eine Isolationsstrategie wählen

Es gibt nicht die eine richtige Ebene; es gibt eine richtige Ebene für jedes Stück Logik. Ein praktischer Ansatz geht von den Invarianten aus, nicht von den Einstellungen.

Als Faustregel ist Read Committed mit expliziten Sperren oder Versionsprüfungen für die meisten Geschäftsanwendungen eine solide, schnelle Voreinstellung, sofern das Team diszipliniert nach Read-Modify-Write-Pfaden sucht. Serializable ist die sicherere Voreinstellung, wenn die Regeln komplex sind, das Team groß ist oder eine verletzte Invariante teuer wird (Geld, Medizin, Betriebssicherheit), und viele Teams setzen es inzwischen für die kritischen Pfade ein und nehmen Wiederholungen in Kauf. Hier sind sich Fachleute wirklich uneinig: Manche argumentieren, dass Serializable als Voreinstellung eine ganze Klasse von Fehlern verhindert, die kein Code-Review je findet; andere argumentieren, dass seine Wiederholungen und seine Konkurrenz um Ressourcen zu viel kosten und dass explizite Sperren die Absicht sichtbar machen. Beide Positionen sind vertretbar, wenn die Wahl bewusst getroffen und getestet ist.