Transaksjonar i globalar InterSystems IRIS

DBMS InterSystems IRIS støttar interessante strukturar for datalagring — globalar. I utgangspunktet er dette flernivå-nøkklar med ulike ekstra funksjonar som transaksjonar, raske funksjonar for å navigere i datatrær, låsing, og sitt eige språk, ObjectScript.

Les meir om globalar i artikkelen «Globalar — sverd og skjold for datalagring»:

Trær. Del 1
Trær. Del 2
Sparsomme matriser. Del 3

Eg vart nysgjerrig på korleis transaksjonar er implementert i globalar, og kva som gjer desse strukturane unike. Det er ein heilt annan måte å lagre data på enn dei vante tabellane. Mye meir låg-nivå.

Som kjent frå teorien om relasjonsdatabasar, bør ein god implementering av transaksjonar oppfylle krava ACID:

A — Atomic (atomaritet). Alle endringar som er gjort i transaksjonen skal registrerast, eller inga endring skal gjerast.

C — Consistency (konsistens). Etter at transaksjonen er fullført, må den logiske tilstanden til databasen vere internt konsistent. Dette kravet angår i stor grad programmaren, men i tilfelle av SQL-databasar, er det også knytt til utanlandske nøklar.

I — Isolate (isolasjon). Parallelt utførte transaksjonar skal ikkje påverke kvarandre.

D — Durable (varigheit). Etter vellykka avslutning av transaksjonen, skal problem på lavare nivå (for eksempel strømsvikt) ikkje påverke data som er endra av transaksjonen.

Globalar er ikkje-relasjonelle datastrukturar. Dei vart utvikla for ekstrem rask drifting på svært avgrensa maskinvare. La oss sjå nærare på implementasjonen av transaksjonar i globalar ved hjelp av den offisielle docker-bilete av IRIS.

For å støtte transaksjonar i IRIS, blir følgjande kommandoar brukte: TSTART, TCOMMIT, TROLLBACK.

1. Atomaritet

Det er lettast å sjekke atomaritet. Vi sjekkar frå databasen sin konsoll.

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

Så får vi ut:

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

Vi får:

1 2 3

Alt i orden. Atomaritet er oppretthaldt: alle endringar er registrert.

La oss gjere oppgåva meir komplisert, vi introduserer ein feil og sjekkar korleis transaksjonen blir bevart, delvis eller ikkje i det heile.

La oss sjekke atomariteten igjen:

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

Deretter tvingar vi til å stoppe containeren, startar opp igjen og ser kva som skjer.

docker kill my-iris

Denne kommandoen er praktisk talt lik en tvungen strømavstengning, da den sender et umiddelbart stoppesignal til prosessen SIGKILL.

Kan det ha vært at transaksjonen ble delvis lagret?

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

— Nei, den ble ikke lagret.

La oss prøve tilbakeføringskommandoen:

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)

Det ble heller ikke lagret noe.

2. Konsistens

Siden i globale databaser blir nøklene også laget på globale nivåer (la meg minne om at global er en lavere nivåstruktur for datalagring enn en relasjonell tabell), for å oppfylle kravene til konsistens må endringen av nøkkelen inkluderes i den samme transaksjonen som endringen av globalen.

For eksempel har vi en global ^person, der vi lagrer personlige data og bruker identitetsnummeret som nøkkel.

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

For å ha rask søking etter etternavn og fornavn laget vi nøkkelen ^index.

^index('Kamenev', 'Sergey', 1234567) = 1

For at databasen skal være konsistent, må vi legge til personen slik:

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

Dermed må vi også bruke en transaksjon ved sletting:

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

Med andre ord ligger oppfyllelsen av konsistenskravene helt på utviklerens skuldre. Men når det gjelder globale, er dette normalt, på grunn av deres lavnivånatur.

3. Isolasjon

Her begynner det å bli komplisert. Mange brukere arbeider samtidig med den samme databasen, endrer de samme dataene.

Situasjonen kan sammenlignes med at mange brukere samtidig jobber med det samme kode-repositoriet og prøver å commite endringer i mange filer på en gang.

Databasen må håndtere alt dette i sanntid. Gitt at i seriøse selskaper finnes det til og med en spesialperson som er ansvarlig for versjonskontroll (for å slå sammen grener, løse konflikter, osv.), og at databasen må gjøre alt dette i sanntid, blir oppgavens kompleksitet og korrektheten i databasedesign og koden som vedlikeholder den åpenbar.

Databasen kan ikke forstå meningen med de handlingene som brukerne utfører for å forhindre konflikter når de jobber med de samme dataene. Den kan bare tilbakekalle en transaksjon som strider mot en annen eller utføre dem sekvensielt.

Et annet problem er at under utførelsen av en transaksjon (før kommittering) kan databasen være i en inkonsekvent tilstand, derfor er det ønskelig at andre transaksjoner ikke har tilgang til den inkonsekvente tilstanden til databasen, noe som oppnås i relasjonsdatabaser på mange måter: ved å lage øyeblikksbilder, ved fleredelelinje og så videre.

Når transaksjoner kjøres parallelt, er det viktig at de ikke forstyrrer hverandre. Dette er egenskapen av isolasjon.

SQL definerer 4 nivåer av isolasjon:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

La oss se på hvert nivå separat. Kostnadene for implementering av hvert nivå øker nesten eksponentielt.

READ UNCOMMITTED — dette er det laveste isolasjonsnivået, men samtidig det raskeste. Transaksjoner kan lese endringer gjort av hverandre.

READ COMMITTED — dette er det neste isolasjonsnivået, som er et kompromiss. Transaksjoner kan ikke lese endringer gjort av hverandre før kommittering, men kan lese eventuelle endringer gjort etter kommittering.

Hvis vi har en lang transaksjon T1, der det har vært kommitteringer i transaksjonene T2, T3… Tn, som har arbeidet med de samme dataene som T1, vil vi hver gang vi forespør data i T1 motta ulike resultater. Dette fenomenet kalles ikke-repetert lesing.

REPEATABLE READ — på dette isolasjonsnivået har vi ikke fenomenet ikke-repetert lesing, fordi for hver forespørsel om å lese data opprettes et øyeblikksbilde av dataresultatet, og når det brukes igjen i denne samme transaksjonen, benyttes dataene fra øyeblikksbildet. Imidlertid er det på dette isolasjonsnivået mulig å lese fantomdata. Dette gjelder lesing av nye rader som er lagt til av parallelle bekreftede transaksjoner.

SERIALIZABLE — det høyeste isolasjonsnivået. Det er preget av det at data som på en eller annen måte brukes i transaksjonen (lesing eller endring) blir tilgjengelige for andre transaksjoner først etter at den første transaksjonen er fullført.

Først må vi se på om det er isolasjon av operasjonene i transaksjonen fra hovedstrømmen. Vi åpner 2 terminalvinduer.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Det finnes ingen isolasjon. Én strøm ser hva den andre som har åpnet transaksjonen gjør.

La oss se om transaksjoner fra forskjellige strømmer ser hva som skjer inni dem.

Vi åpner 2 terminalvinduer og åpner 2 transaksjoner parallelt.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Parallele transaksjoner ser dataene til hverandre. Så vi har fått det enkleste, men også raskeste nivået av isolasjon, READ UNCOMMITTED.

Dette var i prinsippet å forvente for globale variabler, hvor ytelse alltid har vært i fokus.

Hva om vi trenger et høyere nivå av isolasjon for operasjoner på globale variabler?

Her må vi tenke på hvorfor nivåer av isolasjon er nødvendige og hvordan de fungerer.

Det høyeste nivået av isolasjon, SERIALIZE, betyr at resultatet av parallelt utførte transaksjoner er ekvivalent med sekvensiell utføring, som garanterer fravær av kollisjoner.

Dette kan vi oppnå med hensiktsmessige låser i ObjectScript, som har mange forskjellige bruksområder: man kan gjøre vanlig, inkrementell, eller flere låsinger med kommandoen LOCK.

Lavere nivåer av isolasjon er kompromisser laget for å øke databasehastigheten.

La oss se hvordan vi kan oppnå ulike nivåer av isolasjon med hjelp av låser.

Denne operatoren gjør det mulig å ta ikke bare eksklusive låser, som er nødvendige for å endre data, men også såkalte delte låser, som flere strømmer kan ta parallelt når de trenger å lese data som ikke skal endres av andre prosesser under lesing.

Mer om tofaselåsingsmetoden på russisk og engelsk:

→ Tofaselåsning
→ Two-phase locking

Vanskeligheten er at under transaksjonen kan databasens tilstand være inkonsistent, men disse inkonsistente dataene er synlige for andre prosesser. Hvordan unngå dette?

Vi vil lage synsvinduer med låser der databasens tilstand er konsistent. Og all tilgang til slike vinduer med konsistent tilstand vil bli kontrollert av låser.

Delte blokkeringer av de samme dataene er gjenbrukbare — flere prosesser kan ta dem. Disse blokkeringene forhindrer andre prosesser i å endre dataene, dvs. de brukes til å danne vinduer av konsistent tilstand i databasen.

Eksklusive blokkeringer brukes for å endre data — en slik blokkering kan kun tas av én prosess. En eksklusiv blokkering kan tas av:

1. Enhver prosess, hvis dataene er frie.
2. Bare den prosessen som har en delt blokkering på disse dataene og først har bedt om en eksklusiv blokkering.

Jo smalere synsvinduet er, desto lengre må andre prosesser vente, men desto mer konsistent kan tilstanden i databasen være i det.

READ_COMMITED — essensen av dette nivået er at vi bare ser bekreftede data fra andre strømmer. Hvis dataene i en annen transaksjon ikke er bekreftet ennå, ser vi den gamle versjonen.

Dette lar oss parallellisere arbeidet i stedet for å vente på at blokkeringen skal frigjøres.

Uten spesielle triks vil vi ikke kunne se den gamle versjonen av dataene i IRIS, så vi må nøye oss med blokkeringer.

Tilsvarende må vi med hjelp av delte blokkeringer tillate lesing av data bare i konsistensøyeblikkene.

La oss si at vi har en brukerbase ^person som overfører penger til hverandre.

Tidspunktet for overføring fra person 123 til person 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)

Tidspunktet for forespørselen om hvor mye penger person 123 har før fradrag, må være ledsaget av en eksklusiv blokkering (som standard):

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

Men hvis man trenger å vise kontobalansen i den personlige kontoen, kan man bruke en delt blokkering eller helt la være å bruke den:

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

Imidlertid, hvis vi antar at operasjoner med databasen utføres praktisk talt øyeblikkelig (jeg minner om at globale variabler er en langt mer lavnivåstruktur enn relasjonsdatabasen), faller behovet for dette nivået.

REPEATABLE READ — på dette isolasjonsnivået er det tillatt at det kan være flere lesinger av data som kan endres av parallelle transaksjoner.

Tilsvarende må vi sette en delt blokkering på dataene vi endrer og eksklusive blokkeringer på dataene vi endrer.

Operatoren LOCK gjør det mulig å detaljere alle nødvendige låser i én enkelt operator, som kan være mange.

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

andre operasjoner (mens parallelle strømmer prøver å endre ^person(123, amount), men ikke kan)

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

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

Ved å liste opp låser med komma tas de sekvensielt, men hvis vi gjør det slik:

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

tas de atomært alle samtidig.

SERIALIZE — vi må sette opp låser slik at til slutt alle transaksjoner som har felles data utføres sekvensielt. For denne tilnærmingen må de fleste låser være eksklusive og tas på de minste områdene av globalen for ytelse.

Når det gjelder uttak av midler i globalen ^person, er det kun SERIALIZE-isolasjonsnivået som er akseptabelt, siden penger må brukes strengt sekvensielt, ellers kan man risikere å bruke den samme summen flere ganger.

4. Varighet

Jeg har utført tester med hard nedstengning av containeren ved hjelp av

docker kill my-iris

Databasen håndterte dette godt. Det ble ikke oppdaget noen problemer.

Konklusjon

For globaler i InterSystems IRIS er det støtte for transaksjoner. De er faktisk atomære, pålitelige. For å sikre konsistensen i databasen på globaler er det nødvendig med programmererens innsats og bruk av transaksjoner, da det ikke er komplekse innebygde konstruksjoner som fremmednøkler.

Isolasjonsnivået for globaler uten bruk av låser er READ UNCOMMITED, og ved bruk av låser kan det sikres opp til SERIALIZE-nivået.

Korrekthet og hastighet på transaksjoner i globaler avhenger sterkt av programmererens dyktighet: jo mer omfattende shared-låser brukes under lesing, desto høyere er isolasjonsnivået, og jo smalere eksklusive låser brukes, desto bedre ytelse.

Kilde: habr.com