Përshëndetje të gjithëve. Këtu është Vladislav Rodin. Aktualisht, unë jam drejtuesi i kursit 'Arkitekt i ngarkesave të larta' në OTUS, si dhe zhvilloj kurse mbi arkitekturën e softuerit.
Përveç mësimdhënies, siç mund ta keni vënë re, unë merrem edhe me shkrimin e materialeve origjinale për blogun e OTUS në Habr dhe sot do të përkushtoj këtë artikull për hapjen e kursit , për të cilin po hapet regjistrimi në këtë moment.
Hyrje
Në ne biseduam për atë se si transaksionet në bazat e të dhënave shërbejnë për të zgjidhur dy detyra: sigurimin e disponueshmërisë dhe qasjen në të dhëna në një mjedis konkurrues. Për të përmbushur plotësisht këto detyra, transaksioni duhet të ketë pronat ACID. Sot do të flasim në detaje për shkronjën I (izolimi) në këtë akronim.
Izolimi
Izolimi zgjidh problemin e aksesit në të dhëna në një mjedis konkurrues, duke ofruar në fakt mbrojtje nga race condition. Në mënyrë ideale, izolimi do të thotë serializim, domethënë një pronë që garanton se rezultati i ekzekutimit të transaksioneve paralel është i njëjtë si nëse do ishin ekzekutuar njëra pas tjetrës. Problemi kryesor me këtë pronë është se është shumë e vështirë për tu siguruar teknikisht dhe si pasojë ndikon rëndë në performancën e sistemit. Pikërisht për këtë arsye, izolimi shpesh dobësohet, duke pranuar riskun e ndodhjes së disa anomalisht, për të cilat do të flasim më poshtë. Mundësia e ndodhjes së anomali të caktuara karakterizon nivelin e izolimit të transaksioneve.
Anomalitë më të njohura janë: dirty read, non-repeatable read, phantom read, por në të vërtetë ka edhe 5 të tjera: dirty write, cursor lost update, lost update, read skew, write skew.
Dirty write
Thelbi i anomalisë është se transaksionet mund të ridhani të dhëna të paprafruara.
Ky anomali është e rrezikshme jo vetëm sepse të dhënat mund të konflikti pas komitimit të të dyja transaksioneve (siç është në figurë), por edhe sepse dëmton atomikën: pasi ne do të lejojmë që të dhënat e pa komituara të shkruhen përsëri, nuk është e qartë se si të rikthejmë një transaksion pa prekur të tjerët.
Anomalia shpëtohet mjaft lehtë: vendosim një bllokim për shkrimin para fillimit të shkrimit, duke ndaluar transaksionet e tjera të ndryshojnë regjistrimin derisa bllokimi të hiqet.
Leximi i ndyrë
Leximi i ndyrë do të thotë lexim i të dhënave të pa komituara.
Problemet lindin kur bazuar në një mostër duhet të bëhen disa veprime ose të merren vendime.
Për të korrigjuar anomalinë, mund të vendosim një bllokim për leximin, por kjo do të ndikojë shumë në performancë. Më e thjeshtë është të themi se për rikthimin e një transaksioni, gjendja fillestare e të dhënave (para fillimit të shkrimit) duhet patjetër të ruhet në sistem. Pse të mos lexojmë nga aty? Kjo është mjaft e përballueshme, prandaj shumica e bazave të të dhënave e heqin leximin e ndyrë si standart.
Përditësimi i humbur
Përditësimi i humbur do të thotë përditësime të humbura, dhe përkthimi e shpreh mjaft saktësisht thelbin e problemit:
Në fakt, rezultati i transaksionit T2 u anulua. Kjo situatë zgjidhet me bllokime të qarta ose të paarritshme të regjistrimeve. Pra, ne ose thjesht realizojmë një përditësim të regjistrimit, dhe atëherë ndodh një bllokim i paarritshëm, ose ne ekzekutojmë select for update, duke shkaktuar një bllokim për lexim dhe shkrim. Vini re se një operacion i tillë është mjaft i rrezikshëm: me leximin tonë "të pafajshëm", bllokojmë lexime të tjera. Disa baza ofrojnë një select for share, i cili lejon leximin e të dhënave, por nuk lejon ndryshimin e tyre.
Cursor lost update
Për një kontroll më të hollë, bazat mund të ofrojnë mjete të tjera, për shembull, kursori. Kursori është një strukturë që përmban një grup rreshtash dhe lejon iterimin mbi ta. declare cursor_name for select_statement. Përmbajtja e kursori përshkruhet me një select.
Pse na nevojitet kursori? ĂĂ«shtja Ă«shtĂ« se disa baza tĂ« dhĂ«nash ofrojnĂ« bllokim pĂ«r tĂ« gjitha regjistrimet qĂ« zgjidhen me select (stabiliteti i leximit), ose vetĂ«m pĂ«r atĂ« regjistrim, mbi tĂ« cilin ndodhet aktualisht kursori (stabiliteti i kursorit). Me stabilitetin e kursorit, kryhet njĂ« bllokim i shkurtĂ«r, qĂ« ndihmon nĂ« zvogĂ«limin e numrit tĂ« bllokimeve kur iteron mbi njĂ« mostĂ«r tĂ« madhe tĂ« dhĂ«nash. KĂ«shtu, anomalia e humbjes sĂ« azhurnimit shfaqet veçmas pĂ«r kursorin.
Leximi jo-repetues
Leximi jo-repetues përfshin faktin se gjatë ekzekutimit të transaksionit tonë, 2 lexime të njëjtës regjistrim do të çonin në rezultate të ndryshme, sepse një transaksion tjetër ndërhyri mes këtyre dy leximeve, ndryshoi të dhënat tona dhe u komitet.
Pse është kjo në të vërtetë një problem? Imagjinoni se qëllimi i transaksionit T2 në imazh është të zgjedhë të gjitha produktet që kanë çmimin më të vogël se 150 u.e. Disa tjetër e përditësoi çmimin në 200 u.e. Kështu, filtri i vendosur nuk funksionoi.
Anomalitë e të dhënave pushojnë së ndodhur me shtimin e bllokimeve me dy faza ose me përdorimin e mekanizmit MVCC, për të cilin do të doja të flisja veçmas.
Leximi fantazmë
Lexohet si lexim i të dhënave që janë shtuar nga një transaksion tjetër.
Si një shembull, mund të vëzhgohet zgjedhja e gabuar e produktit më të lirë në rastin e kësaj anomalie.
Të heqësh dorë nga leximet fantazmë është mjaft e vështirë. Një bllokim i zakonshëm nuk është i mjaftueshëm, pasi nuk mund të bllokojmë atë që ende nuk ekziston. Sistemet 2PL përdorin bllokimin predikativ, ndërsa sistemet MVCC përdorin planifikuesin e transaksioneve që anulojnë transaksionet që mund të cenohej nga një insertim. Të dy mekanizmat janë mjaft të rëndë.
Leximi i kthyer
Leximi i kthyer ndodh kur punojmë me disa tabela, përmbajtja e të cilave duhet të ndryshojë në mënyrë koherente.
Supozoni se kemi tabela që përfaqësojnë postime dhe metainformacionin e tyre:
Një transaksion lexon nga tabelat, ndërsa tjetra i ndryshon ato:
Si rezultat i ekzekutimit të transaksionit T1, në postimin me titull = Good, dhe updated_by = T2, që përbën një disfunksion.
Në fakt, këtë e quajmë lexim të pa përsëritur, por brenda disa tabelave.
Për të korrigjuar, T1 mund të vendosë bllokime mbi të gjitha rreshtat që do të lexojë, që nuk do t'i lejojë transaksionit T2 të ndryshojë informacionin. Në rastin e MVCC, transaksioni T2 do të anulohet. Mbrojtja ndaj kësaj anomalie mund të bëhet e rëndësishme nëse përdorim kursorët.
Write skew
Këtë anomali është më e lehtë ta shpjegojmë me një shembull: le të supozojmë se në sistemin tonë të paktën një mjek duhet të jetë në shërbim, por të dy mjekët e vendosën ta anulojnë shërbimin e tyre:
Anomalia çoi në faktin që asnjë nga mjekët nuk do të dilte në shërbim. Pse ndodhi kështu? Sepse transaksioni kontrolloi një kusht që mund të ishte shkelur nga një transaksion tjetër, dhe për shkak të izolimit ne nuk pamë këtë ndryshim.
Kjo është e njëjta leximi jo-përsëritës. Si një opsion, select-të mund të vendosin bllokime mbi këto regjistrime.
Write skew dhe read skew janë kombinime të anomali të mëparshme. Mund të shqyrtojmë write skew, i cili është në thelb një lexim fantazmë. Le të shqyrtojmë një tabelë që ka emrat e punonjësve, pagat e tyre dhe projektin në të cilin po punojnë:
Si përfundim, ne marrim këtë pamje: çdo menaxher mendonte se ndryshimi i tij nuk do të çonte në tepricë të buxhetit, prandaj ata bënë ndryshime që në total rezultuan në një tejkaluar të buxhetit.
Arsyeja e shfaqjes së problemit është e njëjtë si te leximet fantazmë.
PĂ«rfundimet
Zbutja e nivelit të izolimit të transaksioneve në bazën e të dhënave është një kompromis midis sigurisë dhe performancës, dhe zgjedhja e këtij niveli duhet të bazohet në rreziqet potenciale për biznesin në rast të ndodhjes së anomali të caktuara.
Burimi: habr.com
