Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Hallo zusammen. Hier ist Wladyslaw Rodin. Ich bin derzeit Leiter des Kurses „Architekt für hohe Lasten“ bei OTUS und unterrichte auch in Kursen über Softwarearchitektur.

Neben dem Unterricht schreibe ich, wie Sie wahrscheinlich bemerkt haben, Originalbeiträge für den OTUS-Blog auf Habr und möchte den heutigen Artikel dem Start des Kurses widmen, „PostgreSQL“für den gerade jetzt die Anmeldung geöffnet ist.

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Einführung

In das letzte Mal Wir haben darüber gesprochen, dass Transaktionen in Datenbanken zwei Aufgaben lösen: die Gewährleistung der Fehlertoleranz und den Datenzugriff in einer konkurrierenden Umgebung. Damit diese Aufgaben vollständig erfüllt werden können, muss eine Transaktion die ACID-Eigenschaften besitzen. Heute werden wir ausführlich über den Buchstaben I (Isolation) in diesem Akronym sprechen.

Isolierung

Isolation löst das Problem des Zugriffs auf Daten in einer konkurrierenden Umgebung und bietet im Wesentlichen Schutz vor Race Conditions. Idealerweise bedeutet Isolation Serialisierung, das heißt, eine Eigenschaft, die sicherstellt, dass das Ergebnis der parallelen Ausführung von Transaktionen dasselbe ist, als würden sie sequenziell ausgeführt werden. Das Hauptproblem dieser Eigenschaft besteht darin, dass sie technisch sehr schwer zu gewährleisten ist und somit die Systemleistung stark beeinträchtigt. Daher wird die Isolation häufig abgeschwächt, indem Risiken hinsichtlich des Auftretens bestimmter Anomalien eingegangen werden, auf die im Folgenden eingegangen wird. Die Möglichkeit des Auftretens unterschiedlicher Anomalien charakterisiert das Niveau der Transaktionsisolierung.

Die bekanntesten Anomalien sind: Dirty Read, Non-repeatable Read, Phantom Read, tatsächlich gibt es noch fünf weitere: Dirty Write, Cursor Lost Update, Lost Update, Read Skew, Write Skew.

Dirty Write

Die Essenz der Anomalie besteht darin, dass Transaktionen nicht bestätigte Daten überschreiben können.

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Diese Anomalie ist gefährlich, nicht nur weil Daten nach dem Commit beider Transaktionen in Konflikt geraten können (wie im Bild), sondern auch weil die Atomarität verletzt wird: Da wir das Überschreiben von nicht-committierten Daten zulassen, ist unklar, wie man eine Transaktion zurücksetzen kann, ohne dabei die andere zu beeinträchtigen.

Die Anomalie lässt sich relativ einfach beheben: Wir setzen vor Beginn des Schreibvorgangs eine Schreibsperre, die es anderen Transaktionen verbietet, die Aufzeichnung zu ändern, bis die Sperre aufgehoben wird.

Dirty read

Dirty read bedeutet das Lesen von nicht-committierten Daten.

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Probleme treten auf, wenn auf Basis einer Abfrage bestimmte Aktionen ausgeführt oder Entscheidungen getroffen werden müssen.

Um die Anomalie zu beheben, könnte man eine Lesesperre setzen, aber das würde die Leistung stark beeinträchtigen. Es ist viel einfacher zu sagen, dass für das Rollback einer Transaktion der ursprüngliche Zustand der Daten (vor dem Schreibvorgang) unbedingt im System gespeichert sein muss. Warum nicht von dort lesen? Das ist relativ kostengünstig, weshalb die meisten Datenbanken dirty reads standardmäßig ausschließen.

Lost update

Lost update bedeutet verlorene Updates, und die Übersetzung gibt das Problem ausreichend genau wieder:

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Tatsächlich wurde das Ergebnis der Transaktion T2 storniert. Solche Situationen werden durch explizite oder implizite Sperrungen des Datensatzes behoben. Das bedeutet, dass wir entweder einfach die Aktualisierung des Datensatzes durchführen, wodurch eine implizite Sperre entsteht, oder wir führen aus select for update, was zu einer Lesesperre und einer Schreibung führt. Beachten Sie, dass eine solche Operation recht riskant ist: Durch unser 'unschuldiges' Lesen sperren wir andere Lesevorgänge. Einige Datenbanken bieten eine sicherere select for share, die das Lesen von Daten ermöglicht, jedoch keine Änderungen daran zulässt.

Cursor lost update

Für eine genauere Kontrolle können Datenbanken andere Werkzeuge anbieten, zum Beispiel einen Cursor. Ein Cursor ist eine Struktur, die eine Menge von Zeilen enthält und es ermöglicht, über diese zu iterieren. declare cursor_name for select_statement. Der Inhalt des Cursors wird durch ein Select beschrieben.

Warum ist ein Cursor wichtig? Einige Datenbanken bieten entweder eine Sperrung für alle Datensätze, die durch ein SELECT ausgewählt werden (Read Stability), oder nur für den Datensatz, auf dem sich der Cursor gerade befindet (Cursor Stability). Bei der Cursor Stability wird eine kurze Sperre durchgeführt, was die Anzahl der Sperrungen verringert, wenn wir durch eine große Datenmenge iterieren. Daher wird das Phänomen des verlorenen Updates für den Cursor separat hervorgehoben.

Nicht wiederholbares Lesen

Nicht wiederholbares Lesen tritt auf, wenn während der Ausführung unserer Transaktion zwei aufeinanderfolgende Lesevorgänge des gleichen Datensatzes zu unterschiedlichen Ergebnissen führen, weil eine andere Transaktion zwischen diesen beiden Lesevorgängen eingreift, unsere Daten ändert und dann abgeschlossen wird.

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Warum ist das überhaupt ein Problem? Stellen Sie sich vor, das Ziel der Transaktion T2 auf dem Bild besteht darin, alle Artikel auszuwählen, deren Preis unter 150 Währungseinheiten liegt. Jemand hat den Preis auf 200 Währungseinheiten aktualisiert. Der festgelegte Filter hat dadurch nicht funktioniert.

Diese Datenanomalien treten nicht mehr auf, wenn zwei-phasige Sperren hinzugefügt werden oder wenn das MVCC-Mechanismus verwendet wird, über das wir gesondert sprechen möchten.

Phantomlesen

Phantome werden als das Lesen von Daten bezeichnet, die von einer anderen Transaktion hinzugefügt wurden.

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Ein Beispiel hierfür ist die falsche Auswahl des billigsten Produkts, wenn diese Anomalie auftritt.

Phantomlesungen zu beseitigen ist bereits schwierig genug. Gewöhnliche Sperren sind nicht ausreichend, da wir nicht das blockieren können, was noch nicht existiert. 2PL-Systeme verwenden prädikative Sperren, während MVCC-Systeme Transaktionen zurücksetzen, die durch Einfügungen gestört werden könnten. Sowohl der erste als auch der zweite Mechanismus sind recht schwerfällig.

Read skew

Read skew tritt auf, wenn wir mit mehreren Tabellen arbeiten, deren Inhalt konsistent geändert werden sollte.

Angenommen, es gibt Tabellen, die Beiträge und deren Metainformationen darstellen:

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Eine Transaktion liest aus den Tabellen, während eine andere sie verändert:

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

In Folge der Ausführung der Transaktion T1 hat der Beitrag den Titel = Good und updated_by = T2, was eine gewisse Inkonsistenz darstellt.

Tatsächlich ist dies ein non-repeatable read, jedoch über mehrere Tabellen hinweg.

Um das zu beheben, kann T1 Sperren auf alle Zeilen setzen, die sie lesen wird, was T2 daran hindert, Informationen zu ändern. Im Falle von MVCC wird die Transaktion T2 abgebrochen. Der Schutz vor dieser Anomalie kann wichtig werden, wenn wir Cursor verwenden.

Write skew

Diese Anomalie lässt sich ebenfalls leichter anhand eines Beispiels erklären: Angenommen, in unserem System muss mindestens ein Arzt im Dienst sein, aber beide Ärzte haben beschlossen, ihren Dienst abzusagen:

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Die Anomalie führte dazu, dass keiner der Ärzte zum Dienst erscheint. Wie konnte das passieren? Weil die Transaktion eine Bedingung überprüfte, die von einer anderen Transaktion verletzt werden kann, und aufgrund der Isolation haben wir diese Änderung nicht gesehen.

Das ist dasselbe wie ein non-repeatable read. Alternativ könnten die Select-Abfragen Sperren auf diesen Datensätzen setzen.

Write skew und read skew sind Kombinationen der vorherigen Anomalien. Man kann write skew betrachten, das im Grunde ein phantom read ist. Betrachten wir eine Tabelle mit den Namen der Mitarbeiter, ihrem Gehalt und dem Projekt, an dem sie arbeiten:

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Welche Folgen kann eine Schwächung des Isolationsniveaus in Datenbanktransaktionen haben?

Am Ende ergibt sich folgendes Bild: Jeder Manager dachte, dass seine Änderung nicht zu Budgetüberschreitungen führen würde, weshalb sie personelle Veränderungen vorgenommen haben, die insgesamt zu Mehrkosten führten.

Der Grund für das Auftreten des Problems ist genau der gleiche wie beim phantom reads.

Fazit

Die Herabsetzung des Isolationslevels von Transaktionen in Datenbanken ist ein Kompromiss zwischen Sicherheit und Leistung. Die Wahl dieses Levels sollte auf Basis der potenziellen Risiken für das Unternehmen bei dem Auftreten bestimmter Anomalien erfolgen.

Weitere Informationen zum Kurs erhalten.

Quelle: habr.com

Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen 🔥 Zuverlässiges Webhosting mit DDoS-Schutz, VPS- und VDS-Server kaufen | ProHoster