Transaktioner
En transaktion är en sekvens av operationer på data som har en början och ett slut.
En transaktion är sekventiell exekvering av läs- och skrivoperationer. Slutet på en transaktion kan vara att antingen spara ändringarna (commit) eller avbryta ändringarna (återställning). I förhållande till en databas består en transaktion av flera förfrågningar som behandlas som en enda begäran.
Transaktioner måste uppfylla ACID-egenskaper
Atomicitet. Transaktionen är antingen genomförd helt eller inte alls.
Konsistens. När en transaktion genomförs får de begränsningar som ålagts uppgifterna (till exempel begränsningar i databasen) inte överträdas. Konsistens innebär att systemet kommer att överföras från ett korrekt tillstånd till ett annat korrekt tillstånd.
Isolering. Transaktioner som löper parallellt bör inte påverka varandra, till exempel ändra data som används av en annan transaktion. Resultatet av att utföra parallella transaktioner bör vara detsamma som om transaktionerna utfördes sekventiellt.
Hållbarhet. När de har begåtts bör ändringar inte gå förlorade.
Transaktionsloggen
Loggen lagrar ändringar gjorda av transaktioner, säkerställer atomicitet och stabilitet för data i händelse av ett systemfel
Loggen innehåller de värden som data hade före och efter att den ändrades av transaktionen. Write-ahead-loggstrategi kräver att du lägger till en loggpost om tidigare värden före start och om slutvärden efter att transaktionen är slutförd. Vid ett plötsligt stopp av systemet läser databasen loggen i omvänd ordning och avbryter de ändringar som gjorts av transaktioner. Efter att ha stött på en avbruten transaktion, kör databasen den och gör ändringar i den i loggen. Eftersom databasen är i tillståndet vid tidpunkten för felet läser databasen inloggningen i vidarebefordran och returnerar ändringarna som gjorts av transaktioner. På så sätt bevaras stabiliteten för transaktioner som redan har begåtts och atomiciteten för den avbrutna transaktionen.
Det räcker inte att helt enkelt återutföra misslyckade transaktioner för återställning.
Exempel. Användaren har $500 på sitt konto och användaren bestämmer sig för att ta ut det från en bankomat. Två transaktioner pågår. Den första läser saldovärdet och om det finns tillräckligt med pengar på saldot ger den ut pengar till användaren. Den andra subtraherar det nödvändiga beloppet från saldot. Låt oss säga att systemet kraschade och den första operationen misslyckades, men den andra gjorde det. I det här fallet kan vi inte återutställa pengar till användaren utan att återställa systemet till sitt ursprungliga tillstånd med ett positivt saldo.
Isoleringsnivåer
Läs Engagerad
Dirty Read-problemet är att en transaktion kan läsa mellanresultatet av en annan transaktion.
Exempel. Det initiala saldovärdet är $0. T1 lägger till $50 till ditt saldo. T2 läser saldovärdet ($50). T1 ignorerar ändringarna och avslutar. T2 fortsätter exekveringen med felaktig balansdata.
Lösningen är att läsa fast data (Read Committed), vilket förbjuder att läsa data som ändrats av transaktionen. Om transaktion A har ändrat en viss uppsättning data, tvingas transaktion B, när den kommer åt dessa data, vänta på att transaktion A ska slutföras.
Repeterbar läsning
Problem med förlorade uppdateringar. T1 sparar ändringar utöver T2:s ändringar.
Exempel. Det initiala saldovärdet är $0 och två transaktioner fyller på saldot samtidigt. T1 och T2 läser ett saldo på $0. T2 lägger sedan till $200 till $0 och sparar resultatet. T1 lägger till $100 till $0 och sparar resultatet. Slutresultatet är $100 istället för $300.
Orepeterbart läsproblem. Att läsa samma data upprepade gånger returnerar olika värden.
Exempel. T1 visar ett saldovärde på $0. T2 lägger sedan till $50 till saldot och avslutar. T1 läser data igen och hittar en diskrepans med det tidigare resultatet.
Repeterbar läsning säkerställer att en andra läsning ger samma resultat. Data som läses av en transaktion kan inte ändras i andra förrän transaktionen är slutförd. Om transaktion A har läst en viss uppsättning data, tvingas transaktion B, när den kommer åt dessa data, vänta på att transaktion A ska slutföras.
Beställd läsning (Serialiserbar)
Phantom Reads problem. Två frågor som väljer data baserat på ett visst villkor returnerar olika värden.
Exempel. T1 begär antalet användare vars saldo är större än $0 men mindre än $100. T2 drar $1 från en användare med ett saldo på $101. T1 skickar begäran på nytt.
Beställd läsning (Serialiserbar). Transaktioner utförs helt sekventiellt. Det är förbjudet att uppdatera eller lägga till poster som faller inom villkoren för begäran. Om transaktion A har begärt data från hela tabellen, fryses hela tabellen för andra transaktioner tills transaktion A slutförs.
Schemaläggare
Ställer in i vilken ordning operationer ska utföras under parallella transaktioner.
Ger en specificerad nivå av isolering. Om resultatet av operationer inte beror på deras ordning, är sådana operationer kommutativa (Permuterbara). Läsoperationer och operationer på olika data är kommutativa. Läs-skriv- och skriv-skriv-operationer är inte kommutativa. Schemaläggarens uppgift är att interfoliera operationer som utförs av parallella transaktioner så att exekveringsresultatet är ekvivalent med sekventiell exekvering av transaktioner.
Mekanismer för att kontrollera parallella jobb (Concurrency Control)
Optimistisk bygger på att upptäcka och lösa konflikter, pessimistisk bygger på att förhindra att konflikter uppstår.
I det optimistiska tillvägagångssättet har flera användare kopior av data till sitt förfogande. Den första personen som slutför redigeringen sparar ändringarna, medan de andra måste slå samman ändringarna. En optimistisk algoritm tillåter konflikt att uppstå, men systemet måste återhämta sig från konflikten.
Med ett pessimistiskt tillvägagångssätt förhindrar den första användaren att fånga data andra från att ta emot data. Om konflikter är sällsynta är det klokt att välja den optimistiska strategin, eftersom den ger en högre grad av samtidighet.
Låsning
Om en transaktion har låst data måste andra transaktioner vänta tills den låses upp när de kommer åt data.
Ett block kan läggas över en databas, tabell, rad eller attribut. Delat lås kan påtvingas samma data genom flera transaktioner, låter alla transaktioner (inklusive den som införde det) läsas, förbjuder modifiering och exklusiv fångst. Exklusivt lås kan införas av endast en transaktion, tillåter alla åtgärder av den imponerande transaktionen, förbjuder alla åtgärder av andra.
Ett dödläge är en situation där transaktioner hamnar i ett väntande tillstånd som varar på obestämd tid.
Exempel. Den första transaktionen väntar på att data som fångats av den andra ska släppas, medan den andra väntar på att data som fångats av den första ska släppas.
En optimistisk lösning på dödlägesproblemet tillåter dödläget att inträffa, men återställer sedan systemet genom att rulla tillbaka en av transaktionerna som är involverade i dödläget.
dödlägen söks efter med vissa intervall. En av detekteringsmetoderna är genom tid, det vill säga att anse att ett dödläge har inträffat om transaktionen tar för lång tid att slutföra. När ett dödläge hittas, rullas en av transaktionerna tillbaka, vilket gör att andra transaktioner som är involverade i dödläget kan slutföras. Valet av offer kan baseras på värdet av transaktioner eller deras anciennitet (Wait-Die och Wound-wait system).
Varje transaktion T en tidsstämpel tilldelas TS som innehåller starttiden för transaktionen.
Vänta-dö.
Om TS(Ti) < TS(Tj), Sedan Ti väntar annars Ti rullar tillbaka och börjar igen med samma tidsstämpel.
Om en ung transaktion har skaffat en resurs och en äldre transaktion begär samma resurs, får den äldre transaktionen vänta. Om en äldre transaktion har förvärvat en resurs kommer den yngre transaktionen som begär den resursen att återställas.
Sår-vänta.
Om TS(Ti) < TS(Tj), Sedan Tj rullar tillbaka och börjar igen med samma tidsstämpel, annars Ti väntar.
Om en yngre transaktion har förvärvat en resurs och en äldre transaktion begär samma resurs, kommer den yngre transaktionen att återställas. Om en äldre transaktion har förvärvat en resurs får den yngre transaktionen som begär den resursen vänta. Preferensbaserat offerurval förhindrar dödlägen, men rullar tillbaka transaktioner som inte är låsta. Problemet är att transaktioner kan rullas tillbaka många gånger eftersom... en äldre transaktion kan hålla resursen under lång tid.
En pessimistisk lösning på dödlägesproblemet tillåter inte att en transaktion börjar utföras om det finns risk för ett dödläge.
För att upptäcka ett dödläge konstrueras en graf (väntande graf, vänta-på-graf), vars hörn är transaktioner, och kanterna riktas från transaktioner som väntar på att data ska släppas till transaktionen som har fångat dessa data. Ett dödläge anses ha inträffat om grafen har en slinga. Att konstruera en väntegraf, särskilt i distribuerade databaser, är en dyr procedur.
Tvåfaslåsning - förhindrar dödlägen genom att lägga beslag på alla resurser som används av en transaktion i början av transaktionen och släppa dem i slutet
Alla blockeringsoperationer måste föregå den första upplåsningen. Den har två faser - Växande fas, under vilken greppen ackumuleras, och krympningsfas, under vilken greppen släpps. Om det är omöjligt att fånga en av resurserna börjar transaktionen om. Det är möjligt att en transaktion inte kommer att kunna skaffa de nödvändiga resurserna, till exempel om flera transaktioner konkurrerar om samma resurser.
En tvåfasig commit säkerställer att commit exekveras på alla databasrepliker
Varje databas matar in information om de data som kommer att ändras i loggen och svarar till koordinatorn OK (Röstningsfas). Efter att alla har svarat OK skickar samordnaren en signal som tvingar alla att engagera sig. Efter commit svarar servrarna OK; om åtminstone en inte svarar OK skickar koordinatorn en signal om att avbryta ändringarna till alla servrar (Completion Phase).
Tidsstämpel metod
En äldre transaktion rullas tillbaka när man försöker komma åt data som är involverad i en yngre transaktion
Varje transaktion tilldelas en tidsstämpel TS motsvarande starttiden för utförandet. Om Ti senior Tj, Sedan TS(Ti) < TS(Tj).
När en transaktion återställs tilldelas den en ny tidsstämpel. Varje dataobjekt Q inblandad i transaktionen är märkt med två etiketter. W-TS(Q) — tidsstämpel för den yngsta transaktionen som framgångsrikt slutförde en övergång Q. R-TS(Q) — tidsstämpel för den yngsta transaktionen som utförde en läspost på Q.
När transaktionen T begäran om att läsa data Q Det finns två alternativ.
Om TS(T) < W-TS(Q), det vill säga att data uppdaterades av en yngre transaktion, sedan transaktionen T rullar tillbaka.
Om TS(T) >= W-TS(Q), sedan utförs avläsningen och R-TS(Q) blir MAX(R-TS(Q), TS(T)).
När transaktionen T begär dataändringar Q Det finns två alternativ.
Om TS(T) < R-TS(Q), det vill säga data har redan lästs av en yngre transaktion och om en ändring görs uppstår en konflikt. Transaktion T rullar tillbaka.
Om TS(T) < W-TS(Q), det vill säga transaktionen försöker skriva över ett nyare värde, transaktion T rullas tillbaka. I andra fall genomförs ändringen och W-TS(Q) blir lika TS(T).
Ingen dyr konstruktion av väntande grafer krävs. Äldre transaktioner beror på nyare, så det finns inga cykler i väntediagrammet. Det finns inga dödlägen eftersom transaktioner inte väntas utan rullas tillbaka omedelbart. Cascading rollbacks är möjliga. Om Ti rullade iväg, och Tj Jag läste uppgifterna som jag ändrade Ti, Sedan Tj ska också rulla tillbaka. Om samtidigt Tj redan har begåtts, kommer det att ske en kränkning av stabilitetsprincipen.
En av lösningarna på kaskadåterställning. En transaktion slutför alla skrivoperationer i slutet, och andra transaktioner måste vänta på att operationen ska slutföras. Transaktioner väntar på att begås innan de läses.
Thomas skrivregel - en variant av tidsstämpelmetoden där data som uppdateras av en yngre transaktion är förbjuden att skrivas över av en äldre.
Transaktion T begär dataändringar Q. om TS(T) < W-TS(Q), det vill säga transaktionen försöker skriva över ett nyare värde, transaktion T rullas inte tillbaka som i tidsstämpelmetoden.
Källa: will.com