3.1 Entstehung von ACID
Die Abkürzung ACID tauchte erstmals 1983 in einem Artikel von Theo Haerder und Andreas Reuter auf. Um den Text zu vereinfachen und überzeugender zu machen, werde ich einen Teil dieses Artikels übersetzen (mit leichten Kürzungen). Dieser Ausschnitt verwendet ein Beispiel einer Banktransaktion, bei der Geld von einem Konto auf ein anderes überwiesen wird.
Das Konzept einer Transaktion, die im Beispiel alle Interaktionen mit der Datenbank zwischen $BEGIN_TRANSACTIONund umfasst $COMMIT_TRANSACTION, erfordert, dass alle Aktionen untrennbar ausgeführt werden: Entweder werden alle Aktionen ordnungsgemäß im Status der Datenbank widergespiegelt, oder es passiert nichts. $COMMIT_TRANSACTIONWenn der Benutzer zu irgendeinem Zeitpunkt vor dem Erreichen eine Anweisung eingibt, die Folgendes ERRORenthält $RESTORE_TRANSACTION, werden keine Änderungen in der Datenbank widergespiegelt.
Um diese Unteilbarkeit zu erreichen, muss eine Transaktion die folgenden vier Eigenschaften haben:
Atomizität (Atomizität). Die Transaktion muss vom oben beschriebenen Alles-oder-Nichts-Typ sein, und egal was passiert, der Benutzer muss wissen, in welchem Zustand sich die Transaktion befindet.
Konsistenz (Konsistenz). Eine Transaktion, die ihr normales Transaktionsende (EOT) erreicht und dadurch ihre Ergebnisse festschreibt, behält die Datenbankkonsistenz bei. Mit anderen Worten: Jede erfolgreiche Transaktion liefert per Definition nur gültige Ergebnisse. Diese Bedingung ist notwendig, um die vierte Eigenschaft – Haltbarkeit – zu unterstützen.
Isolation (Isolation). Ereignisse, die innerhalb einer Transaktion auftreten, müssen vor anderen gleichzeitig ausgeführten Transaktionen verborgen bleiben. Wenn diese Bedingung nicht erfüllt wäre, wäre es aus den oben genannten Gründen unmöglich, die Transaktion zu ihrem Anfang zurückzukehren. Um eine Isolation zu erreichen, werden Methoden namens Synchronisation verwendet ...
Haltbarkeit (Haltbarkeit). Sobald eine Transaktion abgeschlossen ist und ihre Ergebnisse in die Datenbank übertragen wurden, muss das System sicherstellen, dass diese Ergebnisse alle nachfolgenden Fehler überdauern. Da es keinen Kontrollbereich gibt, der mehrere Transaktionsmengen umfasst, hat das Datenbankverwaltungssystem (DBMS) keine Kontrolle über die Grenzen von Transaktionen hinaus.
Daher muss dem Benutzer gewährleistet sein, dass, wenn das System ihn darüber informiert, dass etwas passiert ist, dieses „Etwas“ tatsächlich passiert ist. Da per Definition jede (erfolgreich abgeschlossene - S.K.) Transaktion korrekt ist, können die Ergebnisse zwangsläufig auftretender fehlerhafter Transaktionen (d. h. Transaktionen mit fehlerhaften Daten) nur durch die entsprechende „Gegen“-Transaktion (Gegentransaktion) beseitigt werden.
3.2 Die Entstehung von Transaktionen
Diese vier Eigenschaften – Atomizität, Konsistenz, Isolation und Haltbarkeit (ACID) – beschreiben die Kernmerkmale des Transaktionsparadigmas, die viele Aspekte des Datenbanksystemdesigns beeinflussen. Daher glauben wir, dass die Fähigkeit eines Systems, Transaktionen zu unterstützen, der Prüfstein (ACID-Test) für die Qualität dieses Systems ist.
Ein einfaches PL/1-SQL-Programm, das Gelder von einem Konto auf ein anderes überweist.
FUNDS_TRANSFER. PROCEDURE,
$BEGIN_TRANSACTION;
ON ERROR DO; /* in case of error */
$RESTORE_TRANSACTION, /* undo all work */
GET INPUT MESSAGE; /* reacquire input */
PUT MESSAGE ('TRANSFER FAILED'); /* report failure */
GO TO COMMIT;
END;
GET INPUT MESSAGE; /* get and parse input */
EXTRACT ACCOUNT_EBIT, ACCOUNT_CREDIT,
AMOUNT FROM MESSAGE,
$UPDATE ACCOUNTS /* do debit */
SET BALANCE ffi BALANCE - AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_DEBIT;
$UPDATE ACCOUNTS /* do credit */
SET BALANCE = BALANCE + AMOUNT
WHERE ACCOUNTS.NUMBER = ACCOUNT_CREDIT;
$INSERT INTO HISTORY /* keep audit trail */
<DATE, MESSAGE>;
PUT MESSAGE ('TRANSFER DONE'); /* report success */
COMMIT: /* commit updates */
$COMMIT_TRANSACTION;
END; /* end of program */Ich habe ein Beispiel dieses Codes bereitgestellt, um Sie daran zu erinnern, dass ACID-Eigenschaften tatsächlich einerseits als Anforderungen für jedes DBMS betrachtet werden können, das behauptet, Transaktionen zu unterstützen, und andererseits als Definition einer Transaktion in ein Datenbanksystem . Diese Definition steht voll und ganz im Einklang mit der weltlichen Praxis. Es ist beispielsweise schwer vorstellbar, dass ein Kunde, der eine Banktransaktion durchführt (sei es mit Hilfe eines echten Kassierers oder über Internetbanking), nicht erwartet, dass die Bank alle Eigenschaften von ACID erfüllt. Eine Bank, die ACID-Eigenschaften bei ihren Transaktionen nicht unterstützt, wird im besten Fall Kunden verlieren und im schlimmsten Fall bankrott gehen.
3.3 ACID-Konnektivität
Es ist sehr wichtig, dass die ACID-Eigenschaften untrennbar miteinander verbunden sind. Wenn Sie eine davon verwerfen, wird die verbleibende Kombination bedeutungslos. Insbesondere wenn wir die Konsistenzeigenschaft (in dem Sinne, wie sie im obigen Zitat verwendet wurde) verwerfen, verlieren wir das Kriterium für die Korrektheit einer Transaktion. Das Datenbanksystem kann nicht sinnvoll entscheiden, ob Transaktionen festgeschrieben werden dürfen oder nicht, und alle Überprüfungen der Korrektheit der im aktuellen Zustand der Datenbank durchgeführten Vorgänge müssen im Anwendungscode durchgeführt werden.
Sie müssen verstehen, dass es sich in diesem Fall um logische Konsistenz handelt. Der Kunde der Bank verlangt, dass die Bank nach den von ihm festgelegten und den Kunden bekannten Regeln arbeitet, so dass es unmöglich ist, eine Transaktion durchzuführen, die gegen diese Regeln verstößt, damit die nächste Transaktion desselben Kunden in einem ausgeführt wird Umgebung, die gemäß diesen Regeln vereinbart wurde.
Der Kunde des Online-Shops benötigt die rechtzeitige Lieferung der von ihm bestellten und bezahlten Ware (gemäß den festgelegten und dem Kunden bekannten Regeln). Sonst wird er diesem Laden nicht vertrauen. Gleichzeitig kümmert sich weder der Kunde der Bank noch der Kunde des Internetshops um die interne Küche des Unternehmens und darum, welche internen Maßnahmen ergriffen werden, um seine Transaktion abzuschließen. Dem Kunden ist es egal, wie die physische Konsistenz dieses Unternehmens aufrechterhalten wird und wie Vorgänge auf der physischen Ebene ausgeführt werden.
Wenn sich das DBMS um die Aufrechterhaltung der logischen Konsistenz von Transaktionen (und der Datenbank) kümmert, werden Anwendungen einfacher, verständlicher und zuverlässiger. Die gesamte Logik des Anwendungsbereichs (Bank, Filiale, Lager usw.) bezüglich Transaktionen und der Gültigkeit der Daten geht in das Datenbanksystem ein. Und die Anforderungen an dieses System sind sehr einfach: Unterstützung von ACID-Transaktionen unter Berücksichtigung der von der Anwendung bereitgestellten Konsistenzregeln in der Datenbank. Aus meiner Sicht stellt die Ablehnung von ACID-Transaktionen übermäßige Schwierigkeiten für Anwendungsentwickler dar, die, ob Sie wollen oder nicht, selbst etwas Ähnliches implementieren müssen, um die natürlichen Bedürfnisse ihrer Kunden zu befriedigen.
Und noch einmal stelle ich fest, dass die ACID-Eigenschaften tatsächlich das Konzept einer Transaktion definieren. Um zumindest eine Möglichkeit zu haben, von einem Transaktionsdatenmanagementsystem zu sprechen, in dem die Eigenschaft der Transaktionskonsistenz nicht unterstützt wird, ist es meiner Meinung nach unbedingt erforderlich, zu definieren, was in diesem Fall unter dem Begriff Transaktion zu verstehen ist.
Leider spricht man heute in vielen Fällen (dies ist insbesondere für die NoSQL-Richtung charakteristisch) von der Unterstützung von OLTP-Anwendungen, ohne überhaupt anzugeben, welche Art von Transaktionen damit gemeint sind. Daher werde ich in diesem Artikel die Kombination „ACID-Transaktion“ verwenden, um auf echte Transaktionen zu verweisen, und der nicht qualifizierte Begriff „ Transaktion “ wird in einem informellen Sinne verwendet, der in verschiedenen Kontexten unterschiedlich ist.
Befassen wir uns nun mit dem „Theorem“ von CAP und versuchen herauszufinden, was Konsistenz im Sinne von Brewer bedeutet.