In der heutigen Welt ist die Aufrechterhaltung der Datenintegrität bei immer größer werdenden Datenmengen eine kritische Herausforderung für Unternehmen, die nach größerer Zuverlässigkeit und Leistung suchen. Daher ist das Verständnis der Grundprinzipien der Datenintegrität und der Transaktionen unerlässlich, von ACID-Transaktionen bis hin zu BASE. In diesem Blogpost wird untersucht, wie traditionelle relationale und modernere NoSQL-Datenbanken und DataLakes das Problem der Datenintegrität lösen.

ACID-Transaktionsgarantien

Transaktionen

Eine Transaktion ist eine Gruppierung mehrerer DataBase-Operationen zu einer einzigen Arbeitseinheit; diese Einheit sollte entweder gemeinsam erfolgreich abgeschlossen oder gemeinsam abgebrochen werden. Jeder Datenbanktyp und jeder Anbieter implementiert Transaktionen anders, wobei manchmal mehr oder weniger Geschwindigkeit für die Sicherheit geopfert wird und umgekehrt. Eines der am häufigsten im Zusammenhang mit Transaktionen verwendeten Frameworks wird jedoch durch das Akronym ACID definiert.

ACID

ACID steht für Atomicity (Atomarität), Consistency (Konsistenz), Isolation (Isolierung) und Durability (Dauerhaftigkeit) und ist die gängigste Garantie, die von relationalen Datenbanken geboten wird, die sich selbst als ACID-konform bezeichnen. In der Praxis ist das, was jeder Anbieter mit diesem Begriff meint, etwas anders, insbesondere was die Isolation betrifft.

Atomarität

Das Wort Atom leitet sich vom griechischen Atomos ab, was soviel wie unzerschneidbar bedeutet. Eine Transaktion sollte sich aus Sicht der Datenbank oder der Clients, die auf sie zugreifen, als völlig unteilbar verhalten, d.h. entweder alle Schritte einer Transaktion sind gemeinsam erfolgreich, oder sie sollten im Falle eines Fehlers gemeinsam abbrechen und zurückgehen.

Konsistenz

Konsistenz ist die Vorstellung, dass es bestimmte unveränderliche Aussagen gibt, die während der gesamten Lebensdauer der Datenbank beibehalten werden sollten. Dazu gehören Einschränkungen, Datenintegrität, Konsistenz zwischen Partitionen und die Garantie, dass die Datenbank eine Reihe von vordefinierten Regeln einhält.

Isolierung

Isolation bedeutet, dass mehrere Transaktionen gleichzeitig und unabhängig voneinander ausgeführt werden, ohne dass sie die Ergebnisse der anderen Transaktionen beeinträchtigen. Im Idealfall wäre der resultierende Zustand der DataBase derselbe, als ob alle Operationen seriell ausgeführt worden wären.

Langlebigkeit

Dauerhaftigkeit ist das Konzept, dass die Daten nach dem Schreiben auch dann erhalten bleiben, wenn Probleme in der Datenbank auftreten, was für Zuverlässigkeit und Stabilität sorgt.

Rennbedingungen

Eine Race Condition tritt auf, wenn mehrere Transaktionen versuchen, dieselben Datensätze zu lesen oder zu schreiben, was zu unvorhersehbaren Ergebnissen führen kann. Hier sind einige Beispiele für Race Conditions:

Schmutzige Lektüre

Wenn ein Client eine DataBase liest, während ein anderer sie ändert, aber noch nicht übertragen hat, kann der Lesevorgang nicht übertragene Daten enthalten, die mit dem korrekten Endzustand der übertragenen Daten nicht übereinstimmen.

Schmutzige Briefe

Wenn zwei Clients versuchen, dieselben Daten zu ändern, besteht die Möglichkeit, dass einer von ihnen die Daten des anderen überschreibt, bevor sie übertragen werden.

Schieflage lesen

Wenn ein Client aus der DataBase liest, während ein anderer sie aktualisiert, kann er Ergebnisse von verschiedenen Zeitpunkten erhalten, einige von vor und einige von nach der Aktualisierung, was zu inkonsistenten Lesungen führt.

Schräglage schreiben

Wenn zwei Clients versuchen, Daten zu schreiben oder zu aktualisieren, kann einer von ihnen ältere, noch nicht bestätigte Werte der anderen Transaktion aktualisieren, die mit den neueren aktualisierten Daten inkonsistent sind.

Verlorene Updates

Wenn zwei Clients einen Lese-Änderungs-Schreibvorgang durchführen, kann einer von ihnen die Transaktion aktualisieren, ohne die Änderungen des anderen Clients zu berücksichtigen.

Phantom liest

Wenn eine Transaktion denselben Satz von Zeilen zweimal liest und unterschiedliche Ergebnisse zurückgibt, weil er in der Zwischenzeit von einem anderen Client aktualisiert wurde.

Isolationsstufen

Schwache Isolationsebenen

In der Praxis implementiert jeder DataBase-Anbieter die Isolation anders, wobei die stärkste Isolationsebene Serialisierbare IsolierungDie stärkste Stufe der Isolierung, die serialisierbare Isolierung, ist mit erheblichen Leistungseinbußen verbunden. Daher verzichten viele Systeme auf eine ideale Isolierung zugunsten schwächerer Sicherheitsgarantien, um höhere Geschwindigkeiten zu erreichen und eine breitere Palette von Anwendungsfällen zu unterstützen.

Lesen Sie Engagiert

Read Commit ist eine der einfachsten und beliebtesten Isolationsstufen. Sie verhindert, dass ein Leser unbestätigte Daten lesen kann, und sperrt alle Daten, die geschrieben werden, bis eine Transaktion vollständig bestätigt ist. Dies verhindert Schmutzige Reads und Dirty Writes.

Isolierung von Schnappschüssen

Bei der Snapshot-Isolierung liest jede Transaktion von einem Snapshot der Datenbank, der zu Beginn der Transaktion erstellt wurde. Außerdem werden die Schreibvorgänge in der Datenbank so gesperrt, dass die Leser niemals die Schreiber und die Schreiber niemals die Leser blockieren. Read Committed und verhindert außerdem Leseverzerrung.

Serialisierbare Isolierung

Serialisierbare Isolierung ist die stärkste Isolierungsstufe. Es gibt zwar verschiedene Implementierungen, aber das Endergebnis sollte das Ergebnis aller seriell ausgeführten Transaktionen widerspiegeln, auch wenn sie parallel ausgeführt wurden.

Serielle Ausführung

Die einfachste Art der Implementierung von Serializable Isolation besteht darin, auf Parallelität zu verzichten und alles seriell auszuführen. Dies wirkt sich jedoch auf die Leistung aus und sollte daher nur für Anwendungsfälle reserviert werden, bei denen die gesamte Datenbank in den Speicher passt und jede Transaktion klein genug ist, um mit einem einzigen CPU-Kern schnell ausgeführt zu werden. In-Memory-Datenbanken wie Redis verwenden aus Gründen der Einfachheit und Leistung häufig die serielle Ausführung.

Zwei Phasenverriegelungen

Two Phase Locking verwendet ein System von Schlössern, das dem der Schwachen Isolationsebenen verwendet werden, aber in diesem Fall dürfen Transaktionen nur Daten lesen, auf die kein anderer Client schreibt. Writer blockieren nicht nur wie zuvor andere Writer, sondern auch alle Leser, wodurch alle anderen Race Conditions verhindert werden. Der größte Nachteil von Two Phase Locking ist die geringere Leistung und die sehr hohen Latenzen auf Systemen mit hoher Parallelität.

Serialisierbare Snapshot-Isolierung

Serializable Snapshot Isolation ist ein relativ neuer Algorithmus, der in einigen modernen Datenbanken verwendet wird. Es handelt sich um einen optimistischen Kontrollalgorithmus, der im Gegensatz zu pessimistischen Kontrollalgorithmen wie dem oben erwähnten Zwei-Phasen-Sperrung da er es allen Transaktionen ermöglicht, ohne Blockierung fortzufahren. Wenn eine Transaktion festgeschrieben wird, prüft die DataBase, ob sie serialisierbar war oder nicht und versucht es bei Bedarf erneut. Dieser Ansatz kann im Vergleich zu anderen Strong Isolation-Techniken eine höhere Parallelität bieten, aber er kann einen höheren Overhead mit sich bringen und Anwendungen müssen in der Lage sein, DataBase-Rollbacks zu verarbeiten.

NoSQL – Verzicht auf ACID zu Gunsten von BASE

In der heutigen Zeit verlangt die Notwendigkeit, enorme Datenmengen zu verarbeiten, eine gigantische Skalierbarkeit von DataBases. In einer rund um die Uhr vernetzten Welt werden höhere Verfügbarkeit und Fehlertoleranz möglicherweise einem höheren Maß an Sicherheit vorgezogen. Daher verzichten einige Datenbanken oft auf ACID-Eigenschaften zugunsten eines weicheren Satzes von Transaktionsgarantien, die als BASE

BASE-Eigenschaften

• Grundlegend verfügbar: Selbst bei Ausfällen sollte das System Verfügbarkeit garantieren.
• Weicher Zustand: Auch wenn keine Eingaben gemacht werden, kann sich der Zustand des Systems ändern, um eine eventuelle Konsistenz zu erreichen
• Letztendlich konsistent: Während zu einem bestimmten Zeitpunkt keine Konsistenz garantiert werden kann, wird sich das System in einen konsistenten Zustand entwickeln, wenn keine weiteren Aktualisierungen vorgenommen werden.

Viele NoSQL-Datenbanken wie HBase und Cassandra nutzen diese BASE-Prinzipien, um eine Leistung und Skalierbarkeit zu erreichen, die mit einer strikten ACID-Konformität unvereinbar wäre. BASE hilft uns zwar dabei, die höhere Leistung und Verfügbarkeit zu erreichen, die einige Produkte erfordern, bringt aber auch eine höhere Anwendungskomplexität und die Notwendigkeit mit sich, dass Anwendungen in der Lage sein müssen, die fehlende Datenkonsistenz zu einem bestimmten Zeitpunkt zu unterstützen. Die Übernahme von BASE-Prinzipien bedeutet, dass die Entwickler ihre Systeme so gestalten müssen, dass sie mit eventueller Konsistenz umgehen können.

Moderne Datenseen

In letzter Zeit haben Produkte wie Delta Lake von Databricks und Apache Iceberg daran gearbeitet, die Big Data-Welt der meist BASE Data Lakes in den Bereich der höheren Konsistenz mit ACID-Eigenschaften zu bringen. Diese Technologien bieten eine größere Vielseitigkeit für ein breiteres Spektrum von Anwendungen und eine höhere Benutzerfreundlichkeit, können aber im Vergleich zu traditionellen BASE Data Lakes an Spezifität verlieren und in bestimmten Szenarien schlechter abschneiden.