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

\"TransakcijeSustav DB InterSystems IRIS podr\u017eava zanimljive strukture za pohranu podataka - globalne. U su\u0161tini, to su vi\u0161erazinski klju\u010devi s razli\u010ditim dodatnim mogu\u0107nostima u obliku transakcija, brzih funkcija za pretra\u017eivanje stabala podataka, zaklju\u010davanja i vlastitog jezika ObjectScript.<\/p>\n

Vi\u0161e o globalima u seriji \u010dlanaka \u201eGlobali - ma\u010devi blago za pohranu podataka\u201c:<\/p>\n

Stabla. Dio 1<\/a><\/noindex>
\nStabla. Dio 2<\/a><\/noindex>
\nRaspr\u0161eni nizovi. Dio 3<\/a><\/noindex><\/p>\n

Zanima me kako su implementirane transakcije u globalima, koje su njihove karakteristike. Jer to je potpuno druga\u010dija struktura za pohranu podataka, u odnosu na svima poznate tablice. Mnogo je niskorazinskija.
\n<\/a><\/noindex>
\nKao \u0161to je poznato iz teorije relacijskih baza podataka, dobra implementacija transakcija mora zadovoljiti zahtjeve ACID<\/a><\/noindex>:<\/p>\n

A - Atomic (atomarnost).<\/b> Zapisane su sve promjene napravljene u transakciji ili ni\u0161ta.<\/p>\n

S - Consistency (dosljednost).<\/b> Nakon zavr\u0161etka transakcije, logi\u010dko stanje baze podataka mora biti me\u0111usobno dosljedno. Velikim dijelom, ovaj zahtjev odnosi se na programera, ali u slu\u010daju SQL-baza, to se tako\u0111er odnosi na vanjske klju\u010deve.<\/p>\n

I - Isolate (izolacija).<\/b> Paralelno izvr\u0161ene transakcije ne smiju utjecati jedna na drugu.<\/p>\n

D - Durable (izdr\u017eljivost).<\/b> Nakon uspje\u0161nog zavr\u0161etka transakcije, problemi na ni\u017eim razinama (npr. prekid napajanja) ne smiju utjecati na podatke promijenjene transakcijom.<\/p>\n

Globali su neredne strukture podataka. Kreirani su za izuzetno brzi rad na vrlo ograni\u010denom hardveru. Poglejmo implementaciju transakcija u globalima pomo\u0107u slu\u017ebenog docker-ima\u017ea IRIS<\/a><\/noindex>.<\/p>\n

Za podr\u0161ku transakcijama u IRIS-u koriste se naredbe: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomarnost<\/h2>\n

\nNajlak\u0161e je provjeriti atomarnost. Provjeravamo iz konzole baze podataka.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nNakon toga izvla\u010dimo:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nDobivamo:<\/p>\n
1 2 3<\/code><\/pre>\n
\nSve je u redu. Atomarnost je o\u010duvana: sve promjene su zapisane.<\/p>\n
Pove\u0107ajmo slo\u017eenost, uvest \u0107emo pogre\u0161ku i vidjeti kako \u0107e se transakcija o\u010duvati, djelomi\u010dno ili nikako.<\/p>\n
Jo\u0161 jednom provjeravamo atomarnost:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nNakon \u010dega \u0107emo prisilno zaustaviti kontejner, pokrenuti ga i pogledati. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nOva naredba je gotovo ekvivalentna prisilnom isklju\u010divanju napajanja, jer \u0161alje signal hitnog zaustavljanja procesa SIGKILL.<\/p>\n
Mo\u017eda je transakcija djelomi\u010dno sa\u010duvana?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Ne, nije sa\u010duvana.<\/p>\n
Isprobajmo naredbu za povratak:<\/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
\nTako\u0111er ni\u0161ta nije sa\u010duvano.<\/p>\n
2. Dosljednost<\/h2>\n
\nBudu\u0107i da se u bazama na globalima klju\u010devi tako\u0111er rade na globalima (podsje\u0107am, global je ni\u017ea struktura za pohranu podataka od relacijske tablice), za ispunjavanje zahtjeva dosljednosti, promjenu klju\u010da treba uklju\u010diti u istu transakciju kao i promjenu globala.<\/p>\n
Na primjer, imamo global ^person, u kojem pohranjujemo osobne podatke i kao klju\u010d koristimo OIB.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nKako bismo imali brz pretra\u017eivanje prema prezimenu i imenu, napravili smo klju\u010d ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nKako bi baza bila dosljedna, moramo dodavati osobu na sljede\u0107i na\u010din:<\/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
\nDakle, pri brisanju tako\u0111er moramo koristiti transakciju:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nDrugim rije\u010dima, ispunjavanje zahtjeva dosljednosti potpuno le\u017ei na programerovim le\u0111ima. No kada su u pitanju globali \u2014 to je normalno, s obzirom na njihovu nisku razinu.<\/p>\n
3. Izolacija<\/h2>\n
\nOvdje po\u010dinju komplikacije. Puno korisnika istovremeno radi na istoj bazi, mijenjaju\u0107i iste podatke.<\/p>\n
Situacija je sli\u010dna onoj kada mnogi korisnici istovremeno rade s istim repozitorijem koda i poku\u0161avaju istovremeno poslati promjene u mnoge datoteke.<\/p>\n
Baza podataka to mora rje\u0161avati u stvarnom vremenu. S obzirom na to da u ozbiljnim tvrtkama postoji \u010dak i posebna osoba koja je odgovorna za kontrolu verzija (za spajanje grana, rje\u0161avanje sukoba itd.), a BDP mora raditi sve to u stvarnom vremenu, jasno postaje slo\u017eenost zadatka i ispravnost dizajniranja baze podataka i koda koji ju odr\u017eava.<\/p>\n
Baza podataka ne mo\u017ee shvatiti svrhu radnji koje korisnici poduzimaju kako bi sprije\u010dila sukobe kada rade s istim podacima. Mo\u017ee samo poni\u0161titi jednu transakciju koja je u sukobu s drugom ili ih izvr\u0161iti uzastopno.<\/p>\n
Jo\u0161 jedan problem je \u0161to tijekom izvr\u0161enja transakcije (prije potvrde), stanje baze mo\u017ee biti nesuglasno, stoga je po\u017eeljno da druge transakcije nemaju pristup nesuglasnom stanju baze podataka, \u0161to se posti\u017ee u relacijskim bazama na mnogo na\u010dina: stvaranjem snimaka, vi\u0161estrukim verzijama redaka itd.<\/p>\n
Pri paralelnom izvr\u0161avanju transakcija va\u017eno nam je da ne ometaju jedna drugu. To je svojstvo izolacije.<\/p>\n
SQL definira 4 razine izolacije:<\/p>\n