Shkëputja e prezantimit të vitit 2020 nga Bruce Momjian "Zhbllokimi i Menaxherit të Bllokimeve Postgres".
(Vërejtje: Të gjitha SQL kërkesat nga diapozitivët mund t'i merrni në këtë lidhje: )
Përshëndetje! Është e shkëlqyer të jem përsëri këtu në Rusi. Më vjen keq që nuk arrita të vij vitin e kaluar, por këtë vit Ivan dhe unë kemi plane të mëdha. Shpresoj të jem këtu shumë më shpesh. E adhuroj të vij në Rusi. Do të vizitoj Tyumen dhe Tver. Jam shumë i lumtur që do të kem mundësinë të vizitoj këto qytete.
Quhem Bruce Momjian. Punoj në EnterpriseDB dhe kam punuar me Postgres për më shumë se 23 vjet. Banoj në Filadelfia, SHBA. Udhëtoj rreth 90 ditë në vit dhe vizitoj rreth 40 konferenca. Websajti im , i cili përmban diapozitivët që do t'ju tregoj tani. Kështu që pas konferencës mund t'i shkarkoni ato nga faqja ime personale. Atje gjithashtu ka rreth 30 prezantime. Ka gjithashtu video dhe shumë artikuj në blog, mbi 500. Ky është një burim mjaft informativ. Dhe nëse jeni të interesuar për këtë material, ju ftoj ta shfrytëzoni atë.
Dikur kam qenë mësues, profesor para se të filloja të punoja me Postgres. Dhe jam shumë i lumtur që tani kam mundësinë të flas me ju mbi atë që do t'ju tregohem. Kjo është një nga prezantimet më interesante për mua. Dhe ky prezantim përmban 110 diapozitiva. Do të fillojmë të flasim nga gjërat më të thjeshta, dhe deri në fund prezantimi do të bëhet gjithnjë e më i komplikuar, duke arritur në nivele të mjaftueshme komplekse.
Kjo është një bisedë mjaft e pakëndshme. Bllokimi nuk është tema më e popullarizuar. Ne dëshirojmë që kjo të zhduket. Është si të shkojmë te dentisti.
- Bllokimi është një problem për shumë njerëz që punojnë me baza të dhënash dhe ku operojnë disa procese në të njëjtën kohë. Ata kanë nevojë për bllokime. Kështu që sot do t'ju jap disa njohuri themelore mbi bllokimin.
- Identifikuesit e transaksioneve. Kjo është një pjesë mjaft e mërzitshme e prezantimit, por është e nevojshme ta kuptoni.
- Më pas do të flasim për llojet e bllokimeve. Kjo është një pjesë mjaft mekanike.
- Dhe më pas do të japim disa shembuj të bllokimeve. Kjo do të jetë mjaft e vështirë për t'u kuptuar.
Le të flasim për bllokimet.
Terminologjia jonë është mjaft e ndërlikuar. Sa prej jush e dinë se nga vjen ky fragment? Dy njerëz. Është nga një lojë që quhet "Avantura Kolosale në Shpellë". Ishte një lojë kompjuterike me tekst nga vitet '80, mendoj. Duhej të hyje në një shpellë, në një labirint dhe teksti ndryshonte, por përmbajtja ishte afërsisht e njëjtë çdo herë. Kështu e mbaj mend këtë lojë.
Dhe këtu shohim emrat e bllokimeve që erdhën tek ne nga Oracle. Ne i përdorim ato.
Këtu shohim terma që më shqetësojnë. Për shembull, SHARE UPDATE ECXLUSIVE. Më pas SHARE RAW ECXLUSIVE. Sinqerisht, këto emra nuk janë shumë të qartë. Ne do të përpiqemi t’i shqyrtojmë ato më në detaje. Disa përmbajnë fjalën "share", që do të thotë – ndarje. Disa përmbajnë fjalën "exclusive" – ekskluziv. Në disa përmbajnë të dyja këto fjalë. Do doja të filloja me atë se si funksionojnë këto bllokime.
Dhe gjithashtu është shumë e rëndësishme fjala "akses" — access. Dhe fjalët "row" — rresht. Pra, shpërndarja e aksesit, shpërndarja e rreshtave.
Një problem tjetër që duhet të kuptohet në Postgres, fatkeqësisht nuk do të mund ta tregoj në prezantimin tim, është MVCC. Kam një prezantim të veçantë për këtë temë në faqen time të internetit. Dhe nëse mendoni se kjo prezantim është e komplikuar, atëherë MVCC është ndoshta më e komplikuara për mua. Dhe nëse jeni të interesuar, mund ta shihni atë në faqen e internetit. Mund të shihni videon.
Një tjetër pikë që na nevojitet të kuptojmë është identifikuesit e transaksionit. Shumë transaksione nuk mund të punojnë pa identifikues unikë. Këtu kemi një shpjegim se çfarë është një transaksion. Në Postgres ka dy sisteme numërimi për transaksionet. E di, kjo nuk është një zgjidhje shumë e bukur.
Gjithashtu mbani parasysh se shpërndarja do të jetë mjaft e komplikuar për t'u kuptuar, prandaj mbi atë që është theksuar me ngjyrë të kuqe, pikërisht mbi këtë duhet të kujdesemi.
Shikojmë. Me ngjyrë të kuqe është nxjerrë numri i transaksionit. Këtu shfaqet funksioni SELECT pg_back. Ai kthen transaksionin tim dhe ID-në e atij transaksioni.
Një pika tjetër është që, nëse ju pëlqen kjo prezantim dhe dëshironi ta shkarkoni në bazën tuaj të të dhënave, mund të kaloni në këtë lidhje të theksuar me ngjyrë rozë dhe të shkarkoni SQL për këtë prezantim. Mund ta ekzekutoni në PSQL tuaj dhe e gjithë prezantimi do të shfaqet menjëherë në ekranin tuaj. Nuk do të përmbajë ngjyra, por së paku do ta shohim.
Në këtë rast shohim ID-në e transaksionit. Ky është numri që i kemi caktuar. Ka edhe një lloj tjetër ID transaksioni në Postgres, i quajtur ID virtual e transaksionit.
Dhe ne duhet ta kuptojmë këtë. Është shumë e rëndësishme, ndryshe nuk do të mund ta kuptojmë bllokimin në Postgres.
ID virtual e transaksionit është ID e një transaksioni që nuk përmban vlera të përhershme. Për shembull, nëse unë ekzekutoj komandën SELECT, do të ishte e mundur që të mos ndërroj bazën e të dhënave, nuk do të bllokoja asgjë. Prandaj, kur ekzekutojmë një SELECT të thjeshtë, nuk i japim kësaj transaksioni një ID të përhershme. Atij i japim vetëm një ID virtual.
Dhe kjo rrit performancën e Postgres, përmirëson mundësitë për pastrim, prandaj ID virtual i transaksionit përbëhet nga dy numra. Numri i parë para shkronjës është ID i backend-it. Ndërsa në të djathtë shohim thjesht një numër.
Prandaj, nëse ekzekutoj një kërkesë, ai thotë se ID i backend-it është 2.
Dhe nëse unë ekzekutoj një seri transaksionesh të tilla, shohim se numri rritet çdo herë, kur ekzekutoj kërkesën. Për shembull, kur ekzekutoj kërkesën 2/10, 2/11, 2/12 etj.
Mbani parasysh se këtu janë dy kolona. Në të majtë shohim ID-në virtuale të transaksionit – 2/12. Ndërsa në të djathtë kemi ID të përhershëm të transaksionit. Dhe ky fushë është bosh. Dhe ky transaksion nuk modifikon bazën e të dhënave. Prandaj, nuk i caktova një ID të përhershëm transaksioni.
Sapo të ekzekutoj komandën analizë (ANALYZE), i njëjti kërkesë më jep një ID të përhershëm të transaksionit. Shikoni si ka ndryshuar kjo. Më parë nuk e kisha këtë ID, tani e kam.
Pra, këtu është një kërkesë tjetër, një transaksion tjetër. Numri virtual i transaksionit është 2/13. Dhe nëse kërkoj ID të përhershëm të transaksionit, atëherë, kur do të ekzekutoj kërkesën, do ta marr.
Pra, përsëri. Kemi ID virtual të transaksionit dhe ID të përhershëm të transaksionit. Thjesht kuptoni këtë pikë për të kuptuar sjelljen e Postgres.
Kemi duke kaluar në seksionin e tretë. Këtu do të kalojmë nëpër llojet e ndryshme të bllokimeve në Postgres. Nuk është shumë interesante. Seksioni i fundit do të jetë shumë më interesant. Por duhet të shqyrtojmë gjërat bazike, sepse përndryshe nuk do ta kuptojmë atë që do të vijë më pas.
Ne do të kalojmë nëpër këtë seksion, do të shohim çdo lloj bllokimi. Dhe do t'ju tregoj shembuj se si vendosen, si funksionojnë, do t'ju tregoj disa pyetje që mund të përdoren për të parë se si punon bllokimi në Postgres.
Për të krijuar një pyetje dhe për të parë se çfarë po ndodh në Postgres, na nevojitet të lëshojmë një pyetje në pamjen e sistemit. Në këtë rast, në ngjyrë të kuqe kemi theksuar pg_lock. Pg_lock është një tabelë sistemike që na tregon cilat bllokime përdoren aktualisht në Postgres.
Megjithatë, më është shumë e vështirë t'ju tregoj pg_lock vetë, sepse është mjaft e komplikuar. Pra, kam krijuar një pamje që tregon pg_locks. Dhe ajo gjithashtu kryen për mua disa punë që më lejojnë ta kuptoj më mirë. Kjo do të thotë, ajo përjashton bllokimet e mia, sesionin tim të vetë, etj. Kjo është thjesht SQL standard dhe më lejon të tregoj që është më e qartë për ju se çfarë ndodh.
Një problem tjetër është se kjo pamje është shumë e gjerë, prandaj më duhet të krijoj një të dytë – lockview2.
Dhe ajo më tregon edhe disa kolona nga tabela. Dhe një tjetër, që më tregon kolonat e tjera. Kjo është mjaft e komplikuar, prandaj kam përpjekur ta paraqes sa më thjeshtë të jetë e mundur.
Pra, ne krijuam një tabelë, e cila quhet Lockdemo. Dhe ne krijuam atje një rresht. Kjo është tabela jonë e modelit. Dhe do të krijojmë seksione për të treguar thjesht shembuj bllokimesh.
Pra, një rresht, një kolonë. Lloji i parë i bllokimit quhet ACCESS SHARE. Ky është bllokimi më pak restriktiv. Kjo do të thotë se praktikisht nuk përplaset me bllokimet e tjera.
Dhe nëse duam të përcaktojmë shprehimisht bllokimin, ne ekzekutojmë komandën «lock table». Ajo e bllokon qartë, pra, në mënyrën ACCESS SHARE ne ekzekutojmë lock table. Dhe nëse nis PSQL në sfond, atëherë nis kështu një sesion të dytë nga sesioni im i parë. Çfarë do të bëj këtu? Unë kaloj në një sesion tjetër dhe i them «më trego lockview për këtë kërkesë». Dhe këtu kam AccessShareLock në këtë tabelë. Kjo është siç e kërkova. Dhe ai thotë se bllokimi i është caktuar. Mjaft e thjeshtë.
Më pas, nëse shohim në kolonën e dytë, atje s’ka asgjë. Janë bosh.
Dhe nëse ekzekutoj komandën «SELECT», kjo është një mënyrë implicit (shprehëse) për të kërkuar AccessShareLock. Prandaj unë liroj tabelën time dhe ekzekutoj kërkesën, dhe kërkesa kthen disa rreshta. Dhe në një nga rreshtat shohim AccessShareLock. Pra, SELECT shkakton AccessShareLock në tabelë. Dhe ajo nuk krijon konflikte pothuajse me asgjë, sepse është një bllokim me nivel të ulët.
Çfarë ndodh nëse ekzekutoj SELECT dhe kam tri tabela të ndryshme? Më parë kam ekzekutuar vetëm një tabelë, tani po ekzekutoj tri: pg_class, pg_namespace dhe pg_attribute.
Dhe tani, kur shoh kërkesën, shoh 9 AccessShareLocks në tre tabela. Pse? Me ngjyrë blu janë theksuar tri tabelat: pg_attribute, pg_class, pg_namespace. Por gjithashtu mund të shihni se të gjitha indekset që janë caktuar përmes këtyre tabelave gjithashtu kanë AccessShareLock.
Dhe ky është një bllokim që pothuajse nuk krijon konflikte me të tjerët. Ajo që bën është thjesht të mos na lejojë të lirojmë tabelën derisa ta zgjedhim. Ka kuptim. Pra, nëse zgjedhim tabelën, ajo në atë moment humbet, kjo është e pasaktë, prandaj AccessShare është një bllokim me nivel të ulët që na thotë "mos e fshini këtë tabelë derisa unë të punoj".. Në thelb, kjo është gjithçka që bën.
ROW SHARE është një bllokim që paksa ndryshon.
Le të marrim një shembull. SELECT ROW SHARE është mënyra e bllokimit të çdo rreshti veç e veç.. Pra, askush nuk mund t'i fshijë apo i ndryshojë ato derisa ne t'i shikojmë.
Pra ndaj, çfarë bën SHARE LOCK? Ne shohim që ID e transaksionit 681 për SELECT. Dhe kjo është interesante. Çfarë ndodhi këtu? Herën e parë që shohim një numër në fushën "Lock". Ne e marrim ID-në e transaksionit dhe ajo thotë se e bllokon në mënyrë ekskluzive. Çfarëdo që ajo bën, ajo thotë se kam një rresht që teknikisht është bllokuar diku në tabelë. Por nuk thotë se ku saktësisht. Pak më vonë do të shqyrtojmë këtë më në detaje.
Këtu po flasim se bllokimi përdoret nga ne.
Pra, bllokimi ekskluziv e thotë qartë, që është ekskluziv. Po ashtu, nëse fshini një rresht në këtë tabelë, atëherë kjo do të ndodhë, siç mund ta shihni.
SHARE EXCLUSIVE – është një bllokim më i gjatë.
Kjo është (ANALYZE) komanda e analizuesit, e cila do të përdoret.
SHARE LOCK – ju mund ta bllokoni në mënyrë eksplicite në modin share.
Ju gjithashtu mund të krijoni një indeks unik. Dhe atje mund të shihni SHARE LOCK, i cili është pjesë e tyre. Dhe ai bllokon tabelën dhe vendos mbi të bllokimin SHARE LOCK.
Në parazgjedhje, SHARE LOCK në tabelë do të thotë se njerëzit e tjerë mund të lexojnë tabelën, por askush nuk mund ta modifikojë atë. Dhe kjo ndodh kur krijoni një indeks unik.
Nëse krijoj një indeks unik njëkohësisht, atëherë do të kem një lloj tjetër bllokimi, sepse, siç e mbani mend, përdorimi i indekseve njëkohësisht ul kërkesat për bllokim. Dhe nëse përdor një bllokim normal, indeksi normal, atëherë kështu do të parandaloj shkrimin në tabelën e indeksit gjatë krijimit të saj. Nëse përdor një indeks njëkohësisht, atëherë duhet të përdor një lloj tjetër bllokimi.
SHARE ROW EXCLUSIVE – përsëri mund të konstatohet eksplicit (qartë).
Ose mund të krijojmë një rregull, pra të marrim një rast të caktuar, kur do të përdoret.
Bllokimi EXCLUSIVE do të thotë që askush tjetër nuk do të mund ta modifikonte tabelën.
Këtu shohim lloje të ndryshme bllokimesh.
ACCESS EXCLUSIVE, për shembull, është një komandë bllokimi. Për shembull, nëse bëni CLUSTER table, atëherë do të thotë se askush nuk do të mund të shkruajë aty. Dhe ajo bllokon jo vetëm tabelën, por gjithashtu indekset.
Kjo është faqja e dytë e bllokimit ACCESS EXCLUSIVE, ku shohim saktësisht se çfarë bllokon në tabelë. Ajo bllokon rreshta të veçantë në tabelë, që është mjaft interesante.
Ky është gjithë informacioni bazë që doja të jepja. Folëm për bllokimet, për ID-të e transaksioneve, folëm për ID virtuale të transaksioneve, për ID të qëndrueshme të transaksioneve.
Dhe tani do të kalojmë në shembujt e bllokimeve. Kjo është pjesa më interesante. Do të shohim raste shumë interesante. Dhe detyra ime në këtë prezantim është t'ju ofroj një kuptim më të mirë të asaj që Postgres në të vërtetë bën kur përpiqet të bllokojë gjëra të caktuara. Më duket se ai e bën shumë mirë bllokimin e pjesëve të veçanta.
Le të shqyrtojmë disa shembuj të caktuar.
Do të fillojmë me tabelat dhe një rresht në tabelë. Kur të insertoj diçka, do të shoh një ExclusiveLock, ID-në e transaksionit dhe një ExclusiveLock në tabelë.
Por çfarë do të ndodhë nëse insertoj edhe dy rreshta të tjerë? Tani në tabelën tonë kemi tre rreshta. Dhe unë insertoj një rresht dhe kam këtë rezultat. Dhe nëse insertoj edhe dy rreshta, çfarë është e çuditshme këtu? Ka një çudi, sepse unë kam shtuar tre rreshta në këtë tabelë, por unë ende kam dy rreshta në bllokim. Dhe kjo, në thelb, është një sjellje themelore e Postgres.
Shumë mendojnë se nëse në databazë bllokoni 100 rreshta, do të nevojiten 100 hyrje bllokimi. Nëse unë bllokoj 1 000 rreshta menjëherë, atëherë do të më nevojiten 1 000 kërkesa të tilla. Dhe nëse kam nevojë të bllokoj një milion ose një miliard. Por nëse do ta bënim kështu, nuk do të funksiononte mirë. Nëse keni përdorur një sistem që krijon hyrje bllokimi për çdo rresht të veçantë, e shihni se është e komplikuar. Sepse duhet të parashikoni tabelën e bllokimit e cila mund të mbushet, por Postgres nuk e bën këtë.
Dhe në këtë slajd është shumë e rëndësishme që këtu demonstron qartë se ka një sistem tjetër që punon brenda MVCC, i cili bllokon rreshta të veçantë. Pra, kur bllokoni miliarda rreshta, Postgres nuk krijon miliard komanda të veçanta për bllokim. Dhe kjo ka një ndikim shumë pozitiv në performancën.
Çfarë ndodh me përditësimin? Po përditësoj disa rreshta tani, dhe mund ta vini re se ai menaxhoi të dy operacionet në të njëjtën kohë. Ai bllokoi tabelën, por gjithashtu bllokoi dhe indeksin. Duhej të bllokonte indeksin sepse ka kufizime unike në këtë tabelë. Dhe ne duam të sigurohemi që askush të mos e ndryshojë, prandaj e bllokojmë atë.
Çfarë ndodh nëse dua të përditësoj dy rreshta? Dhe ne shohim se ai sillet po ashtu. Ne bëjmë dy herë më shumë përditësime, por saktësisht të njëjtin numër rreshtash të bllokuar.
Nëse jeni të interesuar si Postgres e bën këtë, duhet të dëgjoni fjalimet e mia për MVCC, për të kuptuar se si Postgres brenda tij i etiketon këta rreshta që ndryshon. Dhe Postgres ka një mënyrë se si e bën këtë, por nuk e bën në nivelin e bllokimit të tabelave, e bën në një nivel më të ulët dhe më efikas.
Por çfarë ndodh nëse dua të fshi një gjë? Nëse fshij, për shembull, një rresht dhe ende kam të dyja bllokimet e mia, dhe edhe nëse dëshiroj t'i fshij të gjitha, ato ende janë aty.
Dhe, për shembull, nëse dua të fus 1,000 rreshta, dhe pastaj të fshij ose të shtoj 1,000 rreshta, ato rreshta individualë që shtoj ose ndryshoj, nuk regjistrohen këtu. Ato regjistrohen në një nivel më të ulët brenda vetë rreshtit. Dhe gjatë fjalimit për MVCC, kam folur rreth kësaj në detaje. Por është shumë e rëndësishme që kur analizoni bllokimet, të siguroheni që keni një bllokim në nivelin e tabelës dhe që këtu nuk e shihni se si po regjistrohen rreshtat individualë.
Çfarë ndodh me bllokimin eksplicit?
Nëse klikoj "përditëso", atëherë kam dy rreshta të bllokuar. Dhe nëse i zgjedh të gjithë ata dhe klikoj "përditëso në të gjithë", prapë kam dy regjistra bllokimi.
Ne nuk krijojmë regjistra të veçantë për çdo rresht individual. Sepse atëherë performanca bie, mund të ketë shumë prej tyre. Dhe mund të gjendemi në një situatë të pakëndshme.
Po ashtu ndodh nëse bëjmë shared, mund të bëjmë për të gjithë 30 herë.
Ne rikonstruktojmë tabelën tonë, fshijmë gjithçka, pastaj sërish fusim një rresht.
Një tjetër lloj sjelljeje që shihni në Postgres është një sjellje shumë e njohur dhe e dëshiruar – është se mund të kryeni update ose select. Dhe mund ta bëni këtë njëkohësisht. Dhe select nuk bllokon update dhe e njëjta gjë ndodh në anën tjetër. Ne po themi që ai që lexon nuk bllokon atë që shkruan, dhe ai që shkruan, nuk bllokon lexuesin.
Do t'ju tregoj një shembull të kësaj. Po bëj tani një zgjedhje. Më pas do të bëjmë INSERT. Dhe do të mund të shihni – 694. Do të mund të shihni ID-në e transaksionit që bëri këtë insertim. Dhe kjo është se si funksionon.
Dhe nëse tani shikoj ID-në time në backend, ajo është bërë – 695.
Dhe mund të shoh se 695 shfaqet në tabelën time.
Dhe nëse bëj një përditësim këtu kështu, atëherë marr një rast tjetër. Në këtë rast 695 është bllokim ekskluziv, dhe përditësimi ka një sjellje të ngjashme, por midis tyre nuk ka konflikte, që është mjaft e çuditshme.
Dhe mund të vini re se në krye është ShareLock, ndërsa poshtë është ExclusiveLock. Dhe të dy transaksionet u realizuan.
Dhe duhet të dëgjoni fjalimin tim mbi MVCC, për të kuptuar se si ndodh kjo. Por kjo është një ilustrim se mund ta bëni këtë njëkohësisht, pra të bëni SELECT dhe UPDATE njëkohësisht.
Le të heqim dhe të bëjmë sërish një operacion.
Nëse provoni të ekzekutoni dy update njëkohësisht në të njëjtin rresht, atëherë do të bllokohet. Dhe kujtoni, thashë që lexuesi nuk bllokon atë që shkruan, dhe ai që shkruan bllokon lexuesin, por një shkruese bllokon një tjetër shkruese. Pra, nuk mund të bëjmë që dy persona të përditësojnë një rresht të njëjtë njëkohësisht. Duhet të presim derisa njëri prej tyre të përfundojë.
Dhe për ta ilustruar këtë, do të shikoj tabelën Lockdemo. Dhe do të shohim një rresht. Në transaksionin 698.
E kemi përditësuar deri në 2. 699 është përditësimi i parë. Dhe ka kaluar me sukses ose është në një transaksion në pritje dhe pret që të konfirmojmë ose të anulojmë.
Por shikoni diçka tjetër - 2/51 - kjo është transaksioni ynë i parë, sesioni ynë i parë. 3/112 - ky është kërkesa e dytë që doli nga lart dhe që e ndryshoi këtë vlerë në 3. Dhe nëse e vini re, e sipërmja e bllokoi veten, e cila është 699. Por 3/112 nuk ofroi bllokim. Në kolonën Lock_mode shkruhet se po pret. Ai po pret 699. Dhe nëse shikoni se ku është 699, është mbi. Dhe çfarë bëri sesioni i parë? Ai krijoi një bllokim ekskluziv mbi ID-në e tij të transaksionit. Kështu e bën Postgres. Ai bllokon ID-në e tij të transaksionit. Dhe nëse doni të prisni derisa dikush të konfirmojë ose të anulojë, duhet të prisni derisa të ketë një transaksion që pret. Dhe për këtë mund të shohim një rresht të çuditshëm.
Le të shohim përsëri. Nga e majta shohim ID-në tonë të procesimit. Në kolonën e dytë shohim ID-në tonë virtuale të transaksionit, dhe në të tretën shohim lock_type. Çfarë do të thotë kjo? Në thelb, ajo thotë se bllokon ID-në e transaksionit. Por vini re se në të gjitha rreshtat poshtë shkruhet relacion. Dhe për këtë keni dy lloje bllokimi në tabelë. Ka bllokim relacioni. Por gjithashtu ka bllokim transactionid, ku ne bllokojmë veten, kjo është ajo që ndodh në rreshtin e parë ose në fundin më të ulët, ku transactionid, ku presim që 699 të përfundojë operacionin e vet.
Unë shikoj se çfarë po ndodh këtu. Dhe këtu ndodhin në të njëjtën kohë dy gjëra. Ju shikoni bllokimin sipas ID-së së transaksionit në rreshtin e parë, i cili bllokon veten. Dhe ajo bllokon veten për të detyruar njerëzit të presin.
Nëse shikoni rreshtin e 6-të, është e njëjtë me të parën. Dhe për këtë arsye transaksioni 699 bllokohet. 700 gjithashtu vetëbllokohet. Dhe pastaj në rreshtin e poshtëm do të shihni se po presim kur 699 të përfundojë operacionin e tij.
Dhe në lock_type, tuple shihni numrat.
Ju mund të shikoni se është 0/10. Dhe kjo është numri i faqes, si dhe offset-i i këtij rreshti të veçantë.
Dhe ju shihni se bëhet 0/11, kur e përditësojmë.
Por në të vërtetë - është 0/10, sepse ndodh pritja e këtij operacioni. Ne kemi mundësinë të shohim se ky është rreshti që po pres për ta konfirmuar.
Sapo e konfirmuam dhe e shtypëm commit, dhe kur përfundoi përditësimi, ky është rezultati që marrim përsëri. Transaksioni 700 është bllokimi i vetëm, ai nuk pret më askënd, sepse është angazhuar. Ai thjesht pret që transaksioni të përfundojë. Sapo të përfundojë 699, nuk presim më asgjë. Dhe tani transaksioni 700 thotë se gjithçka është mirë, se të gjitha bllokimet që i nevojiten, i ka në të gjitha tabelat e lejuara.
Dhe për ta bërë akoma më të komplikuar, ne krijojmë një shikim tjetër, i cili këtë herë do t'i japë një hierarki. Nuk pres që ju ta kuptoni këtë kërkesë. Por kjo do t'i ofrojë një pamje më të qartë mbi atë që po ndodh.
Ky është një shikim rekursiv, i cili gjithashtu ka një seksion tjetër. Dhe pastaj kthen gjithçka përsëri së bashku. Le ta përdorim këtë.
Çfarë ndodh nëse bëjmë tre përditësime të njëkohshme dhe themi se rreshti tani është i barabartë me tre. Dhe ne e ndryshojmë 3 në 4.
Dhe ja ku shohim 4. Dhe ID e transaksionit 702.
Dhe pastaj e ndryshoj 4 në 5. E 5 në 6, e 6 në 7. Dhe unë radhitem njerëzit që do të presin që kjo një transaksion të përfundojë.
Dhe gjithçka bëhet e qartë. Cili është rreshti i parë? Ky është 702. Ky është ID e transaksionit që fillimisht vendosi këtë vlerë. Dhe çfarë kam shkruar në kolonën e Miratimeve? Kam shënimet f. Këto janë përditësimet e mia, që (5, 6, 7) nuk mund të miratohen, sepse po presim që ID e transaksionit 702 të përfundojë. Aty kemi një bllokim të ID e transaksionit. Dhe del 5 bllokime të ID e transaksionit.
Dhe nëse e shikoni 704, 705, atje nuk ka ende asgjë, sepse ata ende nuk e dinë se çfarë po ndodh. Thjesht shkruajnë se nuk kanë asnjë ide se çfarë po ndodh. Dhe ata gjithashtu do të bien në gjumë, sepse presin që dikush të përfundojë dhe t'i zgjojë kur të vijë mundësia për të ndryshuar rreshtin.
Kjo është si duket. E qartë është se të gjithë presin rreshtin 12.
Kjo është ajo që pamë këtu. Ja 0/12.
Pra, sapo transaksioni i parë miratohet, mund ta shihni këtu se si funksionon hierakia. Dhe tani gjithçka bëhet e qartë. Të gjitha bëhen të pastra. Dhe ata në të vërtetë janë ende në pritje.
Këtu është se çfarë po ndodh. 702 po angazhohet. Tani 703 merr këtë bllokim radhë, dhe pastaj 704 fillon të presë deri sa 703 të angazhohet. Dhe 705 gjithashtu po e pret këtë. Kur të gjitha këto përfundojnë, ato vetë pastruan. Dëshiroj të theksoj se të gjithë rreshtohen. Kjo është shumë e ngjashme me situatën me trafikun, kur të gjithë presin makinën e parë. Makinës e parë ndalon, dhe të gjithë rreshtohen në një linjë të gjatë. Pastaj ajo lëviz, dhe pastaj makina tjetër mund të kalojë përpara dhe të marrë bllokimin e saj, etj.
Dhe nëse ju duket se kjo nuk është mjaft e komplikuar, tani do të flasim për deadlocks. Nuk e di kush nga ju ka hasur në to. Kjo është një problem relativisht i zakonshëm në sistemet e bazës së të dhënave. Por deadlocks janë ai rast, kur një seancë po pret që diçka të përfundojë nga një seancë tjetër. Ndërkohë, seanca tjetër po pret për diçka nga seanca e parë.
Dhe, për shembull, nëse Ivan thotë: "Më jep diçka", dhe unë i them: "Jo, unë do t'ja jap vetëm nëse ti më jep diçka tjetër". Dhe ai thotë: "Jo, nuk do t'ja jap nëse ti nuk më jep". Dhe ne kemi një situatë deadlock. Jam i sigurt që Ivan nuk do ta bënte këtë, por ju kuptoni kuptimin, që kemi dy persona që duan të marrin diçka dhe nuk janë të gatshëm ta japin derisa personi tjetër t'ua japë atë që ata duan. Dhe këtu nuk ka zgjidhje.
Dhe, në esencë, baza juaj e të dhënave duhet ta identifikojë këtë. Dhe pastaj është e nevojshme të fshihet ose të mbyllet një nga seancat, sepse në të kundërt ato do të mbeten aty përgjithmonë. Dhe ne e shohim këtë në bazat e të dhënave, e shohim në sistemet operative. Dhe në të gjitha vendet ku kemi procese paralele, kjo mund të ndodhë.
Dhe tani do të vendosim dy deadlocks. Do të vendosim 50 dhe 80. Në rreshtin e parë do të kryej një përditësim nga 50 në 50. Do të kem numrin e transaksionit 710.
Dhe pastaj do ta ndërronj 80 me 81, dhe 50 me 51.
Dhe kështu do të duket. Dhe prandaj 710 ka një bllokim radhë, ndërsa 711 pret konfirmimin. E kemi parë këtë kur përditësuam. 710 është pronari i radhës sonë. Dhe 711 po pret që 710 të përfundojë transaksionin.
Dhe madje shkruhet se në cilin radhë ndodhin deadlocks. Dhe këtu fillon të bëhet e çuditshme.
Tani po e përditësojmë 80 në 80.
Dhe ja ku fillon deadlocks. 710 po pret përgjigje nga 711, ndërsa 711 po pret 710. Dhe kjo do të përfundojë keq. Nuk ka zgjidhje për këtë. Ata do të presin përgjigjen nga njëri-tjetri.
Dhe kjo do fillojë të ndalojë gjithçka. Dhe ne nuk e duam këtë.
Në Postgres, ka mënyra për të vërejtur kur ndodhin këto. Kur ndodhin, merrni këtë lëshim. Kjo tregon se një proces po pret SHARE LOCK nga një proces tjetër, dmth. që bllokohet nga procesi 711. Procesi tjetër priste që të jepet SHARE LOCK për një ID transaksioni të caktuar dhe ishte bllokuar nga një tjetër proces. Prandaj, kjo është një situatë deadlock.
A ndodhin deadlocks me tre palë? A është e mundur? Po.
Ne shkruajmë këto numra në tabelë. Ne e ndryshojmë 40 në 40, ne bëjmë bllokimin.
E ndryshojmë 60 në 61, 80 në 81.
Pastaj e ndryshojmë 80 dhe – bum!
Dhe 714 tani pret 715. 716-a pret 715-ën. Dhe këtu nuk ka asgjë për të bërë.
Këtu nuk janë dy persona, por tre persona. Unë dua diçka prej teje, ai dëshiron diçka nga personi e tretë, dhe personi i tretë dëshiron diçka nga unë. Dhe ne jemi në një pritje me tre palë, sepse të gjithë presim që tjetri të përfundojë atë që duhet të bëjë.
Dhe Postgres e di në cilin rresht ndodh kjo. Prandaj, ai do t'ju japë këtë mesazh, i cili tregon se keni një problem, ku tre hyrje bllokojnë njëra-tjetrën. Këtu nuk ka kufij. Kjo mund të ndodhë në një rast ku 20 regjistrime bllokojnë njëra-tjetrën.
Problemi tjetër është se është serializable.
Nëse ndodhi një bllokim special serializable.
Dhe kthehemi te 719. Ai ka një rezultat krejt normal.
Dhe ju mund të klikoni për të bërë një transaksion nga serializable.
Dhe ju kuptoni që tani keni një tjetër lloj bllokimi SA – kjo do të thotë serializable.
Prandaj, kemi një lloj të ri të bllokimit, i quajtur SARieadLock, i cili është një bllokim seri dhe lejon të hyjnë seritë.
Gjithashtu, mund të vendosni indekse unike.
Në këtë tabelë kemi indekse unike.
Prandaj, nëse unë fut numrin 2 këtu, kam 2. Por në krye fut një 2 tjetër. Dhe ju mund të shihni se 721 ka një bllokim ekskluziv. Por tani 722 pret që 721 të përfundojë operacionin e tij, sepse nuk mund të futë 2 për sa kohë nuk di se çfarë do të ndodhë me 721.
Dhe nëse bëjmë subtransaction.
Këtu kemi 723.
Dhe nëse ruajmë një pikë dhe pastaj e azhurnojmë, ne marrim një ID të re transaksioni. Kjo është një tjetër karakteristikë e sjelljes që duhet të dini. Nëse e kthejmë këtë, ID e transaksionit shkon. 724 shkon. Por tani ne kemi 725.
Dhe çfarë përpiqem të bëj këtu? Po përpiqem t'ju tregoj shembuj të bllokimeve të pazakonta që mund të gjeni: qoftë bllokime serializable ose SAVEPOINT - këto janë lloje të ndryshme bllokimesh që do të shfaqen në tabelën e bllokimeve.
Kjo është krijimi i bllokimeve eksplicite, të cilat kanë pg_advisory_lock.
Dhe shihni se lloji i bllokimit këtu liston si advisory. Dhe këtu është shkruar me të kuqe "advisory". Dhe mund ta bllokoni kështu në të njëjtën kohë me pg_advisory_unlock.
Dhe duke përfunduar, do doja t'ju tregoj diçka tjetër befasuese. Do të krijoj një tjetër lloj. Por do ta lidh tabelën pg_locks me tabelën pg_stat_activity. Dhe pse dëshiroj ta bëj këtë? Sepse kjo do të më lejojë të shoh dhe të kuptoj të gjitha sesionet aktuale dhe të shoh se cilat bllokime po presin. Dhe kjo është mjaft interesante kur ne kombinojmë tabelën e bllokimeve dhe tabelën e kërkesave.
Dhe këtu ne krijojmë pg_stat_view.
Dhe ne azhurnojmë një rresht për një. Dhe këtu shohim 724. Pastaj e azhurnojmë rreshtin tonë deri në tre. Dhe çfarë shihni këtu tani? Këto janë kërkesat, dmth. ju shihni tërë listën e kërkesave që janë të listuara në kolonën e majtë. Dhe pastaj në anën e djathtë mund të shihni bllokimet dhe atë që ato krijojnë. Dhe kjo mund të jetë më e qartë për ju, në mënyrë që të mos keni nevojë të ktheheni çdo herë te çdo sesion dhe të shihni - nëse duhet të bashkoni apo jo. Kjo e bëjnë për ne.
Një tjetër funksion që është shumë i dobishëm është pg_blocking_pidsNdoshta nuk keni dëgjuar ndonjëherë për të. Çfarë bën ajo? Ajo na lejon të themi se për këtë seancë 11740, cilat janë ID-të e proceseve që ajo pret. Dhe mund të shihni se 11740 pret 724. Dhe 724 është në krye. Ndërsa 11306 është ID e procesit tuaj. Në thelb, kjo funksion kalon përmes tabelës suaj të bllokimeve. E di që është pak e komplikuar, por ju po arrini ta kuptoni. Në thelb, kjo funksion kalon përmes kësaj tabele bllokimesh dhe përpiqet të gjejë ku është ky ID procesi, duke pasur parasysh ato bllokime që ajo pret. Dhe gjithashtu përpiqet të llogarisë se cili është saktësisht ID i procesit të atij procesi që pret bllokimat. Prandaj mund të filloni këtë funksion. pg_blocking_pids.
Dhe kjo ndodh të jetë shumë e dobishme. E kemi shtuar vetëm me versionin 9.6, prandaj kjo funksion ka vetëm 5 vjet, por është shumë dhe shumë e dobishme. Po ashtu për kërkesën e dytë. Ajo tregon saktësisht atë që na nevojitet të shohim.
Kjo është ajo për të cilën doja të flisja me ju. Dhe siç e prisja, ne përdorëm gjithë kohën tonë, sepse kishte një numër të madh slajdesh. Dhe slajdet janë të disponueshme për shkarkim. Doja t'ju falenderoja që ishit këtu. Jam i sigurt se do t'ju pëlqejë pjesa tjetër e konferencës, shumë faleminderit!
Pyetje:
Për shembull, nëse përpiqem të azhurnoj rreshtat, ndërsa një sesion tjetër përpiqet të fshijë tërë tabelën. Sa e kuptoj, duhet të ketë diçka si intent lock. A ekziston kjo në Postgres?
Kthehemi në fillim. Ndoshta e mbani mend që kur bëni një veprim, për shembull, kur bëni SELECT, ne lëshojmë AccessShareLock. Dhe kjo parandalon fshirjen e tabelës. Prandaj nëse, për shembull, dëshironi të azhurnoni një rresht në tabelë ose të fshini një rresht, atëherë askush nuk mund të fshijë tërë tabelën në të njëjtën kohë, sepse mbani këtë AccessShareLock mbi tërë tabelën dhe mbi rreshtin. Dhe sapo të keni përfunduar, ata mund ta fshijnë atë. Por derisa të jeni duke ndryshuar diçka atje, ata nuk do të kenë mundësi ta bëjnë këtë.
Le të provojmë përsëri. Le të kalojmë te shembulli i fshirjes. Dhe ju shihni se si mbi rresht është një lock ekskluziv mbi tërë tabelën.
Kjo do të duket si lock ekskluziv, e vërtetë?
Po, kjo duket si kjo. E kuptoj se për çfarë po flisni. Po thoni se, nëse unë kryej një SELECT, do të kem ShareExclusive, dhe më pas e kaloj këtë në gjendjen Row Exclusive, a do të ishte kjo një problem? Por për mrekulli, kjo nuk krijon një problem. Duket si një rritje e shkallës së bllokimit, por në thelb, kam një bllokim që parandalon fshirjen. Dhe tani, kur e bëj këtë bllokim më të fuqishëm, ai akoma parandalon fshirjen. Prandaj, nuk është se po rritem lart. P.sh., ai e parandalonte këtë edhe kur ishte në një nivel më të ulët, prandaj, kur e rris nivelin e tij, ai akoma e parandalon fshirjen e tabelës.
E kuptoj për çfarë po flisni. Këtu nuk ka një rast rritjeje të shkallës së bllokimit, ku po përpiqeni të heqni një bllokim për të futur një më të fuqishëm. Këtu thjesht e rrit atë parandalim në të gjithë vendin, prandaj nuk shkakton ndonjë konflikt. Por është një pyetje e mirë. Faleminderit shumë që e ngritët këtë!
Çfarë na nevojitet të bëjmë për të shmangur situatën e deadlock’it, kur kemi shumë seanca, një numër të madh përdoruesish?
Postgres e vërejt automatikisht situatën e deadlock’it. Dhe automatikisht do të fshijë një nga seancat. Një mënyrë që ndihmon për të shmangur situatën e deadlock’it është të bllokoni njerëzit në të njëjtin rend. Prandaj, kur ta shikoni aplikacionin tuaj, shpesh arsyeja për deadlocks... Le ta imagjinojmë se dua të bllokoj dy gjëra të ndryshme. Një aplikacion bllokon tabelën 1, dhe një aplikacion tjetër bllokon tabelën 2, dhe më pas tabelën 1. Dhe mënyra më e lehtë për të shmangur deadlocks është të shikoni aplikacionin tuaj dhe të siguroheni që bllokimi ndodh në të njëjtin rend në të gjithë aplikacionet. Dhe kjo, në përgjithësi, eleminon 80% të problemeve, sepse shumë njerëz të ndryshëm shkruajnë këto aplikacione. Dhe nëse i bllokoni ato në të njëjtin rend, atëherë nuk do të përballeni me situatën e deadlock’it.
Faleminderit shumë për prezantimin tuaj! Flitët për vacuum full dhe, nëse e kuptoj saktësisht, vacuum full deformon rendin e rekordëve në ruajtjen përkatëse, prandaj mban rekordet aktuale të patëmetë. Por pse vacuum full merr një bllokim ekskluziv dhe pse ai është në konflikt me operacionet e shkruar?
Është një pyetje e mirë. Arsyeja është se vacuum full merr tabelën. Në thelb, ne po krijojmë një version të ri të tabelës. Pra, tabela do të jetë e re. Kjo do të thotë se do të jetë një version krejtësisht i ri i tabelës. Problemi është se kur e bëjmë këtë, nuk duam që njerëzit ta shohin, sepse na nevojitet që ata të shohin tabelën e re. Prandaj kjo lidhet me pyetjen e mëparshme. Nëse do të mund të lexoja në të njëjtën kohë, atëherë nuk do të mund ta lëviznim dhe të udhëzonim njerëzit në tabelën e re. Do të na duhej të prisnim që secili të përfundonte leximin e kësaj tabele dhe kështu, në thelb, kjo është një situatë lock exclusive.
Ne thjesht po themi se e bllokojmë që në fillim, sepse e dimë që në fund do të na nevojitet një bllokim ekskluziv për të transferuar të gjithë në kopjen e re. Prandaj potencialisht mund ta lejojmë këtë. Dhe e bëjmë këtë me indeksimin e përbashkët. Por është shumë më e komplikuar ta bësh këtë. Dhe ka të bëjë shumë me pyetjen tënde të mëparshme për lock exclusive.
A është e mundur të shtohet një locking timeout në Postgres? Në Oracle, mund të shkruaj 'zgjedh në përditësim' dhe të pres 50 sekonda deri në përditësim. Kjo ishte e mirë për aplikacionin. Por në Postgres, ose duhet ta bëj menjëherë dhe të mos pres fare, ose të pres deri në një kohë të caktuar.
Po, mund të zgjidhni një kohë krijimi për bllokimet tuaja. Mund të lësh një komandë no way, e cila do të jetë..., nëse nuk mund ta merrni menjëherë bllokimin. Pra, ose bllokoni timeout, ose ndonjë tjetër që do t'ju lejojë ta bëni këtë. Kjo nuk bëhet në nivelin sintaksor. Bëhet si një variabël në server. Ndonjëherë nuk mund ta përdorni këtë.
Mund të hapni sliden 75?
Po.
Dhe pyetja ime është si vijon. Pse të dy proceset e përditësimit po presin 703?
Dhe kjo është një pyetje e shkëlqyer. Nuk e kuptoj, për sa i përket, pse Postgres e bën këtë. Por kur u krijua 703, ai priste 702. Dhe kur 704 dhe 705 shfaqen, duket se ata nuk e dinë atë që presin, sepse atje nuk ka ende asgjë. Dhe Postgres e bën këtë: kur nuk mund të marrësh një bllokim, ai shkruan "Çfarë ka kuptim t'ju përpunoj?", sepse ti edhe ashtu po pret dikë. Prandaj, thjesht le të presim në ajër, ai as që e përditëson këtë. Por çfarë ndodhi këtu? Sa herë që 702 përfundoi procesin dhe 703 mori bllokimin e tij, sistemi u kthye. Dhe tha se tani kemi dy njerëz që janë në pritje. Dhe pastaj le t'i përditësojmë ata së bashku. Dhe të tregojmë se të dy janë në pritje.
Nuk e di pse Postgres e bën kështu. Por ka një problem që quhet f... Më duket se nuk është një term në shqip. Kjo është kur të gjithë presin një bllokim, edhe nëse ka 20 instance që presin bllokimin. Dhe papritmas, ata të gjithë zgjohen në të njëjtën kohë. Dhe të gjithë fillojnë të përpiqen të reagojnë. Por sistemi bën në mënyrë që të gjithë të presin 703. Sepse ata të gjithë presin, dhe ne i vije në radhë të gjithë menjëherë. Dhe nëse ndonjë kërkesë tjetër e re shfaqet, që është formuar pas kësaj, për shembull, 707, atëherë aty përsëri do të jetë boshllëk.
Dhe më duket se kjo bëhet që të mund të thuhet se në këtë hap 702 pret 703, dhe të gjithë ata që do të vijnë pas kësaj, nuk do të kenë asnjë regjistrim në këtë fushë. Por sa herë që ai që pret i parë largohet, dhe të gjithë ata që prisnin në atë moment deri në përditësim, marrin të njëjtin shenjë. Prandaj, më duket se kjo është bërë që ne të mund të përpunojmë në rend, që ata të jenë të rregulluar saktë.
Unë gjithmonë e kam parë këtë si një fenomen mjaft të çuditshëm. Sepse këtu, për shembull, ato fare nuk përmenden. Por, më duket se sa herë që ne i japim një bllokim të ri, ne shikojmë të gjithë ata që janë në procesin e pritjes. Atëherë ne i radhitim ata të gjithë në radhë. Dhe pastaj çdo i ri që vjen, futet në radhë vetëm kur personi i ardhshëm ka përfunduar përpunimin. Një pyetje shumë e mirë. Faleminderit shumë për pyetjen!
Më duket se është shumë më logjike kur 705 pret 704.
Por problemi këtu është ky. Teknikisht, mund të zgjojmë njërin ose tjetrin. Prandaj, ne do të zgjojmë njërin ose tjetrin. Por çfarë ndodh në funksionimin e sistemit? Ju shihni se 703 në krye ka bllokuar ID-në e tij të transaksionit. Kështu funksionon Postgres. Dhe 703 bllokohet nga ID-ja e tij e transaksionit, prandaj, nëse dikush dëshiron të presë, do të presë 703. Dhe në thelb, 703 përfundon. Dhe vetëm pasi të përfundojë, ndonjë nga proceset zgjohet. Dhe ne nuk e dimë se cili proces do të jetë. Pastaj ne i trajtojmë gradualisht të gjitha. Por nuk është e qartë se cili proces zgjohet i pari, sepse mund të jetë ndonjë nga këta procese. Në thelb, kishim një planifikues që tha se tani mund të zgjojmë ndonjë nga këta procese. Ne thjesht zgjedhim njërin rastësisht. Prandaj të dy duhet të shënohen, sepse ne mund ta zgjojmë ndonjërin prej tyre.
Dhe problemi është se kemi CP-pafundësi. Prandaj, është shumë e mundur të zgjojmë të vonuarin. Dhe nëse, për shembull, do të zgjojmë të vonuarin, do të presim atë që sapo mori bllokimin, prandaj nuk e përcaktojmë se cili do të zgjohet i pari. Ne krijojmë thjesht një situatë të tillë, dhe sistemi do t'i zgjojë në rend të rastësishëm.
Ka . Shikoni, ata gjithashtu janë interesantë dhe të dobishëm. Tema, sigurisht, është jashtëzakonisht e komplikuar. Faleminderit shumë, Bruce!
Burimi: habr.com
