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

\"TransaktionerDatabashanteraren InterSystems IRIS st\u00f6djer intressanta strukturer f\u00f6r datalagring \u2013 globala variabler. I grunden \u00e4r detta flerniv\u00e5nycklar med olika ytterligare f\u00f6rdelar som transaktioner, snabba funktioner f\u00f6r att navigera i datatr\u00e4d, l\u00e5sningar och sitt eget spr\u00e5k ObjectScript.<\/p>\n

Mer om globala variabler i en serie artiklar \"Globala variabler \u2013 sv\u00e4rd och skatter f\u00f6r datalagring\":<\/p>\n

Tr\u00e4d. Del 1<\/a><\/noindex>
\nTr\u00e4d. Del 2<\/a><\/noindex>
\nSparsamma arrayer. Del 3<\/a><\/noindex><\/p>\n

Jag blev nyfiken p\u00e5 hur transaktioner \u00e4r implementerade i globala variabler, vilka s\u00e4rdrag de har. Det \u00e4r ju en helt annan struktur f\u00f6r datalagring \u00e4n de vanliga tabellerna. Mycket mer l\u00e5g niv\u00e5.
\n<\/a><\/noindex>
\nSom k\u00e4nt fr\u00e5n teorin om relationsdatabaser ska en bra implementation av transaktioner uppfylla kraven ACID<\/a><\/noindex>:<\/p>\n

A \u2013 Atomic (atom\u00e4r).<\/b> Alla f\u00f6r\u00e4ndringar som g\u00f6rs i en transaktion ska antingen sparas eller inte sparas alls.<\/p>\n

C \u2013 Consistency (konsekvens).<\/b> Efter avslutandet av en transaktion ska den logiska tillst\u00e5ndet i databasen vara internt konsekvent. Mycket av detta krav ber\u00f6r programmeraren, men i fallet med SQL-databaser handlar det \u00e4ven om fr\u00e4mmande nycklar.<\/p>\n

I \u2013 Isolate (isolering).<\/b> Parallellt k\u00f6rande transaktioner ska inte p\u00e5verka varandra.<\/p>\n

D \u2013 Durable (h\u00e5llbarhet).<\/b> Efter att transaktionen framg\u00e5ngsrikt avslutats ska problem p\u00e5 l\u00e4gre niv\u00e5er (som str\u00f6mavbrott, till exempel) inte p\u00e5verka de data som f\u00f6r\u00e4ndrats av transaktionen.<\/p>\n

Globala variabler \u00e4r icke-relationella datastrukturer. De skapades f\u00f6r super snabb drift p\u00e5 mycket begr\u00e4nsad h\u00e5rdvara. L\u00e5t oss titta p\u00e5 implementeringen av transaktioner i globala variabler med hj\u00e4lp av den officiella Docker-bilden f\u00f6r IRIS<\/a><\/noindex>.<\/p>\n

F\u00f6r att st\u00f6dja transaktioner i IRIS anv\u00e4nds kommandon: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atom\u00e4ritet<\/h2>\n

\nDet \u00e4r enklast att kontrollera atom\u00e4ritet. Vi testar fr\u00e5n databasens konsol.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nSedan g\u00f6r vi en utskrift:<\/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
\nAllt \u00e4r i sin ordning. Atom\u00e4ritet \u00e4r uppr\u00e4tth\u00e5llen: alla f\u00f6r\u00e4ndringar har sparats.<\/p>\n
L\u00e5t oss komplicera uppgiften, introducera ett fel och titta p\u00e5 hur transaktionen sparas, delvis eller inte alls.<\/p>\n
Vi kontrollerar atom\u00e4ritet \u00e4nnu en g\u00e5ng:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nD\u00e4refter tvingar vi container att stanna, startar den igen och ser efter. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nDet h\u00e4r kommandot \u00e4r praktiskt taget likv\u00e4rdigt med att tvinga avst\u00e4ngning av str\u00f6mmen, eftersom det skickar en SIGKILL-avbrottssignal.<\/p>\n
Kan transaktionen ha sparats delvis?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 Nej, den har inte sparats.<\/p>\n
L\u00e5t oss prova \u00e5terst\u00e4llningskommandot:<\/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
\nInte heller har n\u00e5got sparats.<\/p>\n
2. Konsistens<\/h2>\n
\nEftersom nycklar i globala databasstrukturer ocks\u00e5 g\u00f6rs p\u00e5 globala niv\u00e5er (kom ih\u00e5g att en global \u00e4r en mer l\u00e5g niv\u00e5 struktur f\u00f6r att lagra data \u00e4n en relationsdatabas), beh\u00f6ver en nyckelf\u00f6r\u00e4ndring ing\u00e5 i samma transaktion som f\u00f6r\u00e4ndringen av den globala, f\u00f6r att uppfylla kravet p\u00e5 konsistens.<\/p>\n
Till exempel har vi en global ^person d\u00e4r vi lagrar personuppgifter och anv\u00e4nder Skatteidentifikationsnummer som nyckel.<\/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
\nF\u00f6r att ha en snabb s\u00f6kning efter efternamn och f\u00f6rnamn har vi skapat nyckeln ^index.<\/p>\n
^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567) = 1<\/code><\/pre>\n
\nF\u00f6r att databasen ska vara konsekvent m\u00e5ste vi l\u00e4gga till personuppgifterna s\u00e5 h\u00e4r:<\/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
\nD\u00e4rf\u00f6r m\u00e5ste vi vid borttagning ocks\u00e5 anv\u00e4nda en transaktion:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index(\u2018Kamenev\u2019, \u2018Sergey\u2019, 1234567)\nTCOMMIT<\/code><\/pre>\n
\nMed andra ord ligger ansvaret f\u00f6r att uppfylla kravet p\u00e5 konsistens helt och h\u00e5llet p\u00e5 programmerarens axlar. Men n\u00e4r det g\u00e4ller globala strukturer \u2014 \u00e4r det normalt, p\u00e5 grund av deras l\u00e5gniv\u00e5natur.<\/p>\n
3. Isolering<\/h2>\n
\nH\u00e4r b\u00f6rjar komplexiteten. M\u00e5nga anv\u00e4ndare arbetar samtidigt med samma databas och \u00e4ndrar samma data.<\/p>\n
Situationen \u00e4r j\u00e4mf\u00f6rbar med att m\u00e5nga anv\u00e4ndare arbetar samtidigt med samma kodf\u00f6rvar och f\u00f6rs\u00f6ker commitera f\u00f6r\u00e4ndringar i m\u00e5nga filer samtidigt.<\/p>\n
Databasen m\u00e5ste hantera allt detta i realtid. Med tanke p\u00e5 att seri\u00f6sa f\u00f6retag till och med har en speciell person som ansvarar f\u00f6r versionkontroll (f\u00f6r sammanslagning av grenar, konfliktl\u00f6sning etc.), och att databaser m\u00e5ste g\u00f6ra allt detta i realtid, blir uppenbar komplexiteten i uppgiften och vikten av korrekt databasdesign samt koden som st\u00f6der den.<\/p>\n
En databas kan inte f\u00f6rst\u00e5 inneb\u00f6rden av de \u00e5tg\u00e4rder som anv\u00e4ndarna utf\u00f6r f\u00f6r att f\u00f6rhindra konflikter, om de arbetar med samma data. Den kan bara \u00e5terkalla en transaktion som strider mot en annan eller utf\u00f6ra dem i sekvens.<\/p>\n
Ytterligare ett problem \u00e4r att under tiden en transaktion utf\u00f6rs (fram till commit), kan databasens tillst\u00e5nd vara inkonsistent, s\u00e5 det \u00e4r \u00f6nskv\u00e4rt att andra transaktioner inte har tillg\u00e5ng till ett inkonsistent tillst\u00e5nd i databasen, vilket uppn\u00e5s i relationella databaser p\u00e5 m\u00e5nga s\u00e4tt: genom att skapa snapshots, genom multiversionering av rader osv.<\/p>\n
Vid parallell k\u00f6rning av transaktioner \u00e4r det viktigt att de inte st\u00f6r varandra. Detta \u00e4r egenskapen av isolation.<\/p>\n
SQL definierar 4 niv\u00e5er av isolation:<\/p>\n