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

\"TehingudInterSystems IRIS andmebaas toetab huvitavaid andmestruktuure \u2014 globaalid. Sisuliselt on need mitmeastmelised v\u00f5tmed koos erinevate lisafunktsioonidega, nagu tehingud, kiired funktsioonid andmepuude l\u00e4bimiseks, lukustamine ja oma ObjectScript'i keel.<\/p>\n

Rohkem globaalidest artiklisarjas \u00abGlobaalid \u2014 andmete salvestamise m\u00f5\u00f5gakoolid\u00bb:<\/p>\n

Puud. Osa 1<\/a><\/noindex>
\nPuud. Osa 2<\/a><\/noindex>
\nH\u00f5redad masstid. Osa 3<\/a><\/noindex><\/p>\n

Mind huvitab, kuidas tehingud globaalides on rakendatud, millised on seal omadused. L\u00f5ppude l\u00f5puks on see t\u00e4iesti erinev andmesalvestamisstruktuur, v\u00f5rreldes tuttavate tabelitega. Oluliselt madalama tasandi.
\n<\/a><\/noindex>
\nKuna on teada, et relatsiooniliste andmebaaside teooria kohaselt peab hea tehingute teostus vastama n\u00f5uetele ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomite (aatomsus).<\/b> K\u00f5ik tehingus tehtud muutused salvestatakse v\u00f5i mitte \u00fchtegi.<\/p>\n

C \u2014 Consistency (koosk\u00f5la).<\/b> P\u00e4rast tehingu l\u00f5petamist peab andmebaasi loogiline seisund olema sisemiselt j\u00e4rjekindel. Suurel m\u00e4\u00e4ral puudutab see n\u00f5ue programmeerijat, kuid SQL-andmebaaside puhul puudutab see ka v\u00e4liseid v\u00f5tmeid.<\/p>\n

I \u2014 Isolate (isoleeritus).<\/b> Samas k\u00e4ivitatud tehingud ei tohiks \u00fcksteisele m\u00f5ju avaldada.<\/p>\n

D \u2014 Durable (p\u00fcsivus).<\/b> P\u00e4rast tehingu edukat l\u00f5petamist ei tohiks madalama taseme probleemid (n\u00e4iteks toitekaotused) m\u00f5jutada tehingu k\u00e4igus muudetud andmeid.<\/p>\n

Globaalid on mittesuhtelised andmestruktuurid. Need on loodud \u00fcliv\u00f5imsateks toiminguteks v\u00e4ga piiratud riistvaral. Uurime, kuidas tehingud globaalides t\u00f6\u00f6tavad, kasutades ametlikku docker-pilti IRIS<\/a><\/noindex>.<\/p>\n

Tehingute toetamiseks IRIS-is kasutatakse j\u00e4rgmisi k\u00e4sklusi: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Aatomilisus<\/h2>\n

\nAatomilisuse kontrollimine on k\u00f5ige lihtsam. Kontrollime andmebaasi kontolt.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nSeej\u00e4rel teeme j\u00e4relduse:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nSaame:<\/p>\n
1 2 3<\/code><\/pre>\n
\nK\u00f5ik on korras. Aatomilisus on tagatud: k\u00f5ik muudatused on salvestatud.<\/p>\n
Vaatame \u00fclesannet keerulisemaks, sisestame vea ja vaatame, kuidas tehing s\u00e4ilib, osaliselt v\u00f5i \u00fcldse mitte.<\/p>\n
Kontrollime aatomilisust veel kord:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nSeej\u00e4rel peatame konteineri sundimisega, k\u00e4ivitame selle ja vaatame. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nSee k\u00e4sk on praktiliselt samav\u00e4\u00e4rne j\u00f5ulise toitev\u00e4ljal\u00fclitamisega, kuna saadab SIGKILL protsessi kohese l\u00f5petamise signaali.<\/p>\n
Kas v\u00f5ib juhtuda, et tehing on osaliselt salvestatud?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Ei, see ei ole salvestatud.<\/p>\n
Katsume tagasip\u00f6\u00f6rdumise k\u00e4sku:<\/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
\nKa see ei ole salvestatud.<\/p>\n
2. Sidusus<\/h2>\n
\nKuna globaalsetes andmebaasides luuakse v\u00f5tmed samuti globaalsetele (meeldetuletuseks, et globaal on madalama taseme struktuur andmete salvestamiseks kui relatsiooniline tabel), peab sidususe n\u00f5ude t\u00e4itmiseks v\u00f5tme muutmine olema sama tehingu osaks kui globaali muutmine.<\/p>\n
N\u00e4iteks on meil globaalsed ^person, kuhu salvestame isikuandmed ja v\u00f5tmena kasutame INN-i.<\/p>\n
^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n...<\/code><\/pre>\n
\nKuna soovime kiiret otsingut perekonnanime ja eesnime j\u00e4rgi, l\u00f5ime v\u00f5tme ^index.<\/p>\n
^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1<\/code><\/pre>\n
\nEt andmebaas oleks sidus, peame isikuandmed lisama j\u00e4rgmiselt:<\/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
\nSeega, kustutamise puhul peame samuti kasutama tehingut:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567)\nTCOMMIT<\/code><\/pre>\n
\nTeisis\u00f5nu, n\u00f5uete j\u00e4rjepidevuse t\u00e4itmine lasub t\u00e4ielikult arendaja \u00f5lgadel. Kuid kui tegemist on globaalidega \u2014 on see normaalne, arvestades nende madalama taseme iseloomu.<\/p>\n
3. Isolatsioon<\/h2>\n
\nSiinkohal algavad p\u00f5hjalikud probleemid. Paljud kasutajad t\u00f6\u00f6tavad sama andmebaasi kallal, muutes samu andmeid.<\/p>\n
See olukord on sarnane olukorraga, kus mitmed kasutajad t\u00f6\u00f6tavad sama koodirepositooriumi kallal ja \u00fcritavad samal ajal teha muudatusi paljudes failides.<\/p>\n
Andmebaas peab seda k\u00f5ike reaalajas haldama. Arvestades, et t\u00f5sistes ettev\u00f5tetes on isegi eraldi inimene, kes vastutab versioonihalduse (harude sulandumine, konfliktide lahendamine jne) eest, ja andmebaasi peaks seda tegema reaalajas, siis on \u00fclesande keerukus ja andmebaasi ning selle halduskoodi korrektne projekteerimine ilmne.<\/p>\n
Andmebaas ei saa m\u00f5ista kasutajate teoste t\u00e4hendust, et v\u00e4ltida konflikte, kui nad t\u00f6\u00f6tavad sama andmete kallal. Ta suudab vaid t\u00fchistada \u00fche tehingu, mis on vastuolus teisega, v\u00f5i t\u00e4ita need j\u00e4rjestikku.<\/p>\n
Veel \u00fcks probleem on see, et tehingu t\u00e4itmise ajal (enne kinnitust) v\u00f5ib andmebaas olla \u00fchtlustamata olekus, seet\u00f5ttu on soovitatav, et teistel tehingutel ei oleks juurdep\u00e4\u00e4su \u00fchtlustamata andmebaasi olekule, mida saavutatakse relatsioonilistes andmebaasides paljusid viise kaudu: l\u00f5ikepunktide loomine, mitme versiooni ridade kasutamine jne.<\/p>\n
Paralleelse tehingute t\u00e4itmise puhul on meil oluline, et nad ei segaks \u00fcksteist. See ongi isoleerimise omadus.<\/p>\n
SQL m\u00e4\u00e4ratleb 4 isoleerimistaset:<\/p>\n