{"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\/ro\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Tranzac\u021bii \u00een globalurile InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Tranzac\u021biiSGBD InterSystems IRIS sus\u021bine structuri interesante pentru stocarea datelor - globale. Practic, acestea sunt chei multilaterale cu diverse avantaje suplimentare, precum tranzac\u021bii, func\u021bii rapide pentru navigarea \u00een arborii de date, blocaje \u0219i un limbaj propriu, ObjectScript.<\/p>\n

Mai multe despre globale \u00een seria de articole \u201eGlobale - s\u0103bii cu dou\u0103 t\u0103i\u0219uri pentru stocarea datelor\u201d:<\/p>\n

Arbori. Partea 1<\/a><\/noindex>
\nArbori. Partea 2<\/a><\/noindex>
\nMatrice sparse. Partea 3<\/a><\/noindex><\/p>\n

M-a interesat cum sunt implementate tranzac\u021biile \u00een globale, ce caracteristici au. Este o structur\u0103 complet diferit\u0103 pentru stocarea datelor, comparativ cu tabelele obi\u0219nuite. Mult mai la un nivel de baz\u0103.
\n<\/a><\/noindex>
\nDup\u0103 cum se \u0219tie din teoria bazelor de date rela\u021bionale, o implementare bun\u0103 a tranzac\u021biilor ar trebui s\u0103 \u00eendeplineasc\u0103 cerin\u021bele ACID<\/a><\/noindex>:<\/p>\n

A - Atomic (atomaritate).<\/b> Toate modific\u0103rile efectuate \u00een tranzac\u021bie trebuie \u00eenregistrate sau niciuna.<\/p>\n

C - Consistency (consisten\u021b\u0103).<\/b> Dup\u0103 finalizarea tranzac\u021biei, starea logic\u0103 a bazei de date trebuie s\u0103 fie intern coerent\u0103. \u00cen mare parte, aceast\u0103 cerin\u021b\u0103 se refer\u0103 la programator, dar \u00een cazul bazelor de date SQL se refer\u0103 \u0219i la cheile externe.<\/p>\n

I - Isolate (izolare).<\/b> Tranzac\u021biile care se execut\u0103 simultan nu trebuie s\u0103 se influen\u021beze reciproc.<\/p>\n

D - Durable (durabilitate).<\/b> Dup\u0103 finalizarea cu succes a tranzac\u021biei, problemele de la nivelurile inferioare (de exemplu, o c\u0103dere a aliment\u0103rii) nu trebuie s\u0103 afecteze datele modificate de tranzac\u021bie.<\/p>\n

Globalele sunt structuri de date nerela\u021bionale. Au fost create pentru a func\u021biona extrem de rapid pe hardware foarte limitat. S\u0103 analiz\u0103m implementarea tranzac\u021biilor \u00een globale folosind imaginea oficial\u0103 Docker IRIS<\/a><\/noindex>.<\/p>\n

Pentru a sus\u021bine tranzac\u021biile \u00een IRIS, sunt folosite comenzile: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomaritate<\/h2>\n

\nCel mai u\u0219or de verificat este atomaritatea. Verific\u0103m din consola bazei de date.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nApoi facem concluzia:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nVom ob\u021bine:<\/p>\n
1 2 3<\/code><\/pre>\n
\nTotul este \u00een regul\u0103. Atomaritatea a fost respectat\u0103: toate modific\u0103rile au fost \u00eenregistrate.<\/p>\n
S\u0103 complic\u0103m pu\u021bin sarcina, introduc\u00e2nd o eroare \u0219i s\u0103 vedem cum se va p\u0103stra tranzac\u021bia, par\u021bial sau deloc.<\/p>\n
Verific\u0103m din nou atomaritatea:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nDup\u0103 care vom opri for\u021bat containerul, \u00eel vom porni \u0219i vom verifica. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nAceast\u0103 comand\u0103 este practic echivalent\u0103 cu oprirea for\u021bat\u0103 a aliment\u0103rii, deoarece trimite semnalul de oprire imediat\u0103 a procesului SIGKILL.<\/p>\n
Poate c\u0103 tranzac\u021bia a fost salvat\u0103 par\u021bial?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nu, nu s-a salvat.<\/p>\n
S\u0103 test\u0103m comanda de rollback:<\/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
\nNici asta nu s-a salvat.<\/p>\n
2. Consisten\u021ba<\/h2>\n
\nDeoarece \u00een bazele de date pe globale, cheile sunt de asemenea create pe globale (amintesc c\u0103 globalul este o structur\u0103 de nivel inferior pentru stocarea datelor, comparativ cu o tabel\u0103 rela\u021bional\u0103), pentru a \u00eendeplini cerin\u021ba de consisten\u021b\u0103, modificarea cheii trebuie inclus\u0103 \u00een aceea\u0219i tranzac\u021bie cu modificarea globalului.<\/p>\n
De exemplu, avem globalul ^person, \u00een care stoc\u0103m persoanele \u0219i folosim ca \u0219i cheie CNP-ul.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nPentru a avea c\u0103ut\u0103ri rapide dup\u0103 nume \u0219i prenume, am creat cheia ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nPentru ca baza de date s\u0103 fie consistent\u0103, trebuie s\u0103 ad\u0103ug\u0103m persoana astfel:<\/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
\nPrin urmare, la \u0219tergere, trebuie de asemenea s\u0103 folosim o tranzac\u021bie:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nCu alte cuvinte, \u00eendeplinirea cerin\u021bei de consisten\u021b\u0103 este complet pe umerii programatorului. Dar c\u00e2nd vine vorba de globale, este normal, din cauza naturii lor de nivel inferior.<\/p>\n
3. Izolarea<\/h2>\n
\nAici \u00eencep problemele. Mul\u021bi utilizatori lucreaz\u0103 simultan asupra acelea\u0219i baze de date, modific\u00e2nd acelea\u0219i date.<\/p>\n
Situa\u021bia este comparabil\u0103 cu aceea \u00een care mul\u021bi utilizatori lucreaz\u0103 simultan cu acela\u0219i repository de cod \u0219i \u00eencearc\u0103 s\u0103 comiteze modific\u0103ri \u00een multe fi\u0219iere \u00een acela\u0219i timp.<\/p>\n
Baza de date trebuie s\u0103 gestioneze totul \u00een timp real. Av\u00e2nd \u00een vedere c\u0103 \u00een companiile mari exist\u0103 chiar o persoan\u0103 responsabil\u0103 de controlul versiunilor (pentru a gestiona fuziunile ramurilor, rezolvarea conflictelor etc.), iar baza de date trebuie s\u0103 fac\u0103 tot acest lucru \u00een timp real, devine evident\u0103 complexitatea sarcinii \u0219i corectitudinea proiect\u0103rii bazei de date \u0219i a codului care o \u00eentre\u021bine.<\/p>\n
O baz\u0103 de date nu poate \u00een\u021belege sensul ac\u021biunilor efectuate de utilizatori pentru a preveni conflictele atunci c\u00e2nd ace\u0219tia lucreaz\u0103 cu acelea\u0219i date. Aceasta poate anula o tranzac\u021bie care contrazice alta sau poate s\u0103 le execute secven\u021bial.<\/p>\n
O alt\u0103 problem\u0103 este c\u0103, \u00een timpul execu\u021biei unei tranzac\u021bii (p\u00e2n\u0103 la commit), starea bazei de date poate fi inconsistenta. Din acest motiv, este de dorit ca alte tranzac\u021bii s\u0103 nu aib\u0103 acces la starea inconsistent\u0103 a bazei de date, ceea ce se realizeaz\u0103 \u00een bazele de date rela\u021bionale prin mai multe metode: crearea de snapshot-uri, gestionarea versiunilor multiple a r\u00e2ndurilor etc.<\/p>\n
C\u00e2nd tranzac\u021biile sunt executate \u00een paralel, este important s\u0103 nu se interfereze reciproc. Acesta este ceea ce se nume\u0219te proprietatea izola\u021biei.<\/p>\n
SQL define\u0219te 4 niveluri de izola\u021bie:<\/p>\n