Tehingud InterSystems IRIS globaalides

Andmebaasi InterSystems IRIS toetab huvitavaid andmestruktuure - globaalid. Tegelikult on need mitmetasandilised võtmed, millel on erinevad lisafunktsioonid, nagu tehingud, kiire funktsionaalsus andmepuude läbimiseks, lukustused ja oma keele ObjectScript.

Rohkem globaalsest sügiseks artiklite tsüklis „Globaalid - andmete salvestamise mõõgad”:

Puud. Osa 1
Puud. Osa 2
Sparssed massiivid. Osa 3

Mind huvitab, kuidas tehingud globaalides on ellu viidud, millised omadused seal on. See on ju täiesti erinev andmestruktuur võrreldes traditsiooniliste tabelitega. Oluliselt madalamal tasemel.

Kuna on teada, et relatsiooniliste andmebaaside teooriast peaks hea tehingu teostus vastama nõuetele ACID:

A - Atoomilisus. Kogu tehingu jooksul tehtud muudatused peavad olema kas täiesti salvestatud või mitte midagi.

C - Konsistentsus. Tehingu lõpuks peab andmebaasi loogiline seisund olema omavahel kooskõlas. Suur osa sellest nõudest puudutab programmeerijat, kuid SQL-andmebaaside puhul kehtib see ka väliste võtmete kohta.

I - Isolatsioon. Samal ajal toimuvad tehingud ei tohiks üksteist mõjutada.

D - Vastupidavus. Pärast tehingu edukat lõpetamist ei tohiks madalama taseme probleemid (nt voolukatkestus) mõjutada tehingu käigus muudetud andmeid.

Globaalid on relatsioonilised andmestruktuurid. Need loodi ülikiireks tööks väga piiratud riistvaral. Uurime, kuidas tehingud globaalides on ellu viidud ametliku docker-pildi IRIS abil.

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

1. Atoomilisus

Atoomilisust on kõige lihtsam kontrollida. Kontrollime andmebaasi konsoolist.

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. Atoomilisus on tagatud: kõik muudatused on salvestatud.

Võtame ülesande keerulisemaks, sisse viies vea, ja vaatame, kuidas tehing säilib, osaliselt või üldse mitte.

Kordame atooblisuse kontrolli:

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

Pärast seda peatame konteineri sunniviisil, käivitame selle uuesti ja vaatame.

docker kill my-iris

See käsk on praktiliselt ekvivalentne järsu voolu katkestamisega, kuna see saadab protsessile SIGKILL kohese peatumise signaali.

Kas tehing võib olla osaliselt salvestatud?

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

— Ei, ei salvestunud.

Proovime 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)

Samuti ei salvestunud midagi.

2. Ühtsus

Kuna globaalides luuakse võtmed samuti globaalide järgi (tuletan meelde, et gloobaal on madalama taseme struktuur andmete salvestamiseks kui relatsiooniline tabel), peab ühtsuse nõude täitmiseks võtme muutmine olema sama tehingu sees nagu gloobala muutmine.

Näiteks meil on gloobaal ^person, kus salvestame isikute andmeid ja võtmena kasutame isikukoodi.

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

Kuna kiireks otsinguks perekonna nime ja eesnime järgi, lõime võtme ^index.

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

Selleks, et andmebaas oleks ühtne, peame isikuandmeid lisama järgmiselt:

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

Seega, kustutamise korral peame samuti kasutama tehingut:

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

Teisisõnu, ühtsuse nõuete täitmine lasub täielikult programmeerija õlul. Kuid kui me räägime globaalidest, on see normaalne, kuna nende madalama taseme loomus.

3. Isolatsioon

Siin hakkavad keerulised asjad pihta. Paljud kasutajad töötavad sama andmebaasi kallal samal ajal, muutes samu andmeid.

Situatsioon on võrreldav sellega, kui palju kasutajaid üritab samaaegselt töötada ühe ja sama koodi hoidla kallal ning üritavad korraga teha komiteeringuid paljude failide osas.

Andmebaas peab seda kõike lahendama reaalajas. Arvestades, et tõsistes ettevõtetes on isegi spetsiaalne isik, kes vastutab versioonihalduse eest (harude ühinemine, konfliktide lahendamine jne), ja andmebaas peab seda kõike tegema reaalajas, siis tekib selge ülesande keerukus ning andmebaasi ja sellele teenindava koodi õige projekteerimise vajadus.

Andmebaas ei saa mõista, mida kasutajad teevad, et vältida konflikte, kui nad töötavad sama teabega. See suudab ainult tühistada ühe tehingu, mis on vasturääkiv teisele, või täita need järjestikku.

Veel üks probleem on see, et tehingu täitmise ajal (enne kinnitamist) võib andmebaasi seisund olla ühitamatu, seetõttu on soovitav, et teised tehingud ei pääseks ühitamata andmebaasi olekusse. Rikkalikud andmebaasid saavutavad selle mitmel viisil: lõike loomise, versioonide haldamise jne kaudu.

Tehingute paralleelsel täitmisel on oluline, et need ei segaks üksteist. See on isoleerituse omadus.

SQL määratleb 4 isoleerituse taset:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

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

READ UNCOMMITTED — see on madalaim isoleerituse tase, kuid samal ajal ka kiireim. Tehingud saavad lugeda üksteise tehtud muudatusi.

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

Kui meil on pikk tehing T1, mille jooksul on toimunud kinnitamised tehingutes T2, T3 … Tn, mis töötasid sama teabega nagu T1, siis T1-s andmeid küsides saame iga kord erineva tulemuse. Seda nähtust nimetatakse mitteuuesti lugemiseks.

REPEATABLE READ — selle isoleerituse tasemega ei ole meil mitteuuesti lugemise nähtust, kuna iga kord, kui andmeid loetakse, luuakse andmete tulemi lõige, ja selles sama tehingus kasutatakse andmeid lõigetest. Kuid selle isoleerituse taseme korral on võimalik lugeda fantoomandmeid, mille alla kuuluvad uute ridade lugemine, mis on lisatud paralleelsete kinnitatud tehingute poolt.

SERIALIZABLE — kõrgeim isoleerituse tase. Sellel on see omadus, et tehingus kasutatavad andmed (lugemiseks või muutmiseks) muutuvad teistele tehingutele kättesaadavaks alles pärast esimest tehingu lõpetamist.

Alustame sellest, kas tehingutes on toimingute isolatsioon peavoolust. Avame 2 terminali aken.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Isolatsiooni ei ole. Üks voog näeb, mida teeb teine, kes avas tehingu.

Vaadakem, kas erinevate voogude tehingud näevad, mis toimub nende sees.

Avame 2 terminali akent ja avame 2 tehingut paralleelselt.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Paralleelsed tehingud näevad üksteise andmeid. Niisiis saime kõige lihtsama, kuid ka kõige kiirema isolatsioonitase READ UNCOMMITED.

Põhimõtteliselt oli seda oodata globaalselt, kus tõhusus oli alati esmatähtis.

Kuidas toimida, kui me vajame globaalsetes toimingutes kõrgemat isolatsioonitaset?

Siin tasub mõelda, miks üldse on vajalikud isolatsioonitasemed ja kuidas need toimivad.

Kõrgeim isolatsioonitase SERIALIZE tähendab, et paralleelselt teostatavate tehingute tulemus on ekvivalentne nende järjestikusele teostamisele, mis tagab konflikti puudumise.

Seda saame teha, kasutades hästi planeeritud lukustusi ObjectScriptis, mis pakuvad mitmeid rakendusi: võime teha tavalise, inkrementaalse, mitmeotstarbelise lukustamise käsuga LOCK.

Madalamad isolatsioonitasemed on kompromissid, mille eesmärk on suurendada andmebaasi töökiirus.

Vaadakem, kuidas saame lukustuste abil saavutada erinevaid isolatsioonitasemeid.

See käsk võimaldab võtta mitte ainult eksklusiivseid lukustusi, mis on vajalikud andmete muutmiseks, vaid ka nn jagatud lukustusi, mida saavad korraga mitu voogu, kui nad peavad lugema andmeid, mida ei tohi teiste protsesside poolt lugemise ajal muuta.

Rohkem teavet kahefaasilise lukustamise meetodi kohta vene ja inglise keeles:

→ Kahefaasiline lukustus
→ Two-phase locking

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

Loome lukustuste abil sellised vaateaknad, kus andmebaasi seisund on konsolideeritud. Ja kõik sellistele konsolideeritud seisundi vaateakendele tehtavad päringud kontrollitakse lukustuste abil.

Jagatud lukud samaaegsetele andmetele on korduvkasutatavad - need võivad omada mitu protsessi. Need lukud keelavad teistel protsessidel andmete muutmist, st neid kasutatakse andmebaasi konsolideeritud oleku akende moodustamiseks.

Eksklusiivsed lukud on kasutusel andmete muutmiseks - sellist lukku saab omada ainult üks protsess. Eksklusiivset lukku saab võtta:

1. Iga protsess, kui andmed on vabastatud
2. Ainult see protsess, millel on nende andmete jagatud lukud ja kes esimesena soovis eksklusiivset lukku.

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

READ_COMMITTED — selle taseme sisu on, et näeme ainult teistest voogudest kinnitatud andmeid. Kui andmed teises tehingus ei ole veel kinnitatud, siis näeme nende vana versiooni.

See võimaldab meil tööd paralleliseerida, selle asemel et oodata luku vabastamist.

Ilma spetsiaalsete nõtkusteta ei näe me vana andmeversiooni IRISes, seetõttu peame rahulduma lukudega.

Seega peame jagatud lukudega lubama andmete lugemise ainult kooskõlastusmomentide ajal.

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

Rahaülekande hetk isikult 123 isikule 242:

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)

Raha summa küsimise hetk isikult 123 enne arveldamist peab olema kaasas eksklusiivne lukustamine (vaikimisi):

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

Kui peab näitama konto seisu isiklikus kabinetis, siis saab kasutada jagatud lukku või üldse mitte kasutada:

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

Kuid kui eeldada, et andmebaasi muudatuste teostamine toimub peaaegu koheselt (meenutan, et globaalid on palju madalamal tasemel struktuur kui suhteline tabel), siis on selle taseme vajadus vähenenud.

REPEATABLE READ — selle isolatsiooni tasemel on lubatud, et andmete lugemised, mida võivad muuta paralleelsed tehingud, võivad olla mitu.

Seega peame jagatud lukku panema andmete lugemiseks, mida me muudame ja eksklusiivsed lukud andmete jaoks, mida me muudame.

LOCK operaator võimaldab ühes operaatoris detailselt loetleda kõik vajalikud lukustused, mida võib olla väga palju.

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

muid operatsioone (sel ajal üritavad paralleelsed vood ^person(123, amount) muuta, kuid ei saa)

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

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

Lukustuste loetlemisel koma kaudu võetakse neid järjestikku, aga kui teha nii:

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

siis võetakse need atomaarsetena korraga.

SERIALIZE — me peame seadma lukustused nii, et lõpuks kõik tehingud, mis omavad ühiseid andmeid, teostatakse järjestikku. Selle lähenemise jaoks peavad enamik lukustustest olema eksklusiivsed ja võetud kõige väiksematel globaalsetel aladel, et tagada tulemuslikkus.

Kui rääkida vahendite väljavõtmisest globaalsetes ^person, siis on selle jaoks vastuvõetav vaid SERIALIZE isolatsioonitase, kuna raha tuleb kulutada rangelt järjestikku, vastasel juhul on võimalik kulutada sama summa mitu korda.

4. Kestus

Olen teinud katseid konteineri järsu väljalülitamisega

docker kill my-iris

Andmebaas talus seda hästi. Probleeme ei olnud.

Kokkuvõte

Globaalide jaoks InterSystems IRIS-is on tehingute tugi. Need on tõeliselt atomaarsetes ja usaldusväärsetes. Andmebaasi järjepidevuse tagamiseks globaalides on vajalik programmeerija pingutus ja tehingute kasutamine, kuna seal ei ole keerulisi sisseehitatud struktuure, nagu välised võtmed.

Globaalide isolatsioonitase lukustuste kasutamata on READ UNCOMMITTED, aga lukustuste kasutamise korral võib selle tagada kuni SERIALIZE tasemeni.

Tehingute korrektne ja kiire toimimine globaalides sõltub väga palju programmeerija oskustest: mida rohkem kasutatakse jagatud lukustusi lugemisel, seda kõrgem on isolatsioonitase, ja mida kitsamalt võetakse eksklusiivseid lukustusi, seda rohkem suureneb jõudlus.

Allikas: habr.com