Millele võib viia tehingute eraldusvõime nõrgendamine andmebaasides

Tere kõigile. Siin on Vladislav Rodin. Praegu olen ma kursuse "Suure koormuse arhitekt" juht OTUSes, samuti õpetan tarkvaraarhitektuuri kursustel.

Lisaks õpetamisele, nagu olete võib-olla märganud, kirjutan ma OTUSi blogisse autorimaterjali ja täna tahan ma artikli pühendada kursuse käivitamisele «PostgreSQL», millele on praegu avatud registreerimine.

Sissejuhatus

Uues eelmine kord Me oleme rääkinud sellest, et andmebaasides toimuvad tehingud lahendavad kahte ülesannet: tagavad talitlushäirete talumise ja andmete ligipääsu konkurentsikeskkonnas. Et neid ülesandeid täita, peab tehing omama ACID omadusi. Täna räägime me põhjalikult tähest I (isolatsioon) selles akronüümis.

Isolatsioon

Isolatsioon lahendab probleemi andmete ligipääsust konkurentsikeskkonnas, pakkudes tegelikult kaitset race condition'ide eest. Ideaalis tähendab isolatsioon serialiseerimist, ehkki omadust, mis tagab, et tehingute samaaegne täitmine on sama, nagu kui need täidetaks järjestikku. Peamine probleem selle omaduse juures on see, et seda on väga keeruline tehniliselt tagada ja seetõttu mõjutab see tugevalt süsteemi jõudlust. Seepärast nõrgestatakse isolatsiooni sageli, võttes riske teatud anomaaliate tekkeks, millest allpool räägime. Teatud anomaaliate tekkimise võimalus iseloomustabki tehingute isolatsiooni taset.

Kõigist tuntumatest anomaaliatest on: dirty read, non-repeatable read, phantom read, kuid tegelikult on neid veel 5: dirty write, cursor lost update, lost update, read skew, write skew.

Dirty write

Anomaalia olemus seisneb selles, et tehingud võivad kirjutada kinnitamata andmeid üle.

See anomaalia on ohtlik mitte ainult selle poolest, et andmed võivad pärast mõlema tehingu kinnitamist konflikti sattuda (nagu pildil), vaid ka seetõttu, et rikutakse aatomilisust: kuna me lubame kinnitamata andmete ümberkirjutamise, siis ei ole selge, kuidas tagada ühe tehingu tagasivõtmine, rikkumata samal ajal teist.

Anomaalia lahendamine on üsna lihtne: paneme kirjutamisele lukustuse enne kirjutamise alustamist, keelates teistel tehingutel ülesande muutmise, kuni lukustust ei eemaldata.

Dirty read

Dirty read tähendab kinnitamata andmete lugemist.

Probleemid tekivad siis, kui valimi põhjal tuleb teha toiminguid või otsuseid.

Anomaalia parandamiseks saab lukustada lugemise, kuid see mõjutab oluliselt jõudlust. Palju lihtsam on öelda, et tehingu tagasiviimiseks (rollback) peab algne andmeolek (enne kirjutamist) olema süsteemis salvestatud. Miks mitte lugeda sealt? See on piisavalt odav, seega enamiku andmebaaside vaike seadistuses on dirty read lihtsalt eemaldatud.

Kadunud värskendus

Kadunud värskendus tähistab kadunud värskendusi ja see tõlge peegeldab probleemi olemust üsna täpselt:

Tegelikult tühistati tehingu T2 tulemus. Selline olukord lahendatakse selgete või mitte-selgete kirjalukudega. See tähendab, et kas me lihtsalt uuendame kirjet, ja siis tekib mitte-selge lukutus, või sooritame select for update, põhjustades lugemise ja kirjutamise lukustamise loomist. Pange tähele, et selline operatsioon on piisavalt ohtlik: oma "kahjutuga" lugemisega lukustame me teised lugemised. Mõned andmebaasid pakuvad turvalisemat select for share, mis võimaldab andmeid lugeda, kuid ei luba neid muuta.

Kursori kadunud värskendus

Täpsema kontrolli jaoks võivad andmebaasid pakkuda muid tööriistu, näiteks kursoreid. Kursor on struktuur, mis sisaldab ridade kogumit ja võimaldab neist iteratsiooni. declare cursor_name for select_statement. Kursorirealiskivid on kirjeldatud selectiga.

Miks on kursor vajalik? Asi on selles, et mõned andmebaasid pakuvad lukustamist kõikidele ridadele, mis on valitud selectiga (read stability), või ainult sellele real, kus kursor asub (cursor stability). Kursoristabiilsuse korral toimub lühiajaline lukustus, mis aitab vähendada lukustuste arvu, kui me iteratsiooni teeme suure valiku andmetega. Seetõttu tuuakse kadunud värskendus probleemi jaokskursori puhul esile eraldi.

Mitte-korduvalt loetud

Mitte-korduv lugemine seisneb selles, et meie tehingu käivitamise ajal toob kahe järjestikuse sama kirje lugemine kaasa erinevaid tulemusi, kuna teine tehing sekkus nende kahe lugemise vahel, muutis meie andmeid ja tehti kinnitatud.

Miks see üldse probleem on? Kujutage ette, et transaktsiooni T2 eesmärk on valida kõik tooted, mille hind on madalam kui 150 eurot. Keegi teine muutis hinna 200 euro peale. Nii et kehtestatud filter ei tööta.

Need anomaaliad lakkavad esinemast, kui lisatakse kahefasaalsed lukud või kasutatakse MVCC mehhanismi, millest sooviksin eraldi rääkida.

Fantoomlugemine

Fantoomlugemine on andmete lugemine, mis on lisatud teise transaktsiooni poolt.

Näiteks võib täheldada vale kõige odavama toote valikut, kui see aken esineb.

Fantoomlugemistest vabanemine on juba piisavalt keeruline. Tavaline lukustus ei ole piisav, kuna ei saa lukustada seda, mida veel ei ole. 2PL-süsteemid kasutavad predikatiivset lukustamist, samas kui MVCC-süsteemides tühistab tehingute planeerija need transaktsioonid, mida võib rikkuda lisamine. Mõlemad mehhanismid on piisavalt suured.

Lugemissegu

Lugemissegu tekib, kui töötame mitme tabeliga, mille sisu peab muutuma järjepidevalt.

Oletame, et meil on tabelid, mis esindavad postitusi ja nende metaandmeid:

Üks transaktsioon loeb tabelitest, teine muudab neid:

Transaktsiooni T1 täitmise tulemuseks on, et postituse pealkiri on Good ja updated_by = T2, mis on mingisugune vastuolu.

Tegelikult on see non-repeatable read, kuid mitme tabeli osas.

Korrekteerimiseks võib T1 panna lukud kõikidele ridadele, mida ta kavatseb lugeda, mis ei lase transaktsioonil T2 teavet muuta. MVCC puhul tühistatakse transaktsioon T2. Selle anomaalia kaitsmine võib muutuda oluliseks, kui kasutame kursorit.

Kirjutamissegu

Seda anomaaliat on lihtsam seletada näite kaudu: oletame, et meie süsteemis peab vähemalt üks arst olema valves, kuid mõlemad arstid otsustasid oma valve ära jätta:

Anomaalia viis selleni, et mitte ükski arst ei tule valvele. Miks see juhtus? Kuna transaktsioon kontrollis tingimust, mida võis rikuda teine transaktsioon, ja eraldatuse tõttu me seda muudatust ei näinud.

See on sama non-repeatable read. Alternatiivina võivad select'id panna lukud nendele kirjadele.

Write skew ja read skew on eelnevaid anomaaliaid kombineerivad nähtused. Võime vaadata write skew'i, mis on sisuliselt phantom read. Vaatame tabelit, kus on töötajate nimed, nende palgad ja projekt, millega nad tegelevad:

Lõppkokkuvõttes saame järgmise pildi: iga juht arvas, et tema muudatus ei vii eelarvest kõrvale, seega tegid nad kadude muudatused, mis kokku viisid ülelaekumisele.

Probleemi teke on täpselt sama, mis phantom read'i puhul.

Järeldused

Andmebaasi tehingute isoleerimise taseme nõrgenemine on kompromiss ohutuse ja jõudluse vahel; selle taseme valimisel tuleb arvestada ettevõtte potentsiaalsete riskidega, mis tekivad teatud anomaaliate korral.

Tutvu kursusega lähemalt.

Allikas: habr.com