Hej alla. Vladislav Rodin är i kontakt. Jag är för närvarande kursledare för High Workload Architect-kursen på OTUS och undervisar även i programvaruarkitekturkurser.
Förutom undervisning, som du kanske har märkt, skriver jag originalmaterial för OTUS-bloggen på Habré och jag vill sammanfalla med dagens artikel för att sammanfalla med lanseringen av kursen , som är öppen för registrering just nu.
Inledning
В vi pratade om det faktum att transaktioner i databaser tjänar till att lösa två problem: att säkerställa feltolerans och tillgång till data i en konkurrensutsatt miljö. För att utföra dessa uppgifter fullt ut måste transaktionen ha ACID-egenskaper. Idag kommer vi att prata i detalj om brevet jag (isolering) i denna förkortning.
Isolering
Isolering löser problemet med att komma åt data i en konkurrensutsatt miljö, vilket i huvudsak ger skydd mot rasförhållanden. Idealiskt innebär isolering serialisering, vilket är en egenskap som säkerställer att resultatet av att utföra transaktioner parallellt är detsamma som om de utfördes sekventiellt. Det största problemet med den här egenskapen är att den är mycket svår att tillhandahålla tekniskt och som ett resultat har den en betydande inverkan på systemets prestanda. Det är därför isoleringen ofta försvagas och accepterar riskerna för vissa anomalier, som kommer att diskuteras nedan. Möjligheten att vissa anomalier inträffar kännetecknar just nivån av transaktionsisolering.
De mest kända anomalierna är: smutsig läsning, ej repeterbar läsning, fantomläsning, men i själva verket finns det 5 till: smutsig skrivning, markör förlorad uppdatering, förlorad uppdatering, läs skev, skriv skev.
Smutsigt skrivande
Kärnan i anomalien är att transaktioner kan skriva över oengagerad data.
Denna anomali är farlig inte bara för att data kan komma i konflikt efter att båda transaktionerna har utförts (som på bilden), utan också för att atomiciteten kränks: eftersom vi tillåter att oengagerad data skrivs över är det inte klart hur man återställer en transaktion utan att påverka en annan .
Avvikelsen kan behandlas ganska enkelt: vi fäster ett lås till posten innan inspelningen påbörjas, vilket förbjuder andra transaktioner att ändra posten tills låset tas bort.
Smutsig läsning
Smutsig läsning betyder att läsa oengagerad data.
Problem uppstår när åtgärder eller beslut måste fattas utifrån urvalet.
För att korrigera avvikelsen kan du fästa ett läslås, men det kommer att påverka prestandan i hög grad. Det är mycket enklare att säga att för en återställningstransaktion måste det ursprungliga tillståndet för data (innan inspelningen påbörjas) sparas i systemet. Varför inte läsa därifrån? Det är tillräckligt billigt för att de flesta databaser tar bort smutsig läsning som standard.
Förlorad uppdatering
Förlorad uppdatering betyder förlorade uppdateringar, och översättningen återspeglar ganska exakt problemets kärna:
Faktum är att resultatet av transaktion T2 omkastades. Denna situation kan korrigeras genom explicita eller implicita skrivlås. Det vill säga, antingen uppdaterar vi helt enkelt posten och sedan uppstår en implicit låsning, eller så utför vi välj för uppdatering, vilket gör att ett läs- och skrivlås uppstår. Observera att en sådan operation är ganska farlig: med vår "oskyldiga" läsning blockerar vi andra avläsningar. Vissa databaser erbjuder säkrare välj för delning, vilket gör att data kan läsas men inte ändras.
Markören förlorade uppdateringen
För finare kontroll kan baser erbjuda andra verktyg, till exempel en markör. En markör är en struktur som innehåller en uppsättning rader och låter dig iterera över dem. deklarera cursor_name för select_statement. Innehållet i markören beskrivs genom att välja.
Varför behöver du en markör? Faktum är att vissa databaser erbjuder ett lås på alla poster som valts av select (lässtabilitet), eller bara på posten där markören för närvarande är placerad (markörstabilitet). Med markörstabilitet implementeras kort lås, vilket gör att vi kan minska antalet lås om vi itererar över ett stort urval av data. Därför isoleras den förlorade uppdateringsavvikelsen separat för markören.
Ej repeterbar läsning
Icke-repeterbar läsning är att under utförandet av vår transaktion kommer 2 på varandra följande läsningar av samma post att leda till olika resultat, eftersom en annan transaktion ingrep mellan dessa två läsningar, ändrade våra data och begicks.
Varför är detta ens ett problem? Föreställ dig att målet med transaktion T2 i bilden är att välja alla varor vars pris är mindre än 150 USD. Någon annan uppdaterade priset till $200. Det installerade filtret fungerade alltså inte.
Dessa anomalier upphör att inträffa när tvåfasförreglingar läggs till eller när MVCC-mekanismen används, vilket jag skulle vilja diskutera separat.
Fantomläsning
Phantom är en läsning av data som har lagts till av en annan transaktion.
Som ett exempel kan vi observera det felaktiga valet av den billigaste produkten när denna anomali inträffar.
Att bli av med fantomläsningar är redan ganska svårt. Regelbunden blockering räcker inte, eftersom vi inte kan blockera något som ännu inte finns. 2PL-system använder prediktiv låsning, medan MVCC-system har en transaktionsschemaläggare som återställer transaktioner som kan störas av en infogning. Både den första och andra mekanismen är ganska tunga.
Läs skevt
Lässkevning uppstår när vi arbetar med flera tabeller, vars innehåll måste ändras konsekvent.
Låt oss säga att vi har tabeller som representerar inlägg och deras metainformation:
En transaktion läses från tabellerna, den andra modifierar dem:
Som ett resultat av transaktion T1 har inlägget titel = Bra och uppdaterad_av = T2, vilket är någon form av inkonsekvens.
I själva verket är detta en icke-repeterbar läsning, men som en del av flera tabeller.
För att fixa detta kan T1 sätta lås på alla rader som den kommer att läsa, vilket kommer att förhindra transaktion T2 från att ändra informationen. Vid MVCC kommer T2-transaktionen att avbrytas. Skydd mot denna anomali kan bli viktigt om vi använder markörer.
Skriv skevt
Denna anomali är också lättare att förklara med ett exempel: anta att i vårt system borde minst en läkare vara i tjänst, men båda läkarna bestämde sig för att avbryta sin tjänst:
Avvikelsen gjorde att ingen av läkarna skulle vara i tjänst. Varför hände det här? Eftersom transaktionen kontrollerade ett villkor som kunde överträdas av en annan transaktion, och på grund av isolering såg vi inte denna förändring.
Detta är samma icke-repeterbara läsning. Alternativt kan utvalda placera lås på dessa poster.
Skriv skevt och läs skevt är kombinationer av de tidigare anomalierna. Du kan överväga att skriva skevt, vilket i huvudsak är en fantomläsning. Tänk på en tabell som innehåller namnen på anställda, deras löner och projektet de arbetar med:
Som ett resultat får vi följande bild: varje chef trodde att deras byte inte skulle leda till att budgeten gick över, så de gjorde personalförändringar som tillsammans ledde till kostnadsöverskridanden.
Orsaken till problemet är exakt densamma som vid fantomläsning.
Resultat
Att lätta på transaktionsisoleringsnivån i databasen är en avvägning mellan säkerhet och prestanda; valet av denna nivå bör närma sig baserat på de potentiella riskerna för verksamheten om vissa avvikelser uppstår.
Källa: will.com