ACID

In computer science, ACID (atomicity, consistency, isolation, durability) is a set of properties of database transactions intended to guarantee data validity despite errors, power failures, and other mishaps. For example, a transfer of funds from one bank account to another, involving multiple changes such as debiting one account and crediting another, is a single transaction.

In 1983,^[1]Andreas Reuter and Theo Härder coined the acronym ACID, building on earlier work by Jim Gray^[2] who named atomicity, consistency, and durability, but not isolation, when characterizing the transaction concept. These four properties are the major guarantees of the transaction paradigm, which has influenced many aspects of development in database systems.

According to Gray and Reuter, the IBM Information Management System supported ACID transactions as early as 1973 (although the acronym was created later).^[3]

BASE steht für „ basically available , soft state, and everually consistent“ (grundsätzlich verfügbar, stabil und letztendlich konsistent ) : Das Akronym verdeutlicht, dass BASE das Gegenteil von ACID ist , analog zu den chemischen Entsprechungen Säure und Base . ACID-Datenbanken priorisieren Konsistenz vor Verfügbarkeit – die gesamte Transaktion schlägt fehl, wenn in einem beliebigen Schritt ein Fehler auftritt. Im Gegensatz dazu priorisieren BASE-Datenbanken Verfügbarkeit vor Konsistenz : Anstatt die Transaktion abzubrechen, können Benutzer vorübergehend auf inkonsistente Daten zugreifen : Datenkonsistenz wird erreicht, jedoch nicht sofort . Eine Datenbank tendiert entweder zu ACID oder zu BASE, kann aber nicht beides sein (gemäß dem CAP-Theorem ). Beispielsweise basieren SQL- Datenbanken (wie MySQL , PostgreSQL , AWS Redshift ) auf dem ACID-Modell, während NoSQL -Datenbanken (wie DynamoDB ^{[ 4 ]} oder MongoDB ) die BASE-Architektur verwenden. Einige NoSQL-Datenbanken können jedoch bestimmte ACID-Merkmale aufweisen. ^{[ 5 ]}

Die von Reuter und Härder definierten Merkmale dieser vier Eigenschaften sind folgende:

Transaktionen bestehen oft aus mehreren Anweisungen . Die Atomarität garantiert, dass jede Transaktion als eine einzige Einheit behandelt wird, die entweder vollständig erfolgreich ist oder vollständig fehlschlägt: Schlägt eine der Anweisungen einer Transaktion fehl, schlägt die gesamte Transaktion fehl und die Datenbank bleibt unverändert. Ein atomares System muss die Atomarität in jeder Situation gewährleisten, einschließlich Stromausfällen, Fehlern und Systemabstürzen. ^{[ 6 ]} Die Garantie der Atomarität verhindert, dass Datenbankaktualisierungen nur teilweise erfolgen, was größere Probleme verursachen kann als die vollständige Ablehnung der gesamten Transaktionsfolge. Folglich kann ein anderer Datenbankclient nicht beobachten, ob die Transaktion noch läuft. Zum einen ist sie noch nicht abgeschlossen, zum nächsten Zeitpunkt ist sie bereits vollständig ausgeführt (oder es ist nichts passiert, falls die Transaktion abgebrochen wurde).

Konsistenz gewährleistet, dass eine Transaktion die Datenbank nur von einem konsistenten Zustand in einen anderen überführen kann und dabei Datenbankinvarianten bewahrt : Alle in die Datenbank geschriebenen Daten müssen gemäß allen definierten Regeln gültig sein, einschließlich Einschränkungen , Kaskaden , Triggern und beliebigen Kombinationen davon. Dies verhindert die Beschädigung der Datenbank durch eine unzulässige Transaktion. Ein Beispiel für eine Datenbankinvariante ist die referenzielle Integrität , die die Beziehung zwischen Primärschlüssel und Fremdschlüssel garantiert . ^{[ 7 ]}

Transaktionen werden häufig parallel ausgeführt (z. B. lesen und schreiben mehrere Transaktionen gleichzeitig auf eine Tabelle). Die Isolation stellt sicher, dass die Datenbank nach der parallelen Ausführung von Transaktionen im selben Zustand verbleibt, der auch bei sequenzieller Ausführung der Transaktionen erreicht worden wäre. Isolation ist das Hauptziel der Parallelitätskontrolle ; je nach verwendetem Isolationsgrad sind die Auswirkungen einer unvollständigen Transaktion für andere Transaktionen möglicherweise nicht sichtbar. ^{[ 8 ]}

Die Dauerhaftigkeit gewährleistet, dass eine einmal abgeschlossene Transaktion auch im Falle eines Systemausfalls (z. B. Stromausfall oder Absturz ) erhalten bleibt. Dies bedeutet üblicherweise, dass abgeschlossene Transaktionen (oder deren Auswirkungen) im nichtflüchtigen Speicher gespeichert werden . ^{[ 9 ]}

Die folgenden Beispiele veranschaulichen die ACID-Eigenschaften. In diesen Beispielen hat die Datenbanktabelle zwei Spalten, A und B. Eine Integritätsbedingung erfordert, dass die Summe der Werte in A und B 100 ergibt. Der folgende SQL- Code erstellt eine Tabelle wie oben beschrieben:

CREATE TABLE acidtest ( A INTEGER , B INTEGER , CHECK ( A + B = 100 ));

Atomarität garantiert, dass eine Reihe von Datenbankoperationen in einer atomaren Transaktion entweder vollständig ausgeführt wird (erfolgreiche Operation) oder keine (fehlgeschlagene Operation). Die Operationen können nicht in einzelne Teile aufgeteilt werden, wodurch die Reihe unteilbar wird. Die Atomaritätsgarantie verhindert, dass Datenbankaktualisierungen nur teilweise erfolgen, was größere Probleme verursachen kann als die vollständige Ablehnung der gesamten Reihe. Anders ausgedrückt: Atomarität bedeutet Unteilbarkeit und Unreduzierbarkeit. ^{[ 10 ]} Alternativ kann man sagen, dass eine logische Transaktion aus mehreren physischen Transaktionen bestehen kann. Solange nicht alle physischen Teiltransaktionen ausgeführt sind, ist die logische Transaktion nicht abgeschlossen.

Ein Beispiel für eine atomare Transaktion ist eine Geldüberweisung von Bankkonto A auf Konto B. Sie besteht aus zwei Operationen: der Abbuchung des Geldes von Konto A und der Einzahlung auf Konto B. Wir möchten nicht, dass der Betrag von Konto A abgebucht wird, bevor wir sicher sind, dass er auch auf Konto B überwiesen wurde. Die Durchführung dieser Operationen in einer atomaren Transaktion gewährleistet, dass die Datenbank in einem konsistenten Zustand bleibt , d. h., Geld wird weder belastet noch gutgeschrieben, wenn eine dieser beiden Operationen fehlschlägt. ^{[ 11 ]}

Konsistenz ist ein sehr allgemeiner Begriff, der verlangt, dass die Daten alle Validierungsregeln erfüllen. Im vorherigen Beispiel ist die Validierung die Anforderung, dass A + B = 100 gilt . Alle Validierungsregeln müssen geprüft werden, um Konsistenz zu gewährleisten. Angenommen, eine Transaktion versucht, 10 von A zu subtrahieren , ohne B zu verändern . Da die Konsistenz nach jeder Transaktion geprüft wird, ist bekannt, dass A + B = 100 gilt , bevor die Transaktion beginnt. Wenn die Transaktion 10 erfolgreich von A subtrahiert , ist Atomarität erreicht. Eine Validierungsprüfung zeigt jedoch, dass A + B = 90 gilt, was nicht mit den Datenbankregeln übereinstimmt. Die gesamte Transaktion muss abgebrochen und die betroffenen Zeilen auf ihren Zustand vor der Transaktion zurückgesetzt werden. Hätten weitere Einschränkungen, Trigger oder Kaskaden bestanden, wäre jede einzelne Änderungsoperation vor dem Commit der Transaktion auf die gleiche Weise wie oben geprüft worden. Ähnliche Probleme können bei anderen Einschränkungen auftreten. Beispielsweise könnten wir die Datentypen von A und B als Ganzzahlen festgelegt haben. Wenn wir beispielsweise den Wert 13,5 für A eingeben , wird die Transaktion abgebrochen, oder das System gibt eine Warnung in Form eines Triggers aus (sofern dieser entsprechend konfiguriert wurde). Ein weiteres Beispiel wären Integritätsbedingungen, die es uns nicht erlauben, eine Zeile in einer Tabelle zu löschen, deren Primärschlüssel von mindestens einem Fremdschlüssel in anderen Tabellen referenziert wird.

Um die Isolation zu demonstrieren, gehen wir davon aus, dass zwei Transaktionen gleichzeitig ausgeführt werden und jeweils versuchen, dieselben Daten zu ändern. Eine der beiden Transaktionen muss warten, bis die andere abgeschlossen ist, um die Isolation aufrechtzuerhalten.

Betrachten wir zwei Transaktionen:

• T ₁ überträgt 10 von A nach B.
• T ₂ überträgt 20 von B nach A.

Insgesamt ergeben sich vier Aktionen:

1. T ₁ subtrahiert 10 von A.
2. T ₁ addiert 10 zu B.
3. T ₂ subtrahiert 20 von B.
4. T ₂ addiert 20 zu A.

Werden diese Operationen der Reihe nach ausgeführt, bleibt die Isolation erhalten, obwohl T2 _warten muss. Was passiert, wenn T1 _mittendrin ausfällt? Die Datenbank eliminiert die Auswirkungen von T1, und T2 _{sieht nur} noch gültige Daten.

Durch die Verschachtelung der Transaktionen könnte die tatsächliche Reihenfolge der Aktionen wie folgt aussehen:

1. T ₁ subtrahiert 10 von A.
2. T ₂ subtrahiert 20 von B.
3. T ₂ addiert 20 zu A.
4. T ₁ addiert 10 zu B.

Betrachten wir erneut, was passiert, wenn Transaktion T1 _in Schritt 4 beim Ändern von B fehlschlägt. Zum Zeitpunkt des Fehlschlags von T1 hat Transaktion T2 _{A bereits geändert; es kann nicht auf den Wert vor T1} zurückgesetzt werden, ohne eine ungültige Datenbank zu hinterlassen. Dies wird als Schreibkonflikt bezeichnet ^{[ 12 ]} , da zwei Transaktionen versucht haben, in dasselbe Datenfeld zu schreiben. In einem typischen System würde das Problem behoben, indem zum letzten bekannten fehlerfreien Zustand zurückgekehrt, die fehlgeschlagene Transaktion T1 abgebrochen _und die unterbrochene Transaktion T2 vom fehlerfreien Zustand aus neu gestartet _wird .

Betrachten wir eine Transaktion, die 10 von A nach B überträgt. Zuerst werden 10 von A abgebucht, dann 10 zu B addiert. Dem Benutzer wird nun mitgeteilt, dass die Transaktion erfolgreich war. Die Änderungen befinden sich jedoch noch im Festplattenpuffer und warten darauf, auf die Festplatte geschrieben zu werden. Bei einem Stromausfall gehen die Änderungen verloren, aber der Benutzer geht (verständlicherweise) davon aus, dass die Änderungen erhalten bleiben.

Die Verarbeitung einer Transaktion erfordert oft eine Abfolge von Operationen, die aus verschiedenen Gründen fehlschlagen können. Beispielsweise kann der Speicherplatz auf den Festplatten erschöpft sein oder die zugewiesene CPU-Zeit aufgebraucht sein. Es gibt zwei gängige Verfahren: Write-Ahead-Logging und Shadow Paging . In beiden Fällen müssen Sperren für alle zu aktualisierenden Informationen und – je nach Isolationsgrad – gegebenenfalls auch für alle lesbaren Daten gesetzt werden. Beim Write-Ahead-Logging wird die Datenbeständigkeit gewährleistet, indem die geplante Änderung vor der Änderung der Datenbank in ein persistentes Protokoll geschrieben wird. Dadurch kann die Datenbank im Falle eines Absturzes in einen konsistenten Zustand zurückkehren. Beim Shadow Paging werden Aktualisierungen auf eine Teilkopie der Datenbank angewendet, die beim Commit der Transaktion aktiviert wird.

Viele Datenbanken nutzen Sperren, um die ACID-Eigenschaften zu gewährleisten. Sperren bedeutet, dass eine Transaktion die von ihr verwendeten Daten markiert, sodass das Datenbankmanagementsystem (DBMS) anderen Transaktionen den Zugriff darauf verwehrt, bis die erste Transaktion erfolgreich abgeschlossen oder fehlgeschlagen ist. Die Sperre muss stets vor der Datenverarbeitung erworben werden, auch vor Daten, die zwar gelesen, aber nicht verändert werden. Komplexe Transaktionen erfordern typischerweise eine große Anzahl von Sperren, was zu erheblichem Mehraufwand führt und andere Transaktionen blockiert. Führt beispielsweise Benutzer A eine Transaktion aus, die eine Datenzeile lesen muss, die Benutzer B ändern möchte, muss Benutzer B warten, bis die Transaktion von Benutzer A abgeschlossen ist. Um vollständige Isolation zu gewährleisten, wird häufig die Zwei-Phasen-Sperre eingesetzt.

Eine Alternative zu Sperren ist die Versionskontrolle (VCC) . Dabei stellt die Datenbank jeder lesenden Transaktion die vorherige, unveränderte Version der Daten bereit, die gerade von einer anderen aktiven Transaktion geändert werden. Dadurch können Leser arbeiten, ohne Sperren zu erwerben, d. h. Schreibtransaktionen blockieren keine Lesetransaktionen und umgekehrt. Um auf das Beispiel zurückzukommen: Wenn die Transaktion von Benutzer A Daten anfordert, die Benutzer B gerade ändert, stellt die Datenbank A die Version dieser Daten bereit, die beim Start der Transaktion von Benutzer B existierte. Benutzer A erhält somit eine konsistente Sicht auf die Datenbank, selbst wenn andere Benutzer Daten ändern. Eine Implementierung, die sogenannte Snapshot-Isolation , lockert diese Isolationseigenschaft.

Die Gewährleistung der ACID-Eigenschaften in einer verteilten Transaktion über eine verteilte Datenbank hinweg, in der kein einzelner Knoten für alle transaktionsrelevanten Daten verantwortlich ist, birgt zusätzliche Komplikationen. Netzwerkverbindungen können ausfallen, oder ein Knoten kann seinen Teil der Transaktion erfolgreich abschließen und muss seine Änderungen aufgrund eines Fehlers auf einem anderen Knoten rückgängig machen. Das Zwei-Phasen-Commit-Protokoll (nicht zu verwechseln mit Zwei-Phasen-Sperren ) gewährleistet die Atomarität verteilter Transaktionen , indem es sicherstellt, dass alle Teilnehmer der Transaktion zustimmen, ob die Transaktion abgeschlossen werden soll oder nicht. ^{[ 13 ]} Kurz gesagt: In der ersten Phase fragt ein Knoten (der Koordinator) die anderen Knoten (die Teilnehmer) ab, und erst wenn alle ihre Bereitschaft signalisiert haben, formalisiert der Koordinator in der zweiten Phase die Transaktion.

• Eventuelle Konsistenz (BASE: im Grunde verfügbar)
• CAP-Theorem
• Gleichzeitigkeitskontrolle
• Java Transaction API
• Offene Systemverbindungen
• Transaktionales NTFS
• Zwei-Phasen-Commit-Protokoll
• Dreck