Pozdrav svima. Ovde je Vladislav Rodin. Trenutno sam voditelj tečaja "Arhitekt visoke opterećenosti" u OTUS-u, a također predajem na tečajevima posvećenim softverskoj arhitekturi.
Osim podučavanja, kao što ste mogli primijetiti, pišem autorski sadržaj za blog OTUS na Habr-u i današnji članak želim posvetiti pokretanju tečaja , za koji je trenutno otvorena prijava.
Uvod
U Razgovarali smo o tome da transakcije u bazama podataka služe za rješavanje dva zadatka: osiguranje otpornosti na greške i pristup podacima u konkurentnom okruženju. Da bi se ti zadaci u potpunosti izvršili, transakcija mora imati ACID svojstva. Danas ćemo detaljno razgovarati o slovu I (izolacija) u ovoj akronim.
Izolacija
Izolacija rješava problem pristupa podacima u konkurentnom okruženju, zapravo pružajući zaštitu od race conditions. U idealnom slučaju, izolacija znači serijalizaciju, odnosno svojstvo koje osigurava da je rezultat izvođenja transakcija paralelno isti kao da su se izvodile sekvencijalno. Glavni problem ovog svojstva je u tome što ga je vrlo teško tehnički osigurati i kao rezultat toga značajno pogađa performanse sustava. Zbog toga se izolacija često slabi, prihvaćajući rizike od pojave nekih anomalija o kojima će biti riječ u nastavku. Mogućnost pojave raznih anomalija upravo karakterizira razinu izolacije transakcija.
Najpoznatije anomalije su: dirty read, non-repeatable read, phantom read, ali u stvarnosti ih ima još 5: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Bit anomalije leži u tome da transakcije mogu prepisivati nekomitirane podatke.
Ova anomalija nije opasna samo zbog toga što podaci mogu doći u sukob nakon potvrde obiju transakcija (kao na slici), već i zbog toga što krši atomskost: jer ćemo dozvoliti prepisivanje nekomitiranih podataka, nejasno je kako vratiti jednu transakciju, a da pritom ne naškodimo drugoj.
Anomalija se prilično jednostavno liječi: postavljamo zaključavanje na pisanje prije početka pisanja, zabranjujući drugim transakcijama da mijenjaju zapis sve dok zaključavanje ne bude uklonjeno.
Dirty read
Dirty read označava čitanje nezavezanih podataka.
Problemi nastaju kada je potrebno na osnovu uzorka izvršiti neke radnje ili donijeti odluke.
Za ispravljanje anomalije može se postaviti zaključavanje za čitanje, ali to će značajno utjecati na performanse. Puno je jednostavnije reći da se za rollback transakcije izvorno stanje podataka (prije početka zapisivanja) mora obavezno sačuvati u sustavu. Zašto ne čitati odande? To je dovoljno jeftino, pa većina baza podataka po defaultu isključuje dirty read.
Lost update
Lost update označava izgubljene ažuriranja, a prijevod prilično točno oslikava bit problema:
U stvarnosti, rezultat transakcije T2 je otkazan. Ova situacija se ispravlja eksplicitnim ili implicitim zaključavanjima zapisa. Drugim riječima, ili jednostavno ažuriramo zapis, čime nastaje implicite zaključavanje, ili izvedemo select for update, uzrokujući zaključavanje na čitanje i na zapis. Imajte na umu da je ova operacija prilično opasna: svojim 'nevino' čitanjem, zaključavamo druga čitanja. Neki sustavi nude sigurniji select for share, koji omogućuje čitanje podataka, ali ne dopušta njihovu izmjenu.
Cursor lost update
Za finiju kontrolu, baze mogu nuditi druge alate, poput kursora. Kursor je struktura koja sadrži skup redaka i omogućuje iteraciju kroz njih. declare cursor_name for select_statement. Sadržaj kursora opisuje select.
Zašto je potreban kursor? Djeluje se na tome da neke baze podataka nude zaključavanje na sve zapise odabranih selectom (read stability), ili samo na onaj zapis na kojem se trenutno nalazi kursor (cursor stability). Kod cursor stability provodi se kratko zaključavanje, što omogućuje smanjenje broja zaključavanja u slučaju da iteriramo kroz veliko uzorko podataka. Stoga se anomalija lost update izdvaja za kursor posebno.
Non-repeatable read
Non-repeatable read se sastoji u tome da će tijekom izvršavanja naše transakcije 2 uzastopna čitanja istog zapisa dovesti do različitih rezultata, jer je druga transakcija intervenisala između ta dva čitanja, promijenila naše podatke i bila zakazana.
Zašto je to uopće problem? Zamislite da je cilj transakcije T2 na slici odabrati sve proizvode čija je cijena manja od 150 u.e. Netko drugi je ažurirao cijenu na 200 u.e. Tako da postavljeni filtar nije proradio.
Ove anomale prestaju nastajati dodavanjem dvofazne blokade ili korištenjem mehanizma MVCC, o čemu bih volio posebno razgovarati.
Fantomsko čitanje
Fantomsko se naziva čitanje podataka koji su dodani od strane druge transakcije.
Kao primjer možemo vidjeti pogrešan odabir najjeftinijeg proizvoda kada se dogodi ova anomalia.
Osloboditi se fantomskih čitanja već je dovoljno teško. Obična blokada nije dovoljna, jer ne možemo blokirati ono što još ne postoji. 2PL-sustavi koriste predikativnu blokadu, dok MVCC sustavi otkazuju transakcije koje mogu biti narušene umetanjima. I jedan i drugi mehanizam su prilično teški.
Read skew
Read skew se javlja kada radimo s više tablica čiji sadržaj treba biti usklađen.
Pretpostavimo da imamo tablice koje predstavljaju postove i njihove meta informacije:
Jedna transakcija čita iz tablica, dok ih druga mijenja:
Kao rezultat izvršenja transakcije T1, post s naslovom = Good, a updated_by = T2, što predstavlja određenu neusklađenost.
Faktički, ovo je non-repeatable read, ali u okviru više tablica.
Kako bi se ispravilo to, T1 može postavljati blokade na sve redove koje će čitati, što neće dopustiti transakciji T2 da mijenja informacije. U slučaju MVCC, transakcija T2 će biti otkazana. Zaštita od ove anomale može postati važna ako koristimo kursor.
Write skew
Ovu anomalu također je lakše objasniti na primjeru: pretpostavimo da u našem sustavu barem jedan doktor mora biti dežuran, ali su oba doktora odlučila otkazati svoju dežurstvo:
Anomalia je dovela do toga da nijedan od doktora ne ode na dežurstvo. Zašto se to dogodilo? Zato što je transakcija provjeravala uvjet koji može biti narušen od strane druge transakcije, a zbog izolacije nismo vidjeli tu promjenu.
To je isto kao i non-repeatable read. Kao opcija, selecti mogu postavljati blokade na ove zapise.
Write skew i read skew su kombinacije prethodnih anomalija. Možemo razmotriti write skew, koji je u suštini phantom read. Uzmimo za primjer tablicu koja sadrži imena zaposlenika, njihove plaće i projekte na kojima rade:
Na kraju, dobivamo sljedeću sliku: svaki menadžer je mislio da njegova promjena neće dovesti do prekoračenja budžeta, pa su izvršili kadrovske promjene koje su ukupno dovele do prekomjerne potrošnje.
Uzrok nastanka problema je potpuno isti kao i kod phantom read-a.
Zaključci
Smanjenje razine izolacije transakcija u bazi podataka kompromis je između sigurnosti i performansi, a izbor te razine treba se temeljiti na potencijalnim rizicima za poslovanje u slučaju određenih anomalija.
Izvor: habr.com
