Transaktioner i globala InterSystems IRIS

Databashanteraren InterSystems IRIS stödjer intressanta strukturer för datalagring – globala variabler. I grunden är detta flernivånycklar med olika ytterligare fördelar som transaktioner, snabba funktioner för att navigera i dataträd, låsningar och sitt eget språk ObjectScript.

Mer om globala variabler i en serie artiklar "Globala variabler – svärd och skatter för datalagring":

Träd. Del 1
Träd. Del 2
Sparsamma arrayer. Del 3

Jag blev nyfiken på hur transaktioner är implementerade i globala variabler, vilka särdrag de har. Det är ju en helt annan struktur för datalagring än de vanliga tabellerna. Mycket mer låg nivå.

Som känt från teorin om relationsdatabaser ska en bra implementation av transaktioner uppfylla kraven ACID:

A – Atomic (atomär). Alla förändringar som görs i en transaktion ska antingen sparas eller inte sparas alls.

C – Consistency (konsekvens). Efter avslutandet av en transaktion ska den logiska tillståndet i databasen vara internt konsekvent. Mycket av detta krav berör programmeraren, men i fallet med SQL-databaser handlar det även om främmande nycklar.

I – Isolate (isolering). Parallellt körande transaktioner ska inte påverka varandra.

D – Durable (hållbarhet). Efter att transaktionen framgångsrikt avslutats ska problem på lägre nivåer (som strömavbrott, till exempel) inte påverka de data som förändrats av transaktionen.

Globala variabler är icke-relationella datastrukturer. De skapades för super snabb drift på mycket begränsad hårdvara. Låt oss titta på implementeringen av transaktioner i globala variabler med hjälp av den officiella Docker-bilden för IRIS.

För att stödja transaktioner i IRIS används kommandon: TSTART, TCOMMIT, TROLLBACK.

1. Atomäritet

Det är enklast att kontrollera atomäritet. Vi testar från databasens konsol.

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

Sedan gör vi en utskrift:

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

Vi får:

1 2 3

Allt är i sin ordning. Atomäritet är upprätthållen: alla förändringar har sparats.

Låt oss komplicera uppgiften, introducera ett fel och titta på hur transaktionen sparas, delvis eller inte alls.

Vi kontrollerar atomäritet ännu en gång:

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

Därefter tvingar vi container att stanna, startar den igen och ser efter.

docker kill my-iris

Det här kommandot är praktiskt taget likvärdigt med att tvinga avstängning av strömmen, eftersom det skickar en SIGKILL-avbrottssignal.

Kan transaktionen ha sparats delvis?

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

— Nej, den har inte sparats.

Låt oss prova återställningskommandot:

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)

Inte heller har något sparats.

2. Konsistens

Eftersom nycklar i globala databasstrukturer också görs på globala nivåer (kom ihåg att en global är en mer låg nivå struktur för att lagra data än en relationsdatabas), behöver en nyckelförändring ingå i samma transaktion som förändringen av den globala, för att uppfylla kravet på konsistens.

Till exempel har vi en global ^person där vi lagrar personuppgifter och använder Skatteidentifikationsnummer som nyckel.

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

För att ha en snabb sökning efter efternamn och förnamn har vi skapat nyckeln ^index.

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

För att databasen ska vara konsekvent måste vi lägga till personuppgifterna så här:

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

Därför måste vi vid borttagning också använda en transaktion:

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

Med andra ord ligger ansvaret för att uppfylla kravet på konsistens helt och hållet på programmerarens axlar. Men när det gäller globala strukturer — är det normalt, på grund av deras lågnivånatur.

3. Isolering

Här börjar komplexiteten. Många användare arbetar samtidigt med samma databas och ändrar samma data.

Situationen är jämförbar med att många användare arbetar samtidigt med samma kodförvar och försöker commitera förändringar i många filer samtidigt.

Databasen måste hantera allt detta i realtid. Med tanke på att seriösa företag till och med har en speciell person som ansvarar för versionkontroll (för sammanslagning av grenar, konfliktlösning etc.), och att databaser måste göra allt detta i realtid, blir uppenbar komplexiteten i uppgiften och vikten av korrekt databasdesign samt koden som stöder den.

En databas kan inte förstå innebörden av de åtgärder som användarna utför för att förhindra konflikter, om de arbetar med samma data. Den kan bara återkalla en transaktion som strider mot en annan eller utföra dem i sekvens.

Ytterligare ett problem är att under tiden en transaktion utförs (fram till commit), kan databasens tillstånd vara inkonsistent, så det är önskvärt att andra transaktioner inte har tillgång till ett inkonsistent tillstånd i databasen, vilket uppnås i relationella databaser på många sätt: genom att skapa snapshots, genom multiversionering av rader osv.

Vid parallell körning av transaktioner är det viktigt att de inte stör varandra. Detta är egenskapen av isolation.

SQL definierar 4 nivåer av isolation:

• READ UNCOMMITTED
• READ COMMITTED
• REPEATABLE READ
• SERIALIZABLE

Låt oss överväga varje nivå för sig. Kostnaderna för implementering av varje nivå ökar nästan exponentiellt.

READ UNCOMMITTED — detta är den lägsta nivån av isolation, men samtidigt den snabbaste. Transaktioner kan läsa förändringar som har gjorts av varandra.

READ COMMITTED — detta är nästa nivå av isolation, som är en kompromiss. Transaktioner kan inte läsa förändringar som har gjorts av varandra fram till commit, men kan läsa alla förändringar som gjorts efter commit.

Om vi har en lång transaktion T1, under vilken commits har gjorts i transaktioner T2, T3 … Tn, som har arbetat med samma data som T1, då kommer vi varje gång vi frågar efter data i T1 att få ett annat resultat. Detta fenomen kallas icke-repetitiv läsning.

REPEATABLE READ — på denna isolationsnivå har vi inget fenomen av icke-repetitiv läsning, på grund av att för varje begäran om att läsa data skapas en snapshot av resultatdata och när de används igen i samma transaktion används data från snapshot. Men på denna isolationsnivå är det möjligt att läsa fantomdata. Det avser att läsa nya rader som har lagts till av parallella, fixerade transaktioner.

SERIALIZABLE — den högsta nivån av isolation. Den kännetecknas av att data som på något sätt används i transaktionen (läsa eller ändra) blir tillgängliga för andra transaktioner först efter att den första transaktionen har avslutats.

Låt oss börja med att förstå om det finns någon isolering av operationerna i transaktionen från huvudflödet. Vi öppnar 2 terminalfönster.

Kill ^t

Write ^t(1)
2

TSTART
Set ^t(1)=2

Det finns ingen isolering. En tråd ser vad den andra som öppnat transaktionen gör.

Låt oss se om transaktionerna i olika trådar ser vad som händer inuti dem.

Vi öppnar 2 terminalfönster och startar 2 transaktioner parallellt.

kill ^t
TSTART
Write ^t(1)
3

TSTART
Set ^t(1)=3

Parallella transaktioner ser varandras data. Så vi har fått den enklaste, men också den snabbaste nivån av isolation READ UNCOMMITTED.

Detta kunde i princip förväntas för globala variabler, där prestanda alltid har satts i första rummet.

Vad gör vi om vi behöver en högre nivå av isolering i operationer på globala variabler?

Här behöver vi reflektera över varför nivåer av isolering alls är nödvändiga och hur de fungerar.

Den högsta nivån av isolering SERIALIZE innebär att resultatet av parallellt körda transaktioner är ekvivalent med deras sekventiella utförande, vilket garanterar att det inte uppstår kollisioner.

Detta kan vi göra med hjälp av intelligenta lås i ObjectScript, som har många olika användningsområden: man kan göra vanliga, inkrementella eller flerlåsningskommandon med LOCK.

Lägre nivåer av isolering är kompromisser som syftar till att öka databasens prestanda.

Låt oss se hur vi kan uppnå olika nivåer av isolering med hjälp av lås.

Denna operator tillåter att ta inte bara exklusiva lås, som behövs för att ändra data, utan också så kallade delade lås, som kan tas av flera trådar parallellt när de behöver läsa data som inte får förändras av andra processer under läsningen.

Mer om tvåfasmetoden för låsning på ryska och engelska:

→ Tvåfaslåsning
→ Two-phase locking

Svårigheten ligger i att under transaktionen kan databasens tillstånd vara inkonsistent, men dessa inkonsistenta data är synliga för andra processer. Hur undviker vi detta?

Vi kommer att skapa sådana synfönster med lås där databasens tillstånd kommer att vara konsistent. Och alla åtkomster till sådana synfönster med konsistent tillstånd kommer att kontrolleras av lås.

Delade låsningar av samma data är återanvändbara - de kan tas av flera processer. Dessa låsningar förhindrar andra processer från att ändra data, dvs. de används för att skapa fönster för en överenskommen databasstatus.

Exklusiva låsningar används för att ändra data - en sådan låsning kan endast tas av en process. En exklusiv låsning kan tas av:

1. Vilken som helst process, om data är fria
2. Endast den process som har en shared-låsning på dessa data och som först begärde den exklusiva låsningen.

Ju mer begränsad synfältet är, desto längre måste andra processer vänta, men desto mer överensstämmande kan databasens tillstånd vara i det.

READ_COMMITED — kärnan i denna nivå är att vi bara ser de begångna data från andra strömmar. Om data i en annan transaktion ännu inte är begångna ser vi deras gamla version.

Detta gör att vi kan parallellisera arbetet istället för att vänta på att låsningen ska släppas.

Utan speciella knep kommer vi inte att kunna se den gamla versionen av data i IRIS, så vi måste klara oss med låsningar.

Därför måste vi med hjälp av shared-låsningar tillåta läsning av data endast vid punkter av överensstämmelse.

Anta att vi har en användardatabas ^person, där de överför pengar till varandra.

Överföringsögonblicket från person 123 till person 242:

LÅS +^person(123), +^person(242)
Ställ in ^person(123, amount) = ^person(123, amount) - amount
Ställ in ^person(242, amount) = ^person(242, amount) + amount
LÅS -^person(123), -^person(242)

Ögonblicket för att begära antalet pengar från person 123 innan debitering måste åtföljas av en exklusiv låsning (som standard):

LÅS +^person(123)
Skriv ^person(123)

Om vi behöver visa kontots status i personligt konto kan vi använda en shared-låsning eller helt skippa den:

LÅS +^person(123)#”S”
Skriv ^person(123)

Men om vi antar att operationer med databasen utförs nästan omedelbart (jag noterar att globala är en mycket mer låg nivåstruktur än en relationsdatabas), minskar behovet av denna nivå.

REPEATABLE READ — på denna isoleringsnivå tillåts att det kan finnas flera läsningar av data som kan ändras av parallella transaktioner.

Därför måste vi sätta en shared-låsning för att läsa data som vi ändrar och exklusiva låsningar för de data vi förändrar.

Med hjälp av LOCK-operatören kan man noggrant ange alla nödvändiga lås inom en enda operator, eftersom det kan vara väldigt många.

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

andra operationer (under tiden försöker parallella trådar att ändra ^person(123, amount), men kan inte)

LOCK +^person(123, amount)
ändra ^person(123, amount)
LOCK -^person(123, amount)

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

När man listar lås med kommatecken tas de i sekvens, men om man gör så här:

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

tilldelas de atomärt på en gång.

SERIALIZE — vi måste ställa in låsen så att slutligen alla transaktioner som har gemensamma data utförs sekventiellt. För denna metod måste de flesta lås vara exklusiva och tas på de minsta områdena i globalen för prestanda.

Om vi talar om uttag av medel i globalen ^person, så är endast SERIALIZE-isoleringsnivån acceptabel, eftersom pengar måste spenderas strikt sekventiellt, annars kan samma belopp spenderas flera gånger.

4. Långvarighet

Jag har genomfört tester med hård avstängning av containern genom

docker kill my-iris

Databasen hanterade det bra. Inga problem upptäcktes.

Slutsats

För globalerna i InterSystems IRIS finns stöd för transaktioner. De är verkligen atomära, pålitliga. För att säkerställa databasens konsekvens i globalerna krävs det insatser från programmerarens sida och användning av transaktioner, eftersom det inte finns några komplexa inbyggda strukturer som externa nycklar.

Isoleringsnivån för globalerna utan att använda lås är READ UNCOMMITTED, och med användning av lås kan den uppnås ända upp till SERIALIZE-nivån.

Korrekthet och hastighet för transaktioner på globalerna beror väldigt mycket på programmerarens skicklighet: ju mer som delas av shared-lås vid läsning, desto högre isoleringsnivå, och ju mer restriktivt exklusiva lås tas, desto bättre prestanda.

Källa: habr.com