Hej alle. Vladislav Rodin er i kontakt. Jeg er i øjeblikket kursusleder for High Workload Architect-kurset på OTUS og underviser også i softwarearkitekturkurser.
Udover undervisning, som du måske har bemærket, skriver jeg originalt materiale til OTUS-bloggen på Habré, og jeg vil gerne falde sammen med dagens artikel for at falde sammen med lanceringen af kurset , som er åben for tilmelding lige nu.
Indledning
В vi talte om, at transaktioner i databaser tjener til at løse to problemer: sikring af fejltolerance og adgang til data i et konkurrencepræget miljø. For fuldt ud at udføre disse opgaver skal transaktionen have ACID-egenskaber. I dag vil vi tale i detaljer om brevet I (isolation) i denne forkortelse.
Isolering
Isolation løser problemet med at få adgang til data i et konkurrencepræget miljø, hvilket i det væsentlige giver beskyttelse mod raceforhold. Ideelt set betyder isolation serialisering, som er en egenskab, der sikrer, at resultatet af at udføre transaktioner parallelt er det samme, som hvis de blev udført sekventielt. Hovedproblemet med denne egenskab er, at den er meget vanskelig at levere teknisk og som følge heraf har en betydelig indvirkning på systemets ydeevne. Derfor er isolation ofte svækket, idet man accepterer risikoen for visse anomalier, som vil blive diskuteret nedenfor. Muligheden for, at visse anomalier opstår, karakteriserer netop niveauet af transaktionsisolation.
De mest kendte anomalier er: dirty read, non-repeatable read, fantom read, men faktisk er der 5 mere: dirty write, cursor lost update, lost update, read skæv, skrive skæv.
Beskidt skrive
Essensen af anomalien er, at transaktioner kan overskrive uforpligtede data.
Denne uregelmæssighed er farlig, ikke kun fordi data kan komme i konflikt efter at have begået begge transaktioner (som på billedet), men også fordi atomiciteten er overtrådt: da vi tillader at ikke-forpligtede data overskrives, er det ikke klart, hvordan man ruller en transaktion tilbage uden at påvirke en anden .
Uregelmæssigheden kan behandles ganske simpelt: Vi knytter en lås til posten, før optagelsen starter, og forbyder andre transaktioner at ændre posten, indtil låsen er fjernet.
Beskidt læsning
Beskidt læsning betyder læsning af uforpligtende data.
Problemer opstår, når handlinger eller beslutninger skal træffes baseret på stikprøven.
For at rette op på uregelmæssigheden kan du vedhæfte en læselås, men dette vil i høj grad påvirke ydeevnen. Det er meget nemmere at sige, at for en rollback-transaktion skal den oprindelige tilstand af dataene (før start af registrering) gemmes i systemet. Hvorfor ikke læse derfra? Det er billigt nok til, at de fleste databaser fjerner dirty read som standard.
Mistet opdatering
Mistet opdatering betyder mistede opdateringer, og oversættelsen afspejler ganske præcist essensen af problemet:
Faktisk blev resultatet af transaktion T2 tilbageført. Denne situation kan korrigeres med eksplicitte eller implicitte skrivelåse. Det vil sige, at vi enten opdaterer posten, og så opstår der en implicit låsning, eller også udfører vi vælg for opdatering, hvilket får en læse- og skrivelås til at opstå. Bemærk venligst, at en sådan operation er ret farlig: med vores "uskyldige" læsning blokerer vi andre aflæsninger. Nogle databaser tilbyder mere sikker vælg til deling, så data kan læses, men ikke ændres.
Markøren mistede opdatering
For bedre kontrol kan baser tilbyde andre værktøjer, såsom en markør. En markør er en struktur, der indeholder et sæt rækker og giver dig mulighed for at iterere over dem. erklær cursor_name for select_statement. Indholdet af markøren beskrives ved at vælge.
Hvorfor har du brug for en markør? Faktum er, at nogle databaser tilbyder en lås på alle poster, der er valgt ved select (læsestabilitet), eller kun på den post, hvor markøren i øjeblikket er placeret (cursorstabilitet). Med markørstabilitet implementeres kort lås, som giver os mulighed for at reducere antallet af låse, hvis vi itererer over et stort udvalg af data. Derfor er den tabte opdaterings-anomali isoleret separat for markøren.
Ikke-gentagelig læsning
Ikke-gentagelig læsning er, at under udførelsen af vores transaktion vil 2 på hinanden følgende læsninger af den samme registrering føre til forskellige resultater, fordi en anden transaktion greb ind mellem disse to læsninger, ændrede vores data og blev begået.
Hvorfor er dette overhovedet et problem? Forestil dig, at målet med transaktion T2 på billedet er at vælge alle varer, hvis pris er mindre end 150 USD. En anden opdaterede prisen til $200. Det installerede filter virkede således ikke.
Disse uregelmæssigheder ophører med at forekomme, når to-fasede låse tilføjes, eller når MVCC-mekanismen bruges, hvilket jeg gerne vil diskutere separat.
Fantomlæsning
Phantom er en læsning af data, der blev tilføjet af en anden transaktion.
Som et eksempel kan vi observere det forkerte valg af det billigste produkt, når denne anomali opstår.
At slippe af med fantomlæsninger er allerede ret svært. Regelmæssig blokering er ikke nok, for vi kan ikke blokere noget, der endnu ikke eksisterer. 2PL-systemer bruger prædiktiv låsning, mens MVCC-systemer har en transaktionsplanlægger, der ruller tilbage transaktioner, der kan blive forstyrret af en indsættelse. Både den første og anden mekanisme er ret tunge.
Læs skævt
Læseskævhed opstår, når vi arbejder med flere tabeller, hvis indhold skal ændres konsekvent.
Lad os sige, at vi har tabeller, der repræsenterer indlæg og deres metaoplysninger:
En transaktion læser fra tabellerne, den anden ændrer dem:
Som et resultat af transaktion T1 har indlægget title = Good og updated_by = T2, hvilket er en form for inkonsekvens.
Faktisk er dette en ikke-gentagelig læsning, men som en del af flere tabeller.
For at rette op på dette kan T1 sætte låse på alle rækker, som den vil læse, hvilket vil forhindre transaktion T2 i at ændre informationen. I tilfælde af MVCC vil T2-transaktionen blive annulleret. Beskyttelse mod denne anomali kan blive vigtig, hvis vi bruger markører.
Skriv skævt
Denne anomali er også lettere at forklare med et eksempel: antag, at i vores system skulle mindst én læge være på vagt, men begge læger besluttede at aflyse deres vagt:
Anomalien betød, at ingen af lægerne ville være på vagt. Hvorfor skete dette? Fordi transaktionen tjekkede en betingelse, der kunne blive overtrådt af en anden transaktion, og på grund af isolation så vi ikke denne ændring.
Dette er den samme ikke-gentagelige læsning. Alternativt kan selects placere låse på disse poster.
Skriv skævt og læs skævt er kombinationer af de tidligere anomalier. Du kan overveje at skrive skævt, som i det væsentlige er en fantomlæsning. Overvej en tabel, der indeholder navne på medarbejdere, deres lønninger og det projekt, de arbejder på:
Som et resultat får vi følgende billede: hver leder mente, at deres skift ikke ville føre til at overskride budgettet, så de lavede personaleændringer, der tilsammen førte til omkostningsoverskridelser.
Årsagen til problemet er nøjagtig den samme som ved fantomlæsning.
Fund
At slække på transaktionsisolationsniveauet i databasen er en afvejning mellem sikkerhed og ydeevne; valget af dette niveau bør gribes an baseret på de potentielle risici for virksomheden, hvis der opstår visse uregelmæssigheder.
Kilde: www.habr.com