InterSystems IRIS DBMS styður áhugaverð uppbygging til að geyma gögn - hnattræn. Í meginatriðum eru þetta fjölþrepa lyklar með ýmsum aukahlutum í formi viðskipta, hraðvirkum aðgerðum til að fara yfir gagnatré, læsingar og eigin ObjectScript tungumál.
Lestu meira um hnattræna aðila í greinaröðinni „Globals eru fjársjóðssverð til að geyma gögn“:
Ég fékk áhuga á því hvernig viðskipti eru útfærð á heimsvísu, hvaða eiginleikar það eru. Enda er þetta allt önnur uppbygging til að geyma gögn en venjulegar töflur. Miklu lægra stig.
Eins og vitað er af kenningunni um venslagagnagrunna þarf góð útfærsla á viðskiptum að uppfylla kröfur :
A - Atóm (atómvirkni). Allar breytingar sem gerðar eru á viðskiptunum eða engar eru skráðar.
C - Samræmi. Eftir að færslu er lokið verður rökrétt ástand gagnagrunnsins að vera innra í samræmi. Að mörgu leyti varðar þessi krafa forritarann, en þegar um SQL gagnagrunna er að ræða snertir hún einnig erlenda lykla.
Ég - Einangra. Samhliða viðskipti ættu ekki að hafa áhrif á hvort annað.
D - Varanlegur. Eftir að færslu hefur verið lokið ættu vandamál á lægri stigum (td rafmagnsbilun) ekki að hafa áhrif á gögnin sem viðskiptin breyta.
Hnattrænar gagnastrúktúrar eru ekki tengslasamstæður. Þau voru hönnuð til að keyra mjög hratt á mjög takmörkuðum vélbúnaði. Við skulum skoða framkvæmd viðskipta í alþjóðlegum fyrirtækjum með því að nota .
Til að styðja við viðskipti í IRIS eru eftirfarandi skipanir notaðar: , , .
1. Atómvirkni
Auðveldasta leiðin til að athuga er atómvirkni. Við athugum úr gagnagrunnsborðinu.
Kill ^a
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TCOMMITÞá ályktum við:
Write ^a(1), “ ”, ^a(2), “ ”, ^a(3)Við fáum:
1 2 3Allt er í lagi. Atómvirkni er viðhaldið: allar breytingar eru skráðar.
Við skulum flækja verkefnið, kynna villu og sjá hvernig viðskiptin eru vistuð, að hluta eða ekki.
Við skulum athuga atomicity aftur:
Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3Þá munum við stöðva gáminn af krafti, ræsa hann og sjá.
docker kill my-irisÞessi skipun jafngildir næstum þvingunarstöðvun, þar sem hún sendir SIGKILL merki til að stöðva ferlið strax.
Kannski var færslunni bjargað að hluta?
WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)— Nei, það hefur ekki lifað af.
Við skulum prófa rollback skipunina:
Kill ^A
TSTART
Set ^a(1) = 1
Set ^a(2) = 2
Set ^a(3) = 3
TROLLBACK
WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)Ekkert hefur heldur varðveist.
2. Samræmi
Þar sem í gagnagrunnum sem byggjast á hnattrænum gagnagrunnum eru lyklar einnig gerðir á hnattrænum (minni þig á að hnattræn er lægra stigi uppbygging til að geyma gögn en venslatafla), til að uppfylla samræmiskröfuna, verður breyting á lyklinum að fylgja með. í sömu viðskiptum og breyting á hnattrænu.
Til dæmis höfum við alþjóðlega ^persónu, þar sem við geymum persónuleika og við notum TIN sem lykil.
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
...Til þess að hafa skjóta leit eftir eftirnafni og fornafni gerðum við ^index lykilinn.
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1Til þess að gagnagrunnurinn sé samkvæmur verðum við að bæta persónunni svona við:
TSTART
^person(1234567, ‘firstname’) = ‘Sergey’
^person(1234567, ‘lastname’) = ‘Kamenev’
^person(1234567, ‘phone’) = ‘+74995555555
^index(‘Kamenev’, ‘Sergey’, 1234567) = 1
TCOMMITÍ samræmi við það verðum við líka að nota færslu við eyðingu:
TSTART
Kill ^person(1234567)
ZKill ^index(‘Kamenev’, ‘Sergey’, 1234567)
TCOMMITMeð öðrum orðum, að uppfylla samræmiskröfuna hvílir algjörlega á herðum forritarans. En þegar kemur að hnattrænum mönnum, þá er þetta eðlilegt, vegna þess að þeir eru á lágu stigi.
3. Einangrun
Þetta er þar sem villtirnar byrja. Margir notendur vinna samtímis á sama gagnagrunni og breyta sömu gögnum.
Ástandið er sambærilegt við það þegar margir notendur vinna samtímis með sömu kóðageymsluna og reyna að framkalla breytingar á mörgum skrám í einu.
Gagnagrunnurinn ætti að raða þessu öllu út í rauntíma. Með hliðsjón af því að í alvarlegum fyrirtækjum er jafnvel sérstakur aðili sem ber ábyrgð á útgáfustýringu (við sameiningu útibúa, lausn á ágreiningi o.s.frv.) og gagnagrunnurinn verður að gera þetta allt í rauntíma, hversu flókið verkefnið er og réttmæti gagnagrunnshönnun og kóða sem þjónar honum.
Gagnagrunnurinn getur ekki skilið merkingu þeirra aðgerða sem notendur framkvæma til að forðast árekstra ef þeir eru að vinna með sömu gögnin. Það getur aðeins afturkallað eina færslu sem stangast á við aðra, eða framkvæmt þau í röð.
Annað vandamál er að við framkvæmd færslu (fyrir skuldbindingu) getur ástand gagnagrunnsins verið ósamræmi, svo það er æskilegt að önnur viðskipti hafi ekki aðgang að ósamræmi stöðu gagnagrunnsins, sem næst í venslagagnagrunnum á margan hátt: að búa til skyndimyndir, raðir í mörgum útgáfum o.s.frv.
Þegar viðskipti eru framkvæmd samhliða er mikilvægt fyrir okkur að þau trufli ekki hvert annað. Þetta er eiginleiki einangrunar.
SQL skilgreinir 4 einangrunarstig:
- LESIÐ ÓSKRÁTT
- LESA SKOFNAÐ
- Endurtekjanlegur LEstur
- Raðhæft
Við skulum skoða hvert stig fyrir sig. Kostnaður við að innleiða hvert þrep eykst næstum veldishraða.
LESIÐ ÓSKRÁTT - þetta er lægsta einangrunarstigið, en á sama tíma það hraðasta. Viðskipti geta lesið breytingar sem gerðar eru af hvor annarri.
LESA SKOFNAÐ er næsta stig einangrunar, sem er málamiðlun. Færslur geta ekki lesið breytingar hvers annars fyrir skuldbindinguna, en þær geta lesið allar breytingar sem gerðar eru eftir skuldbindinguna.
Ef við erum með langa færslu T1, þar sem skuldbindingar áttu sér stað í færslum T2, T3 ... Tn, sem virkuðu með sömu gögn og T1, þá fáum við aðra niðurstöðu í hvert skipti þegar beðið er um gögn í T1. Þetta fyrirbæri er kallað óendurtekinn lestur.
Endurtekjanlegur LEstur — á þessu einangrunarstigi höfum við ekki fyrirbærið óendurtekinn lestur, vegna þess að fyrir hverja beiðni um að lesa gögn er búið til skyndimynd af niðurstöðugögnunum og þegar þau eru endurnotuð í sömu viðskiptum, gögnin úr skyndimyndinni er notað. Hins vegar er hægt að lesa fantom gögn á þessu einangrunarstigi. Þetta vísar til að lesa nýjar línur sem bættust við með samhliða skuldbundnum færslum.
Raðhæft - hæsta einangrun. Það einkennist af því að gögn sem notuð eru á einhvern hátt í viðskiptum (lesa eða breyta) verða aðgengileg öðrum viðskiptum fyrst eftir að fyrstu viðskiptunum er lokið.
Í fyrsta lagi skulum við reikna út hvort það sé einangrun aðgerða í viðskiptum frá aðalþræðinum. Við skulum opna 2 flugstöðvarglugga.
Kill ^t
Write ^t(1)
2
TSTART
Set ^t(1)=2Það er engin einangrun. Einn þráðurinn sér hvað sá seinni sem opnaði viðskiptin er að gera.
Við skulum sjá hvort viðskipti mismunandi þráða sjái hvað er að gerast inni í þeim.
Opnum 2 flugstöðvarglugga og opnum 2 færslur samhliða.
kill ^t
TSTART
Write ^t(1)
3
TSTART
Set ^t(1)=3
Samhliða viðskipti sjá gögn hvers annars. Þannig að við fengum einfaldasta, en einnig hraðasta einangrunarstigið, LESA ÓFYRIR.
Í grundvallaratriðum mætti búast við þessu fyrir alþjóðlega aðila, þar sem frammistaða hefur alltaf verið í forgangi.
Hvað ef við þurfum meiri einangrun í aðgerðum á heimsvísu?
Hér þarftu að hugsa um hvers vegna einangrunarstig er yfirleitt þörf og hvernig þau virka.
Hæsta einangrunarstigið, SERIALIZE, þýðir að niðurstaða viðskipta sem framkvæmd er samhliða jafngildir raðframkvæmd þeirra, sem tryggir að árekstrar séu ekki til staðar.
Við getum gert þetta með því að nota snjalllása í ObjectScript, sem hafa mikið af mismunandi notkun: þú getur gert reglulega, stigvaxandi, margfalda læsingu með skipuninni .
Lægri einangrunarstig eru málamiðlun sem er hönnuð til að auka gagnagrunnshraða.
Við skulum sjá hvernig við getum náð mismunandi stigum einangrunar með því að nota læsingar.
Þessi rekstraraðili gerir þér kleift að taka ekki aðeins einkalása sem þarf til að breyta gögnum, heldur svokallaða sameiginlega læsa, sem geta tekið nokkra þræði samhliða þegar þeir þurfa að lesa gögn sem ekki ætti að breyta af öðrum ferlum meðan á lestrinum stendur.
Nánari upplýsingar um tveggja fasa lokunaraðferðina á rússnesku og ensku:
→
→
Erfiðleikarnir eru þeir að meðan á viðskiptum stendur gæti ástand gagnagrunnsins verið ósamræmi, en þessi ósamræmi gögn eru sýnileg öðrum ferlum. Hvernig á að forðast þetta?
Með því að nota læsingar munum við búa til sýnileikaglugga þar sem ástand gagnagrunnsins verður í samræmi. Og öllum aðgangi að slíkum gluggum um sýnileika hins samþykkta ríkis verður stjórnað af læsingum.
Samnýttir læsingar á sömu gögnum eru endurnýtanlegir - nokkrir ferli geta tekið þá. Þessir læsingar koma í veg fyrir að aðrir ferlar breyti gögnum, þ.e. þau eru notuð til að mynda glugga með samræmdu gagnagrunnsástandi.
Einkalásar eru notaðir fyrir gagnabreytingar - aðeins eitt ferli getur tekið slíkan lás. Einkalás er hægt að taka með því að:
- Hvaða ferli sem er ef gögnin eru ókeypis
- Aðeins ferlið sem hefur sameiginlegan lás á þessum gögnum og var fyrst til að biðja um einkalás.
Því þrengri sem sýnileikaglugginn er, því lengur þurfa önnur ferli að bíða eftir honum, en því samkvæmara getur ástand gagnagrunnsins innan hans verið.
READ_COMMITTED — Kjarninn í þessu stigi er að við sjáum aðeins skuldbundin gögn frá öðrum þráðum. Ef gögnin í öðrum viðskiptum hafa ekki enn verið framin, þá sjáum við gömlu útgáfuna.
Þetta gerir okkur kleift að samhliða verkinu í stað þess að bíða eftir að lásinn losni.
Án sérstakra brellna munum við ekki geta séð gömlu útgáfuna af gögnunum í IRIS, þannig að við verðum að láta okkur nægja lása.
Í samræmi við það verðum við að nota sameiginlega læsa til að leyfa aðeins að lesa gögn á augnablikum samkvæmis.
Segjum að við höfum notendagrunn ^manneskja sem millifærir peninga á milli sín.
Tilfærslustund frá einstaklingi 123 til einstaklings 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)Augnablikinu sem biður um peningaupphæðina frá einstaklingi 123 fyrir skuldfærslu verður að fylgja einangruð blokkun (sjálfgefið):
LOCK +^person(123)
Write ^person(123)Og ef þú þarft að sýna reikningsstöðuna á persónulega reikningnum þínum, þá geturðu notað sameiginlegan lás eða ekki notað hann yfirleitt:
LOCK +^person(123)#”S”
Write ^person(123)Hins vegar, ef við gerum ráð fyrir að gagnagrunnsaðgerðir séu framkvæmdar nánast samstundis (minni þig á að hnattrænar eru mun lægra stigi uppbygging en venslatafla), þá minnkar þörfin fyrir þetta stig.
Endurtekjanlegur LEstur - Þetta einangrunarstig gerir kleift að lesa margar gögn sem hægt er að breyta með samhliða viðskiptum.
Í samræmi við það verðum við að setja sameiginlegan læsingu á lestur gagna sem við breytum og einkalása á gögnum sem við breytum.
Sem betur fer gerir LOCK rekstraraðilinn þér kleift að skrá í smáatriðum alla nauðsynlega lása, sem það getur verið mikið af, í einni yfirlýsingu.
LOCK +^person(123, amount)#”S”
чтение ^person(123, amount)aðrar aðgerðir (á þessum tíma reyna samhliða þræðir að breyta ^persónu(123, upphæð), en geta það ekki)
LOCK +^person(123, amount)
изменение ^person(123, amount)
LOCK -^person(123, amount)
чтение ^person(123, amount)
LOCK -^person(123, amount)#”S”Þegar læsingar eru aðskildar með kommum eru skráðar í röð, en ef þú gerir þetta:
LOCK +(^person(123),^person(242))þá eru þau tekin í frumeindaformi allt í einu.
RÆÐI — við verðum að setja læsingar þannig að á endanum séu öll viðskipti sem hafa sameiginleg gögn framkvæmd í röð. Fyrir þessa nálgun ættu flestir lásar að vera einir og teknir á minnstu svæði heimsins fyrir frammistöðu.
Ef við tölum um skuldfærslu fjármuna í alþjóðlegri ^persónu, þá er aðeins SERIALIZE einangrunarstigið ásættanlegt fyrir það, þar sem peningum verður að eyða nákvæmlega í röð, annars er hægt að eyða sömu upphæð nokkrum sinnum.
4. Ending
Ég gerði prófanir með harðri klippingu á ílátinu með því að nota
docker kill my-irisGrunnurinn þoldi þær vel. Engin vandamál komu fram.
Ályktun
Fyrir alþjóðlegt fólk hefur InterSystems IRIS viðskiptastuðning. Þeir eru sannarlega atómbundnir og áreiðanlegir. Til að tryggja samræmi í gagnagrunni sem byggir á hnattrænum gögnum er þörf á forritaraátaki og notkun viðskipta, þar sem hann hefur ekki flóknar innbyggðar smíðar eins og erlenda lykla.
Einangrunarstig hnattrænna án þess að nota lása er LESIÐ ÓFYRIRTÆKIÐ og þegar lásar eru notaðar er hægt að tryggja það upp í SERIALIZE stigið.
Réttmæti og hraði viðskipta á hnattrænum fyrirtækjum fer mjög eftir kunnáttu forritarans: því fleiri læsingar sem eru notaðar víðar við lestur, því hærra sem einangrunarstigið er og því meira sem takmarkaðari læsingar eru teknar, því hraðari verða afköst.
Heimild: www.habr.com