Tere kõigile. Siin on Vladislav Rodin. Praegu olen ma kursuse "Kuna kõrge koormuse arhitekt" juht OTUSes ning õpetan ka tarkvaraarhitektuuri kursustel.
Lisaks õpetamisele, nagu olete ilmselt märganud, kirjutan ma autorimaterjali OTUSi blogisse Habr ja täna soovin pühendada artikli kursuse käivitamisele. , millele on hetkel avatud registreerimine.
Sissejuhatus
V Rääkisime sellest, et andmebaaside tehingud lahendavad kahte ülesannet: tagades veakindluse ja juurdepääsu andmetele konkurentsikeskkonnas. Nende ülesannete täitmiseks peab tehing omama ACID omadusi. Täna räägime põhjalikult tähede I (isolation) sellel akronüümil.
Isolatsioon
Isolatsioon lahendab andmete pääsul konkurentsikeskkonnas, pakkudes tegelikult kaitset race condition'ide eest. Ideaalis tähendab isolatsioon serialiseerimist, mis tähendab omadust, mis tagab, et tehingute tulemused paralleelselt on samad, kui need täidetakse järjestikku. Peamine probleem selle omaduse puhul on see, et seda on väga keeruline tehniliselt tagada, mille tulemuseks on süsteemi jõudluse tõsine langemine. Just seetõttu nõrgestatakse isolatsiooni sageli, võttes riske teatud anomaaliate ilmnemise osas, millest allpool räägitakse. Võimalus erinevate anomaaliate tekkeks iseloomustabki tehingute isolatsiooni taset.
Tuntuimad anomaaliad on: dirty read, non-repeatable read, phantom read, kuid tegelikult on veel 5: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Anomaalia olemus seisneb selles, et tehingud võivad kirjutada üle kinnitamata andmed.
See anomaalia on ohtlik mitte ainult selle poolest, et andmed võivad pärast mõlema tehingu kinnitamist konfliktida (nagu pildil), vaid ka seetõttu, et rikutakse aatomilisust: kuna me lubame kirjutamata andmeid üle kirjutada, ei ole selge, kuidas ühe tehingu tagasiviimine toimub, kahjustamata samal ajal teist.
Anomaalia ravi on piisavalt lihtne: paigaldame kirjutamisblokaadi enne kirjutamise algust, keelates teistel tehingutel kirje muutmise seni, kuni blokk on eemaldatud.
Dirty read
Dirty read tähendab kinnitamata andmete lugemist.
Probleemid tekivad, kui valiku alusel tuleb teha mingisuguseid toiminguid või otsuseid.
Anomaalia parandamiseks saab kirjutamise blokeeringu peale panna, kuid see kahjustab tugevalt jõudlust. Oluliselt lihtsam on öelda, et tehingu tagasiviimiseks peab andmete algne olek (enne kirjutamise algust) olema süsteemis alati salvestatud. Miks mitte lugeda sealt? See on piisavalt odav, seetõttu enamik andmebaase eemaldab dirty read vaikimisi.
Lost update
Lost update tähendab kadunud uuendusi, ja tõlge kuvab probleemi olemuse üsna täpselt:
Tegelikult oli T2 tehingu tulemus tühistatud. Sellist olukorda saab lahendada selgete või varjatud kirje lukustustega. See tähendab, et me kas lihtsalt uuendame kirjet, mille puhul tekib varjatud lukustus, või me teeme select for update, põhjustades lugemis- ja kirjutamislukustuse tekkimist. Pange tähele, et selline toiming on piisavalt ohtlik: oma "nende süütute" lugemistega lukustame muid lugemisi. Mõned andmebaasid pakuvad turvalisemat select for share, mis võimaldab andmeid lugeda, kuid ei luba neid muuta.
Cursor lost update
Kitsama kontrolli jaoks võivad andmebaasid pakkuda ka muid tööriistu, näiteks kursoreid. Kursor on struktuur, mis sisaldab ridade kogumit ja võimaldab nende kaudu iteratiivset töötlemist. declare cursor_name for select_statement. Kursoris oleva sisu määratleb select.
Miks on kursori kasutamine vajalik? Asi on selles, et mõned andmebaasid pakuvad lukustamist kõigi valitud salvestuste jaoks (read stability) või ainult selle salvestuse jaoks, mille küljes kursori asub (cursor stability). Kursori stabiilsuse korral toimub lühike lukustus, mis vähendab lukustuste arvu, kui me itereerime suurte andmehulkade üle. Seetõttu käsitletakse kadunud uuenduse anomaaliat eraldi kursori jaoks.
Mitte korduv lugemine
Mitte korduv lugemine seisneb selles, et meie tehingu käigus toob kaks järjestikust sama salvestuse lugemist kaasa erinevate tulemuste saamise, kuna teine tehing sekkus nende kahe lugemise vahele, muutis meie andmeid ja tehti kinnitatuks.
Miks see probleem on? Kujutage ette, et tehingu T2 eesmärk on pildil valida kõik tooted, mille hind on madalam kui 150 ühikut. Keegi teine uuendas hinna 200 ühikuni. Seega ei toimi seatud filter.
Need anomaaliad lakkuvad esinemast kahefaasiliste lukustuste lisamise või MVCC mehhanismi kasutamise korral, millest sooviksin eraldi rääkida.
Vaimne lugemine
Fantoomlugemine viitab andmete lugemisele, mis on lisatud teise tehingu poolt.
Näiteks võib sel juhul täheldada odavaima toote vale valikut.
Fantoomlugemist on küllaltki keeruline kõrvaldada. Tavaline lukustus ei ole piisav, kuna me ei saa lukustada seda, mida veel ei ole. 2PL-süsteemid kasutavad predikatiivset lukustamist, samas kui MVCC-süsteemid tühistavad tehingud, mis võivad olla rikutud sisestamise tõttu. Mõlemad mehhanismid on piisavalt rasked.
Read skew
Read skew tekib, kui töötame mitme tabeliga, mille sisu peaks muutuma kooskõlastatult.
Oletame, et meil on tabelid, mis esindavad postitusi ja nende metaandmeid:
Üks tehing loeb tabelitest, teine muudab neid:
Tehingu T1 teostamisel on postil title = Good ja updated_by = T2, mis on teatud vastuolu.
Tegelikult on see non-repeatable read, kuid mitme tabeli osana.
T1 võib lukustada kõik read, mida ta loeb, mis takistab T2-l teavet muuta. MVCC puhul tühistatakse T2 tehing. Selle anomaalia kaitse võib osutuda oluliseks, kui kasutame kursorit.
Write skew
Seda anomaaliat on samuti lihtsam selgitada näite kaudu: oletame, et meie süsteemis peab üks arst olema vahetuses, kuid mõlemad arstid otsustasid oma vahetuse tühistada:
Anomaalia viib selleni, et ükski arst ei tule vahetusse. Kuidas see juhtus? Sest tehing kontrollis tingimust, mida võis rikkuda teine tehing, ja isolatsiooni tõttu ei saanud me seda muudatust näha.
See on sama, mis non-repeatable read. Alternatiivina võivad select'id need kirjed lukustada.
Write skew ja read skew on eelnevate anomaaliate kombinatsioonid. Võime arutada write skew'd, mis on põhimõtteliselt phantom read. Vaatame tabelit, kus on töötajate nimed, nende palgad ja projekt, millega nad töötavad:
Kokkuvõttes saame sellise pildi: iga juht arvas, et tema muudatus ei viiks eelarvest üle, seega tegid nad personali muudatusi, mis kokkuvõttes viisid ületamisse.
Probleemi tekkimise põhjus on täpselt sama nagu vaimse lugemise korral.
Järeldused
Tehingute isolatsioonitaseme nõrgendamine andmebaasis on kompromiss turvalisuse ja jõudluse vahel; sellele tasemele tuleks läheneda, lähtudes äri võimalike riskide hindamisest, mis võivad tekkida erinevate anomaaliate korral.
Allikas: habr.com
