🍖 🧘🏼 ☦️ Was kann sich aus der Schwächung der Transaktionsisolation in Datenbanken ergeben? 🤜🏾 🔣 👩🏼‍⚕️

Hallo alle zusammen. In Kontakt Vladislav Rodin. Ich bin derzeit Leiter des High Load Architect-Kurses bei OTUS und unterrichte auch Kurse über Softwarearchitektur.

Wie Sie vielleicht bemerkt haben, unterrichte ich neben dem Unterrichten auch urheberrechtlich geschütztes Material für den OTUS-Blog im Hub und möchte mit dem heutigen Artikel zusammenfallen, um den "PostgreSQL" -Kurs zu starten , der derzeit für die Rekrutierung offen ist.

Einführung

Das letzte Mal haben Sie und ich über diese Transaktion in Datenbanken gesprochen, die für zwei Zwecke verwendet wurden: um Fehlertoleranz und Datenzugriff in einem wettbewerbsorientierten Umfeld sicherzustellen. Um diese Aufgaben auszuführen, muss eine Transaktion über ACID-Eigenschaften verfügen. Heute werden wir in dieser Abkürzung ausführlich über den Buchstaben I (Isolation) sprechen .

Isolierung

Die Isolation löst das Problem des Zugriffs auf Daten in einem Wettbewerbsumfeld und bietet wirksamen Schutz vor Rennbedingungen. Im Idealfall bedeutet Isolation Serialisierung, dh eine Eigenschaft, die sicherstellt, dass das Ergebnis der parallelen Ausführung von Transaktionen dasselbe ist, als ob sie nacheinander ausgeführt würden. Das Hauptproblem dieser Eigenschaft besteht darin, dass sie technisch sehr schwierig bereitzustellen ist und daher einen erheblichen Einfluss auf die Systemleistung hat. Aus diesem Grund wird die Isolation häufig geschwächt, wodurch die Risiken einiger Anomalien akzeptiert werden, auf die weiter unten eingegangen wird. Die Möglichkeit, dass bestimmte Anomalien auftreten, kennzeichnet den Grad der Transaktionsisolation.

Die bekanntesten Anomalien sind: Dirty Read, nicht wiederholbares Lesen, Phantom Read, aber tatsächlich gibt es 5 weitere: Dirty Write, Aktualisierung des Cursors verloren, Update verloren, Leseversatz, Schreibversatz.

Schmutziges Schreiben

Das Wesentliche der Anomalie ist, dass Transaktionen nicht festgeschriebene Daten überschreiben können.

Bild

Diese Anomalie ist nicht nur gefährlich, weil die Daten nach dem Festschreiben beider Transaktionen (wie im Bild) in Konflikt geraten können, sondern auch, weil die Atomizität verletzt wird: Da wir das Überschreiben nicht gesperrter Daten zulassen, ist nicht klar, wie eine Transaktion zurückgesetzt werden kann, ohne die andere zu treffen .

Die Anomalie wird ganz einfach behandelt: Wir legen die Schreibsperre auf, bevor die Aufzeichnung beginnt, und verbieten anderen Transaktionen, die Aufzeichnung zu ändern, bis die Sperre aufgehoben wird.

Schmutzige Lektüre

Dirty Read bedeutet das Lesen nicht festgeschriebener Daten.

Bild

Probleme treten auf, wenn anhand einer Stichprobe einige Maßnahmen durchgeführt oder Entscheidungen getroffen werden müssen.

Um die Anomalie zu beheben, können Sie eine Lesesperre aufhängen, die jedoch die Leistung stark beeinträchtigt. Es ist viel einfacher zu sagen, dass für eine Rollback-Transaktion der Anfangszustand der Daten (vor der Aufzeichnung) im System gespeichert werden muss. Warum nicht von dort lesen? Dies ist ziemlich kostengünstig, daher entfernen die meisten Datenbanken standardmäßig fehlerhaftes Lesen.

Update verloren

Verlorene Aktualisierung bedeutet verlorene Aktualisierungen, und die Übersetzung spiegelt genau das Wesentliche des Problems wider:

Bild

Tatsächlich wurde das Ergebnis der Transaktion T2 abgebrochen. Diese Situation wird durch explizite oder implizite Schreibsperren behoben. Das heißt, wir aktualisieren entweder einfach den Datensatz und dann tritt eine implizite Sperre auf, oder wir führen eine Auswahl für die Aktualisierung durch , wodurch eine Lese- und Schreibsperre auftritt. Bitte beachten Sie, dass eine solche Operation ziemlich gefährlich ist: Mit unserer „unschuldigen“ Lesung blockieren wir andere Lesungen. Einige Datenbanken bieten eine sicherere Auswahl für die Freigabe , mit der Sie Daten lesen, aber nicht ändern können.

Cursor hat Update verloren

Für eine feinere Steuerung können Basen andere Werkzeuge anbieten, beispielsweise einen Cursor. Ein Cursor ist eine Struktur, die eine Reihe von Linien enthält und über die Sie iterieren können. Deklarieren Sie den Cursornamen für select_statement . Der Inhalt des Cursors wird durch Auswahl beschrieben.

Warum brauchen wir einen Cursor? Tatsache ist, dass einige Datenbanken eine Sperre für alle Datensätze bieten, die durch Auswahl ausgewählt wurden (Lesestabilität), oder nur für den Datensatz, auf dem sich der Cursor gerade befindet (Cursorstabilität). Mit der Cursor-Stabilität wird eine kurze Sperre implementiert, mit der wir die Anzahl der Sperren reduzieren können, wenn wir über eine große Datenprobe iterieren. Daher wird die verlorene Aktualisierungsanomalie für den Cursor separat hervorgehoben.

Nicht wiederholbares Lesen

Nicht wiederholbares Lesen bedeutet, dass während der Ausführung unserer Transaktion 2 aufeinanderfolgende Lesevorgänge desselben Datensatzes zu unterschiedlichen Ergebnissen führen, da eine andere Transaktion zwischen diesen beiden Lesevorgängen intervenierte, unsere Daten änderte und festgeschrieben wurde.

Bild

Warum ist das überhaupt ein Problem? Stellen Sie sich vor, der Zweck der Transaktion T2 im Bild besteht darin, alle Produkte auszuwählen, deren Preis weniger als 150 cu beträgt Jemand anderes hat den Preis auf 200 US-Dollar aktualisiert Somit funktionierte der installierte Filter nicht.

Diese Anomalien treten nicht mehr auf, wenn zweiphasige Sperren hinzugefügt werden oder wenn der MVCC-Mechanismus verwendet wird, über den ich separat sprechen möchte.

Phantom gelesen

Phantom liest Daten, die von einer anderen Transaktion hinzugefügt wurden.

Bild

Wenn diese Anomalie auftritt, können Sie beispielsweise die falsche Auswahl des billigsten Produkts beobachten.

Phantomwerte loszuwerden ist schon ziemlich schwierig. Normales Blockieren reicht nicht aus, da wir nicht blockieren können, was noch nicht verfügbar ist. 2PL-Systeme verwenden Predictive Locking, während MVCC-Systeme einen Transaktionsplaner verwenden, um Transaktionen abzubrechen, die durch eine Einfügung unterbrochen werden könnten. Sowohl der erste als auch der zweite Mechanismus sind ziemlich schwer.

Schrägstellung lesen

Leseversatz entsteht, wenn wir mit mehreren Tabellen arbeiten, deren Inhalt sich konsistent ändern sollte.

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

Bild

Eine Transaktion liest aus Tabellen, eine andere ändert sie:

Bild

Als Ergebnis der Transaktion T1 hat der Beitrag den Titel = Gut und aktualisiert_durch = T2, was eine gewisse Inkonsistenz darstellt.

Tatsächlich ist dies ein nicht wiederholbarer Lesevorgang, der jedoch Teil mehrerer Tabellen ist.

Zur Korrektur kann T1 Sperren für alle zu lesenden Zeilen aufhängen, wodurch verhindert wird, dass T2 Informationen ändert. Bei MVCC wird die Transaktion T2 abgebrochen. Der Schutz vor dieser Anomalie kann wichtig werden, wenn wir Cursor verwenden.

Schiefe schreiben

Diese Anomalie lässt sich auch anhand eines Beispiels leichter erklären: Nehmen wir an, dass in unserem System mindestens ein Arzt im Dienst sein muss, aber beide Ärzte beschließen, ihren Dienst zu kündigen: Die

Bild

Anomalie hat dazu geführt, dass keiner der Ärzte im Dienst sein wird. Warum ist das passiert? Da die Transaktion eine Bedingung überprüft hat, die möglicherweise von einer anderen Transaktion verletzt wurde, und aufgrund der Isolation, wurde diese Änderung nicht angezeigt.

Dies ist der gleiche nicht wiederholbare Lesevorgang. Alternativ können ausgewählte Elemente Sperren für diese Datensätze aufhängen.

Schreibversatz und Leseversatz sind Kombinationen früherer Anomalien. Sie können einen Schreibversatz in Betracht ziehen, der im Wesentlichen ein Phantom-Lesevorgang ist. Stellen Sie sich eine Tabelle vor, in der die Namen der Mitarbeiter, ihr Gehalt und das Projekt, an dem sie arbeiten, aufgeführt sind:

Bild

Als Ergebnis erhalten wir das folgende Bild: Jeder Manager war der Meinung, dass seine Änderung nicht zum Budget führen würde, und nahm daher personelle Änderungen vor, die insgesamt zu einem Überlauf führten.

Die Ursache des Problems ist genau die gleiche wie beim Phantomlesen.

Ergebnisse

Die Schwächung der Transaktionsisolation in der Datenbank stellt einen Kompromiss zwischen Sicherheit und Leistung dar. Die Wahl dieser Stufe sollte auf der Grundlage potenzieller Risiken für das Unternehmen im Falle von Anomalien getroffen werden.

Erfahren Sie mehr über den Kurs.

Was kann sich aus der Schwächung der Transaktionsisolation in Datenbanken ergeben?