Transaktionen in globalen InterSystems IRIS

Die InterSystems IRIS-Datenbank unterstützt interessante Datenstrukturen – Global-Variablen. Im Grunde handelt es sich dabei um mehrstufige Schlüssel mit verschiedenen zusätzlichen Funktionen wie Transaktionen, schnellen Methoden zur Navigierung in Datenbäumen, Sperrmechanismen und einer eigenen Sprache, ObjectScript.

Mehr zu Global-Variablen finden Sie in der Artikelreihe „Global-Variablen – die Schätze der Datenspeicherung“:

Bäume. Teil 1
Bäume. Teil 2
Sparsame Arrays. Teil 3

Ich war neugierig, wie Transaktionen in Global-Variablen umgesetzt sind und welche Besonderheiten es dabei gibt. Schließlich handelt es sich um eine völlig andere Struktur zur Datenspeicherung als die uns vertrauten Tabellen – viel tiefer in der Ebene.

Wie aus der Theorie relationaler Datenbanken bekannt ist, sollte eine gute Implementierung von Transaktionen die Anforderungen erfüllen ACID:

A — Atomic (Atomarität). Alle Änderungen, die in einer Transaktion vorgenommen werden, müssen entweder vollständig erfasst oder gar nicht gespeichert werden.

C — Consistency (Konsistenz). Nach Abschluss der Transaktion muss der logische Zustand der Datenbank intern widerspruchsfrei sein. Dieses Erfordernis betrifft in hohem Maße den Programmierer, ist aber auch für relationale SQL-Datenbanken relevant und betrifft die externen Schlüssel.

I — Isolation (Isolation). Parallel ausgeführte Transaktionen dürfen sich nicht gegenseitig beeinflussen.

D — Durable (Beständigkeit). Nach dem erfolgreichen Abschluss einer Transaktion sollten Probleme auf unteren Ebenen (zum Beispiel Stromausfälle) keinen Einfluss auf die durch die Transaktion geänderten Daten haben.

Globals sind nicht-relationale Datenstrukturen. Sie wurden für eine extrem schnelle Ausführung auf sehr begrenzter Hardware entwickelt. Lassen Sie uns die Implementierung von Transaktionen in Globals mithilfe von dem offiziellen Docker-Image von IRIS.

Für die Unterstützung von Transaktionen in IRIS werden die folgenden Befehle verwendet: TSTART, TCOMMIT, TROLLBACK.

1. Atomarität

Die Überprüfung der Atomarität ist am einfachsten. Wir überprüfen dies über die Datenbankkonsole.

Kill ^a
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TCOMMIT

Dann ziehen wir folgende Schlussfolgerung:

Write ^a(1), “ ”, ^a(2), “ ”, ^a(3)

Wir erhalten:

1 2 3

Alles in Ordnung. Die Atomarität wurde gewahrt: Alle Änderungen wurden gespeichert.

Lassen Sie uns die Aufgabe erschweren, einen Fehler einführen und sehen, wie die Transaktion gespeichert wird, teilweise oder gar nicht.

Überprüfen wir erneut die Atomarität:

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3

Danach stoppen wir den Container gewaltsam, starten ihn neu und schauen nach.

docker kill my-iris

Dieser Befehl ist praktisch das Äquivalent zu einem gewaltsamen Ausschalten des Stroms, da er ein sofortiges Stoppsignal für den Prozess SIGKILL sendet.

Könnte die Transaktion teilweise gespeichert worden sein?

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

— Nein, es wurde nichts gespeichert.

Testen wir den Rollback-Befehl:

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TROLLBACK

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

Es wurde ebenfalls nichts gespeichert.

2. Konsistenz

Da in den Globals die Schlüssel ebenfalls auf den Globals basieren (ich erinnere daran, dass ein Global eine niedrigere Datenspeicherstruktur als eine relationale Tabelle ist), muss für die Einhaltung der Konsistenz die Änderung des Schlüssels in dieselbe Transaktion einbezogen werden, wie die Änderung des Globals.

Zum Beispiel haben wir ein Global ^person, in dem wir Personen speichern, und als Schlüssel verwenden wir die Steueridentifikationsnummer.

^person(1234567, 'firstname') = 'Sergey'
^person(1234567, 'lastname') = 'Kamenev'
^person(1234567, 'phone') = '+74995555555
...

Um eine schnelle Suche nach Nachnamen und Vornamen zu ermöglichen, haben wir den Schlüssel ^index erstellt.

^index('Kamenev', 'Sergey', 1234567) = 1

Damit die Datenbank konsistent bleibt, müssen wir die Person so hinzufügen:

TSTART
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1
TCOMMIT

Daher müssen wir bei einer Löschung ebenfalls eine Transaktion verwenden:

TSTART
Kill ^person(1234567)
ZKill ^index(‘Kamenev’, ‘Sergey’, 1234567)
TCOMMIT

Mit anderen Worten, die Einhaltung des Konsistenzanspruchs liegt vollständig in der Verantwortung des Programmierers. Wenn es um globale Variablen geht, ist das jedoch in Ordnung, aufgrund ihrer niedrigen Abstraktionsebene.

3. Isolation

Hier wird es kompliziert. Viele Benutzer arbeiten gleichzeitig an derselben Datenbank und ändern dieselben Daten.

Die Situation ist vergleichbar mit vielen Benutzern, die gleichzeitig an demselben Code-Repository arbeiten und versuchen, gleichzeitig Änderungen an vielen Dateien zu committen.

Die Datenbank muss all dies in Echtzeit bewältigen. In ernsthaften Unternehmen gibt es sogar spezielle Personen, die für die Versionskontrolle (für das Zusammenführen von Branches, das Lösen von Konflikten usw.) zuständig sind, während die Datenbank all dies in Echtzeit erledigen muss. Daher wird die Komplexität der Aufgabe und die Richtigkeit des Datenbankdesigns sowie des Codes, der sie betreut, offensichtlich.

Die Datenbank kann den Sinn der von den Nutzern durchgeführten Aktionen nicht verstehen, um Konflikte zu vermeiden, wenn sie an denselben Daten arbeiten. Sie kann lediglich eine Transaktion, die einer anderen widerspricht, zurücknehmen oder diese nacheinander ausführen.

Ein weiteres Problem besteht darin, dass während der Ausführung einer Transaktion (vor dem Commit) der Zustand der Datenbank inkonsistent sein kann. Daher ist es wünschenswert, dass andere Transaktionen keinen Zugriff auf einen inkonsistenten Zustand der Datenbank haben, was in relationalen Datenbanken auf verschiedene Weise erreicht wird: durch das Erstellen von Snapshots, Mehrversionen von Zeilen usw.

Bei der parallelen Ausführung von Transaktionen ist es wichtig, dass sie sich nicht gegenseitig stören. Das ist das Isolationsmerkmal.

SQL definiert 4 Isolationsebenen:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Betrachten wir jede Ebene einzeln. Die Implementierungskosten jeder Ebene steigen beinahe exponentiell.

READ UNCOMMITTED — dies ist die niedrigste Isolationsebene, aber gleichzeitig die schnellste. Transaktionen können Änderungen lesen, die von anderen vorgenommen wurden.

READ COMMITTED — dies ist die nächste Isolationsebene, die einen Kompromiss darstellt. Transaktionen können keine Änderungen lesen, die von anderen vorgenommen wurden, bis diese festgeschrieben sind, aber sie können alle Änderungen lesen, die nach dem Commit vorgenommen wurden.

Wenn wir eine lange Transaktion T1 haben, während der Commits in den Transaktionen T2, T3 … Tn stattfinden, die mit denselben Daten arbeiten wie T1, werden wir bei einer Abfrage von Daten in T1 jedes Mal ein anderes Ergebnis erhalten. Dieses Phänomen wird als nicht wiederholbare Lesung bezeichnet.

REPEATABLE READ — In diesem Isolationsniveau gibt es kein Phänomen des wiederholten Lesens, da für jede Datenleseanfrage eine Momentaufnahme der Daten erstellt wird und bei der erneuten Verwendung in derselben Transaktion die Daten aus der Momentaufnahme verwendet werden. Allerdings ist in diesem Isolationsniveau das Lesen von Phantomdaten möglich. Das bedeutet das Lesen neuer Zeilen, die von parallel fixierten Transaktionen hinzugefügt wurden.

SERIALIZABLE — Die höchste Stufe der Isolation. Sie zeichnet sich dadurch aus, dass Daten, die in einer Transaktion auf irgendeine Weise verwendet werden (lesen oder ändern), für andere Transaktionen erst nach Abschluss der ersten Transaktion verfügbar sind.

Lassen Sie uns zunächst herausfinden, ob es eine Isolation der Operationen in der Transaktion vom Hauptthread gibt. Öffnen wir 2 Terminalfenster.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Es gibt keine Isolation. Ein Thread sieht, was der andere, der die Transaktion eröffnet hat, macht.

Lassen Sie uns überprüfen, ob die Transaktionen unterschiedlicher Threads das sehen, was innerhalb von ihnen passiert.

Öffnen wir 2 Terminalfenster und initiieren wir 2 Transaktionen parallel.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Parallele Transaktionen sehen einander die Daten. Daher haben wir die einfachste, aber auch schnellste Isolationsstufe READ UNCOMMITTED erreicht.

Das war grundsätzlich für globale Transaktionen zu erwarten, bei denen die Leistung stets im Vordergrund steht.

Was ist, wenn wir benötigen, eine höhere Isolationsstufe für die Operationen auf den globalen Transaktionen?

Hier sollten wir darüber nachdenken, warum Isolationsstufen überhaupt notwendig sind und wie sie funktionieren.

Die höchste Isolationsstufe SERIALIZE bedeutet, dass das Ergebnis parallel ausgeführter Transaktionen dem sequenziellen Ablauf entspricht, was Kollisionen ausschließt.

Das können wir mit geeigneten Sperren in ObjectScript erreichen, die zahlreiche Anwendungsmöglichkeiten bieten: man kann einfache, inkrementelle oder multiple Sperren mit dem Befehl LOCK.

Niedrigere Isolationsstufen sind Kompromisse, die dazu dienen, die Geschwindigkeit der Datenbank zu erhöhen.

Schauen wir uns an, wie wir verschiedene Isolationsstufen mit Hilfe von Sperren erreichen können.

Dieser Operator ermöglicht nicht nur exklusive Sperren, die für die Datenänderung erforderlich sind, sondern auch sogenannte Shared-Sperren, die parallel von mehreren Threads genutzt werden können, wenn sie Daten lesen müssen, die von anderen Prozessen während des Lesens nicht verändert werden dürfen.

Mehr über das Zwei-Phasen-Sperrverfahren in russischer und englischer Sprache:

→ Zwei-Phasen-Sperrverfahren
→ Two-phase locking

Die Schwierigkeit besteht darin, dass der Zustand der Datenbank während einer Transaktion inkonsistent sein kann, jedoch sind diese inkonsistenten Daten für andere Prozesse sichtbar. Wie kann man das vermeiden?

Wir erstellen mithilfe von Sperren Sichtfenster, in denen der Datenbankzustand konsistent ist. Und alle Zugriffe auf solche Sichtfenster des konsistenten Zustands werden durch Sperren kontrolliert.

Shared-Sperren für dieselben Daten sind wiederverwendbar – sie können von mehreren Prozessen beansprucht werden. Diese Sperren verhindern, dass andere Prozesse die Daten ändern, d.h. sie werden verwendet, um Fenster des konsistenten Datenbankzustands zu bilden.

Exklusive Sperren werden verwendet, um Datenänderungen zu steuern – eine solche Sperre kann nur von einem Prozess übernommen werden. Eine exklusive Sperre kann übernommen werden von:

1. Jedem Prozess, wenn die Daten verfügbar sind
2. Nur dem Prozess, der eine Shared-Sperre für diese Daten hat und der als Erster eine exklusive Sperre angefordert hat.

Je enger das Sichtfenster, desto länger müssen andere Prozesse warten, doch desto konsistenter kann der Zustand der Datenbank darin sein.

READ_COMMITED Der Kern dieses Niveaus ist, dass wir nur die von anderen Streams committeten Daten sehen. Wenn die Daten in einer anderen Transaktion noch nicht committet sind, sehen wir ihre alte Version.

Das ermöglicht uns, die Arbeit zu parallelisieren, anstatt auf das Freigeben der Sperre zu warten.

Ohne spezielle Tricks können wir die alte Datenversion in IRIS nicht sehen, daher müssen wir mit Sperren arbeiten.

Daher müssen wir mithilfe von Shared-Sperren das Lesen von Daten nur in Momenten der Konsistenz erlauben.

Angenommen, wir haben eine Benutzerdatenbank ^person, in der Nutzer Geld untereinander überweisen.

Der Moment der Überweisung von Person 123 zu Person 242:

LOCK +^person(123), +^person(242)
Set ^person(123, amount) = ^person(123, amount) - amount
Set ^person(242, amount) = ^person(242, amount) + amount
LOCK -^person(123), -^person(242)

Der Moment der Abfrage des Geldbetrags bei Person 123 vor der Abbuchung muss mit einer exklusiven Sperre (standardmäßig) einhergehen:

LOCK +^person(123)
Write ^person(123)

Wenn Sie den Kontostand im Kundenportal anzeigen müssen, können Sie eine gemeinsame Sperre verwenden oder sie sogar ganz weglassen:

LOCK +^person(123)#”S”
Write ^person(123)

Allerdings, wenn man annimmt, dass Datenbankoperationen nahezu sofort durchgeführt werden (ich erinnere daran, dass Globals eine viel niedrigere Struktur sind als relationale Tabellen), sinkt die Notwendigkeit dieses Levels.

REPEATABLE READ — auf diesem Isolationslevel ist es zulässig, dass mehrere Lesevorgänge auf Daten durchgeführt werden, die durch parallele Transaktionen geändert werden können.

Deshalb müssen wir eine gemeinsame Sperre für das Lesen von Daten setzen, die wir ändern, und exklusive Sperren für die Daten, die wir ändern.

Zum Glück erlaubt der LOCK-Befehl, in einem einzigen Befehl alle erforderlichen Sperren detailliert aufzulisten, was sehr viele sein können.

LOCK +^person(123, amount)#”S”
Lesen von ^person(123, amount)

andere Operationen (parallel versuchen währenddessen andere Threads ^person(123, amount) zu ändern, können dies jedoch nicht)

LOCK +^person(123, amount)
Änderung von ^person(123, amount)
LOCK -^person(123, amount)

Lesen von ^person(123, amount)
LOCK -^person(123, amount)#”S”

Bei der Auflistung von Sperren durch Kommas werden diese nacheinander behandelt, und wenn man es so macht:

LOCK +(^person(123),^person(242))

werden sie atomar alle sofort behandelt.

SERIALIZE — wir müssen die Sperren so setzen, dass am Ende alle Transaktionen, die gemeinsame Daten haben, nacheinander ausgeführt werden. Für diesen Ansatz sollten die meisten Sperren exklusiv sein und auf die kleinsten Bereiche des Globals für die Leistung gesetzt werden.

Spricht man jedoch von Abhebungen im Global ^person, ist nur das Isolationsniveau SERIALIZE akzeptabel, da Geld strikt nacheinander ausgegeben werden muss, sonst könnte der gleiche Betrag mehrere Male ausgegeben werden.

4. Beständigkeit

Ich habe Tests mit abruptem Herunterfahren des Containers durchgeführt durch

docker kill my-iris

Die Basis hat das gut verkraftet. Es wurden keine Probleme festgestellt.

Fazit

Für Globalen bietet InterSystems IRIS Unterstützung für Transaktionen. Diese sind tatsächlich atomar und zuverlässig. Um jedoch die Konsistenz der Datenbank in diesen Globalen zu gewährleisten, sind Programmieraufwand und der Einsatz von Transaktionen erforderlich, da es keine komplexen eingebauten Strukturen wie Fremdschlüssel gibt.

Das Isolationsniveau bei Globalen ohne Verwendung von Sperren ist READ UNCOMMITTED, während bei Verwendung von Sperren auch SERIALIZE als Isolationsniveau erreicht werden kann.

Die Korrektheit und Geschwindigkeit von Transaktionen in Globalen hängen stark von der Kompetenz des Programmierers ab: Je breiter Shared-Sperren beim Lesen eingesetzt werden, desto höher ist das Isolationsniveau, während eine engere Verwendung exklusiver Sperren die Geschwindigkeit erhöht.

Quelle: habr.com