Um Datenbanktransaktionen, die ACID-Prinzipien und Alternativen
dazu geht es in der einhundertsiebenundachzigsten Episode des
IT-Berufe-Podcasts. TL;DR An Beispielen aus dem Alltag zeige ich
dir, wie Datenbanktransaktionen zusammengehörige SQL-Statements als
Einheit ausführen und welche Eigenschaften ACID dafür beschreibt.
Du erfährst, wie Isolation parallele Zugriffe absichert, welche
Fehler dabei auftreten können und wie du Transaktionen mit SQL oder
einem ORM steuerst. Für verteilte Datenbanken kommen das
CAP-Theorem und BASE hinzu, die beschreiben, welche Anforderungen
an konsistente und verfügbare Daten bestehen. Als IT-Azubi brauchst
du dieses Wissen beim Entwickeln von Anwendungen; ACID gehört
außerdem zum Prüfungsstoff. Kapitelmarken [00:00:01] Thema und
Bedeutung für die IT-Ausbildung [00:02:58] Was ist eine
Datenbanktransaktion? [00:03:28] Beispiel Banküberweisung
[00:04:53] Der Begriff Transaktion im Datenbankkontext [00:06:33]
Beispiel Blogbeitrag und Tag [00:08:17] Beispiel Bestellung und
Bestellposition [00:09:18] Beispiel Versicherungstarif [00:11:28]
Die ACID-Prinzipien [00:12:52] Atomicity: Atomarität [00:15:06]
Consistency: Konsistenz [00:16:35] Isolation bei parallelen
Zugriffen [00:18:58] Durability und Transaktionslogs [00:22:48]
Isolationsebenen und Sperren [00:26:24] Serializable [00:29:14]
Repeatable Read [00:30:19] Read Committed [00:32:03] Read
Uncommitted [00:33:39] Fehler bei parallelen Transaktionen
[00:34:12] Dirty Reads [00:36:37] Lost Updates [00:38:20]
Non-Repeatable Reads [00:40:05] Phantom Reads [00:42:17] Fehler den
Isolationsebenen zuordnen [00:44:36] Transaktionen in SQL und
Autocommit [00:46:58] BEGIN TRANSACTION, COMMIT und ROLLBACK
[00:48:26] Transaktionen mit ORMs [00:52:13] Jakarta Transactions
und Transaction Around [00:56:24] Verteilte Datenbanken und
Replikation [01:02:19] Das CAP-Theorem [01:03:32] Konsistenz bei
ACID und CAP [01:04:34] Die Eigenschaften von CAP [01:07:17] Die
BASE-Prinzipien [01:09:19] Verfügbarkeit am Beispiel eines
Streamingdienstes [01:11:35] Basically Available [01:12:15] Soft
State [01:12:53] Eventual Consistency [01:15:14] Shownotes und
Prüfungsrelevanz [01:16:43] Newsletter zur IT-Ausbildung Inhalt
Datenbanktransaktionen sollten jedem/jeder ITler:in etwas sagen, da
wir fast täglich mit datenbankgestützten Anwendungen arbeiten,
egal, ob wir selbst diese Anwendungen programmieren oder "nur"
Abfragen gegen eine Datenbank durchführen. Was ist eine
Datenbanktransaktion? Eine Transaktion ist eine Menge aus mehreren
zusammenhängenden Datenbankoperationen, die gemeinsam als eine
Einheit durchgeführt werden müssen. Beispiele für
Datenbanktransaktionen: Banküberweisung von 100 EUR von Konto DE123
auf Konto DE432 UPDATE konto SET kontostand = kontostand - 100
WHERE iban = 'DE123'; UPDATE konto SET kontostand = kontostand +
100 WHERE iban = 'DE432'; Neuen Tag katze zu einem Blog-Post mit ID
123 hinzufügen INSERT INTO tag (id, name) VALUES (1, 'katze');
INSERT INTO tag_post (post_id, tag_id) VALUES (123, 1); Neue
Bestellung für einen Kunden mit ID 324 erfassen für Artikel 253
INSERT INTO bestellung (id, datum, kunde_id) VALUES (123,
'2024-04-10', 324); INSERT INTO bestellposition (bestellung_id,
artikel_id, menge, preis) VALUES (123, 253, 1, 123.92); Neuen
Tarifsatz einer Versicherung anlegen und bisherigen beenden UPDATE
tarif SET gueltig_bis='2024-04-10' WHERE id=122; INSERT INTO tarif
(id, gueltig_ab, beitrag) VALUES (123, '2024-04-10', 143.23);
Begriffsabgrenzung Eine Datenbanktransaktion ist nicht zu
verwechseln mit einer Transaktion im Geschäftsbetrieb, z.B. einer
Überweisung bei einer Bank, dem Kauf eines Autos oder der Buchung
eines Fluges. Die ACID-Prinzipien Datenbanktransaktion
müssen/sollen bestimmten Kriterien genügen, die als ACID-Prinzipien
bekannt sind. Atomarität/Atomicity: Alle Datenbankoperationen
werden entweder vollständig gemeinsam durchgeführt oder gar nicht.
Es kann nicht sein, dass nur einige Operationen durchgeführt werden
und andere nicht. Dazu werden die Datenbankoperationen in eine
Transaktion "eingeklammert". Beispiel: Bei der Banküberweisung darf
nicht nur Geld abgebucht oder gutgeschrieben werden, sondern beide
Buchungen müssen gemeinsam durchgeführt werden.
Konsistenz/Consistency: Wenn die Datenbank vor der Transaktion in
einem konsistenten Zustand war, dann muss sie es auch nach der
Transaktion sein. Beispiel: Bei der Banküberweisung bleibt der
Gesamtbetrag an Geld gleich. Es entsteht kein Geld aus dem Nichts
und es geht auch kein Geld verloren. Isolation/Isolation: Mehrere
Transaktionen dürfen sich nicht gegenseitig beeinflussen. Hierzu
folgen weiter unten verschiedene Maßnahmen zur Umsetzung. Beispiel:
Bei zwei parallelen Banküberweisungen vom gleichen Konto müssen
beide Beträge nacheinander abgebucht werden und nicht nur der der
zuletzt durchgeführten Transaktion. Dauerhaftigkeit/Durability: Die
Daten müssen nach Abschluss der Transaktion persistent gespeichert
sein und z.B. auch einen Systemausfall überstehen. Das wird durch
sogenannte Transaktionslogs sichergestellt. Beispiel: Wenn nach dem
Abschluss einer Transaktion der Datenbankprozess abstürzt, müssen
auch nach dem Neustart der Datenbank die aktualisierten Daten
vorhanden sein. Maßnahmen zur Wahrung der Isolation von
Transaktionen Wenn Transaktionen nicht isoliert voneinander
ablaufen, können verschiedene Probleme in der Datenbank auftreten.
Dirty Read: Veränderte Daten einer noch offenen Transaktion werden
von einer anderen Transaktion gelesen und weisen somit einen
"dreckigen" Zustand auf, weil er noch nicht final ist. Beispiel:
Bei einem Ticketkauf geht die zweite Buchung schon vom veränderten
Bestand der ersten Transaktion aus. Lost Updates: Wenn zwei
Transaktionen gleichzeitig denselben Datensatz verändern, "gewinnt"
die Änderung der zuletzt durchgeführten Transaktion und die der
ersten ist verloren. Beispiel: Bei zwei Banküberweisungen wird der
Kontostand auf den Ursprungsstand abzgl. der zweiten Überweisung
gesetzt, aber ohne die erste Überweisung abzuziehen. Non-Repeatable
Read: Wiederholte Lesevorgänge innerhalb einer Transaktion liefern
unterschiedliche Ergebnisse. Beispiel: Bei einer Flugbuchung wird
geprüft, ob noch ausreichend Plätze frei sind, aber durch eine
parallele Buchung wird bei der zweiten Abfrage ein
unterschiedliches Ergebnis geliefert. Phantom Read: Während eine
Transaktion Datensätze nach einem bestimmten Kriterium liest,
werden weitere Datensätze zum gleichen Kriterium
hinzugefügt/gelöscht/verändert. Beispiel: Während der
Durchschnittsberechnung von Gehältern von Mitarbeiter:innen wird
ein neuer Mitarbeiter hinzugefügt, der beim Summieren des Gehalts
noch nicht berücksichtigt wird, aber beim Zählen der Datensätze
dann schon. Die Datenbank kann verschiedene
Transaktionsisolationsebenen implementieren, um den obigen
Problemen entgegenzuwirken. Grundsätzlich werden dabei Sperren
verwendet, um die gleichzeitige Verarbeitung der Daten
einzuschränken. Es kann dabei eine Lesesperre und/oder eine
Schreibsperre gesetzt werden, wodurch das gleichzeitige Lesen bzw.
Schreiben eingeschränkt wird. Read Uncommitted: Es werden keine
Sperren verwenden. Quasi kein Schutz vor obigen Problemen.
Vergleichbar mit NO ACTION bei referenzieller Integrität. Read
Committed: Für die gesamte Transaktion werden Schreibsperren auf
alle beteiligten Objekte gesetzt, die verändert werden sollen.
Lesesperren werden aber nur kurzzeitig gesetzt. Es können
Non-Repeatable Read und Phantom Read auftreten. Repeatable Read: Es
werden für die gesamte Transaktion Lese- und Schreibsperren auf
alle beteiligten Objekte gesetzt. Nur Phantom Reads können noch
auftreten (weil dabei zwei lesende Operationen mit
unterschiedlichen Kriterien durchgeführt werden). Serializable: Die
Datenbank verhält sich so, als würden die Transaktionen komplett
separiert nacheinander ("seriell") durchgeführt. Dabei kann keines
der obigen Probleme mehr auftreten, aber Transaktionen müssen ggfs.
abgebrochen werden. Starten z.B. zwei Flugbuchungen für zwei
Sitzplätze parallel auf dem Sitzplatzbestand von 2, wird die erste
Transaktion den Bestand auf 0 reduzieren und die zweite Transaktion
(die "gewartet" hat) muss abbrechen, weil die Sitzplätze nun nicht
mehr ausreichen. Umsetzung in SQL Mit der Transaction Control
Language (TCL) gibt es eine eigene Familie an SQL-Befehlen, die
sich nur um die Transaktionssteuerung kümmert. Hiermit können
Datenbankoperationen zu einer Transaktion zusammengefasst werden.
BEGIN TRANSACTION: Startet eine Datenbanktransaktion. COMMIT:
Beendet eine Datenbanktransaktion und schreibt die Änderungen fest.
ROLLBACK: Rollt eine Datenbanktransaktion zurück und verwirft alle
Änderungen. In vielen Datenbanken muss man nicht explizit
Transaktionen starten und beenden. Sie verwenden ein sogenanntes
Auto-Commit. Dabei wird jedes Statement in einer eigenen
Transaktion durchgeführt. Umsetzung in ORMs Brauche ich als
Softwareentwickler:in überhaupt Wissen über Datenbanktransaktionen?
In modernen Entwicklungsprojekten werden doch sowieso
objektrelationale Mapper (ORM) verwendet. Doch auch diese ORMs
können natürlich nicht zaubern, sondern verwenden unter der Haube
die normalen Datenbankoperationen. Daher ist auch bei Verwendung
eines ORMs wichtig zu wissen, welche Operationen in einer
gemeinsamen Transaktion durchgeführt werden müssen. Dafür bieten
viele ORMs entsprechende Befehle an. Jakarta EE hat sogar einen
eigenen Standard dafür: Jakarta Transactions (JTA). Dort wird z.B.
Annotation @Transactional verwendet. Diese wird an eine
Java-Methode geschrieben, die dann automatisch innerhalb einer
Datenbanktransaktion ausgeführt wird. Im Fall einer aufgetretenen
Exception wird dabei dann automatisch ein Rollback durchgeführt.
CAP und BASE Transaktionen nach den ACID-Prinzipien sind ein
wichtiger Bestandteil vieler Datenbanksysteme. Sobald die Datenbank
jedoch auf mehrere Knoten verteilt wird,...
Kommentare (0)
Melde dich an, um einen Kommentar zu schreiben.