Datenbanktransaktionen, ACID, CAP-Theorem und BASE – IT-Berufe-Podcast #187

IT-Berufe-Podcast

Um Datenbanktransaktionen, die ACID-Prinzipien und Alternativen dazu geht es in der einhundertsiebenundachzigsten Episode des IT-Berufe-Podcasts. 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,