Transaksjoner i InterSystems IRIS globals

InterSystems IRIS DBMS støtter interessante strukturer for lagring av data - globaler. I hovedsak er dette flernivånøkler med diverse tilleggsgodbiter i form av transaksjoner, raske funksjoner for å krysse datatrær, låser og eget ObjectScript-språk.

Les mer om globaler i artikkelserien «Globals er skattesverd for å lagre data»:

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

Jeg ble interessert i hvordan transaksjoner implementeres i globaler, hvilke funksjoner det er. Dette er tross alt en helt annen struktur for lagring av data enn de kjente tabellene. Mye lavere nivå.

Som kjent fra teorien om relasjonsdatabaser må en god gjennomføring av transaksjoner tilfredsstille kravene ACID:

A - Atomisk (atomisitet). Alle endringer som er gjort i transaksjonen eller ingen i det hele tatt blir registrert.

C - Konsistens. Etter at en transaksjon er fullført, må den logiske tilstanden til databasen være internt konsistent. På mange måter gjelder dette kravet programmereren, men når det gjelder SQL-databaser, gjelder det også fremmednøkler.

I - Isoler. Transaksjoner som går parallelt bør ikke påvirke hverandre.

D - Slitesterk. Etter vellykket gjennomføring av en transaksjon skal problemer på lavere nivåer (for eksempel strømbrudd) ikke påvirke dataene som endres av transaksjonen.

Globaler er ikke-relasjonelle datastrukturer. De ble designet for å kjøre superraskt på svært begrenset maskinvare. La oss se på implementering av transaksjoner i globalt bruk offisielt IRIS docker-bilde.

For å støtte transaksjoner i IRIS, brukes følgende kommandoer: TSTART, TCOMMIT, TROLLBACK.

1. Atomitet

Den enkleste måten å sjekke er atomitet. Vi sjekker fra databasekonsollen.

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

Så konkluderer vi:

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

Vi får:

1 2 3

Alt er bra. Atomiteten opprettholdes: alle endringer registreres.

La oss komplisere oppgaven, introdusere en feil og se hvordan transaksjonen lagres, delvis eller ikke i det hele tatt.

La oss sjekke atomiteten igjen:

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

Da vil vi tvangsstanse containeren, lansere den og se.

docker kill my-iris

Denne kommandoen tilsvarer nesten en kraftavstengning, da den sender et SIGKILL-signal for å stoppe prosessen umiddelbart.

Kanskje transaksjonen ble delvis lagret?

WRITE ^a(1), ^a(2), ^a(3)
^
<UNDEFINED> ^a(1)

– Nei, den har ikke overlevd.

La oss prøve tilbakerullingskommandoen:

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)

Ingenting har overlevd heller.

2. Konsistens

Siden i databaser basert på globaler lages nøkler også på globaler (la meg minne om at en global er en struktur på lavere nivå for lagring av data enn en relasjonstabell), for å oppfylle konsistenskravet, må en endring i nøkkelen inkluderes i samme transaksjon som en endring i den globale.

For eksempel har vi en global ^person, der vi lagrer personligheter og vi bruker TIN som nøkkel.

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

For å ha et raskt søk etter etternavn og fornavn, laget vi ^index-tasten.

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

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

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

Følgelig, når vi sletter, må vi også bruke en transaksjon:

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

Å oppfylle konsistenskravet hviler med andre ord helt på programmererens skuldre. Men når det gjelder globaler, er dette normalt, på grunn av deres lavnivå-natur.

3. Isolasjon

Det er her villmarken begynner. Mange brukere jobber samtidig på den samme databasen, og endrer de samme dataene.

Situasjonen kan sammenlignes med når mange brukere samtidig jobber med samme kodelager og prøver å foreta endringer i mange filer samtidig.

Databasen skal sortere det hele i sanntid. Tatt i betraktning at i seriøse selskaper er det til og med en spesiell person som er ansvarlig for versjonskontroll (for å slå sammen filialer, løse konflikter, etc.), og databasen må gjøre alt dette i sanntid, kompleksiteten til oppgaven og riktigheten av oppgaven. databasedesign og kode som tjener den.

Databasen kan ikke forstå betydningen av handlingene som utføres av brukere for å unngå konflikter hvis de jobber med samme data. Den kan bare angre en transaksjon som er i konflikt med en annen, eller utføre dem sekvensielt.

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

Når du utfører transaksjoner parallelt, er det viktig for oss at de ikke forstyrrer hverandre. Dette er egenskapen til isolasjon.

SQL definerer 4 isolasjonsnivåer:

• LES UENGASJERT
• LES ENGASJERT
• REPETERbar LES
• SERIALISERBAR

La oss se på hvert nivå separat. Kostnadene ved å implementere hvert nivå vokser nesten eksponentielt.

LES UENGASJERT – dette er det laveste isolasjonsnivået, men samtidig det raskeste. Transaksjoner kan lese endringer gjort av hverandre.

LES ENGASJERT er neste nivå av isolasjon, som er et kompromiss. Transaksjoner kan ikke lese hverandres endringer før commit, men de kan lese eventuelle endringer som er gjort etter commit.

Hvis vi har en lang transaksjon T1, hvor forpliktelser fant sted i transaksjonene T2, T3 ... Tn, som fungerte med de samme dataene som T1, vil vi når vi ber om data i T1 få et annet resultat hver gang. Dette fenomenet kalles ikke-repeterbar lesing.

REPETERbar LES — i dette isolasjonsnivået har vi ikke fenomenet ikke-repeterbar lesing, på grunn av det faktum at for hver forespørsel om å lese data, opprettes et øyeblikksbilde av resultatdataene, og når de gjenbrukes i samme transaksjon, dataene fra øyeblikksbildet benyttes. Det er imidlertid mulig å lese fantomdata på dette isolasjonsnivået. Dette refererer til å lese nye rader som ble lagt til av parallelle forpliktede transaksjoner.

SERIALISERBAR — høyeste isolasjonsnivå. Det er preget av det faktum at data som brukes på noen måte i en transaksjon (lesing eller endring) blir tilgjengelig for andre transaksjoner først etter fullføringen av den første transaksjonen.

Først, la oss finne ut om det er isolasjon av operasjoner i en transaksjon fra hovedtråden. La oss åpne 2 terminalvinduer.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Det er ingen isolasjon. En tråd ser hva den andre som åpnet transaksjonen gjør.

La oss se om transaksjoner av forskjellige tråder ser hva som skjer inne i dem.

La oss åpne 2 terminalvinduer og åpne 2 transaksjoner parallelt.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Parallelle transaksjoner ser hverandres data. Så vi fikk det enkleste, men også det raskeste isolasjonsnivået, LES UENGASJERT.

I prinsippet kan dette forventes for globale, der ytelse alltid har vært en prioritet.

Hva om vi trenger en høyere grad av isolasjon i operasjoner på globale?

Her må du tenke på hvorfor isolasjonsnivåer i det hele tatt trengs og hvordan de fungerer.

Det høyeste isolasjonsnivået, SERIALISERE, betyr at resultatet av transaksjoner utført parallelt tilsvarer deres sekvensielle utførelse, noe som garanterer fravær av kollisjoner.

Vi kan gjøre dette ved å bruke smarte låser i ObjectScript, som har mange forskjellige bruksområder: du kan gjøre vanlig, inkrementell, multippel låsing med kommandoen LOCK.

Lavere isolasjonsnivåer er avveininger designet for å øke databasehastigheten.

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

Denne operatøren lar deg ta ikke bare eksklusive låser som trengs for å endre data, men såkalte delte låser, som kan ta flere tråder parallelt når de skal lese data som ikke skal endres av andre prosesser under leseprosessen.

Mer informasjon om to-fase blokkeringsmetoden på russisk og engelsk:

→ To-fase blokkering
→ To-fase låsing

Vanskeligheten er at under en transaksjon kan tilstanden til databasen være inkonsekvent, men disse inkonsekvente dataene er synlige for andre prosesser. Hvordan unngå dette?

Ved å bruke låser vil vi lage synlighetsvinduer der tilstanden til databasen vil være konsistent. Og all tilgang til slike vinduer for synlighet av den avtalte staten vil bli kontrollert av låser.

Delte låser på de samme dataene kan gjenbrukes – flere prosesser kan ta dem. Disse låsene hindrer andre prosesser i å endre data, dvs. de brukes til å danne vinduer med konsistent databasetilstand.

Eksklusive låser brukes til dataendringer - kun én prosess kan ta en slik lås. En eksklusiv lås kan tas av:

1. Enhver prosess hvis dataene er gratis
2. Bare prosessen som har en delt lås på disse dataene og var den første som ba om en eksklusiv lås.

Jo smalere synlighetsvinduet er, jo lenger må andre prosesser vente på det, men jo mer konsistent kan tilstanden til databasen i den være.

READ_COMMITTED — essensen av dette nivået er at vi kun ser forpliktede data fra andre tråder. Hvis dataene i en annen transaksjon ennå ikke er forpliktet, ser vi den gamle versjonen.

Dette gjør at vi kan parallellisere arbeidet i stedet for å vente på at låsen 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 låser.

Følgelig må vi bruke delte låser for å tillate at data kun kan leses i øyeblikk med konsistens.

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

Overføringstidspunkt 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)

Øyeblikket for å be om beløpet fra person 123 før debitering må være ledsaget av en eksklusiv blokkering (som standard):

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

Og hvis du trenger å vise kontostatusen i din personlige konto, kan du bruke en delt lås eller ikke bruke den i det hele tatt:

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

Imidlertid, hvis vi antar at databaseoperasjoner utføres nesten umiddelbart (la meg minne deg på at globaler er en struktur på mye lavere nivå enn en relasjonstabell), så reduseres behovet for dette nivået.

REPETERbar LES - Dette isolasjonsnivået gir mulighet for flere avlesninger av data som kan endres ved samtidige transaksjoner.

Følgelig må vi sette en delt lås på lesing av dataene vi endrer og eksklusive låser på dataene vi endrer.

Heldigvis lar LOCK-operatøren deg i detalj liste opp alle nødvendige låser, som det kan være mye av, i en setning.

LOCK +^person(123, amount)#”S”
чтение ^person(123, amount)

andre operasjoner (på dette tidspunkt prøver parallelle tråder å endre ^person(123, beløp), men kan ikke)

LOCK +^person(123, amount)
изменение ^person(123, amount)
LOCK -^person(123, amount)

чтение ^person(123, amount)
LOCK -^person(123, amount)#”S”

Når du viser låser atskilt med komma, tas de sekvensielt, men hvis du gjør dette:

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

så blir de tatt atomært på en gang.

serial — vi må sette låser slik at til syvende og sist alle transaksjoner som har felles data blir utført sekvensielt. For denne tilnærmingen bør de fleste låser være eksklusive og brukes på de minste områdene i verden for ytelse.

Hvis vi snakker om å debitere midler i den globale ^personen, er det bare SERIALISE-isolasjonsnivået som er akseptabelt for det, siden penger må brukes strengt sekvensielt, ellers er det mulig å bruke samme beløp flere ganger.

4. Holdbarhet

Jeg gjennomførte tester med hardkutting av beholderen vha

docker kill my-iris

Basen tålte dem godt. Ingen problemer ble identifisert.

Konklusjon

For globale, har InterSystems IRIS transaksjonsstøtte. De er virkelig atomære og pålitelige. For å sikre konsistens i en database basert på globaler, kreves programmererinnsats og bruk av transaksjoner, siden den ikke har 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 SERIALISER-nivået.

Korrektheten og hastigheten til transaksjoner på globaler avhenger veldig av ferdighetene til programmereren: jo mer utbredt delte låser som brukes under lesing, jo høyere isolasjonsnivå, og jo mer snevert eksklusive låser tas, jo raskere blir ytelsen.

Kilde: www.habr.com