Ein Leitfaden zu ACID-Eigenschaften in Datenbankmanagementsystemen
Der Einsatz von Echtzeitanwendungen und Geräten des Internet of Things (IoT) sowie das exponentielle Wachstum unstrukturierter Datenbestände führen dazu, dass immer mehr Unternehmen auf NoSQL-Datenbanken umsteigen. Tatsächlich wird erwartet, dass der NoSQL-Markt bis 2032 ein Volumen von 74,5 Milliarden US-Dollar erreichen wird, was einer durchschnittlichen jährlichen Wachstumsrate (CAGR) von 24,9 % im Zeitraum von 2024 bis 2032 entspricht (IMARC Group, 2024).
Dieses Wachstum ist nicht überraschend, wenn man bedenkt, dass NoSQL-Datenbankmanagementsysteme (DBMS) große, vielfältige Datensätze effektiv verwalten und die damit verbundenen Big-Data-Analysen durchführen können.
Viele sind jedoch nach wie vor der Meinung, dass NoSQL-DBMS nicht in der Lage sind, eine wichtige Anforderung vieler Unternehmen zu erfüllen – die Verwaltung und Einhaltung von ACID-Transaktionen. Die gute Nachricht ist, dass einige NoSQL-DBMS dies absolut können!
In diesem Artikel werden wir erläutern, was ACID-Transaktionen sind, welche Eigenschaften ACID-Transaktionen haben, warum diese Transaktionen wichtig sind und ein Beispiel für eine ACID-Transaktion in einem NoSQL-DBMS vorstellen.
Inhaltsverzeichnis
- Ein kurzer Überblick über die Geschichte der ACID-Transaktionen
- Was sind ACID-Transaktionen?
- Warum sind ACID-Transaktionen wichtig?
- Beispiel für ACID-Transaktionen in DBMS
- Wie funktionieren ACID-Transaktionen in MongoDB?
- Wann sollte ich MongoDB-Transaktionen für mehrere Dokumente verwenden?
- Was sind die Best Practices für Transaktionen in MongoDB?
- FAQ
Ein kurzer Überblick über die Geschichte der ACID-Transaktionen
Das Konzept von ACID-Transaktionen ist seit den späten 1970er Jahren von zentraler Bedeutung für die Entwicklung moderner Datenbanksysteme.
Als Unternehmen und Forschungseinrichtungen zunehmend auf digitale Daten zurückgriffen, wurde die Notwendigkeit verlässlicher Verfahren zur Verarbeitung komplexer Vorgänge über mehrere Datensätze hinweg deutlich. Frühe relationale Datenbanken wie IBMs System R und Oracle gehörten zu den ersten, die damit experimentierten, strengere Garantien hinsichtlich Datenintegrität und Transaktionszuverlässigkeit durchzusetzen.
Im Jahr 1983 definierten die Informatiker Andreas Reuter und Theo Härder in einer wegweisenden Veröffentlichung die vier ACID-Eigenschaften – Atomarität, Konsistenz, Isolation und Dauerhaftigkeit – formal. Ihre Arbeit verschaffte der Datenbank-Community eine gemeinsame Sprache zur Beschreibung der Anforderungen an zuverlässige Datenbanktransaktionen. Jede Eigenschaft sollte eine bestimmte Herausforderung angehen, um sicherzustellen, dass Daten auch bei Ausfällen gültig blieben und zuverlässig verarbeitet wurden:
- Die Atomizität garantiert, dass mehrere Vorgänge in einer Transaktion als eine Einheit fungieren – entweder alle sind erfolgreich oder alle schlagen fehl.
- Konsistenz stellt sicher, dass die Datenbank in einem gültigen Zustand bleibt, der den definierten Regeln und Einschränkungen entspricht.
- Isolation verhindert, dass sich gleichzeitige Transaktionen gegenseitig stören.
- Die Dauerhaftigkeit stellt sicher, dass die Ergebnisse nach dem Festschreiben einer Transaktion dauerhaft sind, selbst nach Systemausfällen.
Dieses Framework wurde zum Goldstandard für Relational Database Management System (RDBMS), insbesondere als Unternehmen sie für das Bankwesen, den Einzelhandel und die Telekommunikation einsetzten – Branchen, in denen Finanztransaktionen und die Einhaltung gesetzlicher Vorschriften absolute Genauigkeit erfordern.
In den 1990er Jahren und zu Beginn der 2000er Jahre wurden in relationalen Datenbanken wie Oracle, IBM DB2 und Microsoft SQL Server die Implementierungsmethoden der ACID-Garantien kontinuierlich weiterentwickelt, wobei häufig Techniken wie Write-Ahead-Logging, Sperren und Multi-Version Concurrency Control zum Einsatz kamen.
Diese Methoden ermöglichten es Unternehmen, Millionen von Datenbankoperationen zu verarbeiten und dabei eine strenge Konsistenz aufrechtzuerhalten.
Mit dem Aufkommen von NoSQL-Datenbanken in den 2010er Jahren stellten einige die Frage, ob ACID-Garantien in Systemen beibehalten werden könnten, die auf horizontale Skalierbarkeit und Hochverfügbarkeit ausgelegt sind. Frühe NoSQL-Plattformen gingen häufig zugunsten von Leistung und Verfügbarkeit Kompromisse bei der Konsistenz ein, was zu der Annahme führte, dass ACID-Konformität und NoSQL-Skalierbarkeit sich gegenseitig ausschließen würden.
Da jedoch die Anforderungen an die Datenintegrität in verteilten Systemen zunahmen, bewiesen Anbieter wie MongoDB, dass es möglich ist, dokumentübergreifende Transaktionen zu unterstützen und gleichzeitig die Skalierung über mehrere Knoten hinweg zu gewährleisten.
Auch heute noch sind ACID-Transaktionen so relevant wie eh und je. Sie bilden die Grundlage für die Wahrung der Datenintegrität in Branchen, in denen Fehler nicht akzeptabel sind – von Banküberweisungen bis hin zu Patientenakten.
Gleichzeitig haben moderne Plattformen wie MongoDB die ACID-Garantien auf flexible, unstrukturierte Daten und komplexe Vorgänge über verteilte Cluster hinweg ausgeweitet. Diese Kombination aus Zuverlässigkeit und Skalierbarkeit sorgt dafür, dass die vor über 40 Jahren erstmals definierten ACID-Prinzipien auch weiterhin die Zukunft der Datenbankverwaltung prägen.
Was sind ACID-Transaktionen?
Transaktionen erklärt
Im Grunde genommen handelt es sich bei Datenbanktransaktionen um eine Gruppe von Datenbanklese- und -schreibvorgängen, die gemäß DBMS-Definitionen (z. B. definierte Transaktionskriterien) erfolgreich abgeschlossen wurden. Es gibt zwei Haupttypen von Transaktionen:
- Einzeltransaktionen: Eine Einzeltransaktion bezeichnet eine Abfolge von einem oder mehreren Datenbankvorgängen, die zu einer einzigen, erfolgreich abgeschlossenen Aktion führen. Sobald die Transaktion abgeschlossen ist, wird sie akzeptiert und ist im Transaktionsprotokoll nachschlagbar. Ein gängiges Beispiel für eine Einzeltransaktion ist die Geldabhebung an einem Geldautomaten.
- Multitransaktionen: Eine Multitransaktion, auch verteilte Transaktion genannt, besteht aus mehreren, voneinander abhängigen Transaktionen, die über verschiedene Datenbanken und Systeme (z. B. verteilte Systeme) verteilt sind. Aufzeichnungen dieser Transaktionen finden sich auch in einem Transaktionsprotokoll. Ein Beispiel für diese Transaktionen ist die Überweisung von Geld von einem Konto auf ein anderes oder die Ausstellung eines Sicherheitsausweises mit Foto für einen neuen Mitarbeiter durch den Arbeitgeber.
Es ist wichtig zu beachten, dass einige Transaktionen strenge Standards der Datenintegrität (z. B. Daten sind vollständig und korrekt) und Datenkonsistenz (z. B. der Wert ist in allen Tabellen/Datenbanken gleich) einhalten müssen. Dies ist häufig der Fall, wenn es um treuhänderische Verantwortung oder die Einhaltung gesetzlicher Vorschriften geht.
Beispiele hierfür sind das kommerzielle Bankgeschäft, die Vermittlung von Investitionen und die Abwicklung von Rechtsgeschäften.
In diesen Situationen reicht die standardmäßige Einhaltung der DBMS-Definitionen nicht aus, und es sind ACID-Transaktionen erforderlich.
ACID-Transaktionen
ACID ist ein Akronym, das für Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isolation) und Durability (Dauerhaftigkeit) steht. Zusammen stellen die ACID-Eigenschaften sicher, dass eine Reihe von Datenbankoperationen (die in einer Transaktion zusammengefasst sind) die Datenbank auch im Falle unerwarteter Fehler in einem gültigen Zustand verlassen.
Darüber hinaus bieten ACID-Transaktionen das Maß an Transaktionsgarantien, das von vielen Aufsichtsbehörden gefordert wird.
Im Folgenden finden Sie einen allgemeinen Überblick über die einzelnen ACID-Transaktionselemente sowie eine Beschreibung, wie eine NoSQL-Dokumentendatenbank diese ACID-Elemente umsetzen kann. Für die Zwecke dieses Artikels wird MongoDB Atlas verwendet.
Atomarität
Die Atomizität garantiert, dass alle Befehle, aus denen eine Transaktion besteht, als eine Einheit behandelt werden und entweder alle zusammen erfolgreich sind oder alle zusammen fehlschlagen. Dies ist im Falle eines System- oder Stromausfalls wichtig, da eine nicht vollständig verarbeitete Transaktion verworfen wird und die Datenbank ihre Datenintegrität beibehält.
Wie MongoDB Atomarität gewährleistet
In MongoDB ist ein Schreibvorgang auf der Ebene eines einzelnen Dokuments atomar, selbst wenn der Vorgang mehrere eingebettete Dokumente innerhalb eines einzelnen Dokuments ändert.
Für Situationen, in denen die Atomarität von Lese- und Schreibvorgängen an mehreren Dokumenten (in einer einzelnen Sammlung oder in mehreren Sammlungen) erforderlich ist, unterstützt MongoDB verteilte Transaktionen, einschließlich Transaktionen auf Replikatsätzen und Sharded Clustern.
Konsistenz
Konsistenz garantiert, dass Änderungen, die innerhalb einer Transaktion vorgenommen werden, im gesamten Datenbanksystem (z. B. Knoten) und in Übereinstimmung mit den DBMS-Beschränkungen übernommen werden. Wenn die Datenkonsistenz durch eine Transaktion in einem inkonsistenten Zustand negativ beeinflusst wird, schlägt die gesamte Transaktion fehl.
Wie MongoDB Konsistenz gewährleistet
MongoDB bietet die Flexibilität, Daten zu normalisieren oder zu duplizieren, um Anwendungen zu optimieren. Wenn Daten im Schema dupliziert werden, muss der Entwickler entscheiden, wie duplizierte Daten über mehrere Sammlungen hinweg konsistent gehalten werden sollen. Bei einigen Anwendungen müssen duplizierte Daten sofort konsistent gemacht werden, während andere Anwendungen das Lesen veralteter Daten tolerieren können. Beispiele sind im Folgenden dargestellt:
Hinweis: Erfahren Sie mehr über Datenkonsistenz.
Isolation
Jede Transaktion wird von den anderen Transaktionen isoliert, um Datenkonflikte zu vermeiden. Dies erleichtert auch Datenbankvorgänge im Zusammenhang mit der Verwaltung mehrerer Einträge und mehrstufiger Transaktionen.
Wenn beispielsweise zwei Benutzer versuchen, dieselben Daten (oder sogar dieselbe Transaktion) zu ändern, setzt das DBMS einen sogenannten Sperrmanager ein, um andere Benutzer zu blockieren, bis die vom ersten Benutzer vorgenommenen Änderungen abgeschlossen sind.
Wie MongoDB Isolation gewährleistet
MongoDB verwendet eine Technik namens „Snapshot Isolation“ (d. h., jede Transaktion scheint auf einem persönlichen Snapshot der Datenbank zu basieren, der zu Beginn der Transaktion erstellt wurde). Transaktionen können Daten aus dem „Snapshot“ der Daten lesen, die zum Zeitpunkt des Transaktionsstarts festgelegt wurden, und alle widersprüchlichen Aktualisierungen führen zum Abbruch der Transaktion.
Darüber hinaus unterstützen MongoDB-Transaktionen eine Schreibsicherheitsstufe auf Transaktionsebene. Clients können eine geeignete Lese- und Schreibsicherheitsstufe festlegen, wobei die strengste Kombination aus „Snapshot-Lesesicherheitsstufe“ und „Majority-Schreibsicherheitsstufe“ ist. „Majority-Schreibsicherheitsstufe“ bedeutet, dass die Schreibvorgänge dauerhaft auf einer berechneten Mehrheit der datentragenden Knoten (vom Entwickler konfigurierbar) festgeschrieben wurden.
Dauerhaftigkeit
Die Dauerhaftigkeit garantiert, dass Änderungen nach Abschluss der Transaktion in die Datenbank geschrieben und dort beibehalten werden. Dadurch wird sichergestellt, dass die Daten innerhalb des Systems auch bei Systemausfällen wie Abstürzen oder Stromausfällen erhalten bleiben. Das Konzept der Dauerhaftigkeit ist ein Schlüsselelement für die Zuverlässigkeit von Daten.
Wie MongoDB Dauerhaftigkeit gewährleistet
MongoDB erstellt ein OpLog, das für jeden „Schreibvorgang“ den Speicherort auf der Festplatte und die Anzahl der geänderten Bytes enthält. Tritt während des Schreibvorgangs der Transaktion ein unvorhergesehenes Ereignis ein (z. B. ein Stromausfall), kann das OpLog beim Neustart des Systems verwendet werden, um alle Schreibvorgänge nachzubilden, die vor dem Herunterfahren noch nicht auf die Festplatte geschrieben wurden.
Darüber hinaus werden Vorgänge geändert, bevor sie in OpLog geschrieben werden, sodass sie idempotent sind und mehrmals wiederholt werden können. Transaktionen oder „Schreibvorgänge“ werden standardmäßig etwa alle 60 Sekunden auf die Festplatte geschrieben.
Warum sind ACID-Transaktionen wichtig?
ACID-Transaktionen tragen zur Wahrung der Datenintegrität und -zuverlässigkeit bei und gewährleisten zugleich, dass wichtige Daten, die gesetzlichen oder branchenspezifischen Vorschriften unterliegen (z. B. Bankkonten, Aktienportfolios), die erforderlichen Standards erfüllen. Darüber hinaus ist die Einhaltung von ACID oft eine Voraussetzung für die Implementierung der Datenreplikation und die Erzielung einer hohen Verfügbarkeit in verteilten Datenbanksystemen.
Beispiel für ACID-Transaktionen in DBMS
Anhand der NoSQL-Dokumentendatenbank MongoDB Atlas wird hier ein Beispiel dafür gegeben, wie dokumentübergreifende ACID-Transaktionen abgewickelt werden und wie ACID-Transaktionen die Einhaltung der Mindeststandards für ACID-Eigenschaften gewährleisten.
Dokumentübergreifende ACID-Transaktionen
Stellen Sie sich vor, Sie erstellen eine Funktion, um Geld von einem Bankkonto auf ein anderes zu überweisen, wobei jedes Konto einen eigenen Datensatz darstellt. Wenn Geld erfolgreich vom Quellkonto abgebucht, aber nie dem Zielkonto gutgeschrieben wird, ist ein schwerwiegendes Buchhaltungsproblem entstanden. Umgekehrt tritt ein weiteres schwerwiegendes Problem in der Buchhaltung auf, wenn das Zielkonto zwar eine Gutschrift erhält, das Quellkonto jedoch nie belastet wird.
Diese beiden Schreibvorgänge müssen entweder beide stattfinden oder beide nicht stattfinden, damit das System und seine Daten konsistent bleiben. Außerdem bedeutet dies, dass die Datenbank alle Änderungen, die sie im Verlauf der Transaktion vorgenommen hat, rückgängig machen (d. h. widerrufen) muss, wenn ein Befehl in der Transaktion fehlschlägt.
Hinweis: Weitere Informationen finden Sie im Node.js Quick Start GitHub-Repository, wo Sie eine Kopie des vollständigen Codebeispiels erhalten und es selbst ausführen können.
Zu beachtende Auswirkungen
Wenn Sie mit Transaktionen mit mehreren Dokumenten in einem verteilten System arbeiten, sollten Sie bedenken, dass es zu Performance-Overhead kommt, der sich auf Ressourcenbeschränkungen und Leistungsziele auswirken kann. Da die Datenbank zudem die beteiligten Ressourcen „sperren“ muss, um zu verhindern, dass gleichzeitige Schreibvorgänge sich gegenseitig stören (z. B. Transaktionsfehler), können andere Clients, die versuchen, Daten zu schreiben, möglicherweise festsitzen und auf den Abschluss der Transaktion warten, was sich auf die Anwendungslatenz und die Benutzererfahrung auswirken kann.
Wie funktionieren ACID-Transaktionen in MongoDB?
Das Dokumentmodell von MongoDB ermöglicht es, zusammengehörige Daten in einem einzigen Dokument zu speichern. Das Dokumentmodell macht in Kombination mit atomaren Dokumentaktualisierungen Transaktionen in den meisten Anwendungsfällen überflüssig. Dennoch gibt es Fälle, in denen echte MongoDB-Transaktionen mit mehreren Dokumenten und mehreren Sammlungen die beste Wahl sind.
MongoDB-Transaktionen funktionieren ähnlich wie Transaktionen in anderen Datenbanken. Um eine Transaktion zu verwenden, starten Sie eine MongoDB-Sitzung über einen Treiber. Verwenden Sie dann diese Sitzung, um Ihre Gruppe von Datenbankoperationen auszuführen. Sie können jeden der CRUD-Vorgänge (Create, Read, Update und Delete) über mehrere Dokumente, Sammlungen und Shards hinweg ausführen.
Spezifische Codebeispiele für die Implementierung von Transaktionen finden Sie in den folgenden Schnellstarts:
- Dokumentübergreifende ACID-Transaktionen in MongoDB mit Golang
- Dokumentübergreifende ACID-Transaktionen in MongoDB mit Java
- Dokumentübergreifende ACID-Transaktionen in MongoDB mit Node.js
- Dokumentübergreifende ACID-Transaktionen in MongoDB mit Python
Besuchen Sie die Dokumentation zu MongoDB-Treibern für sprachspezifische Anleitungen zu jeder der von MongoDB offiziell unterstützten Sprachen. Sie können auch eine Liste mit Best Practices für Transaktionen und Überlegungen zur Produktion anzeigen.
Wann sollte ich MongoDB-Transaktionen für mehrere Dokumente verwenden?
Anwendungen, die Transaktionen erfordern, haben in der Regel Anwendungsfälle, bei denen Werte zwischen verschiedenen Parteien ausgetauscht werden. Dabei handelt es sich typischerweise um „System of Record“- oder „Line of Business“-Anwendungen.
Beispiele für Anwendungen, die von Transaktionen mit mehreren Dokumenten profitieren können, sind:
- Systeme, die Gelder von einem Konto auf ein anderes übertragen (z. B. Bankanwendungen, Zahlungsverarbeitungssysteme, Handelsplattformen).
- Lieferketten- und Buchungssysteme, bei denen das Eigentum an Waren und Dienstleistungen von einer Partei auf eine andere übertragen wird.
- Abrechnungssysteme, die Informationen sowohl in Detail- als auch in Übersichtsaufzeichnungen speichern.
Was sind die Best Practices für Transaktionen in MongoDB?
Im Allgemeinen wird empfohlen, Daten so zu modellieren, dass gemeinsam genutzte Daten auch gemeinsam gespeichert werden. Wenn die Daten auf diese Weise modelliert werden, wird nicht nur eine bessere Leistung erzielt, sondern es sind auch keine Transaktionen erforderlich.
Für Anwendungen, die Transaktionen erfordern, sollten Sie die folgenden Best Practices einhalten:
- Teilen Sie lang andauernde Transaktionen in kleinere Einheiten auf, damit sie die standardmäßige Timeout-Zeit von 60 Sekunden nicht überschreiten. (Beachten Sie, dass diese Timeout-Zeit verlängert werden kann.) Stellen Sie sicher, dass die Vorgänge in Transaktionen Indizes verwenden, damit sie schnell ausgeführt werden können.
- Beschränken Sie jede Transaktion auf 1.000 Dokumentenänderungen.
- Stellen Sie sicher, dass die entsprechenden Lese- und Schreibsicherheitsstuffen konfiguriert sind (beachten Sie, dass MongoDB ab Version 5.0 standardmäßig die erforderliche „Majority“-Schreibberechtigungsstufe verwendet).
- Fügen Sie eine entsprechende Fehlerbehandlung hinzu und wiederholen Sie Transaktionen, die aufgrund vorübergehender Fehler fehlschlagen.
- Denken Sie an die Leistungseinbußen von Transaktionen, die mehrere Shards betreffen. Weitere Informationen zu diesen Best Practices finden Sie im Whitepaper „Dokumentübergreifende ACID-Transaktionen mit MongoDB“ sowie in der MongoDB-Dokumentation zu Transaktionen.