Hallo zusammen. Hier spricht Wladislaw Rodin. Ich bin zurzeit der Leiter des Kurses „Architekt für hohe Lasten“ bei OTUS und unterrichte auch in Kursen, die sich mit Softwarearchitektur befassen.
Neben dem Unterrichten schreibe ich, wie Sie vielleicht bemerkt haben, originelle Inhalte für den OTUS-Blog auf Habr, und den heutigen Artikel möchte ich an den Start des Kurses , für den gerade die Anmeldungen geöffnet sind, anknüpfen.
Einführung
Im Wir haben darüber gesprochen, dass Transaktionen in Datenbanken zwei Aufgaben lösen: Gewährleistung der Fehlertoleranz und Zugriff auf Daten in einer konkurrierenden Umgebung. Um diese Aufgaben vollständig zu erfüllen, muss eine Transaktion über ACID-Eigenschaften verfügen. 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, indem sie faktisch Schutz vor Race Conditions bietet. Im Idealfall bedeutet Isolation Serialization, also eine Eigenschaft, die gewährleistet, dass das Ergebnis der parallelen Ausführung von Transaktionen dasselbe ist, als ob sie nacheinander ausgeführt worden wären. Das Hauptproblem dieser Eigenschaft besteht darin, dass sie technisch sehr schwer umsetzbar ist und in der Folge die Leistung des Systems stark beeinträchtigt. Aus diesem Grund wird die Isolation häufig abgeschwächt, indem Risiken für das Auftreten bestimmter Anomalien in Kauf genommen werden, über die wir im Folgenden sprechen werden. Die Möglichkeit des Auftretens bestimmter Anomalien charakterisiert gerade den Grad der Isolation von Transaktionen.
Die bekanntesten Anomalien sind: dirty read, non-repeatable read, phantom read, aber es gibt tatsächlich noch fünf weitere: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Die Essenz dieser Anomalie besteht darin, dass Transaktionen nicht festgeschriebene Daten überschreiben können.
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: Wenn wir erlauben, nicht festgeschriebene Daten zu überschreiben, ist unklar, wie eine Transaktion zurückgesetzt werden kann, ohne die andere zu beeinträchtigen.
Die Anomalie lässt sich recht einfach beheben: Wir setzen eine Schreibsperre vor Beginn des Schreibvorgangs, um anderen Transaktionen zu verbieten, die Aufzeichnung zu ändern, bis die Sperre aufgehoben wird.
Dirty read
Dirty read bedeutet das Lesen von nicht festgeschriebenen Daten.
Probleme treten auf, wenn auf der Basis einer Stichprobe Handlungen ausgeführt oder Entscheidungen getroffen werden müssen.
Um die Anomalie zu beheben, kann eine Lesesperre verhängt werden, aber das würde die Leistung erheblich beeinträchtigen. Es ist viel einfacher zu sagen, dass für das Rollback einer Transaktion der ursprüngliche Zustand der Daten (vor Beginn der Aufzeichnung) unbedingt im System gespeichert sein muss. Warum nicht von dort lesen? Das ist recht kostengünstig, weshalb die meisten Datenbanken dirty reads standardmäßig ausschließen.
Verlorenes Update
Verlorenes Update bedeutet verlorene Aktualisierungen, und die Übersetzung spiegelt das Kernproblem ziemlich genau wider:
Tatsächlich wurde das Ergebnis der Transaktion T2 zurückgesetzt. Diese Situation wird durch explizite oder implizite Schreibsperren korrigiert. Das heißt, entweder aktualisieren wir einfach den Datensatz, wodurch eine implizite Sperre entsteht, oder wir führen aus select for update, was eine Lese- und Schreibsperre verursacht. Beachten Sie, dass eine solche Operation ziemlich riskant ist: Mit unserem "unschuldigen" Lesen sperren wir andere Lesevorgänge. Einige Datenbanken bieten eine sicherere select for share, die das Lesen von Daten erlaubt, aber Änderungen nicht gestattet.
Cursor verlorenes Update
Zum besseren Zugang können Datenbanken andere Werkzeuge anbieten, wie 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 das Select beschrieben.
Warum wird ein Cursor benötigt? Einige Datenbanken bieten eine Sperre für alle Datensätze, die durch das Select ausgewählt wurden (read stability), oder nur für den Datensatz, auf dem sich der Cursor im Moment befindet (cursor stability). Bei der Cursor-Stabilität wird eine kurzfristige Sperre angewendet, die die Anzahl der Sperren verringert, wenn wir uns durch eine große Datenmenge iterieren. Daher wird die Anomalie des verlorenen Updates für Cursors gesondert behandelt.
Nicht-wiederholbare Lesevorgänge
Nicht-wiederholbare Lesevorgänge besagen, dass während der Ausführung unserer Transaktion 2 aufeinanderfolgende Lesevorgänge desselben Datensatzes zu unterschiedlichen Ergebnissen führen, weil eine andere Transaktion zwischen diesen beiden Lesevorgängen eingegriffen hat, unsere Daten geändert hat und festgeschrieben wurde.
Warum ist das überhaupt ein Problem? Stellen Sie sich vor, das Ziel der Transaktion T2 besteht darin, alle Produkte auszuwählen, deren Preis unter 150 Währungseinheiten liegt. Jemand anderes hat den Preis auf 200 Währungseinheiten aktualisiert. Somit hat der festgelegte Filter nicht funktioniert.
Diese Anomalien treten nicht mehr auf, wenn man Zwei-Phasen-Sperren hinzufügt oder den MVCC-Mechanismus verwendet, über den ich gerne separat sprechen würde.
Phantomlesung
Eine Phantomlesung bezeichnet das Lesen von Daten, die von einer anderen Transaktion hinzugefügt wurden.
Als Beispiel kann man feststellen, dass bei Auftreten dieser Anomalie die Auswahl des billigsten Produkts falsch ist.
Phantomlesungen zu beseitigen ist bereits recht schwierig. Eine einfache Sperre reicht nicht aus, da wir das, was noch nicht existiert, nicht sperren können. 2PL-Systeme verwenden prädikative Sperren, während die MVCC-Systeme Transaktionen abbrechen, die durch Einfügungen beeinträchtigt werden könnten. Beide Mechanismen sind recht schwerfällig.
Read Skew
Read Skew tritt auf, wenn wir mit mehreren Tabellen arbeiten, deren Inhalte konsistent geändert werden müssen.
Angenommen, wir haben Tabellen, die Posts und deren Metainformationen darstellen:
Eine Transaktion liest aus den Tabellen, eine andere verändert sie:
Im Ergebnis der Ausführung der Transaktion T1 hat der Post den Titel = Good und updated_by = T2, was eine gewisse Inkonsistenz darstellt.
Tatsächlich handelt es sich hierbei um eine nicht wiederholbare Lesung, jedoch in mehreren Tabellen.
Um dies zu beheben, kann T1 Sperren auf alle Zeilen setzen, die sie lesen wird, was der Transaktion T2 verbietet, Informationen zu ändern. Im Falle von MVCC wird die Transaktion T2 abgebrochen. Der Schutz vor dieser Anomalie kann wichtig werden, wenn wir Cursors verwenden.
Write Skew
Diese Anomalie lässt sich ebenfalls einfacher anhand eines Beispiels erklären: Angenommen, in unserem System muss mindestens ein Arzt im Dienst sein, doch beide Ärzte haben beschlossen, ihren Dienst abzusagen:
Die Anomalie führte dazu, dass keiner der Ärzte in den Dienst tritt. Wie konnte es dazu kommen? Weil die Transaktion eine Bedingung überprüfte, die von einer anderen Transaktion verletzt werden kann, und wir aufgrund der Isolation diese Änderung nicht gesehen haben.
Das ist dasselbe wie eine nicht wiederholbare Lesung. Alternativ können Select-Abfragen Sperren auf diese Datensätze setzen.
Write Skew und Read Skew sind Kombinationen der vorher genannten Anomalien. Write Skew kann als eine Art Phantom-Lesung betrachtet werden. Betrachten wir eine Tabelle, die die Namen der Mitarbeiter, ihre Gehälter und das Projekt, an dem sie arbeiten, enthält:
Insgesamt ergibt sich folgendes Bild: Jeder Manager dachte, dass seine Änderung nicht zu einem Budgetüberschreitung führen würde, weshalb sie personelle Änderungen vornahmen, die insgesamt zu einem Überschuss führten.
Der Grund für das Auftreten des Problems ist der gleiche wie bei Phantom-Lesungen.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Die Lockerung des Isolationsniveaus von Transaktionen in einer Datenbank ist ein Kompromiss zwischen Sicherheit und Leistung, und die Wahl dieses Niveaus sollte unter Berücksichtigung der potenziellen Risiken für das Unternehmen bei den verschiedenen Anomalien getroffen werden.
Quelle: habr.com
