Hei alle sammen. Vladislav Rodin er i kontakt. Jeg er for tiden kursleder for High Workload Architect-kurset ved OTUS og underviser også i programvarearkitekturkurs.
I tillegg til undervisning, som du kanskje har lagt merke til, skriver jeg originalt materiale for OTUS-bloggen på Habré, og jeg ønsker å sammenfalle med dagens artikkel for å sammenfalle med lanseringen av kurset , som er åpen for påmelding akkurat nå.
Innledning
В vi snakket om det faktum at transaksjoner i databaser tjener til å løse to problemer: å sikre feiltoleranse og tilgang til data i et konkurranseutsatt miljø. For å utføre disse oppgavene fullt ut, må transaksjonen ha ACID-egenskaper. I dag skal vi snakke i detalj om brevet jeg (isolasjon) i denne forkortelsen.
Isolasjon
Isolering løser problemet med å få tilgang til data i et konkurransedyktig miljø, og gir i hovedsak beskyttelse mot raseforhold. Ideelt sett betyr isolasjon serialisering, som er en egenskap som sikrer at resultatet av å utføre transaksjoner parallelt er det samme som om de ble utført sekvensielt. Hovedproblemet med denne egenskapen er at den er svært vanskelig å gi teknisk og som et resultat har den en betydelig innvirkning på systemytelsen. Det er grunnen til at isolasjon ofte svekkes, og aksepterer risikoen for visse anomalier, som vil bli diskutert nedenfor. Muligheten for forekomsten av visse anomalier karakteriserer nøyaktig nivået av transaksjonsisolasjon.
De mest kjente anomaliene er: skitten lesing, ikke-repeterbar lesing, fantomlesing, men faktisk er det 5 flere: skitten skriving, markør tapt oppdatering, tapt oppdatering, leseskjevhet, skriveskjevhet.
Skitten skrive
Essensen av anomalien er at transaksjoner kan overskrive ikke-forpliktede data.
Denne anomalien er farlig, ikke bare fordi data kan komme i konflikt etter å ha begått begge transaksjonene (som på bildet), men også fordi atomitet er krenket: siden vi tillater at ikke-forpliktet data blir overskrevet, er det ikke klart hvordan man ruller tilbake en transaksjon uten å påvirke en annen. .
Uregelmessigheten kan behandles ganske enkelt: vi fester en lås til posten før du starter opptaket, og forbyr andre transaksjoner å endre posten før låsen er fjernet.
Skitten lesning
Skitten lesing betyr å lese uforpliktende data.
Problemer oppstår når handlinger eller beslutninger må tas basert på utvalget.
For å korrigere uregelmessigheten kan du feste en leselås, men dette vil ha stor innvirkning på ytelsen. Det er mye enklere å si at for en tilbakeføringstransaksjon må den opprinnelige tilstanden til dataene (før start av opptak) lagres i systemet. Hvorfor ikke lese derfra? Det er billig nok til at de fleste databaser fjerner skitten lesning som standard.
Mistet oppdatering
Tapt oppdatering betyr tapte oppdateringer, og oversettelsen gjenspeiler ganske nøyaktig essensen av problemet:
Faktisk ble resultatet av transaksjon T2 reversert. Denne situasjonen kan korrigeres med eksplisitte eller implisitte skrivelåser. Det vil si at vi enten oppdaterer posten, og så oppstår en implisitt låsing, eller så utfører vi velg for oppdatering, noe som forårsaker en lese- og skrivelås. Vær oppmerksom på at en slik operasjon er ganske farlig: med vår "uskyldige" lesing blokkerer vi andre målinger. Noen databaser tilbyr sikrere velg for deling, slik at data kan leses, men ikke endres.
Markøren mistet oppdateringen
For bedre kontroll kan baser tilby andre verktøy, for eksempel en markør. En markør er en struktur som inneholder et sett med rader og lar deg iterere over dem. erklær markørnavn for select_statement. Innholdet i markøren beskrives ved å velge.
Hvorfor trenger du en markør? Faktum er at noen databaser tilbyr en lås på alle poster valgt av select (lesestabilitet), eller bare på posten som markøren befinner seg på (markørstabilitet). Med markørstabilitet implementeres kortlås, som lar oss redusere antall låser hvis vi itererer over et stort utvalg av data. Derfor er den tapte oppdateringsavviket isolert separat for markøren.
Lesing som ikke kan gjentas
Ikke-repeterbar lesning er at under utførelsen av transaksjonen vår, vil 2 påfølgende lesninger av samme post føre til forskjellige resultater, fordi en annen transaksjon grep inn mellom disse to avlesningene, endret dataene våre og ble begått.
Hvorfor er dette i det hele tatt et problem? Tenk deg at målet med transaksjon T2 på bildet er å velge alle varer som har en pris på mindre enn 150 USD. Noen andre oppdaterte prisen til $200. Dermed fungerte ikke det installerte filteret.
Disse uregelmessighetene slutter å oppstå når tofaselåser legges til eller når MVCC-mekanismen brukes, noe jeg vil diskutere separat.
Fantomlest
Phantom er en lesing av data som ble lagt til av en annen transaksjon.
Som et eksempel kan vi observere feil valg av det billigste produktet når denne anomalien oppstår.
Å bli kvitt fantomlesninger er allerede ganske vanskelig. Regelmessig blokkering er ikke nok, for vi kan ikke blokkere noe som ennå ikke eksisterer. 2PL-systemer bruker prediktiv låsing, mens MVCC-systemer har en transaksjonsplanlegger som ruller tilbake transaksjoner som kan bli forstyrret av et innlegg. Både den første og andre mekanismen er ganske tunge.
Les skjevt
Leseskjevhet oppstår når vi arbeider med flere tabeller, hvor innholdet må endres konsekvent.
La oss si at vi har tabeller som representerer innlegg og deres metainformasjon:
En transaksjon leser fra tabellene, den andre endrer dem:
Som et resultat av transaksjon T1 har innlegget tittel = Bra, og oppdatert_av = T2, som er en slags inkonsekvens.
Faktisk er dette en lesning som ikke kan gjentas, men som en del av flere tabeller.
For å fikse dette kan T1 sette låser på alle rader som den vil lese, noe som vil forhindre transaksjon T2 i å endre informasjonen. Ved MVCC vil T2-transaksjonen bli kansellert. Beskyttelse mot denne anomalien kan bli viktig hvis vi bruker markører.
Skriv skjevt
Denne anomalien er også lettere å forklare med et eksempel: anta at i vårt system burde minst én lege være på vakt, men begge legene bestemte seg for å avbryte vakt:
Anomalien gjorde at ingen av legene ville være på vakt. Hvorfor skjedde dette? Fordi transaksjonen sjekket en betingelse som kunne bli brutt av en annen transaksjon, og på grunn av isolasjon så vi ikke denne endringen.
Dette er den samme lesningen som ikke kan gjentas. Alternativt kan velgere plassere låser på disse postene.
Skrive skjevt og lese skjevt er kombinasjoner av de tidligere anomaliene. Du kan vurdere å skrive skjevt, som egentlig er en fantomlesning. Tenk på en tabell som inneholder navn på ansatte, deres lønn og prosjektet de jobber med:
Som et resultat får vi følgende bilde: hver leder mente at deres endring ikke ville føre til å gå over budsjett, så de gjorde personalendringer som sammen førte til kostnadsoverskridelser.
Årsaken til problemet er nøyaktig den samme som ved fantomlesing.
Funn
Å slappe av transaksjonsisolasjonsnivået i databasen er en avveining mellom sikkerhet og ytelse; valget av dette nivået bør tilnærmes basert på potensielle risikoer for virksomheten hvis visse uregelmessigheter oppstår.
Kilde: www.habr.com