{"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\/pl\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transakcje w globalach InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransakcjeBaza danych InterSystems IRIS obs\u0142uguje interesuj\u0105ce struktury do przechowywania danych \u2013 globalne. W zasadzie s\u0105 to wielopoziomowe klucze z r\u00f3\u017cnymi dodatkowymi funkcjonalno\u015bciami, takimi jak transakcje, szybkie funkcje do przeszukiwania drzew danych, blokady oraz w\u0142asny j\u0119zyk ObjectScript.<\/p>\n

Wi\u0119cej o globalnych w cyklu artyku\u0142\u00f3w \u201eGlobalne \u2013 miecze-klucze do przechowywania danych\u201d:<\/p>\n

Drzewa. Cz\u0119\u015b\u0107 1<\/a><\/noindex>
\nDrzewa. Cz\u0119\u015b\u0107 2<\/a><\/noindex>
\nRzadkie macierze. Cz\u0119\u015b\u0107 3<\/a><\/noindex><\/p>\n

Zaciekawi\u0142o mnie, jak realizowane s\u0105 transakcje w globalnych, jakie tam s\u0105 szczeg\u00f3lne cechy. Poniewa\u017c jest to zupe\u0142nie inna struktura do przechowywania danych ni\u017c wszystkim znane tabele. O wiele bardziej niskopoziomowe.
\n<\/a><\/noindex>
\nJak wiadomo z teorii relacyjnych baz danych, dobra realizacja transakcji powinna spe\u0142nia\u0107 wymagania ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomic (atomowo\u015b\u0107).<\/b> Rejestrowane s\u0105 wszystkie zmiany dokonane w transakcji lub nie ma \u017cadnych.<\/p>\n

S \u2014 Consistency (sp\u00f3jno\u015b\u0107).<\/b> Po zako\u0144czeniu transakcji logiczny stan bazy danych powinien by\u0107 wewn\u0119trznie sp\u00f3jny. W du\u017cej mierze to wymaganie dotyczy programisty, ale w przypadku baz danych SQL dotyczy tak\u017ce kluczy obcych.<\/p>\n

I \u2014 Isolate (izolacja).<\/b> R\u00f3wnolegle wykonywane transakcje nie powinny wp\u0142ywa\u0107 na siebie nawzajem.<\/p>\n

D \u2014 Durable (trwa\u0142o\u015b\u0107).<\/b> Po pomy\u015blnym zako\u0144czeniu transakcji problemy na ni\u017cszych poziomach (przyk\u0142ad: awaria zasilania) nie powinny wp\u0142ywa\u0107 na dane zmienione przez transakcj\u0119.<\/p>\n

Globalne to struktury danych nierelacyjne. Zosta\u0142y stworzone do ultra szybkiej pracy na bardzo ograniczonym sprz\u0119cie. Przyjrzyjmy si\u0119 wdro\u017ceniu transakcji w globalnych przy u\u017cyciu oficjalnego obrazu dockerowego IRIS<\/a><\/noindex>.<\/p>\n

Aby wspiera\u0107 transakcje w IRIS u\u017cywa si\u0119 polece\u0144: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomowo\u015b\u0107<\/h2>\n

\nNaj\u0142atwiej jest sprawdzi\u0107 atomowo\u015b\u0107. Sprawdzamy z konsoli bazy danych.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nNast\u0119pnie dokonujemy odczytu:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nOtrzymamy:<\/p>\n
1 2 3<\/code><\/pre>\n
\nWszystko w porz\u0105dku. Atomowo\u015b\u0107 przestrzegana: wszystkie zmiany zosta\u0142y zapisane.<\/p>\n
Utrudnimy zadanie, wprowadzimy b\u0142\u0105d i zobaczymy, jak zachowa si\u0119 transakcja, cz\u0119\u015bciowo lub wcale.<\/p>\n
Jeszcze raz sprawdzimy atomowo\u015b\u0107:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nPo czym przymusowo zatrzymamy kontener, uruchomimy go i sprawdzimy. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nTo polecenie jest praktycznie r\u00f3wnowa\u017cne z nag\u0142ym odci\u0119ciem zasilania, poniewa\u017c wysy\u0142a sygna\u0142 natychmiastowego zatrzymania procesu SIGKILL.<\/p>\n
Czy transakcja mog\u0142a si\u0119 zapisa\u0107 cz\u0119\u015bciowo?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nie, nie zosta\u0142a zapisana.<\/p>\n
Wypr\u00f3bujmy polecenie wycofania:<\/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
\nTe\u017c nic nie zosta\u0142o zapisane.<\/p>\n
2. Sp\u00f3jno\u015b\u0107<\/h2>\n
\nPoniewa\u017c w bazach na globalach klucze s\u0105 r\u00f3wnie\u017c tworzone na globalach (przypomn\u0119, \u017ce global to struktura o ni\u017cszym poziomie do przechowywania danych ni\u017c tabela relacyjna), aby spe\u0142ni\u0107 wym\u00f3g sp\u00f3jno\u015bci, nale\u017cy zmiany klucza uwzgl\u0119dni\u0107 w tej samej transakcji, co zmiana globalu.<\/p>\n
Na przyk\u0142ad mamy global ^person, w kt\u00f3rym przechowujemy persony i jako klucz u\u017cywamy NIP.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nAby mie\u0107 szybkie wyszukiwanie wed\u0142ug nazwiska i imienia, stworzyli\u015bmy klucz ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nAby baza by\u0142a sp\u00f3jna, musimy dodawa\u0107 person\u0119 w ten spos\u00f3b:<\/p>\n
TSTART\n^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n^index('Kamenev', 'Sergey', 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nOdpowiednio, przy usuwaniu r\u00f3wnie\u017c musimy u\u017cywa\u0107 transakcji:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nInnymi s\u0142owy, realizacja wymogu sp\u00f3jno\u015bci le\u017cy ca\u0142kowicie w gestii programisty. Ale kiedy mowa o globalach \u2014 jest to normalne, z uwagi na ich niskopoziomow\u0105 natur\u0119.<\/p>\n
3. Izolacja<\/h2>\n
\nTutaj zaczynaj\u0105 si\u0119 zawirowania. Wiele u\u017cytkownik\u00f3w jednocze\u015bnie pracuje nad t\u0105 sam\u0105 baz\u0105, zmieniaj\u0105c te same dane.<\/p>\n
Sytuacja jest por\u00f3wnywalna z tym, kiedy wielu u\u017cytkownik\u00f3w jednocze\u015bnie pracuje z tym samym repozytorium kodu i pr\u00f3buje jednocze\u015bnie zatwierdzi\u0107 zmiany w wielu plikach.<\/p>\n
Baza danych musi to wszystko rozwi\u0105zywa\u0107 w czasie rzeczywistym. Bior\u0105c pod uwag\u0119, \u017ce w powa\u017cnych firmach jest nawet specjalna osoba odpowiedzialna za kontrol\u0119 wersji (za \u0142\u0105czenie ga\u0142\u0119zi, rozwi\u0105zywanie konflikt\u00f3w itp.), a DB musi to wszystko robi\u0107 w czasie rzeczywistym, staje si\u0119 oczywista z\u0142o\u017cono\u015b\u0107 zadania oraz poprawno\u015b\u0107 projektowania bazy danych i kodu, kt\u00f3ry j\u0105 obs\u0142uguje.<\/p>\n
Baza danych nie mo\u017ce zrozumie\u0107 intencji dzia\u0142a\u0144 podejmowanych przez u\u017cytkownik\u00f3w, aby unikn\u0105\u0107 konflikt\u00f3w, gdy pracuj\u0105 nad tymi samymi danymi. Mo\u017ce jedynie cofn\u0105\u0107 jedn\u0105 transakcj\u0119, kt\u00f3ra jest sprzeczna z inn\u0105 lub wykona\u0107 je sekwencyjnie.<\/p>\n
Innym problemem jest to, \u017ce podczas realizacji transakcji (przed zatwierdzeniem), stan bazy danych mo\u017ce by\u0107 niesp\u00f3jny, dlatego po\u017c\u0105dane jest, aby inne transakcje nie mia\u0142y dost\u0119pu do niesp\u00f3jnego stanu bazy danych, co osi\u0105ga si\u0119 w relacyjnych bazach danych na wiele sposob\u00f3w: poprzez tworzenie migawk\u00f3w, wersjonowanie wierszy itp.<\/p>\n
Podczas r\u00f3wnoleg\u0142ego wykonywania transakcji wa\u017cne jest, aby nie przeszkadza\u0142y sobie nawzajem. To jest w\u0142a\u015bnie w\u0142a\u015bciwo\u015b\u0107 izolacji.<\/p>\n
SQL definiuje 4 poziomy izolacji:<\/p>\n