{"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\/da\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transaktioner i globale InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransaktionerDatabasen InterSystems IRIS underst\u00f8tter nysgerrige strukturer til datalagring \u2014 globale. I bund og grund er det flerniveausn\u00f8gler med forskellige ekstra funktioner som transaktioner, hurtige funktioner til traversal af datatr\u00e6er, l\u00e5sninger og sit eget sprog ObjectScript.<\/p>\n

L\u00e6s mere om globale i r\u00e6kken af artikler \"Globale \u2014 sv\u00e6rd-skattekister til datalagring\":<\/p>\n

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

Jeg blev nysgerrig p\u00e5, 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.
\n<\/a><\/noindex>
\nSom det er kendt fra teorien om relationelle databaser, skal en god implementering af transaktioner opfylde kravene ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomaritet.<\/b> Alle \u00e6ndringer foretaget i transaktionen skal enten registreres eller ingenting.<\/p>\n

C \u2014 Konsistens.<\/b> Efter at transaktionen er afsluttet, skal den logiske tilstand af databasen v\u00e6re internt konsistent. I h\u00f8j grad vedr\u00f8rer dette programm\u00f8ren, men i tilf\u00e6lde af SQL-databaser g\u00e6lder det ogs\u00e5 for fremmede n\u00f8gler.<\/p>\n

I \u2014 Isolation.<\/b> Parallelt udf\u00f8rte transaktioner m\u00e5 ikke p\u00e5virke hinanden.<\/p>\n

D \u2014 Holdbarhed.<\/b> Efter en succesfuld afslutning af transaktionen m\u00e5 problemer p\u00e5 de lavere niveauer (som str\u00f8msvigt) ikke p\u00e5virke de data, der er \u00e6ndret af transaktionen.<\/p>\n

Globale er ikke-relationelle datastrukturer. De blev skabt til ekstremt hurtig drift p\u00e5 meget begr\u00e6nset hardware. Lad os unders\u00f8ge implementeringen af transaktioner i globale ved hj\u00e6lp af den officielle IRIS Docker-image<\/a><\/noindex>.<\/p>\n

For at underst\u00f8tte transaktioner i IRIS anvendes kommandoerne: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomaritet<\/h2>\n

\nDet er lettest at teste atomaritet. Lad os tjekke fra databasekonsollen.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nDerefter laver vi udskriften:<\/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 er i orden. Atomariteten er overholdt: alle \u00e6ndringer blev registreret.<\/p>\n
Lad os komplicere opgaven, introducere en fejl og se, hvordan transaktionen bevares, delvist eller slet ikke.<\/p>\n
Lad os kontrollere atomariteten igen:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nHerefter stopper vi containeren tvungent, genstarter den og ser. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nDenne kommando er praktisk talt \u00e6kvivalent med at tvinge str\u00f8mmen fra, da den sender et signal om \u00f8jeblikkelig stop af processen SIGKILL.<\/p>\n
Kan det v\u00e6re, at transaktionen er blevet gemt delvist?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nej, den blev ikke gemt.<\/p>\n
Lad os pr\u00f8ve rollback-kommandoen:<\/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
\nDer blev heller ikke gemt noget.<\/p>\n
2. Konsistens<\/h2>\n
\nDa n\u00f8gler i globale databaser ogs\u00e5 er lavet p\u00e5 globale niveauer (jeg minder om, at en global er en lavere niveau struktur til lagring af data end en relations tabel), skal \u00e6ndringen af n\u00f8glen inkluderes i den samme transaktion som \u00e6ndringen af den globale for at opfylde konsistenskravene.<\/p>\n
For eksempel har vi en global ^person, hvor vi opbevarer personoplysninger, og vi bruger CVR nummeret som n\u00f8gle.<\/p>\n
^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n...<\/code><\/pre>\n
\nFor at have hurtig s\u00f8gning p\u00e5 efternavn og fornavn har vi lavet n\u00f8glen ^index.<\/p>\n
^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1<\/code><\/pre>\n
\nFor at databasen skal v\u00e6re konsistent, skal vi tilf\u00f8je personligheden s\u00e5dan:<\/p>\n
TSTART\n^person(1234567, \u2018firstname\u2019) = \u2018Sergey\u2019\n^person(1234567, \u2018lastname\u2019) = \u2018Kamenev\u2019\n^person(1234567, \u2018phone\u2019) = \u2018+74995555555\n^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nTilsvarende skal vi ogs\u00e5 bruge en transaktion ved sletning:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567)\nTCOMMIT<\/code><\/pre>\n
\nMed andre ord ligger opfyldelsen af konsistenskravene helt p\u00e5 programm\u00f8rens skuldre. Men n\u00e5r det drejer sig om globale, er det normalt i kraft af deres lavniveau karakt\u00e6r.<\/p>\n
3. Isolering<\/h2>\n
\nHer begynder kompleksiteten. Mange brugere arbejder samtidig med den samme database og \u00e6ndrer de samme data.<\/p>\n
Situationen kan sammenlignes med, n\u00e5r mange brugere samtidig arbejder med det samme kode-repository og fors\u00f8ger at commite \u00e6ndringer til mange filer samtidigt.<\/p>\n
Databasen skal h\u00e5ndtere alt dette i realtid. I betragtning af at st\u00f8rre virksomheder endda har en person der er ansvarlig for versionskontrol (for sammenl\u00e6gning af branches, l\u00f8sning af konflikter osv.), og at databasen skal g\u00f8re alt dette i realtid, bliver opgavens kompleksitet og vigtigheden af korrekt design af databasen og den kode, der underst\u00f8tter den, \u00e5benlys.<\/p>\n
Databasen kan ikke forst\u00e5 meningen med de handlinger, som brugerne udf\u00f8rer, for at undg\u00e5 konflikter, hvis de arbejder med de samme data. Den kan kun tilbagekalde \u00e9n transaktion, der modsiger en anden, eller udf\u00f8re dem i r\u00e6kkef\u00f8lge.<\/p>\n
Et andet problem er, at under udf\u00f8relsen af en transaktion (f\u00f8r commit), kan database\u72b6\u6001 v\u00e6re inkonsistent, s\u00e5 det er \u00f8nskeligt, at andre transaktioner ikke har adgang til denne inkonsistente tilstand, hvilket opn\u00e5s i relationelle databaser p\u00e5 mange m\u00e5der: gennem snapshot-dannelse, flere versioner af r\u00e6kker osv.<\/p>\n
N\u00e5r transaktioner udf\u00f8res parallelt, er det vigtigt, at de ikke forstyrrer hinanden. Det er essensen af isolationsprincippet.<\/p>\n
SQL definerer 4 niveauer af isolering:<\/p>\n