Transaktioner i globale InterSystems IRIS

Databasen InterSystems IRIS understøtter nysgerrige strukturer til datalagring — globale. I bund og grund er det flerniveausnøgler med forskellige ekstra funktioner som transaktioner, hurtige funktioner til traversal af datatræer, låsninger og sit eget sprog ObjectScript.

Læs mere om globale i rækken af artikler "Globale — sværd-skattekister til datalagring":

Træer. Del 1
Træer. Del 2
Sparsomme arrays. Del 3

Jeg blev nysgerrig på, hvordan transaktioner er implementeret i globale, og hvilke specielle egenskaber de har. For det er en helt anden struktur til datalagring end de velkendte tabeller. Meget mere lavniveau.

Som det er kendt fra teorien om relationelle databaser, skal en god implementering af transaktioner opfylde kravene ACID:

A — Atomaritet. Alle ændringer foretaget i transaktionen skal enten registreres eller ingenting.

C — Konsistens. Efter at transaktionen er afsluttet, skal den logiske tilstand af databasen være internt konsistent. I høj grad vedrører dette programmøren, men i tilfælde af SQL-databaser gælder det også for fremmede nøgler.

I — Isolation. Parallelt udførte transaktioner må ikke påvirke hinanden.

D — Holdbarhed. Efter en succesfuld afslutning af transaktionen må problemer på de lavere niveauer (som strømsvigt) ikke påvirke de data, der er ændret af transaktionen.

Globale er ikke-relationelle datastrukturer. De blev skabt til ekstremt hurtig drift på meget begrænset hardware. Lad os undersøge implementeringen af transaktioner i globale ved hjælp af den officielle IRIS Docker-image.

For at understøtte transaktioner i IRIS anvendes kommandoerne: TSTART, TCOMMIT, TROLLBACK.

1. Atomaritet

Det er lettest at teste atomaritet. Lad os tjekke fra databasekonsollen.

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

Derefter laver vi udskriften:

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

Vi får:

1 2 3

Alt er i orden. Atomariteten er overholdt: alle ændringer blev registreret.

Lad os komplicere opgaven, introducere en fejl og se, hvordan transaktionen bevares, delvist eller slet ikke.

Lad os kontrollere atomariteten igen:

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

Herefter stopper vi containeren tvungent, genstarter den og ser.

docker kill my-iris

Denne kommando er praktisk talt ækvivalent med at tvinge strømmen fra, da den sender et signal om øjeblikkelig stop af processen SIGKILL.

Kan det være, at transaktionen er blevet gemt delvist?

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

— Nej, den blev ikke gemt.

Lad os prøve rollback-kommandoen:

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)

Der blev heller ikke gemt noget.

2. Konsistens

Da nøgler i globale databaser også er lavet på globale niveauer (jeg minder om, at en global er en lavere niveau struktur til lagring af data end en relations tabel), skal ændringen af nøglen inkluderes i den samme transaktion som ændringen af den globale for at opfylde konsistenskravene.

For eksempel har vi en global ^person, hvor vi opbevarer personoplysninger, og vi bruger CVR nummeret som nøgle.

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

For at have hurtig søgning på efternavn og fornavn har vi lavet nøglen ^index.

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

For at databasen skal være konsistent, skal vi tilføje personligheden sådan:

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

Tilsvarende skal vi også bruge en transaktion ved sletning:

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

Med andre ord ligger opfyldelsen af konsistenskravene helt på programmørens skuldre. Men når det drejer sig om globale, er det normalt i kraft af deres lavniveau karaktær.

3. Isolering

Her begynder kompleksiteten. Mange brugere arbejder samtidig med den samme database og ændrer de samme data.

Situationen kan sammenlignes med, når mange brugere samtidig arbejder med det samme kode-repository og forsøger at commite ændringer til mange filer samtidigt.

Databasen skal håndtere alt dette i realtid. I betragtning af at større virksomheder endda har en person der er ansvarlig for versionskontrol (for sammenlægning af branches, løsning af konflikter osv.), og at databasen skal gøre alt dette i realtid, bliver opgavens kompleksitet og vigtigheden af korrekt design af databasen og den kode, der understøtter den, åbenlys.

Databasen kan ikke forstå meningen med de handlinger, som brugerne udfører, for at undgå konflikter, hvis de arbejder med de samme data. Den kan kun tilbagekalde én transaktion, der modsiger en anden, eller udføre dem i rækkefølge.

Et andet problem er, at under udførelsen af en transaktion (før commit), kan database状态 være inkonsistent, så det er ønskeligt, at andre transaktioner ikke har adgang til denne inkonsistente tilstand, hvilket opnås i relationelle databaser på mange måder: gennem snapshot-dannelse, flere versioner af rækker osv.

Når transaktioner udføres parallelt, er det vigtigt, at de ikke forstyrrer hinanden. Det er essensen af isolationsprincippet.

SQL definerer 4 niveauer af isolering:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Lad os se på hvert niveau enkeltvis. Omkostningerne ved implementeringen af hvert niveau stiger næsten eksponentielt.

READ UNCOMMITTED — det er det laveste isolationsniveau, men det er samtidig det hurtigste. Transaktioner kan læse ændringer foretaget af hinanden.

READ COMMITTED — det er det næste isolationsniveau, som er et kompromis. Transaktioner kan ikke læse ændringer foretaget af hinanden, før de er blevet committet, men kan læse alle ændringer foretaget efter commit.

Hvis vi har en lang transaktion T1, hvor der er blevet committet i transaktioner T2, T3 … Tn, som arbejdede med de samme data som T1, så vil vi hver gang få forskellige resultater, når vi anmoder om data i T1. Dette fænomen kaldes ikke-gentagelig læsning.

REPEATABLE READ — på dette isolationsniveau har vi ikke fænomenet med ikke-gentagelig læsning, fordi der for hver læseforespørgsel oprettes et snapshot af databesvarelsen, og ved gentagen brug i denne samme transaktion anvendes data fra snapshot. Dog er det muligt at læse phantomdata på dette isolationsniveau. Dette refererer til at læse nye rækker, der er tilføjet gennem parallelt bekræftede transaktioner.

SERIALIZABLE — det højeste isolationsniveau. Det er kendetegnet ved, at data, der på en eller anden måde anvendes i transaktionen (læses eller ændres), først bliver tilgængelige for andre transaktioner, efter den første transaktion er afsluttet.

Lad os først finde ud af, om der er isolation af operationer i transaktionen fra hovedtråden. Vi åbner 2 terminalvinduer.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Der er ingen isolation. En tråd kan se, hvad den anden, der har åbnet transaktionen, laver.

Lad os se, om transaktioner fra forskellige tråde ser, hvad der sker inden i dem.

Vi åbner 2 terminalvinduer og åbner 2 transaktioner parallelt.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Parallele transaktioner ser data om hinanden. Så vi har fået det enkleste, men hurtigste niveau af isolation, kaldet READ UNCOMMITTED.

Det var i princippet at forvente for globale variabler, hvor ydeevne altid er i fokus.

Hvad skal vi så gøre, hvis vi har brug for et højere niveau af isolation i operationer på globale variabler?

Her skal vi overveje, hvorfor vi overhovedet har brug for isolationsniveauer, og hvordan de fungerer.

Det højeste isolationsniveau SERIALIZE betyder, at resultatet af parallelt udførte transaktioner svarer til deres sekventielle udførelse, hvilket garanterer, at der ikke er nogle kollisioner.

Dette kan vi gøre ved hjælp af intelligente låse i ObjectScript, som har mange forskellige anvendelsesmetoder: vi kan lave almindelig, inkrementel, multipel låsning med kommandoen LOCK.

Lavere isolationsniveauer er kompromiser, der sigter mod at øge databasehastigheden.

Lad os se, hvordan vi kan opnå forskellige isolationsniveauer ved hjælp af låse.

Denne operator tillader ikke kun eksklusive låse, som er nødvendige for at ændre data, men også såkaldte delte, som kan tages af flere tråde parallelt, når de har brug for at læse data, der ikke bør ændres af andre processer under læseprocessen.

Mere om to-fase låsemetoden på russisk og engelsk:

→ To-fase låsning
→ Two-phase locking

Problemet er, at databasen kan være i en inkonsistent tilstand under transaktionen, men disse inkonsistente data er synlige for andre processer. Hvordan undgår vi det?

Vi vil lave synlighedsvinduer ved hjælp af låse, hvor databasens tilstand vil være konsistent. Og alle henvendelser til sådanne synlighedsvinduer med en konsistent tilstand vil blive kontrolleret af låse.

Shared-låse for de samme data er genanvendelige — flere processer kan tage dem. Disse låse forhindrer andre processer i at ændre data, dvs. de bruges til at danne vinduer af konsistent tilstand i databasen.

Eksklusive låse bruges til at ændre data — en sådan lås kan kun tages af én proces. En eksklusiv lås kan tages af:

1. Enhver proces, hvis data er frie
2. Kun den proces, der har en shared-lås på disse data og først anmodede om en eksklusiv lås.

Jo smallere synsvinduet er, desto længere tid skal andre processer vente, men desto mere konsistent kan tilstanden i databasen være i det.

READ_COMMITTED — essensen af dette niveau er, at vi kun ser bekræftede data fra andre strømme. Hvis data i en anden transaktion endnu ikke er bekræftet, ser vi deres gamle version.

Dette giver os mulighed for at parallelisere arbejdet i stedet for at vente på, at låsen bliver frigivet.

Uden specielle kneb vil vi ikke kunne se den gamle version af dataene i IRIS, så vi må nøjes med låse.

Dermed skal vi ved hjælp af shared-låse tillade læsning af data kun på tidspunkter med konsistens.

Antag, at vi har en brugerdatabase ^person, der overfører penge til hinanden.

Overførselsøjeblikket 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)

Overførselsmomentet, hvor man anmoder om antallet af penge hos person 123 før debitering, skal ledsages af en eksklusiv lås (som standard):

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

Og hvis man skal vise saldoen i kontrolpanelet, kan man bruge en shared-lås eller slet ikke bruge en:

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

Men hvis man antager, at operationerne med databasen udføres næsten øjeblikkeligt (jeg minder om, at globale er en meget lavere strukturelt niveau end en relationel tabel), så falder behovet for dette niveau.

REPEATABLE READ — på dette isolationsniveau tillades det, at der kan være flere læsninger af data, der kan ændres af parallelle transaktioner.

Dermed skal vi sætte shared-låse på de data, vi ændrer, og eksklusive låse på de data, vi ændrer.

LOCK-operatoren gør det muligt at angive alle nødvendige blokeringer detaljeret i én operator, hvilket kan blive ret omfattende.

LOCK +^person(123, amount)#”S”
læsning ^person(123, amount)

andre operationer (i denne periode forsøger parallelle tråde at ændre ^person(123, amount), men kan ikke)

LOCK +^person(123, amount)
ændring ^person(123, amount)
LOCK -^person(123, amount)

læsning ^person(123, amount)
LOCK -^person(123, amount)#”S”

Når blokeringerne angives med komma, tages de sekventielt, og hvis det gøres sådan:

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

tages de atomært alle på én gang.

SERIALIZE — vi skal sikre, at blokeringerne sættes, så i sidste ende udføres alle transaktioner, der har fælles data sekventielt. Til denne tilgang skal de fleste blokeringer være eksklusive og tages på de mindste områder af globalen for ydeevne.

Hvis vi taler om udtræk af midler i globalen ^person, er kun isolationniveauet SERIALIZE acceptabelt, da penge skal bruges strengt sekventielt, ellers er det muligt at bruge det samme beløb flere gange.

4. Varighed

Jeg har udført tests med hård nedlukning af containeren ved hjælp af

docker kill my-iris

Databasen klarede det godt. Der blev ikke identificeret problemer.

Konklusion

For globaler i InterSystems IRIS er der støtte til transaktioner. De er virkelig atomare, pålidelige. For at sikre databasens konsistens på globaler kræves det, at programmøren gør en indsats og bruger transaktioner, da der ikke er komplekse indbyggede konstruktioner som fremmede nøgler.

Isolationniveauet for globaler uden brug af blokeringer er READ UNCOMMITED, og ved brug af blokeringer kan det opretholdes helt op til niveauet SERIALIZE.

Korrektheden og hastigheden af transaktioner på globaler afhænger i høj grad af programmørens dygtighed: jo mere bredt der anvendes shared-blokeringer ved læsning, jo højere er isolationniveauet, og jo strammere eksklusive blokeringer tages, jo bedre bliver ydeevnen.

Kilde: habr.com