Transakcije Flashcards
Transakcije
Da bi sistem bio pouzdan mora SVAKU od ovih stavki obraditi, tako da ne obore ili utiču na performanse celokupnog sistema.
Ne treba svakoj aplikaciji transakciona obrada, i poželjno je performansi radi oslabiti malo garancije koje nude transakcije
ACID
Garancije koje nude transakcije se obično definišu preko ACID akronima
-Atomicnost
-Konzistentnost
-Izolacija
-Trajnost
Sistemi koji ne ispunjavaju ACID se obično zovu BASE
Atomicnost
Možemo pomisliti u kontekstu konkurentnosti, da su operacije “atomične” u smislu da ne mogu biti prekinute
Atomičnost u ACID-u opisuje šta će se desiti ukoliko pri obradi više operacija dođe do nekog fault-a .
Ukoliko su operacije grupisane u atomičku transakciju, a jedna od operacija ne može biti izvršena, onda će transakcija odbiti da se kompletno izvrši (Commit).
Konzistentnost
U smislu transakcija smatra se da uvek moraju postojati određena pravila ili statementi koji uvek moraju biti “istiniti”.
Dakle ACID konzistentnost zavisi isključivo od pravila koje aplikacija propisuje, i nije nešto čime bi baza trebalo da se bavi
Onda se prosto trebamo zapitati, zašto pričamo o konzistentnosti u ACID-u, kada nema nikakve veze sa samom bazom podataka.
Izolacija
Pri svakodnevnom korišćenju baza, normalna je pojava da više korisnika paralelno koristi bazu, što ne predstavlja problem samo po sebi
Izolacija znaci da transakcije koje konkurentno rade neki posao su izolovane jedna od druge, i ne mogu smetati jedna drugoj
Trajnost (Durability)
Baze podataka se smatraju kao mesto na kome se podatak može čuvati bez straha od gubitka tog podatka.
Kod baza podataka koje rade na jednom računaru, trajnost podrazumeva čuvanje na hard disku, kao i dodavanje u write-ahead log u slučaju korupcije podataka.
U repliciranim bazama podataka trajnost podrazumeva da su se podaci prekopirali na neki broj replika.
Savršena trajnost podataka ne postoji, ukoliko nam svi hard diskovi ili replike faultuju u isto vreme, podatak se idalje gubi.
Replikacija i Trajnost
Tradicionalno trajnost se smatrala čuvanjem na hard disku, međutim danas sve više i više znači replikacija podataka
Pri asinhronoj replikaciji podaci se idalje mogu izgubiti, ukoliko padne master
Single Object i Multi Object
Operacije
Kada pričamo o transakciji, generalno podrazumevamo da se radi o modifikaciji više objekata (redova, dokumenata, itd..)
Česta optimizacija ovog slučaja je da denormalizujemo bazu, i da čuvamo unutar baze tačan broj nepročitanih poruka.
Pri nedostatku izolacije može nam se desiti da pročitamo “polu dovršen” podatak. To jest da vidimo nepročitani email, ali da nam counter kaže 0.
Ovakva pojava se zove Dirty Read
Multiobject transakcijama je potreban način da prepoznaju koje operacije spadaju unutar neke transakcije.
Nerelacione baze podataka nemaju mehanizam grupisanja operacija
Single Object Write
Uzmimo za primer 20KB JSON objekaGeneralno ovakvi problemi su malo previše za bilo koju bazu
Atomičnost se postiže log-om za crash recovery, a izolacija se postiže lock-ovima nad tim objektom. (Tako da samo jedan thread može da im pristupi)
Svaka transakcija dobija po jedan thread obično.
Neke baze nude atomičnu increment operaciju, umesto read-modify-write.
Takođe česta je praksa da se implementira compare and set komanda kao atomična
Potreba za Multi Object Transakcijama
Većina baza koje moraju da rade u distribuiranom režimu su odustale od multi object transakcijama, zbog poteškoća u radu sa particijama.
Posebno jer mogu smanjiti visok availability i performanse sistema
Većina baza koje moraju da rade u distribuiranom režimu su odustale od multi object transakcijama, zbog poteškoća u radu sa particijama.
Posebno jer mogu smanjiti visok availability i performanse sistema
–Nemamo mogućnost da održimo referencijalni integritet.
–Document-oriented baze smatraju dokument kao single object. Međutim pri denormalizaciji dokumenata, može nam se pojaviti slučaj da moramo da updejtujemo više dokumenata radi sinhronizacije redundantnih podataka.
–Ukoliko koristimo sekudnarne indekse, svaka promena polja mora se vezati za promenu indeksa. Može nam se desiti da se pojavi u jednom indeksu ali ne u drugom, itd…
Svi ovi problemi se prebacuju aplikacionim programerima, koji moraju bez transakcija upravljati greškama koje se mogu pojaviti.
Upravljanje greškama i prekid transakcija
U standardnim ACID bazama, ukoliko je transakcija pod rizikom da prekrši određene garancije, baza će je prekinuti i ukloniti sve promene
Međutim kod drugih baza, posebno kod leader-less replikacije, sve funkcioniše po “best-effort” principu
Baza će probati sve što može, ali ukoliko se desi error, neće ukloniti sve promene
Dosta programera kao i frameworka(ORM) posmatraju transakcije samo u optimističkom smislu da moraju da prođu, i neće ponovo pokušati ukoliko se javi greška, što je i cela poenta.
Slabi izolacioni nivoi
Read Commited
Read Commited je najprostiji nivo izolacije koji nam garantuje:
–Kada čitamo iz baze, videćemo samo commit-ovane podatke (Nema dirty read-ova)
–Kada upisujemo podatke, samo ćemo pregaziti podatke koji su prethodno commit-ovani
Izbegavanje Dirty read-ova je korisno jer:
–Ukoliko updatujemo više objekata, druga transakcija može videti naše parcijalne promene
–Ukoliko se transakcija prekine, ona mora biti rollbackovana. Dok se ne izvrši rollback može se desiti da neko pročita ne-commitovane podatke.
Dirty Write
Ukoliko imamo konkurentni pristup nekom objektu, možemo predpostaviti da će ona koja se kasnije desila pregaziti onu koja se pre desila.
Međutim ukoliko ona koja se prva dešava duže traje i ne commituje, druga može pregaziti njene uncommmited podatke.
Da bi smo uklonili dirty write, moramo čekati da prva transakcija uradi commit, pre nego što pregazimo
Implementacija Read Commited
Read Commited je popularan izolacioni nivo, i postavljen je kao default kod većine relacionih baza podataka Oracle,Postgres,SQLServer
Baze obično implementiraju Read Commited preko row-lock-ova
Ukoliko hoćemo da menjamo neki red, moramo prvo dobiti lock nad njime, koji ćemo držati dok se transakcija ne završi. Ukoliko je lock zauzet, čekamo da se oslobodi.
Dirty read se zaustavlja tako što se može koristiti isti lock, pri svakom čitanju, koji se momentalno odpušta nakon čitanja. Ovime osiguravamo da row nije dirty ili uncommited.
