Tehingud InterSystems IRIS globaalides

InterSystems IRIS andmebaas toetab huvitavaid andmestruktuure — globaalid. Sisuliselt on need mitmeastmelised võtmed koos erinevate lisafunktsioonidega, nagu tehingud, kiired funktsioonid andmepuude läbimiseks, lukustamine ja oma ObjectScript'i keel.

Rohkem globaalidest artiklisarjas «Globaalid — andmete salvestamise mõõgakoolid»:

Puud. Osa 1
Puud. Osa 2
Hõredad masstid. Osa 3

Mind huvitab, kuidas tehingud globaalides on rakendatud, millised on seal omadused. Lõppude lõpuks on see täiesti erinev andmesalvestamisstruktuur, võrreldes tuttavate tabelitega. Oluliselt madalama tasandi.

Kuna on teada, et relatsiooniliste andmebaaside teooria kohaselt peab hea tehingute teostus vastama nõuetele ACID:

A — Atomite (aatomsus). Kõik tehingus tehtud muutused salvestatakse või mitte ühtegi.

C — Consistency (kooskõla). Pärast tehingu lõpetamist peab andmebaasi loogiline seisund olema sisemiselt järjekindel. Suurel määral puudutab see nõue programmeerijat, kuid SQL-andmebaaside puhul puudutab see ka väliseid võtmeid.

I — Isolate (isoleeritus). Samas käivitatud tehingud ei tohiks üksteisele mõju avaldada.

D — Durable (püsivus). Pärast tehingu edukat lõpetamist ei tohiks madalama taseme probleemid (näiteks toitekaotused) mõjutada tehingu käigus muudetud andmeid.

Globaalid on mittesuhtelised andmestruktuurid. Need on loodud ülivõimsateks toiminguteks väga piiratud riistvaral. Uurime, kuidas tehingud globaalides töötavad, kasutades ametlikku docker-pilti IRIS.

Tehingute toetamiseks IRIS-is kasutatakse järgmisi käsklusi: TSTART, TCOMMIT, TROLLBACK.

1. Aatomilisus

Aatomilisuse kontrollimine on kõige lihtsam. Kontrollime andmebaasi kontolt.

Kill ^a
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TCOMMIT

Seejärel teeme järelduse:

Write ^a(1), “ ”, ^a(2), “ ”, ^a(3)

Saame:

1 2 3

Kõik on korras. Aatomilisus on tagatud: kõik muudatused on salvestatud.

Vaatame ülesannet keerulisemaks, sisestame vea ja vaatame, kuidas tehing säilib, osaliselt või üldse mitte.

Kontrollime aatomilisust veel kord:

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3

Seejärel peatame konteineri sundimisega, käivitame selle ja vaatame.

docker kill my-iris

See käsk on praktiliselt samaväärne jõulise toiteväljalülitamisega, kuna saadab SIGKILL protsessi kohese lõpetamise signaali.

Kas võib juhtuda, et tehing on osaliselt salvestatud?

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

— Ei, see ei ole salvestatud.

Katsume tagasipöördumise käsku:

Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TROLLBACK

WRITE ^a(1), ^a(2), ^a(3)
^
 ^a(1)

Ka see ei ole salvestatud.

2. Sidusus

Kuna globaalsetes andmebaasides luuakse võtmed samuti globaalsetele (meeldetuletuseks, et globaal on madalama taseme struktuur andmete salvestamiseks kui relatsiooniline tabel), peab sidususe nõude täitmiseks võtme muutmine olema sama tehingu osaks kui globaali muutmine.

Näiteks on meil globaalsed ^person, kuhu salvestame isikuandmed ja võtmena kasutame INN-i.

^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
...

Kuna soovime kiiret otsingut perekonnanime ja eesnime järgi, lõime võtme ^index.

^index(‘Kamenev’, ‘Sergey’, 1234567) = 1

Et andmebaas oleks sidus, peame isikuandmed lisama järgmiselt:

TSTART
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1
TCOMMIT

Seega, kustutamise puhul peame samuti kasutama tehingut:

TSTART
Kill ^person(1234567)
ZKill ^index(‘Kamenev’, ‘Sergey’, 1234567)
TCOMMIT

Teisisõnu, nõuete järjepidevuse täitmine lasub täielikult arendaja õlgadel. Kuid kui tegemist on globaalidega — on see normaalne, arvestades nende madalama taseme iseloomu.

3. Isolatsioon

Siinkohal algavad põhjalikud probleemid. Paljud kasutajad töötavad sama andmebaasi kallal, muutes samu andmeid.

See olukord on sarnane olukorraga, kus mitmed kasutajad töötavad sama koodirepositooriumi kallal ja üritavad samal ajal teha muudatusi paljudes failides.

Andmebaas peab seda kõike reaalajas haldama. Arvestades, et tõsistes ettevõtetes on isegi eraldi inimene, kes vastutab versioonihalduse (harude sulandumine, konfliktide lahendamine jne) eest, ja andmebaasi peaks seda tegema reaalajas, siis on ülesande keerukus ja andmebaasi ning selle halduskoodi korrektne projekteerimine ilmne.

Andmebaas ei saa mõista kasutajate teoste tähendust, et vältida konflikte, kui nad töötavad sama andmete kallal. Ta suudab vaid tühistada ühe tehingu, mis on vastuolus teisega, või täita need järjestikku.

Veel üks probleem on see, et tehingu täitmise ajal (enne kinnitust) võib andmebaas olla ühtlustamata olekus, seetõttu on soovitatav, et teistel tehingutel ei oleks juurdepääsu ühtlustamata andmebaasi olekule, mida saavutatakse relatsioonilistes andmebaasides paljusid viise kaudu: lõikepunktide loomine, mitme versiooni ridade kasutamine jne.

Paralleelse tehingute täitmise puhul on meil oluline, et nad ei segaks üksteist. See ongi isoleerimise omadus.

SQL määratleb 4 isoleerimistaset:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Vaatame iga taset eraldi. Iga taseme rakendamise kulud kasvavad peaaegu eksponentsiaalselt.

READ UNCOMMITTED — see on madalaim isoleerimistaseme tase, kuid samas ka kõige kiirem. Tehingud saavad lugeda üksteise tekitatud muudatusi.

READ COMMITTED — see on järgmine isoleerimistaseme tase, mis on kompromiss. Tehingud ei saa lugeda üksteise tekitatud muudatusi enne kinnitamist, kuid saavad lugeda pärast kinnitamist tehtud muudatusi.

Kui meil on pikk tehing T1, mille jooksul toimuvad kinnitused tehingutes T2, T3 ... Tn, mis töötasid sama andmete kallal nagu T1, siis T1-s andmeid küsides saame me alati erinevaid tulemusi. Seda nähtust nimetatakse mittetäielikuks lugemiseks.

REPEATABLE READ — selle isolatsioonitaseme juures ei esine korduvat lugemist, kuna iga andmelugemise päringu jaoks luuakse andmessnapshot ja sama tehingu jooksul kasutatakse seda snapshot'i andmeid. Kuid selle isolatsiooni taseme puhul on võimalik lugeda fantoomandmeid. See tähendab, et on võimalik lugeda uusi ridu, mis on lisatud paralleelsete kinnitatud tehingute kaudu.

SERIALIZABLE — kõrgeim isolatsioonitase. Selle tunnuseks on see, et tehingus kasutatavad andmed (kas lugemine või muutmine) on teistele tehingutele kättesaadavad alles pärast esimeses tehingus lõpetamist.

Käime esmalt läbi, kas tehingus toimingud on peastreamist isoleeritud. Avame kaks terminaliakent.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Isolatsiooni pole. Üks lõim näeb, mida teeb teine, kes avas tehingu.

Vaadakem, kas erinevate lõimude tehingud näevad, mis toimub nende sees.

Avame kaks terminaliakent ja avame samal ajal kaks tehingut.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Paralleelsed tehingud näevad üksteise andmeid. Nii saime kõige lihtsama, aga ka kõige kiirema isoleerimise taseme READ UNCOMMITED.

Põhimõtteliselt sai seda oodata globaalide jaoks, mille puhul on jõudlus alati peamine prioriteet.

Kuidas siis tegelikult toimida, kui meil on vaja kõrgemat isoleerimise taset globaalide operatsioonides?

Siin tuleb mõelda, miks isoleerimistaset üldse vaja on ja kuidas need toimivad.

Kõrgeim isoleerimise tase SERIALIZE tähendab, et paralleelselt täidetud tehingute tulemus on võrreldav nende järjestikuse täitmisega, mis garanteerib konfliktide puudumise.

Seda saame teha õigete lukustustega ObjectScriptis, mis pakuvad palju erinevaid rakendusi: saame teha tavalisi, järjestikuseid ja mitmeosalisi lukustusi käsuga LOCK.

Madalamad isoleerimise tasemed on kompromissid, mille eesmärk on suurendada andmebaasi töökiirust.

Vaatame, kuidas me saame lukustuste abil saavutada erinevaid isoleerimise tasemeid.

See operaator võimaldab mitte ainult eksklusiivsete lukustuste rakendamist, mis on vajalikud andmete muutmiseks, vaid ka nn jagatud lukustusi, mida saavad korraga kasutada mitmed niidid, kui nad peavad lugema andmeid, mida ei tohiks teiste protsesside poolt lugemise ajal muuta.

Lisateave kahefaasilise lukustamismeetodi kohta vene ja inglise keeles:

→ Kahefaasiline lukustamine
→ Two-phase locking

Raskus seisneb selles, et tehingu ajal võib andmebaasi olek olla kooskõlmatu, kuid need kooskõlmatud andmed on nähtavad teistele protsessidele. Kuidas seda vältida?

Loome lukustuste abil sellised nähtavuse aknad, kus andmebaasi olek on kooskõlas. Ja kõik juurdepääsud sellistele kooskõlastatud oleva nähtavuse akendele kontrollitakse lukustuste kaudu.

Jagatud lukustused samadele andmetele on korduvkasutatavad — nendele saavad juurdepääsu mitmed protsessid. Need lukustused keelavad muudele protsessidele andmete muutmise, st neid kasutatakse andmebaasi kooskõlastatud oleku akende vormimiseks.

Eksklusiivsed lukud kasutatakse andmete muutmiseks — sellist lukku saab võtta ainult üks protsess. Eksklusiivset lukku saab võtta:

1. Iga protsess, kui andmed on vabad
2. Ainult see protsess, millel on nende andmete suhtes jagatud lukustus ja kes esimene küsis eksklusiivset lukku.

Mida kitsam on nähtavusakna, seda kauem peavad teised protsessid ootama, kuid sellel võib olla ühtlasem andmebaasi olek.

READ_COMMITED — selle taseme peamine mõte on see, et me näeme ainult erinevates voogudes kinnitatud andmeid. Kui andmed teises tehingus pole veel kinnitatud, siis näeme nende vana versiooni.

See võimaldab meil tööd paralleelselt käia, selle asemel et oodata lukkude vabastamist.

Ilma eriliste trikkideta ei suuda me IRISes näha vana andmeversiooni, seega peame loobuma lukustustest.

Seega peame jagatud lukustuste abil lubama andmete lugemist ainult kooskõla hetkedel.

Oletame, et meil on kasutajate andmebaas ^person, kes kannavad raha üksteisele.

Rahaülekande hetk isikute 123 ja 242 vahel:

LOCK +^person(123), +^person(242)
Set ^person(123, amount) = ^person(123, amount) - amount
Set ^person(242, amount) = ^person(242, amount) + amount
LOCK -^person(123), -^person(242)

Isiku 123 rahasumma küsimine enne mahaarvamist peab olema seotud eksklusiivse lukustamisega (vaikimisi):

LOCK +^person(123)
Write ^person(123)

Kui tuleb näidata konto seisu isiklikus kabinetis, võib kasutada jagatud lukustust või jätta see kasutamata:

LOCK +^person(123)#”S”
Write ^person(123)

Kuid kui eeldada, et andmebaasi tehingud toimuvad praktiliselt koheselt (meenutame, et globaalid on palju madalama taseme struktuur kui relatiivne tabel), siis on selle taseme vajadus vähenenud.

REPEATABLE READ — selle isolatsiooni taseme juures lubatakse, et andmeid võidakse lugeda mitmeid kordi, mida võivad muuta paralleelsed tehingud.

Seetõttu peame seadma jagatud lukustuse neile andmetele, mida me muudame, ja eksklusiivsed lukustused andmetele, mida me muudame.

Hea on see, et LOCK operaator võimaldab ühes käskluses detailsemalt loetleda kõik vajalikud lukustused, mida võib olla väga palju.

LOCK +^person(123, amount)#”S”
Lugemine ^person(123, amount)

teised toimingud (selle ajal üheaegselt katsetab voog ^person(123, amount), kuid ei õnnestu)

LOCK +^person(123, amount)
muutmine ^person(123, amount)
LOCK -^person(123, amount)

lugemine ^person(123, amount)
LOCK -^person(123, amount)#”S”

Kui loetleda lukustusi komaga, siis need võetakse järjestikku, kuid kui teha nii:

LOCK +(^person(123),^person(242))

siis need võetakse atomaarsemalt kõik korraga.

SERIALIZE — peame lukustusi seadma nii, et lõpuks kõik tehingud, mis omavad ühiseid andmeid, toimuksid järjestikku. Selle lähenemise jaoks peaksid enamik lukustusi olema eksklusiivsed ja katma väikseimaid ala globaalses süsteemis, et saavutada paremat jõudlust.

Kui rääkida rahade mahakandmist globaalsetes ^person, siis selle jaoks on sobiv ainult SERIALIZE eraldusvõime, kuna raha peab kulutama rangelt järjestikku, vastasel juhul võib sama summat kulutada mitu korda.

4. Püsivus

Ma tegin katseid konteineri järsu väljalülitamisega läbi

docker kill my-iris

Andmebaas talus seda hästi. Probleeme ei tuvastatud.

Kokkuvõte

InterSystems IRIS'is on globaalsed tehingute tugi. Need on tõeliselt atomaarset ja usaldusväärset. Andmebaasi järjepidevuse tagamiseks globaalses keskkonnas on arendaja pingutused ning tehingute kasutamine vajalik, kuna keerulised sisseehitatud konstruktsioonid, nagu välised võtmed, puuduvad.

Globaalide eraldusaste ilma lukustusteta on READ UNCOMMITTED, ja lukustuste kasutamise korral saab tagada isegi SERIALIZE taseme.

Globaalide tehingute õigsus ja kiirus sõltuvad väga palju arendaja oskustest: mida laiemalt kasutatakse jagatud lukustusi lugemisel, seda kõrgem on eraldatusetunne, ja mida kitsamad on eksklusiivsed lukustused, seda suurem on jõudlus.

Allikas: habr.com