Hoi allegearre. Vladislav Rodin is yn kontakt. Ik bin op it stuit de kursuslieder foar de kursus High Workload Architect by OTUS en lear ek kursussen foar softwarearsjitektuer.
Neist it lesjaan, lykas jo miskien hawwe opfallen, skriuw ik orizjineel materiaal foar it OTUS-blog op Habré en wol ik gearfalle mei it artikel fan hjoed om gear te fallen mei de lansearring fan 'e kursus , dy't op it stuit iepen is foar ynskriuwing.
Ynlieding
В wy prate oer it feit dat transaksjes yn databases tsjinje om twa problemen op te lossen: it garandearjen fan skuldtolerânsje en tagong ta gegevens yn in kompetitive omjouwing. Om dizze taken folslein út te fieren, moat de transaksje ACID-eigenskippen hawwe. Hjoed sille wy prate yn detail oer de brief I (isolaasje) yn dizze ôfkoarting.
Isolaasje
Isolaasje lost it probleem op fan tagong ta gegevens yn in kompetitive omjouwing, en biedt yn essinsje beskerming tsjin racebetingsten. Ideaal betsjut isolaasje serialisaasje, dat is in eigenskip dat soarget dat it resultaat fan it útfieren fan transaksjes parallel is itselde as as se sequentially útfierd waarden. It wichtichste probleem mei dit pân is dat it heul lestich is om technysk te leverjen en hat as gefolch in wichtige ynfloed op systeemprestaasjes. Dêrom wurdt isolemint faak ferswakke, akseptearje de risiko's fan bepaalde anomalies, dy't hjirûnder besprutsen wurde. De mooglikheid dat bepaalde anomalies foarkomme, karakterisearret krekt it nivo fan transaksje-isolaasje.
De bekendste anomalies binne: smoarch lêzen, net-herhaalber lêzen, fantomlêzen, mar yn feite binne d'r 5 mear: smoarch skriuwen, rinnerke ferlern bywurking, ferlear fernijing, lêzen skew, skriuw skew.
Smoarge skriuwe
De essinsje fan 'e anomaly is dat transaksjes ûnbeheinde gegevens kinne oerskriuwe.
Dizze anomaly is gefaarlik net allinich om't gegevens konflikt kinne nei it begean fan beide transaksjes (lykas yn 'e ôfbylding), mar ek om't atomiteit is skeind: om't wy tastean dat net-ferplichte gegevens wurde oerskreaun, is it net dúdlik hoe't jo ien transaksje weromdraaie sûnder in oare te beynfloedzjen .
De anomaly kin frij ienfâldich behannele wurde: wy hechtsje in slûs oan it rekôr foar foardat de opname begjint, en ferbiedt oare transaksjes it rekord te feroarjen oant it slûs fuorthelle is.
Smoarge lêzen
Smoarge lêzen betsjut it lêzen fan net-ferplichte gegevens.
Problemen ûntsteane as aksjes of besluten moatte wurde makke op basis fan it stekproef.
Om de anomaly te korrigearjen, kinne jo in lêsslot taheakje, mar dit sil in protte ynfloed hawwe op prestaasjes. It is folle ienfâldiger om te sizzen dat foar it weromdraaien fan in transaksje de earste steat fan 'e gegevens (foar it begjin fan opname) yn it systeem bewarre wurde moat. Wêrom net lêze fan dêr? It is goedkeap genôch dat de measte databases standert smoarch lêzen ferwiderje.
Ferlern update
Ferlern fernijing betsjut ferlerne updates, en de oersetting wjerspegelet de essinsje fan it probleem frij sekuer:
Yn feite waard it resultaat fan transaksje T2 omkeard. Dizze situaasje kin korrizjearre wurde troch eksplisite of ymplisite skriuwsloten. Dat is, wy óf gewoan bywurkje it rekord, en dan komt in ymplisite slot, of wy fiere selektearje foar update, wêrtroch in lês- en skriuwslot optreedt. Tink derom dat sa'n operaasje frij gefaarlik is: mei ús "ûnskuldige" lêzing blokkearje wy oare lêzingen. Guon databases biede feiliger selektearje foar dielen, wêrtroch gegevens lêzen wurde kinne, mar net wizige wurde.
Cursor ferlern update
Foar fynere kontrôle kinne bases oare ark oanbiede, lykas in rinnerke. In rinnerke is in struktuer dy't in set fan rigen befettet en lit jo iterearje oer har. ferklearje cursor_name foar select_statement. De ynhâld fan it rinnerke wurdt beskreaun troch selektearje.
Wêrom hawwe jo in rinnerke nedich? It feit is dat guon databases biede in slot op alle records selektearre troch selektearje (lêsstabiliteit), of allinnich op it rekord dêr't de rinnerke op it stuit leit (cursor stabiliteit). Mei rinnerke stabiliteit wurdt koart slot ymplemintearre, dat kinne wy ferminderje it oantal slûzen as wy iterearje oer in grutte stekproef fan gegevens. Dêrom wurdt de ferlerne update-anomaly apart isolearre foar de rinnerke.
Net-repeatable lêzen
Net-repeatable lêzing is dat by de útfiering fan ús transaksje, 2 opienfolgjende lêzings fan deselde record sil liede ta ferskillende resultaten, omdat in oare transaksje tusken dizze twa lêzen, feroare ús gegevens en waard ynset.
Wêrom is dit sels in probleem? Stel jo foar dat it doel fan transaksje T2 yn 'e foto is om alle guod te selektearjen wêrfan de priis minder is as 150 USD. Immen oars bywurke de priis nei $200. Sa, it ynstallearre filter wurke net.
Dizze anomalies stopje te foarkommen as twa-faze interlocks wurde tafoege of as it MVCC-meganisme wurdt brûkt, wat ik graach apart besprekke wolle.
Fantom lêzen
Phantom is in lêzing fan gegevens dy't waarden tafoege troch in oare transaksje.
As foarbyld kinne wy de ferkearde seleksje fan it goedkeapste produkt observearje as dizze anomaly foarkomt.
Fantoomlêzen kwytreitsje is al frij lestich. Regelmjittich blokkearjen is net genôch, om't wy eat net blokkearje kinne dat noch net bestiet. 2PL-systemen brûke foarsizzend slot, wylst MVCC-systemen in transaksjeplanner hawwe dy't transaksjes weromdraait dy't miskien wurde fersteurd troch in ynfoegje. Sawol de earste en twadde meganismen binne frij swier.
Lês skeef
Lêzen skew komt foar as wy wurkje mei ferskate tabellen, wêrfan de ynhâld konsekwint feroarje moat.
Litte wy sizze dat wy tabellen hawwe dy't berjochten en har meta-ynformaasje fertsjintwurdigje:
Ien transaksje lêst fan 'e tabellen, de oare feroaret se:
As gefolch fan transaksje T1 hat de post titel = Goed, en updated_by = T2, wat in soarte fan inkonsistinsje is.
Yn feite is dit in net-repeatable lêzen, mar as ûnderdiel fan ferskate tabellen.
Om dit te reparearjen, kin T1 slûzen sette op alle rigen dy't it sil lêze, wat sil foarkomme dat transaksje T2 de ynformaasje feroaret. Yn gefal fan MVCC sil de T2-transaksje wurde annulearre. Beskerming tsjin dizze anomaly kin wichtich wurde as wy rinnerkes brûke.
Skriuw skeef
Dizze anomaly is ek makliker te ferklearjen mei in foarbyld: stel dat yn ús systeem op syn minst ien dokter op plicht moat wêze, mar beide dokters besleaten har plicht te annulearjen:
De anomaly betsjutte dat gjin fan 'e dokters yn tsjinst soe wêze. Wêrom barde dit? Om't de transaksje in betingst kontrolearre dy't koe wurde skeind troch in oare transaksje, en fanwegen isolemint hawwe wy dizze feroaring net sjoen.
Dit is deselde net-herhaalbere lêzing. As alternatyf kinne selekteare slûzen pleatse op dizze records.
Skriuw skew en lês skew binne kombinaasjes fan 'e eardere anomalies. Jo kinne skriuwe skew beskôgje, wat yn wêzen in fantomlêzing is. Beskôgje in tabel dy't de nammen fan meiwurkers, har salarissen, en it projekt dêr't se wurkje oan:
As gefolch krije wy it folgjende byld: elke manager tocht dat har feroaring net liede soe ta it oergean fan budzjet, sadat se personielsferoarings makken dy't mei-inoar liede ta kostenoerienkomsten.
De oarsaak fan it probleem is krekt itselde as yn fantomlêzing.
befinings
It ûntspannen fan it transaksje-isolaasjenivo yn 'e database is in ôfwikseling tusken feiligens en prestaasjes; de kar fan dit nivo moat benadere wurde op basis fan 'e potinsjele risiko's foar it bedriuw as bepaalde anomalies foarkomme.
Boarne: www.habr.com