{"id":36650,"date":"2019-10-31T22:12:54","date_gmt":"2019-10-31T19:12:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-v-globalah-intersystems-iris\/"},"modified":"2019-10-31T22:12:54","modified_gmt":"2019-10-31T19:12:54","slug":"tranzaktsii-v-globalah-intersystems-iris","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transaksjonar i globalar InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransaksjonarDBMS InterSystems IRIS st\u00f8ttar interessante strukturar for datalagring \u2014 globalar. I utgangspunktet er dette flerniv\u00e5-n\u00f8kklar med ulike ekstra funksjonar som transaksjonar, raske funksjonar for \u00e5 navigere i datatr\u00e6r, l\u00e5sing, og sitt eige spr\u00e5k, ObjectScript.<\/p>\n

Les meir om globalar i artikkelen \u00abGlobalar \u2014 sverd og skjold for datalagring\u00bb:<\/p>\n

Tr\u00e6r. Del 1<\/a><\/noindex>
\nTr\u00e6r. Del 2<\/a><\/noindex>
\nSparsomme matriser. Del 3<\/a><\/noindex><\/p>\n

Eg vart nysgjerrig p\u00e5 korleis transaksjonar er implementert i globalar, og kva som gjer desse strukturane unike. Det er ein heilt annan m\u00e5te \u00e5 lagre data p\u00e5 enn dei vante tabellane. Mye meir l\u00e5g-niv\u00e5.
\n<\/a><\/noindex>
\nSom kjent fr\u00e5 teorien om relasjonsdatabasar, b\u00f8r ein god implementering av transaksjonar oppfylle krava ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomic (atomaritet).<\/b> Alle endringar som er gjort i transaksjonen skal registrerast, eller inga endring skal gjerast.<\/p>\n

C \u2014 Consistency (konsistens).<\/b> Etter at transaksjonen er fullf\u00f8rt, m\u00e5 den logiske tilstanden til databasen vere internt konsistent. Dette kravet ang\u00e5r i stor grad programmaren, men i tilfelle av SQL-databasar, er det ogs\u00e5 knytt til utanlandske n\u00f8klar.<\/p>\n

I \u2014 Isolate (isolasjon).<\/b> Parallelt utf\u00f8rte transaksjonar skal ikkje p\u00e5verke kvarandre.<\/p>\n

D \u2014 Durable (varigheit).<\/b> Etter vellykka avslutning av transaksjonen, skal problem p\u00e5 lavare niv\u00e5 (for eksempel str\u00f8msvikt) ikkje p\u00e5verke data som er endra av transaksjonen.<\/p>\n

Globalar er ikkje-relasjonelle datastrukturar. Dei vart utvikla for ekstrem rask drifting p\u00e5 sv\u00e6rt avgrensa maskinvare. La oss sj\u00e5 n\u00e6rare p\u00e5 implementasjonen av transaksjonar i globalar ved hjelp av den offisielle docker-bilete av IRIS<\/a><\/noindex>.<\/p>\n

For \u00e5 st\u00f8tte transaksjonar i IRIS, blir f\u00f8lgjande kommandoar brukte: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomaritet<\/h2>\n

\nDet er lettast \u00e5 sjekke atomaritet. Vi sjekkar fr\u00e5 databasen sin konsoll.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nS\u00e5 f\u00e5r vi ut:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nVi f\u00e5r:<\/p>\n
1 2 3<\/code><\/pre>\n
\nAlt i orden. Atomaritet er oppretthaldt: alle endringar er registrert.<\/p>\n
La oss gjere oppg\u00e5va meir komplisert, vi introduserer ein feil og sjekkar korleis transaksjonen blir bevart, delvis eller ikkje i det heile.<\/p>\n
La oss sjekke atomariteten igjen:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nDeretter tvingar vi til \u00e5 stoppe containeren, startar opp igjen og ser kva som skjer. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nDenne kommandoen er praktisk talt lik en tvungen str\u00f8mavstengning, da den sender et umiddelbart stoppesignal til prosessen SIGKILL.<\/p>\n
Kan det ha v\u00e6rt at transaksjonen ble delvis lagret?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nei, den ble ikke lagret.<\/p>\n
La oss pr\u00f8ve tilbakef\u00f8ringskommandoen:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTROLLBACK\n\nWRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\nDet ble heller ikke lagret noe.<\/p>\n
2. Konsistens<\/h2>\n
\nSiden i globale databaser blir n\u00f8klene ogs\u00e5 laget p\u00e5 globale niv\u00e5er (la meg minne om at global er en lavere niv\u00e5struktur for datalagring enn en relasjonell tabell), for \u00e5 oppfylle kravene til konsistens m\u00e5 endringen av n\u00f8kkelen inkluderes i den samme transaksjonen som endringen av globalen.<\/p>\n
For eksempel har vi en global ^person, der vi lagrer personlige data og bruker identitetsnummeret som n\u00f8kkel.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nFor \u00e5 ha rask s\u00f8king etter etternavn og fornavn laget vi n\u00f8kkelen ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nFor at databasen skal v\u00e6re konsistent, m\u00e5 vi legge til personen slik:<\/p>\n
TSTART\n^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n^index('Kamenev', 'Sergey', 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nDermed m\u00e5 vi ogs\u00e5 bruke en transaksjon ved sletting:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nMed andre ord ligger oppfyllelsen av konsistenskravene helt p\u00e5 utviklerens skuldre. Men n\u00e5r det gjelder globale, er dette normalt, p\u00e5 grunn av deres lavniv\u00e5natur.<\/p>\n
3. Isolasjon<\/h2>\n
\nHer begynner det \u00e5 bli komplisert. Mange brukere arbeider samtidig med den samme databasen, endrer de samme dataene.<\/p>\n
Situasjonen kan sammenlignes med at mange brukere samtidig jobber med det samme kode-repositoriet og pr\u00f8ver \u00e5 commite endringer i mange filer p\u00e5 en gang.<\/p>\n
Databasen m\u00e5 h\u00e5ndtere alt dette i sanntid. Gitt at i seri\u00f8se selskaper finnes det til og med en spesialperson som er ansvarlig for versjonskontroll (for \u00e5 sl\u00e5 sammen grener, l\u00f8se konflikter, osv.), og at databasen m\u00e5 gj\u00f8re alt dette i sanntid, blir oppgavens kompleksitet og korrektheten i databasedesign og koden som vedlikeholder den \u00e5penbar.<\/p>\n
Databasen kan ikke forst\u00e5 meningen med de handlingene som brukerne utf\u00f8rer for \u00e5 forhindre konflikter n\u00e5r de jobber med de samme dataene. Den kan bare tilbakekalle en transaksjon som strider mot en annen eller utf\u00f8re dem sekvensielt.<\/p>\n
Et annet problem er at under utf\u00f8relsen av en transaksjon (f\u00f8r kommittering) kan databasen v\u00e6re i en inkonsekvent tilstand, derfor er det \u00f8nskelig at andre transaksjoner ikke har tilgang til den inkonsekvente tilstanden til databasen, noe som oppn\u00e5s i relasjonsdatabaser p\u00e5 mange m\u00e5ter: ved \u00e5 lage \u00f8yeblikksbilder, ved fleredelelinje og s\u00e5 videre.<\/p>\n
N\u00e5r transaksjoner kj\u00f8res parallelt, er det viktig at de ikke forstyrrer hverandre. Dette er egenskapen av isolasjon.<\/p>\n
SQL definerer 4 niv\u00e5er av isolasjon:<\/p>\n