{"id":36650,"date":"2019-10-31T22:12:54","date_gmt":"2019-10-31T19:12:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-v-globalah-intersystems-iris\/"},"modified":"2019-10-31T22:12:54","modified_gmt":"2019-10-31T19:12:54","slug":"tranzaktsii-v-globalah-intersystems-iris","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transaktionen in globalen InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransaktionenDie InterSystems IRIS-Datenbank unterst\u00fctzt interessante Datenstrukturen \u2013 Global-Variablen. Im Grunde handelt es sich dabei um mehrstufige Schl\u00fcssel mit verschiedenen zus\u00e4tzlichen Funktionen wie Transaktionen, schnellen Methoden zur Navigierung in Datenb\u00e4umen, Sperrmechanismen und einer eigenen Sprache, ObjectScript.<\/p>\n

Mehr zu Global-Variablen finden Sie in der Artikelreihe \u201eGlobal-Variablen \u2013 die Sch\u00e4tze der Datenspeicherung\u201c:<\/p>\n

B\u00e4ume. Teil 1<\/a><\/noindex>
\nB\u00e4ume. Teil 2<\/a><\/noindex>
\nSparsame Arrays. Teil 3<\/a><\/noindex><\/p>\n

Ich war neugierig, wie Transaktionen in Global-Variablen umgesetzt sind und welche Besonderheiten es dabei gibt. Schlie\u00dflich handelt es sich um eine v\u00f6llig andere Struktur zur Datenspeicherung als die uns vertrauten Tabellen \u2013 viel tiefer in der Ebene.
\n<\/a><\/noindex>
\nWie aus der Theorie relationaler Datenbanken bekannt ist, sollte eine gute Implementierung von Transaktionen die Anforderungen erf\u00fcllen ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomic (Atomarit\u00e4t).<\/b> Alle \u00c4nderungen, die in einer Transaktion vorgenommen werden, m\u00fcssen entweder vollst\u00e4ndig erfasst oder gar nicht gespeichert werden.<\/p>\n

C \u2014 Consistency (Konsistenz).<\/b> Nach Abschluss der Transaktion muss der logische Zustand der Datenbank intern widerspruchsfrei sein. Dieses Erfordernis betrifft in hohem Ma\u00dfe den Programmierer, ist aber auch f\u00fcr relationale SQL-Datenbanken relevant und betrifft die externen Schl\u00fcssel.<\/p>\n

I \u2014 Isolation (Isolation).<\/b> Parallel ausgef\u00fchrte Transaktionen d\u00fcrfen sich nicht gegenseitig beeinflussen.<\/p>\n

D \u2014 Durable (Best\u00e4ndigkeit).<\/b> Nach dem erfolgreichen Abschluss einer Transaktion sollten Probleme auf unteren Ebenen (zum Beispiel Stromausf\u00e4lle) keinen Einfluss auf die durch die Transaktion ge\u00e4nderten Daten haben.<\/p>\n

Globals sind nicht-relationale Datenstrukturen. Sie wurden f\u00fcr eine extrem schnelle Ausf\u00fchrung auf sehr begrenzter Hardware entwickelt. Lassen Sie uns die Implementierung von Transaktionen in Globals mithilfe von dem offiziellen Docker-Image von IRIS<\/a><\/noindex>.<\/p>\n

F\u00fcr die Unterst\u00fctzung von Transaktionen in IRIS werden die folgenden Befehle verwendet: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomarit\u00e4t<\/h2>\n

\nDie \u00dcberpr\u00fcfung der Atomarit\u00e4t ist am einfachsten. Wir \u00fcberpr\u00fcfen dies \u00fcber die Datenbankkonsole.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nDann ziehen wir folgende Schlussfolgerung:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nWir erhalten:<\/p>\n
1 2 3<\/code><\/pre>\n
\nAlles in Ordnung. Die Atomarit\u00e4t wurde gewahrt: Alle \u00c4nderungen wurden gespeichert.<\/p>\n
Lassen Sie uns die Aufgabe erschweren, einen Fehler einf\u00fchren und sehen, wie die Transaktion gespeichert wird, teilweise oder gar nicht.<\/p>\n
\u00dcberpr\u00fcfen wir erneut die Atomarit\u00e4t:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nDanach stoppen wir den Container gewaltsam, starten ihn neu und schauen nach. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nDieser Befehl ist praktisch das \u00c4quivalent zu einem gewaltsamen Ausschalten des Stroms, da er ein sofortiges Stoppsignal f\u00fcr den Prozess SIGKILL sendet.<\/p>\n
K\u00f6nnte die Transaktion teilweise gespeichert worden sein?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nein, es wurde nichts gespeichert.<\/p>\n
Testen wir den Rollback-Befehl:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTROLLBACK\n\nWRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\nEs wurde ebenfalls nichts gespeichert.<\/p>\n
2. Konsistenz<\/h2>\n
\nDa in den Globals die Schl\u00fcssel ebenfalls auf den Globals basieren (ich erinnere daran, dass ein Global eine niedrigere Datenspeicherstruktur als eine relationale Tabelle ist), muss f\u00fcr die Einhaltung der Konsistenz die \u00c4nderung des Schl\u00fcssels in dieselbe Transaktion einbezogen werden, wie die \u00c4nderung des Globals.<\/p>\n
Zum Beispiel haben wir ein Global ^person, in dem wir Personen speichern, und als Schl\u00fcssel verwenden wir die Steueridentifikationsnummer.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nUm eine schnelle Suche nach Nachnamen und Vornamen zu erm\u00f6glichen, haben wir den Schl\u00fcssel ^index erstellt.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nDamit die Datenbank konsistent bleibt, m\u00fcssen wir die Person so hinzuf\u00fcgen:<\/p>\n
TSTART\n^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nDaher m\u00fcssen wir bei einer L\u00f6schung ebenfalls eine Transaktion verwenden:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567)\nTCOMMIT<\/code><\/pre>\n
\nMit anderen Worten, die Einhaltung des Konsistenzanspruchs liegt vollst\u00e4ndig in der Verantwortung des Programmierers. Wenn es um globale Variablen geht, ist das jedoch in Ordnung, aufgrund ihrer niedrigen Abstraktionsebene.<\/p>\n
3. Isolation<\/h2>\n
\nHier wird es kompliziert. Viele Benutzer arbeiten gleichzeitig an derselben Datenbank und \u00e4ndern dieselben Daten.<\/p>\n
Die Situation ist vergleichbar mit vielen Benutzern, die gleichzeitig an demselben Code-Repository arbeiten und versuchen, gleichzeitig \u00c4nderungen an vielen Dateien zu committen.<\/p>\n
Die Datenbank muss all dies in Echtzeit bew\u00e4ltigen. In ernsthaften Unternehmen gibt es sogar spezielle Personen, die f\u00fcr die Versionskontrolle (f\u00fcr das Zusammenf\u00fchren von Branches, das L\u00f6sen von Konflikten usw.) zust\u00e4ndig sind, w\u00e4hrend die Datenbank all dies in Echtzeit erledigen muss. Daher wird die Komplexit\u00e4t der Aufgabe und die Richtigkeit des Datenbankdesigns sowie des Codes, der sie betreut, offensichtlich.<\/p>\n
Die Datenbank kann den Sinn der von den Nutzern durchgef\u00fchrten Aktionen nicht verstehen, um Konflikte zu vermeiden, wenn sie an denselben Daten arbeiten. Sie kann lediglich eine Transaktion, die einer anderen widerspricht, zur\u00fccknehmen oder diese nacheinander ausf\u00fchren.<\/p>\n
Ein weiteres Problem besteht darin, dass w\u00e4hrend der Ausf\u00fchrung einer Transaktion (vor dem Commit) der Zustand der Datenbank inkonsistent sein kann. Daher ist es w\u00fcnschenswert, 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.<\/p>\n
Bei der parallelen Ausf\u00fchrung von Transaktionen ist es wichtig, dass sie sich nicht gegenseitig st\u00f6ren. Das ist das Isolationsmerkmal.<\/p>\n
SQL definiert 4 Isolationsebenen:<\/p>\n