Bok svima. Javlja se Vladislav Rodin. Trenutačno sam voditelj tečaja za High Workload Architect tečaj na OTUS-u i također predajem tečajeve softverske arhitekture.
Osim predavanja, kao što ste možda primijetili, pišem izvorni materijal za blog OTUS na Habréu i želim se poklopiti s današnjim člankom kako bi se poklopio s pokretanjem tečaja
Uvod
В
izolacija
Izolacija rješava problem pristupa podacima u konkurentskom okruženju, u biti pruža zaštitu od uvjeta utrke. U idealnom slučaju, izolacija znači serijalizaciju, što je svojstvo koje osigurava da je rezultat paralelnog izvršavanja transakcija isti kao da se izvršavaju sekvencijalno. Glavni problem s ovim svojstvom je taj što ga je vrlo teško tehnički osigurati i, kao rezultat toga, ima značajan utjecaj na performanse sustava. Zbog toga se izolacija često slabi, prihvaćajući rizike određenih anomalija, o kojima će biti riječi u nastavku. Mogućnost pojave određenih anomalija upravo karakterizira razinu izolacije transakcije.
Najpoznatije anomalije su: prljavo čitanje, neponovljivo čitanje, fantomsko čitanje, ali zapravo ih ima još 5: prljavo pisanje, izgubljeno ažuriranje kursora, izgubljeno ažuriranje, krivo čitanje, krivo pisanje.
Prljavo pisanje
Bit anomalije je da transakcije mogu prebrisati nedodijeljene podatke.
Ova anomalija je opasna ne samo zato što se podaci mogu sukobiti nakon izvršenja obiju transakcija (kao na slici), već i zato što je narušena atomičnost: budući da dopuštamo prebrisanje nedodijeljenih podataka, nije jasno kako vratiti jednu transakciju na staro stanje bez utjecaja na drugu .
Anomalija se može tretirati prilično jednostavno: pridajemo katanac zapisu prije početka snimanja, zabranjujući drugim transakcijama da mijenjaju zapis dok se katanac ne ukloni.
Prljavo štivo
Prljavo čitanje znači čitanje nedodijeljenih podataka.
Problemi nastaju kada se radnje ili odluke trebaju donijeti na temelju uzorka.
Da biste ispravili anomaliju, možete priključiti bravu za čitanje, ali to će uvelike utjecati na performanse. Mnogo je jednostavnije reći da za povrat transakcije početno stanje podataka (prije početka snimanja) mora biti spremljeno u sustav. Zašto ne čitati od tamo? Dovoljno je jeftin da većina baza podataka uklanja prljavo čitanje prema zadanim postavkama.
Izgubljeno ažuriranje
Lost update znači izgubljena ažuriranja, a prijevod prilično točno odražava bit problema:
Zapravo, rezultat transakcije T2 bio je obrnut. Ova se situacija može ispraviti eksplicitnim ili implicitnim zaključavanjem pisanja. Odnosno, ili jednostavno ažuriramo zapis, a zatim dolazi do implicitnog zaključavanja, ili izvodimo odaberite za ažuriranje, što uzrokuje zaključavanje čitanja i pisanja. Imajte na umu da je takva operacija vrlo opasna: svojim "nevinim" očitanjem blokiramo druga očitanja. Neke baze podataka nude veću sigurnost odaberite za dijeljenje, dopuštajući da se podaci čitaju, ali ne i mijenjaju.
Kursor je izgubio ažuriranje
Za finiju kontrolu, baze mogu ponuditi druge alate, kao što je kursor. Kursor je struktura koja sadrži skup redaka i omogućuje vam ponavljanje preko njih. deklarirati cursor_name za select_statement. Sadržaj kursora opisuje se odabirom.
Zašto vam je potreban kursor? Činjenica je da neke baze podataka nude zaključavanje svih zapisa odabranih odabirom (stabilnost čitanja), ili samo zapisa na kojem se trenutno nalazi kursor (stabilnost kursora). Sa stabilnošću pokazivača implementirano je kratko zaključavanje, što nam omogućuje smanjenje broja zaključavanja ako ponavljamo veliki uzorak podataka. Stoga je anomalija izgubljenog ažuriranja zasebno izolirana za kursor.
Neponovljivo čitanje
Neponovljivo čitanje je da će tijekom izvršenja naše transakcije, 2 uzastopna čitanja istog zapisa dovesti do različitih rezultata, jer je druga transakcija intervenirala između ova dva čitanja, promijenila naše podatke i bila počinjena.
Zašto je to uopće problem? Zamislite da je cilj transakcije T2 na slici odabrati svu robu čija je cijena manja od 150 USD. Netko drugi je ažurirao cijenu na 200 USD. Dakle, instalirani filter nije radio.
Ove se anomalije prestaju pojavljivati kada se dodaju dvofazne blokade ili kada se koristi MVCC mehanizam, o čemu bih želio zasebno raspravljati.
Fantomsko čitanje
Fantom je čitanje podataka koje je dodala druga transakcija.
Kao primjer možemo navesti pogrešan odabir najjeftinijeg proizvoda kada se pojavi ova anomalija.
Riješiti se fantomskih očitanja već je prilično teško. Redovno blokiranje nije dovoljno, jer ne možemo blokirati nešto što još ne postoji. 2PL sustavi koriste prediktivno zaključavanje, dok MVCC sustavi imaju raspoređivač transakcija koji vraća transakcije koje bi mogle biti prekinute umetanjem. I prvi i drugi mehanizam su prilično teški.
Čitaj iskosa
Iskrivljenje čitanja se događa kada radimo s nekoliko tablica, čiji se sadržaji moraju dosljedno mijenjati.
Recimo da imamo tablice koje predstavljaju objave i njihove meta informacije:
Jedna transakcija čita iz tablica, druga ih mijenja:
Kao rezultat transakcije T1, objava ima naslov = Dobro i updated_by = T2, što je neka vrsta nedosljednosti.
Zapravo, radi se o neponovljivom čitanju, ali u sklopu nekoliko tablica.
Kako bi to popravio, T1 može zaključati sve retke koje će čitati, što će spriječiti transakciju T2 da promijeni informacije. U slučaju MVCC-a, T2 transakcija će biti otkazana. Zaštita od ove anomalije može postati važna ako koristimo kursore.
Pišite iskosa
I ovu je anomaliju lakše objasniti na primjeru: pretpostavimo da bi u našem sustavu barem jedan liječnik trebao dežurati, ali su oba liječnika odlučila otkazati dežurstvo:
Anomalija je značila da nitko od liječnika neće biti na dužnosti. Zašto se to dogodilo? Budući da je transakcija provjeravala uvjet koji bi mogla biti prekršena drugom transakcijom, a zbog izolacije nismo vidjeli ovu promjenu.
Ovo je isto neponovljivo čitanje. Alternativno, odabrani mogu zaključati te zapise.
Nepravilno pisanje i nepravilno čitanje kombinacije su prethodnih anomalija. Možete uzeti u obzir iskrivljeno pisanje, što je u biti fantomsko čitanje. Razmotrite tablicu koja sadrži imena zaposlenika, njihove plaće i projekt na kojem rade:
Kao rezultat toga dobivamo sljedeću sliku: svaki menadžer je mislio da njihova promjena neće dovesti do prekoračenja budžeta, pa su izvršili kadrovske promjene koje su zajedno dovele do prekoračenja troškova.
Uzrok problema je potpuno isti kao kod čitanja fantoma.
Zaključci
Ublažavanje razine izolacije transakcija u bazi podataka kompromis je između sigurnosti i performansi; odabiru ove razine treba pristupiti na temelju potencijalnih rizika za poslovanje ako se pojave određene anomalije.
Izvor: www.habr.com