In der heutigen Welt ist die Aufrechterhaltung der Datenintegrit\u00e4t bei immer gr\u00f6\u00dfer werdenden Datenmengen eine kritische Herausforderung f\u00fcr Unternehmen, die nach gr\u00f6\u00dferer Zuverl\u00e4ssigkeit und Leistung suchen. Daher ist das Verst\u00e4ndnis der Grundprinzipien der Datenintegrit\u00e4t und der Transaktionen unerl\u00e4sslich, von ACID-Transaktionen<\/b> bis hin zu BASE. In diesem Blogpost wird untersucht, wie traditionelle relationale und modernere NoSQL-Datenbanken<\/b> und DataLakes<\/b> das Problem der Datenintegrit\u00e4t l\u00f6sen.<\/span><\/p>\n<\/div><\/div><\/div><\/div><\/div> Eine Transaktion<\/strong> 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\u00fcr die Sicherheit geopfert wird und umgekehrt. Eines der am h\u00e4ufigsten im Zusammenhang mit Transaktionen verwendeten Frameworks wird jedoch durch das Akronym ACID definiert. <\/p>\n ACID<\/strong> steht f\u00fcr Atomicity (Atomarit\u00e4t)<\/strong>, Consistency (Konsistenz)<\/strong>, Isolation (Isolierung)<\/strong> und Durability (Dauerhaftigkeit)<\/strong> und ist die g\u00e4ngigste Garantie, die von relationalen Datenbanken geboten wird, die sich selbst als ACID-konform<\/strong> bezeichnen. In der Praxis ist das, was jeder Anbieter mit diesem Begriff meint, etwas anders, insbesondere was die Isolation betrifft. <\/p>\n Das Wort Atom leitet sich vom griechischen Atomos<\/em> ab, was soviel wie unzerschneidbar bedeutet. Eine Transaktion sollte sich aus Sicht der Datenbank oder der Clients, die auf sie zugreifen, als v\u00f6llig unteilbar verhalten, d.h. entweder alle Schritte einer Transaktion sind gemeinsam erfolgreich, oder sie sollten im Falle eines Fehlers gemeinsam abbrechen und zur\u00fcckgehen.<\/p>\n Konsistenz ist die Vorstellung, dass es bestimmte unver\u00e4nderliche Aussagen gibt, die w\u00e4hrend der gesamten Lebensdauer der Datenbank beibehalten werden sollten. Dazu geh\u00f6ren Einschr\u00e4nkungen, Datenintegrit\u00e4t, Konsistenz zwischen Partitionen und die Garantie, dass die Datenbank eine Reihe von vordefinierten Regeln einh\u00e4lt. <\/p>\n Isolation bedeutet, dass mehrere Transaktionen gleichzeitig und unabh\u00e4ngig voneinander ausgef\u00fchrt werden, ohne dass sie die Ergebnisse der anderen Transaktionen beeintr\u00e4chtigen. Im Idealfall w\u00e4re der resultierende Zustand der DataBase derselbe, als ob alle Operationen seriell ausgef\u00fchrt worden w\u00e4ren. <\/p>\n Dauerhaftigkeit ist das Konzept, dass die Daten nach dem Schreiben auch dann erhalten bleiben, wenn Probleme in der Datenbank auftreten, was f\u00fcr Zuverl\u00e4ssigkeit und Stabilit\u00e4t sorgt.<\/p>\n Eine Race Condition tritt auf, wenn mehrere Transaktionen versuchen, dieselben Datens\u00e4tze zu lesen oder zu schreiben, was zu unvorhersehbaren Ergebnissen f\u00fchren kann. Hier sind einige Beispiele f\u00fcr Race Conditions: <\/p>\n Wenn ein Client eine DataBase liest, w\u00e4hrend ein anderer sie \u00e4ndert, aber noch nicht \u00fcbertragen hat, kann der Lesevorgang nicht \u00fcbertragene Daten enthalten, die mit dem korrekten Endzustand der \u00fcbertragenen Daten nicht \u00fcbereinstimmen.<\/p>\n<\/div> Wenn zwei Clients versuchen, dieselben Daten zu \u00e4ndern, besteht die M\u00f6glichkeit, dass einer von ihnen die Daten des anderen \u00fcberschreibt, bevor sie \u00fcbertragen werden.<\/span><\/p>\n<\/div> Wenn ein Client aus der DataBase liest, w\u00e4hrend 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\u00fchrt.<\/span><\/p>\n<\/div> Wenn zwei Clients versuchen, Daten zu schreiben oder zu aktualisieren, kann einer von ihnen \u00e4ltere, noch nicht best\u00e4tigte Werte der anderen Transaktion<\/strong> aktualisieren, die mit den neueren aktualisierten Daten inkonsistent sind.<\/p>\n Wenn zwei Clients einen Lese-\u00c4nderungs-Schreibvorgang durchf\u00fchren, kann einer von ihnen die Transaktion<\/strong> aktualisieren, ohne die \u00c4nderungen des anderen Clients zu ber\u00fccksichtigen.<\/p>\n Wenn eine Transaktion<\/strong> denselben Satz von Zeilen zweimal liest und unterschiedliche Ergebnisse zur\u00fcckgibt, weil er in der Zwischenzeit von einem anderen Client aktualisiert wurde.<\/p>\n In der Praxis implementiert jeder DataBase-Anbieter die Isolation<\/strong> anders, wobei die st\u00e4rkste Isolationsebene Serialisierbare Isolierung<\/em><\/span>Die st\u00e4rkste Stufe der Isolierung<\/strong>, die serialisierbare Isolierung, ist mit erheblichen Leistungseinbu\u00dfen verbunden. Daher verzichten viele Systeme auf eine ideale Isolierung<\/strong> zugunsten schw\u00e4cherer Sicherheitsgarantien, um h\u00f6here Geschwindigkeiten zu erreichen und eine breitere Palette von Anwendungsf\u00e4llen zu unterst\u00fctzen.<\/p>\n Read Commit<\/strong> ist eine der einfachsten und beliebtesten Isolationsstufen<\/strong>. Sie verhindert, dass ein Leser unbest\u00e4tigte Daten lesen kann, und sperrt alle Daten, die geschrieben werden, bis eine Transaktion vollst\u00e4ndig best\u00e4tigt ist. Dies verhindert Schmutzige Reads<\/em><\/span> und Dirty Writes<\/em><\/span>. <\/p>\n Bei der Snapshot-Isolierung<\/strong> liest jede Transaktion von einem Snapshot der Datenbank, der zu Beginn der Transaktion erstellt wurde. Au\u00dferdem werden die Schreibvorg\u00e4nge in der Datenbank so gesperrt, dass die Leser niemals die Schreiber und die Schreiber niemals die Leser blockieren<\/em>. Read Committed<\/span><\/em> und verhindert au\u00dferdem Leseverzerrung<\/em><\/span>. <\/p>\n Serialisierbare Isolierung<\/strong> ist die st\u00e4rkste Isolierungsstufe. Es gibt zwar verschiedene Implementierungen, aber das Endergebnis sollte das Ergebnis aller seriell ausgef\u00fchrten Transaktionen widerspiegeln, auch wenn sie parallel ausgef\u00fchrt wurden. <\/p>\n Die einfachste Art der Implementierung von Serializable Isolation<\/strong> besteht darin, auf Parallelit\u00e4t zu verzichten und alles seriell auszuf\u00fchren. Dies wirkt sich jedoch auf die Leistung aus und sollte daher nur f\u00fcr Anwendungsf\u00e4lle 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\u00fchrt zu werden. In-Memory-Datenbanken wie Redis verwenden aus Gr\u00fcnden der Einfachheit und Leistung h\u00e4ufig die serielle Ausf\u00fchrung. <\/p>\n Two Phase Locking<\/strong> verwendet ein System von Schl\u00f6ssern, das dem der Schwachen Isolationsebenen<\/span><\/em> verwendet werden, aber in diesem Fall d\u00fcrfen 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\u00f6\u00dfte Nachteil von Two Phase Locking ist die geringere Leistung und die sehr hohen Latenzen auf Systemen mit hoher Parallelit\u00e4t. <\/p>\n Serializable Snapshot Isolation<\/strong> 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\u00e4hnten Zwei-Phasen-Sperrung<\/span><\/em> da er es allen Transaktionen erm\u00f6glicht, ohne Blockierung fortzufahren. Wenn eine Transaktion festgeschrieben wird, pr\u00fcft 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\u00f6here Parallelit\u00e4t bieten, aber er kann einen h\u00f6heren Overhead mit sich bringen und Anwendungen m\u00fcssen in der Lage sein, DataBase-Rollbacks zu verarbeiten.<\/p>\n<\/div> 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\u00f6here Verf\u00fcgbarkeit und Fehlertoleranz m\u00f6glicherweise einem h\u00f6heren Ma\u00df an Sicherheit vorgezogen. Daher verzichten einige Datenbanken oft auf ACID-Eigenschaften zugunsten eines weicheren Satzes von Transaktionsgarantien, die als BASE <\/p>\n Viele NoSQL-Datenbanken<\/strong> wie HBase<\/em> und Cassandra<\/em> nutzen diese BASE-Prinzipien, um eine Leistung und Skalierbarkeit zu erreichen, die mit einer strikten ACID-Konformit\u00e4t<\/strong> unvereinbar w\u00e4re. BASE<\/strong> hilft uns zwar dabei, die h\u00f6here Leistung und Verf\u00fcgbarkeit zu erreichen, die einige Produkte erfordern, bringt aber auch eine h\u00f6here Anwendungskomplexit\u00e4t und die Notwendigkeit mit sich, dass Anwendungen in der Lage sein m\u00fcssen, die fehlende Datenkonsistenz zu einem bestimmten Zeitpunkt zu unterst\u00fctzen. Die \u00dcbernahme von BASE-Prinzipien<\/strong> bedeutet, dass die Entwickler ihre Systeme so gestalten m\u00fcssen, dass sie mit eventueller Konsistenz<\/strong> umgehen k\u00f6nnen.<\/p>\n In letzter Zeit haben Produkte wie Delta Lake von Databricks<\/em> und Apache Iceberg<\/em> daran gearbeitet, die Big Data-Welt der meist BASE<\/strong> Data Lakes in den Bereich der h\u00f6heren Konsistenz mit ACID-Eigenschaften<\/strong> zu bringen. Diese Technologien bieten eine gr\u00f6\u00dfere Vielseitigkeit f\u00fcr ein breiteres Spektrum von Anwendungen und eine h\u00f6here Benutzerfreundlichkeit, k\u00f6nnen aber im Vergleich zu traditionellen BASE<\/strong> Data Lakes an Spezifit\u00e4t verlieren und in bestimmten Szenarien schlechter abschneiden.<\/p>\n<\/div><\/div><\/div><\/div><\/div> Wir haben Sie:<\/span><\/p>\n<\/div><\/div><\/div>ACID-Transaktionsgarantien<\/h2>\n
Transaktionen<\/h3>\n
ACID<\/h3>\n
Atomarit\u00e4t<\/h4>\n
Konsistenz<\/h3>\n
Isolierung<\/h4>\n
Langlebigkeit<\/h4>\n
Rennbedingungen<\/h3>\n
Schmutzige Lekt\u00fcre<\/h4>\n
![](\"https:\/\/ultratendency.academy\/wp-content\/uploads\/2024\/12\/acid-to-base-1.png\" "\\"acid")
<\/span>Schmutzige Briefe<\/span><\/h4>\n
![](\"https:\/\/ultratendency.academy\/wp-content\/uploads\/2024\/12\/acid-to-base-2.png\" "\\"acid")
<\/span>Schieflage lesen<\/span><\/h4>\n
![](\"https:\/\/ultratendency.academy\/wp-content\/uploads\/2024\/12\/acid-to-base-3.png\" "\\"acid")
<\/span>Schr\u00e4glage schreiben<\/h4>\n
Verlorene Updates<\/h4>\n
Phantom liest<\/h4>\n
Isolationsstufen<\/h3>\n
Schwache Isolationsebenen<\/h4>\n
Lesen Sie Engagiert<\/h5>\n
Isolierung von Schnappsch\u00fcssen<\/h5>\n
Serialisierbare Isolierung<\/h4>\n
Serielle Ausf\u00fchrung<\/em><\/h4>\n
Zwei Phasenverriegelungen<\/em><\/h4>\n
Serialisierbare Snapshot-Isolierung<\/em><\/h4>\n
NoSQL – Verzicht auf ACID zu Gunsten von BASE<\/h2>\n
BASE-Eigenschaften<\/h3>\n
\n
Moderne Datenseen<\/h3>\n
Sie suchen die richtige Ausbildung?<\/span><\/h2>\n
![](\"\/wp-content\/uploads\/2024\/07\/Data_build_tool_dbt_logo.png\"){kind=logo}
<\/a><\/span><\/div>![](\"\/wp-content\/uploads\/2024\/11\/datalakehouse.png\")
<\/a><\/span><\/div>![](\"\/wp-content\/uploads\/2024\/09\/python.png\")
<\/a><\/span><\/div>