Die Abkürzung ACID (Atomicity, Consistency, Isolation, Durability) ist ein Begriff aus der Datenbanktheorie und beschreibt Regeln und Vorgehensweisen bei Datenbanktransaktionen. Wenn die Vorgaben von ACID eingehalten werden, sind die Daten in einem System verlässlich und konsistent. Im Laufe des Artikels beleuchten wir neben ACID auch die Eigenschaften des CAP Theorems, die sich nicht nur mit Datenbanken, sondern mit verteilten Systemen beschäftigen. Außerdem beleuchten wir die Vorteile, die sich ergeben, wenn die ACID Eigenschaften erfüllt sind.

Wie lauten die A-C-I-D Grundprinzipien?

Klassische relationale Datenbanken erfüllen die vier ACID Eigenschaften. Diese besagen, dass die wichtigste Anforderung an eine Datenbank ist, den Wahrheitsgehalt und die Aussagekraft der Daten zu erhalten. In vielen Fällen werden Datenspeicher als „Single Point of Truth“ gesehen, somit wäre es fatal, wenn fehlerhafte Informationen gespeichert und weitergegeben werden. Die vier Eigenschaften umfassen die folgenden Punkte:

• Atomicity (A): Datentransaktionen, bspw. die Eintragung eines neuen Datensatzes oder das Löschen eines alten, sollen entweder ganz oder gar nicht ausgeführt werden. Für andere User ist die Transaktion erst sichtbar, wenn sie vollständig ausgeführt ist.
• Consistency (C): Diese Eigenschaft ist erfüllt, wenn jede Datentransaktion die Datenbank von einem konsistenten in einen konsistenten Zustand überführt.
• Isolation (I): Wenn mehrere Transaktionen gleichzeitig stattfinden, muss der Endzustand derselbe sein, als wenn die Transaktionen getrennt voneinander stattfinden würden. Das heißt die Datenbank sollte den Stresstest bestehen. Also nicht durch Überlastung zu falschen Datenbanktransaktionen kommen.
• Durability (D): Die Daten innerhalb der Datenbank dürfen sich nur durch eine Transaktion ändern und nicht durch äußere Einflüsse veränderbar sein. Ein Softwareupdate darf beispielsweise nicht versehentlich dazu führen, dass sich Daten ändern oder womöglich gelöscht werden.

Die Grundprinzipien am Beispiel

Das gängigste Beispiel, um die Komponenten von ACID zu veranschaulichen sind Banküberweisungen, bei denen Geld von einem Konto zum anderen transferiert wird. Das Ziel ist es natürlich, dass alle Überweisungen korrekt ablaufen und alle Kunden den Geldbetrag auf dem Konto haben, der ihnen zusteht.

Angenommen es findet eine Überweisung von Konto A auf Konto B statt. Die Atomarität beschreibt, dass Transaktionen entweder komplett ausgeführt werden oder komplett fehlschlagen. Für unser Beispiel bedeutet das, dass wenn Konto A mit dem Geldbetrag belastet wird und es dann zu einem Systemfehler kommt, das Geld dem Konto A einfach wieder gutgeschrieben wird. Würde das nicht passieren, hätten wir Geld vernichtet und das System wäre in einem falschen Zustand.

Der Konsistenz zur Folge muss nach jeder Transaktion festgestellt werden, dass die Datenbank weiterhin in einem konsistenten Zustand ist, also beispielsweise keine widersprüchlichen Daten enthält. Angenommen unsere Beispielbank führt eine Tabelle mit allen Konten und den aktuellen Guthabenbeträgen. In dieser Tabelle ist die Kontonummer ein Primärschlüssel, sodass jede Kontonummer nur einmal in der Datenbank vorkommen darf. Wenn nach einer fehlerhaften Datenbanktransaktion möglicherweise zwei Datensätze zu einer Kontonummer vorliegen, so liegt eine Inkonsistenz vor und die Transaktion muss rückgängig gemacht werden.

Die Isolation besagt, dass mehrere parallel laufende Transaktionen nicht zu anderen Ergebnissen führen darf, als wenn die Transaktionen einzeln und hintereinander stattfinden würden. Wenn also eine Bank während Peaks 100 Überweisungen gleichzeitig verarbeiten muss, dann muss sichergestellt sein, dass die Guthaben der betroffenen Konten genauso hoch sind, als wenn die Überweisungen nacheinander stattgefunden hätten.

Abschließend muss die Bank für die Dauerhaftigkeit der Daten gewährleisten können, dass der konsistente Datenbestand nicht durch äußere Einflüsse beeinträchtigt wird. Dazu gehören beispielsweise Stromausfälle, Systemabstürze oder Softwareupdates.

Welche Vorteile entstehen durch ACID?

In der Anwendung bieten Datenbanken, welche die ACID Prinzipien erfüllen viele Vorteile. Dazu zählen unter anderem:

• Durch ACID ist die Arbeit von mehreren Personen an einer Datenbank unbedenklich möglich.
• Die Nutzer und Entwickler von Datenbanken können von einem fehlerfreien Datenbestand ausgehen und müssen sich nicht mit der Fehlersuche beschäftigen.
• Die manuelle Fehlersuche ist nicht mehr notwendig, da keine Fehler auftreten.

Erfüllen NoSQL Datenbanken die ACID Eigenschaften?

NoSQL Lösungen können generell die ACID Eigenschaften nicht einhalten, obwohl es Ausnahmen gibt, wie beispielsweise die Graphdatenbanken, welche alle Konzepte erfüllen. NoSQL Datenbanken werden in vielen Fällen über mehrere Geräte und Server verteilt. Dadurch können deutlich größere Datenmengen gleichzeitig verarbeitet und gespeichert werden, was eine Hauptanforderung an diese Systeme ist. Jedoch erfüllen sie dadurch die Eigenschaft der Konsistenz nicht.

Angenommen wir haben eine NoSQL Datenbank auf zwei physischen Servern realisiert, von denen einer in Deutschland und der andere in den USA steht. Die Datenbanken enthalten die Kontostände und -transaktionen von deutschen und amerikanischen Kunden. Dabei sind die deutschen Konten in Deutschland und die amerikanischen Konten auf dem amerikanischen Server gespeichert.

Es kann nun zu Fall kommen, dass ein deutscher Kunde eine Überweisung auf ein amerikanisches Konto vornimmt. Dann werden beide Datenspeicher verändert und sind in diesem Bearbeitungszeitraum inkonsistent. Es kann beispielsweise zu dem Fall kommen, dass wir eine Datenbankabfrage starten während die Verarbeitung in Deutschland bereits abgeschlossen ist, aber die in den USA noch nicht. In diesem Zeitfenster, dem „Inconsistency Window“, stimmen die Daten in der Datenbank nicht und sind inkonsistent. So etwas würde in einer relationalen Datenbank nicht vorkommen.

Was ist das CAP Theorem?

Das CAP Theorem beschreibt insgesamt drei Eigenschaften von Datenbanken auf verteilten Systemen, die nie alle gleichzeitig erfüllt sein können. CAP steht dabei als Abkürzung für die englischen Begriffe „Consistency“, „Availability“ und „Partition Tolerance“ oder auf deutsch „Konsistenz“, „Verfügbarkeit“ und „Partitionstoleranz“. Dieses Theorem gilt vor allem für Datenbanken, die auf mehreren Systemen verteilt sind und in den Bereich der NoSQL-Datenbanken zählen. Für klassische relationale Datenbanken hingegen findet das sogenannte ACID Prinzip Anwendung.

Im Kern besteht CAP aus den folgenden drei Eigenschaften:

• Die Konsistenz beschreibt den Umstand, dass die Daten in der Datenbank zu jedem Zeitpunkt konsistent sein müssen. Das bedeutet, dass es zu keinerlei Unregelmäßigkeiten beim Abruf der Daten kommen darf, egal welcher der Knoten angesprochen wird. Praktisch bedeutet dies beispielsweise, dass beim Einfügen eines neuen Datensatzes die Datenstände auf allen Knoten gleichzeitig stattfinden muss.
• Verfügbarkeit bedeutet, dass das verteilte System immer eine Rückantwort liefert, auch wenn möglicherweise gerade einzelne Knoten ausgefallen sind. Dies ist unabhängig davon, welchen Knoten man im System anspricht. Somit bekommt man auch eine Antwort, wenn man zufülligerweise einen ausgefallenen Knoten angesprochen hat. Das System als ganzes ist somit durchgehend verfügbar.
• Die Partitionstoleranz, oder auch Ausfalltoleranz genannt, beschreibt die Fähigkeit, dass Anfragen stets richtig und komplett bearbeitet werden, selbst wenn es während des Prozesses zu Kommunikationsausfällen gekommen ist.

Es lässt sich axiomatisch zeigen, dass diese Eigenschaften in verteilten Systemen unter keinen Umständen gleichzeitig erfüllt sein können. Deshalb bildete sich das CAP Theorem, welches besagt, dass man sich beim Aufbau von verteilten Datenbanken auf zwei der Eigenschaften beschränken muss und die dritte Eigenschaft damit auf jeden Fall missachtet werden wird.

Wo liegen die Grenzen der ACID Eigenschaften?

ACID-Eigenschaften bieten zwar wichtige Garantien für Datenbanktransaktionen, haben aber auch einige Einschränkungen und Kompromisse zur Folge.

Erstens kann die strikte Einhaltung der ACID-Eigenschaften zu einer geringeren Leistung und Skalierbarkeit führen, insbesondere bei großen verteilten Systemen. Die Aufrechterhaltung der Transaktionskonsistenz über verteilte Knoten hinweg kann eine Herausforderung sein, die zu einer erhöhten Netzwerklatenz und einem geringeren Durchsatz führt.

Zweitens kann die Erzwingung einer strikten Isolierung zu mehr Konflikten und Sperren führen, was wiederum die Gleichzeitigkeit und den Durchsatz verringert. Dies kann zu einem Engpass für Systeme mit hohen Schreibgeschwindigkeiten oder hohem Wettbewerb um gemeinsam genutzte Ressourcen führen.

Drittens können ACID-Transaktionen hinsichtlich der Ressourcennutzung teuer sein, insbesondere bei lang laufenden Transaktionen oder bei Systemen mit hohen Schreibraten. Dies kann zu einem erhöhten Ressourcenverbrauch und potenziellen Leistungsproblemen führen.

Schließlich ist die strikte Einhaltung der ACID-Eigenschaften möglicherweise nicht für alle Anwendungen erforderlich. In Fällen, in denen hohe Verfügbarkeit oder Leistung wichtiger sind als strikte Konsistenz, können einige Kompromisse eingegangen werden, um die ACID-Garantien zugunsten einer verbesserten Leistung oder Skalierbarkeit zu lockern.

Insgesamt bieten ACID-Eigenschaften zwar wichtige Garantien für die Transaktionskonsistenz und -zuverlässigkeit, doch sind sie nicht immer die beste Lösung für jede Anwendung. Bei der Entwicklung von Datenbanksystemen sollten die Kompromisse zwischen Konsistenz, Verfügbarkeit und Leistung sorgfältig bedacht werden.

Wie können die ACID Eigenschaften in Datenbanken implementiert werden?

Die Umsetzung der ACID-Eigenschaften in einem Datenbanksystem erfordert eine Reihe grundlegender Schritte, um die Datenintegrität und Zuverlässigkeit sicherzustellen:

1. Atomicity (A):

• Transaktionsmanagement: Entwickle ein Transaktionsmanagementsystem, das eine Sequenz von SQL-Anweisungen als eine einzelne, unteilbare Einheit behandelt.
• Transaktionsprotokolle: Erstelle detaillierte Transaktionsprotokolle, um alle Änderungen während einer Transaktion zu protokollieren. Diese Protokolle ermöglichen ein Rollback im Falle eines Fehlers.
• Rückrollmechanismus: Implementiere einen Mechanismus, um Änderungen rückgängig zu machen, wenn ein Teil einer Transaktion fehlschlägt und stellt somit die Konsistenz sicher.

2. Consistency (C):

• Datenvalidierung: Erzwinge Datenintegritätsconstraints wie eindeutige Schlüssel und referenzielle Integrität, um die Datenkonsistenz aufrechtzuerhalten.
• Validierungsregeln: Definiere Validierungsregeln, um Daten vor der Einfügung oder Aktualisierung zu überprüfen und sicherzustellen, dass nur gültige Daten akzeptiert werden.
• Vor-Transaktionsprüfungen: Führe Prüfungen an den Daten vor Transaktionsbeginn durch, um Verstöße gegen Konsistenzregeln zu verhindern.

3. Isolation (I):

• Concurrency Control: Implementiere Mechanismen wie Sperren oder Zeitstempel, um gleichzeitige Transaktionen zu verwalten.
• Isolationslevel: Unterstütze verschiedene Isolationslevel, die es Benutzern ermöglichen, das benötigte Isolationsniveau auszuwählen.
• Behandlung von Deadlocks: Erkenne und löse Deadlocks, bei denen Transaktionen gegenseitig auf Ressourcen warten.

4. Durability (D):

• Write-Ahead-Logging: Verwende das Write-Ahead-Logging (WAL), um Änderungen zu protokollieren, bevor sie angewendet werden, und damit die Haltbarkeit sicherzustellen.
• Redo-Protokolle: Behalte Redo-Protokolle bei, die committed Transaktionen für die Wiederherstellung nach einem Systemausfall enthalten.
• Datensicherung: Erstelle regelmäßig Backups der Datenbank, um die Wiederherstellung von Daten nach katastrophalen Ausfällen zu ermöglichen.

5. Transaktionsabschluss:

• Two-Phase Commit (2PC): Implementiere ein Zwei-Phasen-Commit-Protokoll für verteilte Transaktionen, um sicherzustellen, dass alle Teilnehmer gemeinsam bestätigen oder abbrechen.
• Transaktionswiederherstellung: Entwickle Wiederherstellungsverfahren mithilfe von Transaktionsprotokollen, um unvollständige Transaktionen abzuschließen oder rückgängig zu machen, wenn die Datenbank nach einem Ausfall neu gestartet wird.

6. Prüfung und Validierung:

• Compliance-Tests: Teste die Datenbank gründlich, um die Einhaltung der ACID-Eigenschaften in verschiedenen Szenarien zu gewährleisten, einschließlich normaler Operationen, Fehler und gleichzeitiger Zugriffe.
• Validierungstools: Verwende Validierungstools zur Überprüfung der konsistenten Einhaltung der ACID-Anforderungen.

7. Überwachung und Wartung:

• Kontinuierliche Überwachung: Richte Überwachungssysteme ein, um die Leistung und Gesundheit der Datenbank kontinuierlich zu verfolgen.
• Regelmäßige Wartung: Plane Routineaufgaben wie das Management von Protokollen, die Optimierung von Indizes und die Überprüfung von Backups, um die Einhaltung der ACID-Eigenschaften aufrechtzuerhalten.

8. Dokumentation:

• Richtlinien und Dokumentation: Biete klare Dokumentation und Richtlinien für Administratoren und Entwickler zur Umsetzung und Pflege der ACID-Eigenschaften im System.

Diese Schritte gewährleisten gemeinsam ein robustes und zuverlässiges Datenbanksystem, das für Anwendungen von entscheidender Bedeutung ist, die eine sichere und konsistente Datenverwaltung auch unter anspruchsvollen Bedingungen erfordern.

CAP Theorem vs. ACID

Kurz gesprochen unterscheiden sich das CAP Theorem und die ACID Eigenschaften darin, dass sich CAP mit verteilten Systemen beschäftigt wohingegen ACID Aussagen über Datenbanken trifft. Wir wollen an dieser Stelle jedoch noch mehr ins Detail gehen.

Beide Konzepte beschäftigen sich mit der Konsistenz von Daten, jedoch unterscheiden sie sich darin, welche Auswirkungen dies hat. Bei ACID ist die Datenkonsistenz im Bereich von (relationalen) Datenbanken gemeint. Das bedeutet, dass die Daten konsistent sind, sobald im System widersprüchliche Daten vorhanden sind, dann ist die Datenbank inkonsistent. Das kann beispielsweise durch fehlerhafte Dupletten vorkommen, muss es jedoch nicht. Es greift dabei viel tiefer und inkludiert darin auch die Verflechtungen zwischen Tabellen und die Logik dahinter, wie beispielsweise Fremd- und Primärschlüssel.

Im CAP Theorem hingegen bedeutet die Konsistenz, dass das verteilte System bei einer Abfrage immer dasselbe Ergebnis ausgibt. Das bedeutet, dass es Dupletten geben darf auf verschiedenen Servern, diese müssen jedoch immer denselben Stand haben, damit es zu keinen Differenzen kommen kann. Dann ist die Konsistenz im CAP Theorem erfüllt.

Das solltest Du mitnehmen

• ACID (Atomicity, Consistency, Isolation, Durability) ist ein Begriff aus der Datenbanktheorie und beschreibt Regeln und Vorgehensweisen bei Datenbanktransaktionen.
• Relationale Datenbanken erfüllen diese Eigenschaften und sind dadurch zu jeder Zeit konsistent. NoSQL Datenbanken hingegen sind zu großen Teilen nicht ACID konform.
• Durch die Einhaltung der Prinzipien ist sichergestellt, dass Datenbanken zu allen Zeitpunkten einen fehlerfreien Datenbestand haben und gleichzeitige Zugriffe unbedenklich möglich sind.
• ACID unterscheidet sich vom sogenannten CAP Theorem vor allem in der Definition der Konsistenz und darin, dass es sich bei ACID um ein Konzept für Datenbanken handelt und bei CAP um ein Konzept von verteilten Systemen.

Andere Beiträge zum Thema ACID

• IBM bietet auch eine ausführliche Erklärung zu den Prinzipien von ACID.