Hallo zusammen. Vladislav Rodin ist in Kontakt. Ich bin derzeit Kursleiter für den High Workload Architect-Kurs bei OTUS und unterrichte auch Software-Architekturkurse.
Wie Sie vielleicht bemerkt haben, schreibe ich neben dem Unterrichten auch Originalmaterial für den OTUS-Blog auf Habré und möchte den heutigen Artikel zeitgleich mit dem Start des Kurses veröffentlichen , die ab sofort zur Anmeldung geöffnet ist.
Einführung
В Wir haben darüber gesprochen, dass Transaktionen in Datenbanken dazu dienen, zwei Probleme zu lösen: die Gewährleistung von Fehlertoleranz und den Zugriff auf Daten in einem Wettbewerbsumfeld. Um diese Aufgaben vollständig ausführen zu können, muss die Transaktion über ACID-Eigenschaften verfügen. Heute werden wir ausführlich über den Brief sprechen Ich (Isolation) in dieser Abkürzung.
Isolierung
Die Isolierung löst das Problem des Datenzugriffs in einer Wettbewerbsumgebung und bietet im Wesentlichen Schutz vor Wettlaufbedingungen. Im Idealfall bedeutet Isolation Serialisierung. Dabei handelt es sich um eine Eigenschaft, die sicherstellt, dass das Ergebnis parallel ausgeführter Transaktionen dasselbe ist, als ob sie sequentiell ausgeführt würden. Das Hauptproblem dieser Eigenschaft besteht darin, dass sie technisch sehr schwierig bereitzustellen ist und dadurch erhebliche Auswirkungen auf die Systemleistung hat. Aus diesem Grund wird die Isolation häufig geschwächt und die Risiken bestimmter Anomalien in Kauf genommen, auf die weiter unten eingegangen wird. Die Möglichkeit des Auftretens bestimmter Anomalien charakterisiert genau den Grad der Transaktionsisolation.
Die bekanntesten Anomalien sind: Dirty Read, Non-Repeatable Read, Phantom Read, aber tatsächlich gibt es noch fünf weitere: Dirty Write, Cursor Lost Update, Lost Update, Read Skew, Write Skew.
Schmutziges Schreiben
Der Kern der Anomalie besteht darin, dass Transaktionen nicht festgeschriebene Daten überschreiben können.
Diese Anomalie ist nicht nur deshalb gefährlich, weil es nach der Festschreibung beider Transaktionen zu Datenkonflikten kommen kann (wie im Bild), sondern auch, weil die Atomizität verletzt wird: Da wir das Überschreiben nicht festgeschriebener Daten zulassen, ist nicht klar, wie eine Transaktion rückgängig gemacht werden kann, ohne dass sich dies auf eine andere auswirkt .
Die Anomalie kann ganz einfach behandelt werden: Wir versehen den Datensatz mit einer Sperre, bevor wir mit der Aufzeichnung beginnen, und verhindern so, dass andere Transaktionen den Datensatz ändern, bis die Sperre entfernt wird.
Schmutzige Lektüre
Unter Dirty Read versteht man das Lesen nicht festgeschriebener Daten.
Probleme entstehen, wenn auf der Grundlage der Stichprobe Maßnahmen oder Entscheidungen getroffen werden müssen.
Um die Anomalie zu beheben, können Sie eine Lesesperre anbringen, die jedoch die Leistung stark beeinträchtigt. Viel einfacher ist es zu sagen, dass für eine Rollback-Transaktion der Ausgangszustand der Daten (vor Beginn der Aufzeichnung) im System gespeichert werden muss. Warum nicht von dort lesen? Es ist so kostengünstig, dass die meisten Datenbanken Dirty Read standardmäßig entfernen.
Update verloren
Verlorenes Update bedeutet verlorene Updates, und die Übersetzung spiegelt den Kern des Problems ziemlich genau wider:
Tatsächlich wurde das Ergebnis der Transaktion T2 rückgängig gemacht. Diese Situation kann durch explizite oder implizite Schreibsperren behoben werden. Das heißt, wir aktualisieren entweder einfach den Datensatz und dann erfolgt eine implizite Sperre, oder wir führen eine Aktion durch Zum Aktualisieren auswählen, wodurch eine Lese- und Schreibsperre entsteht. Bitte beachten Sie, dass eine solche Operation ziemlich gefährlich ist: Mit unserer „unschuldigen“ Lesung blockieren wir andere Lesungen. Einige Datenbanken bieten mehr Sicherheit Zum Teilen auswählen, sodass Daten gelesen, aber nicht geändert werden können.
Cursor hat Aktualisierung verloren
Für eine feinere Steuerung bieten Basen möglicherweise andere Tools an, beispielsweise einen Cursor. Ein Cursor ist eine Struktur, die eine Reihe von Zeilen enthält und es Ihnen ermöglicht, über diese zu iterieren. deklarieren Sie Cursorname für select_statement. Der Inhalt des Cursors wird durch Select beschrieben.
Warum brauchen Sie einen Cursor? Tatsache ist, dass einige Datenbanken eine Sperre für alle durch Select ausgewählten Datensätze anbieten (Lesestabilität) oder nur für den Datensatz, auf dem sich der Cursor gerade befindet (Cursorstabilität). Mit der Cursorstabilität wird eine kurze Sperre implementiert, die es uns ermöglicht, die Anzahl der Sperren zu reduzieren, wenn wir über eine große Datenstichprobe iterieren. Daher wird die Anomalie „Lost Update“ separat für den Cursor isoliert.
Nicht wiederholbare Lektüre
Nicht wiederholbares Lesen bedeutet, dass während der Ausführung unserer Transaktion zwei aufeinanderfolgende Lesevorgänge desselben Datensatzes zu unterschiedlichen Ergebnissen führen, da zwischen diesen beiden Lesevorgängen eine andere Transaktion eingegriffen hat, unsere Daten geändert und festgeschrieben wurde.
Warum ist das überhaupt ein Problem? Stellen Sie sich vor, dass das Ziel der Transaktion T2 im Bild darin besteht, alle Waren auszuwählen, deren Preis weniger als 150 USD beträgt. Jemand anderes hat den Preis auf 200 $ aktualisiert. Somit funktionierte der installierte Filter nicht.
Diese Anomalien treten nicht mehr auf, wenn zweiphasige Verriegelungen hinzugefügt werden oder wenn der MVCC-Mechanismus verwendet wird, worauf ich gesondert eingehen möchte.
Phantom gelesen
Phantom ist ein Lesevorgang von Daten, die durch eine andere Transaktion hinzugefügt wurden.
Als Beispiel können wir die falsche Auswahl des günstigsten Produkts beobachten, wenn diese Anomalie auftritt.
Phantom Reads loszuwerden, ist bereits ziemlich schwierig. Regelmäßiges Blockieren reicht nicht aus, denn wir können nichts blockieren, was noch nicht existiert. 2PL-Systeme verwenden vorausschauendes Sperren, während MVCC-Systeme über einen Transaktionsplaner verfügen, der Transaktionen zurücksetzt, die durch eine Einfügung unterbrochen werden könnten. Sowohl der erste als auch der zweite Mechanismus sind ziemlich schwer.
Lesefehler
Leseverzerrungen treten auf, wenn wir mit mehreren Tabellen arbeiten, deren Inhalte sich ständig ändern müssen.
Nehmen wir an, wir haben Tabellen, die Beiträge und ihre Metainformationen darstellen:
Eine Transaktion liest aus den Tabellen, die andere ändert sie:
Aufgrund der Transaktion T1 hat der Beitrag den Titel „Gut“ und „Updated_by“ = T2, was eine Art Inkonsistenz darstellt.
Tatsächlich handelt es sich hierbei um einen nicht wiederholbaren Lesevorgang, jedoch als Teil mehrerer Tabellen.
Um dies zu beheben, kann T1 alle Zeilen, die es liest, sperren, wodurch verhindert wird, dass Transaktion T2 die Informationen ändert. Im Falle von MVCC wird die T2-Transaktion abgebrochen. Der Schutz vor dieser Anomalie kann wichtig werden, wenn wir Cursor verwenden.
Schräg schreiben
Auch diese Anomalie lässt sich anhand eines Beispiels leichter erklären: Angenommen, in unserem System sollte mindestens ein Arzt im Dienst sein, aber beide Ärzte haben beschlossen, ihren Dienst abzusagen:
Die Anomalie bedeutete, dass keiner der Ärzte im Dienst war. Warum ist das passiert? Da die Transaktion eine Bedingung überprüfte, die von einer anderen Transaktion verletzt werden könnte, konnten wir diese Änderung aufgrund der Isolation nicht feststellen.
Dies ist derselbe, nicht wiederholbare Lesevorgang. Alternativ können Selects Sperren für diese Datensätze festlegen.
Schreibversatz und Leseversatz sind Kombinationen der vorherigen Anomalien. Sie können einen Schreibversatz in Betracht ziehen, bei dem es sich im Wesentlichen um einen Phantom-Lesevorgang handelt. Stellen Sie sich eine Tabelle vor, die die Namen der Mitarbeiter, ihre Gehälter und das Projekt, an dem sie arbeiten, enthält:
Als Ergebnis erhalten wir folgendes Bild: Jeder Manager war der Meinung, dass seine Änderung nicht zu einer Überschreitung des Budgets führen würde, und nahm daher Personaländerungen vor, die zusammen zu Kostenüberschreitungen führten.
Die Ursache des Problems ist genau die gleiche wie beim Phantomlesen.
Befund
Die Lockerung der Transaktionsisolationsstufe in der Datenbank ist ein Kompromiss zwischen Sicherheit und Leistung; die Wahl dieser Stufe sollte auf der Grundlage der potenziellen Risiken für das Unternehmen getroffen werden, wenn bestimmte Anomalien auftreten.
Source: habr.com