Transkripti i bisedës 2020 të Bruce Momjian "Zhbllokimi i menaxherit të kyçjes së Postgres".
(Shënim: Të gjitha pyetjet SQL nga sllajdet mund të merren nga kjo lidhje: )
Përshëndetje! Është mirë të jesh sërish këtu në Rusi. Më vjen keq që nuk munda 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. Më pëlqen të vij në Rusi. Unë do të vizitoj Tyumen, Tver. Jam shumë i lumtur që do të mund t'i vizitoj këto qytete.
Emri im është Bruce Momjian. Unë punoj në EnterpriseDB dhe kam punuar me Postgres për më shumë se 23 vjet. Unë jetoj në Filadelfia, SHBA. Unë udhëtoj rreth 90 ditë në vit. Dhe marr pjesë në rreth 40 konferenca. E imja , i cili përmban sllajdet që do t'ju tregoj tani. Prandaj, pas konferencës mund t'i shkarkoni nga faqja ime personale. Ai gjithashtu përmban rreth 30 prezantime. Ka gjithashtu video dhe një numër të madh të hyrjeve në blog, më shumë se 500. Ky është një burim mjaft informues. Dhe nëse jeni të interesuar për këtë material, atëherë ju ftoj ta përdorni.
Unë kam qenë mësues, profesor para se të filloja të punoja me Postgres. Dhe jam shumë i lumtur që tani do të jem në gjendje t'ju them atë që do t'ju them. Ky është një nga prezantimet e mia më interesante. Dhe ky prezantim përmban 110 sllajde. Ne do të fillojmë të flasim me gjëra të thjeshta, dhe në fund raporti do të bëhet gjithnjë e më i ndërlikuar dhe do të bëhet mjaft kompleks.
Kjo është një bisedë mjaft e pakëndshme. Bllokimi nuk është tema më e njohur. Ne duam që kjo të zhduket diku. Është si të shkosh te dentisti.
- Bllokimi është një problem për shumë njerëz që punojnë në baza të të dhënave dhe kanë shumë procese që funksionojnë në të njëjtën kohë. Ata kanë nevojë për bllokim. Kjo do të thotë, sot do t'ju jap njohuri bazë për bllokimin.
- ID-të e transaksionit. Kjo është një pjesë mjaft e mërzitshme e prezantimit, por ato duhet të kuptohen.
- Më tej do të flasim për llojet e bllokimit. Kjo është një pjesë mjaft mekanike.
- Dhe më poshtë do të japim disa shembuj të bllokimit. Dhe do të jetë mjaft e vështirë për t'u kuptuar.
Le të flasim për bllokimin.
Terminologjia jonë është mjaft komplekse. Sa prej jush e dini se nga vjen ky pasazh? Dy njerez. Kjo është nga një lojë e quajtur Colossal Cave Adventure. Mendoj se ishte një lojë kompjuterike e bazuar në tekst në vitet '80. Aty duhej të futeshe në një shpellë, në një labirint, dhe teksti ndryshoi, por përmbajtja ishte afërsisht e njëjtë çdo herë. Kështu e mbaj mend këtë lojë.
Dhe këtu shohim emrin e bravave që na erdhën nga Oracle. Ne i përdorim ato.
Këtu shohim terma që më ngatërrojnë. Për shembull, SHARE UPDATE EKXLUSIVE. Tjetra SHARE RAW EKSKLUSIVE. Për të qenë i sinqertë, këta emra nuk janë shumë të qartë. Ne do të përpiqemi t'i shqyrtojmë ato në mënyrë më të detajuar. Disa përmbajnë fjalën "share", që do të thotë të ndash. Disa përmbajnë fjalën "ekskluzive". Disa përmbajnë të dyja këto fjalë. Do të doja të filloja me mënyrën se si funksionojnë këto bravë.
Dhe fjala "qasje" është gjithashtu shumë e rëndësishme. Dhe fjalët "rresht" janë një varg. Kjo është, shpërndarja e aksesit, shpërndarja e rreshtave.
Një çështje tjetër që duhet kuptuar në Postgres, të cilën për fat të keq nuk do të mund ta trajtoj në fjalimin tim, është MVCC. Unë kam një prezantim të veçantë për këtë temë në faqen time të internetit. Dhe nëse mendoni se ky prezantim është i vështirë, MVCC është ndoshta më i vështiri im. Dhe nëse jeni të interesuar, mund ta shikoni në faqen e internetit. Mund ta shikoni videon.
Një tjetër gjë që duhet të kuptojmë janë ID-të e transaksionit. Shumë transaksione nuk mund të funksionojnë pa identifikues unikë. Dhe këtu kemi një shpjegim se çfarë është një transaksion. Postgres ka dy sisteme të numërimit të transaksioneve. E di që kjo nuk është një zgjidhje shumë e bukur.
Gjithashtu mbani në mend se rrëshqitjet do të jenë mjaft të vështira për t'u kuptuar, kështu që ajo që theksohet me të kuqe është ajo që duhet t'i kushtoni vëmendje.
Le të shohim. Numri i transaksionit është theksuar me të kuqe. Funksioni SELECT pg_back shfaqet këtu. Ai kthen transaksionin tim dhe ID-në e transaksionit.
Edhe një gjë, nëse ju pëlqen ky prezantim dhe dëshironi ta ekzekutoni në bazën e të dhënave, atëherë mund të shkoni te kjo lidhje me ngjyrë rozë dhe të shkarkoni SQL-në për këtë prezantim. Dhe thjesht mund ta ekzekutoni në PSQL tuaj dhe i gjithë prezantimi do të shfaqet menjëherë në ekranin tuaj. Nuk do të përmbajë lule, por të paktën ne mund ta shohim atë.
Në këtë rast shohim ID-në e transaksionit. Ky është numri që i kemi caktuar. Dhe ekziston një lloj tjetër i ID-së së transaksionit në Postgres, i cili quhet ID i transaksionit virtual
Dhe ne duhet ta kuptojmë këtë. Kjo është shumë e rëndësishme, përndryshe ne nuk do të arrijmë të kuptojmë mbylljen në Postgres.
Një ID e transaksionit virtual është një ID transaksioni që nuk përmban vlera të qëndrueshme. Për shembull, nëse ekzekutoj një komandë SELECT, atëherë me shumë mundësi nuk do të ndryshoj bazën e të dhënave, nuk do të bllokoj asgjë. Pra, kur ekzekutojmë një SELECT të thjeshtë, ne nuk i japim atij transaksioni një ID të vazhdueshme. Ne i japim asaj vetëm një ID virtuale atje.
Dhe kjo përmirëson performancën e Postgres, përmirëson aftësitë e pastrimit, kështu që ID-ja e transaksionit virtual përbëhet nga dy numra. Numri i parë përpara vijës së pjerrët është ID-ja e fundit. Dhe në të djathtë shohim vetëm një banak.
Prandaj, nëse ekzekutoj një kërkesë, ajo thotë se ID-ja e backend është 2.
Dhe nëse kryej një sërë transaksionesh të tilla, atëherë shohim që numëruesi rritet sa herë që drejtoj një pyetje. Për shembull, kur ekzekutoj pyetjen 2/10, 2/11, 2/12, etj.
Mbani në mend se këtu ka dy kolona. Në të majtë shohim ID-në e transaksionit virtual - 2/12. Dhe në të djathtë kemi një ID të përhershme transaksioni. Dhe kjo fushë është bosh. Dhe ky transaksion nuk modifikon bazën e të dhënave. Kështu që unë nuk i jap një ID të përhershme transaksioni.
Sapo ekzekutoj komandën e analizës ((ANALYZE)), e njëjta pyetje më jep një ID të përhershme të transaksionit. Shikoni si ka ndryshuar kjo për ne. Nuk e kisha këtë ID më parë, por tani e kam.
Pra, këtu është një tjetër kërkesë, një tjetër transaksion. Numri i transaksionit virtual është 2/13. Dhe nëse kërkoj një ID të vazhdueshme të transaksionit, atëherë kur të ekzekutoj pyetjen, do ta marr atë.
Pra, edhe një herë. Ne kemi një ID të transaksionit virtual dhe një ID të vazhdueshme të transaksionit. Thjesht kuptoni këtë pikë për të kuptuar sjelljen e Postgres.
Kalojmë në pjesën e tretë. Këtu thjesht do të kalojmë nëpër llojet e ndryshme të bravave në Postgres. Nuk është shumë interesante. Pjesa e fundit do të jetë shumë më interesante. Por ne duhet të kemi parasysh gjërat themelore, sepse përndryshe nuk do të kuptojmë se çfarë do të ndodhë më pas.
Ne do të kalojmë nëpër këtë seksion, ne do të shikojmë çdo lloj bllokimi. Dhe unë do t'ju tregoj shembuj se si janë instaluar, si funksionojnë, do t'ju tregoj disa pyetje që mund t'i përdorni për të parë se si funksionon bllokimi në Postgres.
Për të krijuar një pyetje dhe për të parë se çfarë po ndodh në Postgres, duhet ta lëshojmë pyetjen në pamjen e sistemit. Në këtë rast, pg_lock është theksuar me të kuqe. Pg_lock është një tabelë e sistemit që na tregon se cilat bravë janë aktualisht në përdorim në Postgres.
Megjithatë, është shumë e vështirë për mua t'ju tregoj pg_lock në vetvete sepse është mjaft kompleks. Kështu që unë krijova një pamje që tregon pg_locks. Dhe gjithashtu bën disa punë për mua që më lejon të kuptoj më mirë. Kjo do të thotë, ai përjashton bllokimet e mia, sesionin tim, etj. Është thjesht SQL standard dhe ju lejon të tregoni më mirë se çfarë po ndodh.
Një problem tjetër është se kjo pamje është shumë e gjerë, kështu që më duhet të krijoj një të dytë - lockview2.
Dhe më tregon më shumë kolona nga tabela. Dhe një tjetër që më tregon pjesën tjetër të kolonave. Kjo është mjaft komplekse, ndaj u përpoqa ta paraqes sa më thjeshtë.
Pra, ne krijuam një tabelë të quajtur Lockdemo. Dhe ne krijuam një linjë atje. Kjo është tabela jonë e mostrës. Dhe ne do të krijojmë seksione vetëm për t'ju treguar shembuj të bravave.
Pra, një rresht, një kolonë. Lloji i parë i bllokimit quhet ACCESS SHARE. Ky është bllokimi më pak kufizues. Kjo do të thotë që praktikisht nuk bie ndesh me bravë të tjera.
Dhe nëse duam të përcaktojmë në mënyrë eksplicite një bllokim, ne ekzekutojmë komandën “lock table”. Dhe padyshim që do të bllokojë, d.m.th. në modalitetin ACCESS SHARE ne hapim tabelën e kyçjes. Dhe nëse ekzekutoj PSQL në sfond, atëherë e filloj seancën e dytë nga sesioni im i parë në këtë mënyrë. Domethënë, çfarë do të bëj këtu? Shkoj në një seancë 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ë pikërisht ajo që kam kërkuar. Dhe thotë se blloku është caktuar. Shume e thjeshte.
Më tej, nëse shikojmë kolonën e dytë, atëherë nuk ka asgjë atje. Janë bosh.
Dhe nëse ekzekutoj komandën "SELECT", atëherë kjo është mënyra e nënkuptuar (e qartë) për të kërkuar AccessShareLock. Kështu që unë lëshoj tabelën time dhe ekzekutoj pyetjen dhe pyetja kthen rreshta të shumtë. Dhe në një nga rreshtat shohim AccessShareLock. Kështu, SELECT thërret AccessShareLock në tryezë. Dhe nuk bie ndesh me pothuajse asgjë, sepse është një bllokim i nivelit të ulët.
Po sikur të ekzekutoj një SELECT dhe të kem tre tabela të ndryshme? Më parë drejtoja vetëm një tabelë, tani po ekzekutoj tre: pg_class, pg_namespace dhe pg_attribute.
Dhe tani kur shikoj pyetjen, shoh 9 AccessShareLocks në tre tabela. Pse? Tre tabela janë theksuar me blu: pg_attribute, pg_class, pg_namespace. Por ju gjithashtu mund të shihni se të gjithë indekset që përcaktohen përmes këtyre tabelave kanë gjithashtu AccessShareLock.
Dhe kjo është një bravë që praktikisht nuk bie ndesh me të tjerët. Dhe gjithçka që bën është thjesht të na pengojë të rivendosim tabelën ndërkohë që ne e zgjedhim atë. Kjo ka kuptim. Domethënë, nëse zgjedhim një tabelë, ajo zhduket në atë moment, atëherë kjo është e gabuar, kështu që AccessShare është një bllokim i nivelit të ulët që na thotë "mos e lëshoni këtë tabelë ndërsa jam duke punuar". Në thelb, kjo është gjithçka që ajo bën.
NDAJ RRESHT - Ky bravë është pak më ndryshe.
Le të marrim një shembull. ZGJIDHni metodën e NDARJES së RRESHTIT për mbylljen e secilit rresht individualisht. Në këtë mënyrë askush nuk mund t'i fshijë ose t'i ndryshojë ndërsa ne i shikojmë.
Pra, çfarë bën SHARE LOCK? Ne shohim që ID e transaksionit është 681 për SELECT. Dhe kjo është interesante. Çfare ndodhi ketu? Herën e parë që e shohim numrin është në fushën "Bllokimi". Ne marrim ID-në e transaksionit dhe ai thotë se po e bllokon atë në modalitetin ekskluziv. Gjithçka që bën është që thotë se kam një rresht që është teknikisht i mbyllur diku në tabelë. Por ai nuk thotë se ku saktësisht. Ne do ta shikojmë këtë më në detaje pak më vonë.
Këtu themi se brava përdoret nga ne.
Pra, një bravë ekskluzive thotë në mënyrë eksplicite se është ekskluzive. Dhe gjithashtu nëse fshini një rresht në këtë tabelë, atëherë kjo është ajo që do të ndodhë, siç mund ta shihni.
SHARE EXCLUSIVE është një bravë më e gjatë.
Kjo është komanda e analizuesit (ANALYZE) që do të përdoret.
SHARE LOCK – mund të kyçeni në mënyrë eksplicite në modalitetin e ndarjes.
Ju gjithashtu mund të krijoni një indeks unik. Dhe aty mund të shihni SHARE LOCK, që është pjesë e tyre. Dhe mbyll tavolinën dhe vendos mbi të një SHARE LOCK.
Si parazgjedhje, SHARE LOCK në një tabelë do të thotë që njerëzit e tjerë mund ta lexojnë tabelën, por askush nuk mund ta modifikojë atë. Dhe kjo është pikërisht ajo që ndodh kur krijoni një indeks unik.
Nëse krijoj një indeks unik njëkohësisht, atëherë do të kem një lloj tjetër mbylljeje sepse, siç e mbani mend, përdorimi i indekseve në të njëjtën kohë zvogëlon kërkesën për kyçje. Dhe nëse përdor një bllokim normal, një indeks normal, atëherë do të parandaloj kështu shkrimin në indeksin e tabelës gjatë krijimit të tij. Nëse përdor një indeks njëkohësisht, atëherë duhet të përdor një lloj tjetër mbylljeje.
SHARE ROW EXCLUSIVE – përsëri mund të vendoset në mënyrë eksplicite (në mënyrë eksplicite).
Ose mund të krijojmë një rregull, d.m.th., të marrim një rast specifik në të cilin do të përdoret.
Bllokimi EKSKLUZIV do të thotë që askush tjetër nuk mund ta ndryshojë tabelën.
Këtu shohim lloje të ndryshme bravash.
ACCESS EXCLUSIVE, për shembull, është një komandë bllokuese. Për shembull, nëse e bëni CLUSTER table, atëherë kjo do të thotë që askush nuk do të jetë në gjendje të shkruajë atje. Dhe bllokon jo vetëm vetë tabelën, por edhe indekset.
Kjo është faqja e dytë e bllokimit ACCESS EXCLUSIVE, ku shohim saktësisht se çfarë bllokon në tabelë. Ai mbyll rreshtat individuale të tabelave, gjë që është mjaft interesante.
Ky është i gjithë informacioni bazë që doja të jepja. Ne folëm për bravat, për ID-të e transaksioneve, folëm për ID-të e transaksioneve virtuale, për ID-të e transaksioneve të përhershme.
Dhe tani do të kalojmë nëpër disa shembuj bllokues. Kjo është pjesa më interesante. Do të shohim raste shumë interesante. Dhe qëllimi im në këtë prezantim është t'ju jap një kuptim më të mirë të asaj që Postgres po bën në të vërtetë kur përpiqet të bllokojë disa gjëra. Unë mendoj se ai është shumë i mirë në bllokimin e pjesëve.
Le të shohim disa shembuj specifikë.
Ne do të fillojmë me tabela dhe një rresht në një tabelë. Kur fut diçka, kam në tabelë të shfaqur ExclusiveLock, Transaction ID dhe ExclusiveLock.
Çfarë ndodh nëse fut dy rreshta të tjerë? Dhe tani tabela jonë ka tre rreshta. Dhe futa një rresht dhe e mora këtë si rezultat. Dhe nëse fus dy rreshta të tjerë, çfarë është e çuditshme për këtë? Ka një gjë të çuditshme këtu, sepse unë kam shtuar tre rreshta në këtë tabelë, por unë kam ende dy rreshta në tabelën e kyçjes. Dhe kjo është në thelb sjellja themelore e Postgres.
Shumë njerëz mendojnë se nëse në një bazë të dhënash bllokoni 100 rreshta, atëherë do t'ju duhet të krijoni 100 hyrje të kyçjes. Nëse bllokoj 1 rreshta menjëherë, atëherë do të më duhen 000 pyetje të tilla. Dhe nëse më duhen një milion ose një miliard për të bllokuar. Por nëse e bëjmë këtë, nuk do të funksionojë shumë mirë. Nëse keni përdorur një sistem që krijon hyrje bllokuese për çdo rresht individual, atëherë mund të shihni se kjo është e ndërlikuar. Sepse ju duhet të përcaktoni menjëherë një tabelë bllokimi që mund të tejmbushet, por Postgres nuk e bën këtë.
Dhe ajo që është me të vërtetë e rëndësishme për këtë rrëshqitje është se ai tregon qartë se ekziston një sistem tjetër që funksionon brenda MVCC që bllokon rreshtat individualë. Pra, kur bllokoni miliarda rreshta, Postgres nuk krijon një miliardë komanda të veçanta kyçjeje. Dhe kjo ka një efekt shumë të mirë në produktivitetin.
Po në lidhje me një përditësim? Po përditësoj rreshtin tani dhe mund të shihni që ka kryer dy operacione të ndryshme njëherësh. E mbylli tryezën në të njëjtën kohë, por mbylli edhe indeksin. Dhe ai kishte nevojë të mbyllte indeksin sepse ka kufizime unike në këtë tabelë. Dhe ne duam të sigurohemi që askush të mos e ndryshojë, ndaj e bllokojmë.
Çfarë ndodh nëse dua të përditësoj dy rreshta? Dhe ne shohim që ai sillet në të njëjtën mënyrë. Ne bëjmë dy herë më shumë përditësime, por saktësisht të njëjtin numër linjash bllokimi.
Nëse po pyesni veten se si e bën Postgres këtë, do t'ju duhet të dëgjoni bisedat e mia në MVCC për të mësuar se si Postgres i shënon nga brenda këto rreshta që ndryshon. Dhe Postgres ka një mënyrë në të cilën e bën këtë, por nuk e bën atë në nivelin e mbylljes së tavolinës, e bën atë në një nivel më të ulët dhe më efikas.
Po sikur të dua të fshij diçka? Nëse fshij, për shembull, një rresht dhe kam ende dy hyrjet e mia bllokuese, dhe edhe nëse dua t'i fshij të gjitha, ato janë ende aty.
Dhe, për shembull, unë dua të fus 1 rreshta, dhe pastaj ose të fshij ose të shtoj 000 rreshta, pastaj ato rreshta individuale që shtoj ose ndryshoj, ato nuk regjistrohen këtu. Ato janë shkruar në një nivel më të ulët brenda vetë serisë. Dhe gjatë fjalimit të MVCC-së fola për këtë në detaje. Por është shumë e rëndësishme kur jeni duke analizuar bravat të siguroheni që jeni duke u kyçur në nivelin e tabelës dhe se nuk po shihni se si po regjistrohen rreshtat individualë këtu.
Po në lidhje me bllokimin e qartë?
Nëse klikoj refresh, kam dy rreshta të kyçur. Dhe nëse i zgjedh të gjitha dhe klikoj "përditëso kudo", atëherë kam ende dy regjistrime bllokuese.
Ne nuk krijojmë rekorde të veçanta për çdo rresht individual. Sepse atëherë produktiviteti bie, mund të ketë shumë prej tij. Dhe ne mund të gjendemi në një situatë të pakëndshme.
Dhe e njëjta gjë, nëse e bëjmë të përbashkët, mund t'i bëjmë të gjitha 30 herë.
Ne rivendosim tabelën tonë, fshijmë gjithçka, pastaj futim përsëri një rresht.
Një sjellje tjetër që shihni në Postgres që është shumë e njohur dhe e dëshiruar është që ju mund të bëni një përditësim ose një përzgjedhje. Dhe ju mund ta bëni këtë në të njëjtën kohë. Dhe zgjidhni nuk bllokon përditësimin dhe e njëjta gjë në drejtim të kundërt. Ne i themi lexuesit të mos e bllokojë shkrimtarin dhe shkrimtari nuk e bllokoi lexuesin.
Unë do t'ju tregoj një shembull të kësaj. Unë do të bëj një zgjedhje tani. Më pas do të bëjmë INSERT. Dhe pastaj mund të shihni - 694. Ju mund të shihni ID-në e transaksionit që ka kryer këtë futje. Dhe kështu funksionon.
Dhe nëse shikoj ID-në time të pasme tani, tani është 695.
Dhe unë mund të shoh 695 që shfaqet në tabelën time.
Dhe nëse përditësoj këtu si kjo, atëherë kam një rast tjetër. Në këtë rast, 695 është një bllokim ekskluziv dhe përditësimi ka të njëjtën sjellje, por nuk ka asnjë konflikt midis tyre, gjë që është mjaft e pazakontë.
Dhe mund të shihni se në krye është ShareLock, dhe në fund është ExclusiveLock. Dhe të dy transaksionet funksionuan.
Dhe ju duhet të dëgjoni bisedën time në MVCC për të kuptuar se si ndodh kjo. Por ky është një ilustrim që ju mund ta bëni në të njëjtën kohë, d.m.th. të bëni një ZGJIDHJE dhe një UPDATE në të njëjtën kohë.
Le të rivendosim dhe të bëjmë një operacion tjetër.
Nëse përpiqeni të ekzekutoni dy përditësime njëkohësisht në të njëjtin rresht, ai do të bllokohet. Dhe mbani mend, thashë që lexuesi nuk e bllokon shkrimtarin, dhe shkrimtari nuk bllokon lexuesin, por një shkrimtar bllokon një shkrimtar tjetër. Kjo do të thotë, ne nuk mund të kemi dy persona që të përditësojnë të njëjtin rresht në të njëjtën kohë. Duhet të prisni derisa njëra prej tyre të përfundojë.
Dhe për ta ilustruar këtë, unë do të shikoj tabelën Lockdemo. Dhe ne do të shikojmë në një rresht. Për transaksion 698.
Ne e kemi përditësuar këtë në 2. 699 është përditësimi i parë. Dhe ishte i suksesshëm ose është në një transaksion në pritje dhe pret që ne të konfirmojmë ose anulojmë.
Por shikoni diçka tjetër - 2/51 është transaksioni ynë i parë, sesioni ynë i parë. 3/112 është kërkesa e dytë që erdhi nga lart që e ndryshoi atë vlerë në 3. Dhe nëse vini re, ajo e sipërme u kyç në vetvete, që është 699. Por 3/112 nuk e dha bllokimin. Kolona Lock_mode thotë se çfarë pret. Ajo pret 699. Dhe nëse shikoni se ku është 699, është më e lartë. Dhe çfarë bëri seanca e parë? Ajo krijoi një bllokim ekskluziv në ID-në e saj të transaksionit. Kështu e bën Postgres. Ai bllokon ID-në e tij të transaksionit. Dhe nëse doni të prisni që dikush të konfirmojë ose anulojë, atëherë duhet të prisni derisa të ketë një transaksion në pritje. Dhe kjo është arsyeja pse ne mund të shohim një linjë të çuditshme.
Le të shohim përsëri. Në të majtë shohim ID-në tonë të përpunimit. Në kolonën e dytë ne shohim ID-në tonë të transaksionit virtual, dhe në të tretën shohim lock_type. Çfarë do të thotë kjo? Në thelb ajo që thotë është se po bllokon ID-në e transaksionit. Por vini re se të gjitha rreshtat në fund thonë lidhje. Dhe kështu ju keni dy lloje bravash në tavolinë. Ekziston një bllokim i lidhjes. Dhe më pas është bllokimi i transaksioneve, ku ju bllokoni vetë, që është pikërisht ajo që ndodh në rreshtin e parë ose në fund, ku është transaksioni, ku presim që 699 të përfundojë funksionimin e tij.
Do të shoh se çfarë do të ndodhë këtu. Dhe këtu ndodhin dy gjëra njëkohësisht. Po shikoni një bllokim të ID-së së transaksionit në rreshtin e parë që bllokohet vetë. Dhe ajo bllokon veten për t'i bërë njerëzit të presin.
Nëse shikoni rreshtin e 6-të, është e njëjta hyrje si e para. Dhe për këtë arsye transaksioni 699 është i bllokuar. 700 eshte edhe vete mbyllese. Dhe pastaj në rreshtin e poshtëm do të shihni se ne jemi duke pritur që 699 të përfundojë funksionimin e tij.
Dhe në lock_type, tuple ju shihni numrat.
Mund ta shihni se është 0/10. Dhe ky është numri i faqes, dhe gjithashtu kompensimi i këtij rreshti të veçantë.
Dhe e shihni se bëhet 0/11 kur përditësojmë.
Por në realitet është 0/10, sepse ka një pritje për këtë operacion. Kemi mundësinë të shohim se ky është seriali që pres ta konfirmoj.
Pasi ta kemi konfirmuar dhe shtypim commit, dhe kur përditësimi të përfundojë, kjo është ajo që ne marrim përsëri. Transaksioni 700 është i vetmi bravë, nuk pret askënd tjetër sepse është kryer. Thjesht pret që transaksioni të përfundojë. Pasi mbaron 699, nuk presim më asgjë. Dhe tani transaksioni 700 thotë se gjithçka është në rregull, se ka të gjitha bravat që i nevojiten në të gjitha tavolinat e lejuara.
Dhe për ta bërë edhe më të komplikuar të gjithë këtë, ne krijojmë një pamje tjetër, e cila këtë herë do të na sigurojë një hierarki. Nuk pres që ta kuptoni këtë kërkesë. Por kjo do të na japë një pamje më të qartë të asaj që po ndodh.
Kjo është një pamje rekursive që ka gjithashtu një seksion tjetër. Dhe pastaj i bashkon gjithçka përsëri. Le ta përdorim këtë.
Po sikur të bëjmë tre përditësime të njëkohshme dhe të themi se rreshti tani është tre. Dhe ne do të ndryshojmë 3 në 4.
Dhe këtu shohim 4. Dhe ID-në e transaksionit 702.
Dhe pastaj do të ndryshoj 4 në 5. Dhe 5 në 6, dhe 6 në 7. Dhe do të rreshtoj një numër njerëzish që do të presin që ky transaksion të përfundojë.
Dhe gjithçka bëhet e qartë. Cili është rreshti i parë? Ky është 702. Ky është ID-ja e transaksionit që fillimisht e vendosi këtë vlerë. Çfarë është shkruar në kolonën time të dhënë? Unë kam shenja f. Këto janë përditësimet e mia që (5, 6, 7) nuk mund të miratohen sepse ne presim që të përfundojë ID 702 e transaksionit. Aty kemi bllokimin e ID-së së transaksionit. Dhe kjo rezulton në 5 bllokime ID transaksionale.
Dhe nëse shikoni 704, në 705, asgjë nuk është shkruar ende atje, sepse ata nuk e dinë ende se çfarë po ndodh. Ata thjesht shkruajnë se nuk e kanë idenë se çfarë po ndodh. Dhe ata thjesht do të shkojnë të flenë sepse presin që dikush të përfundojë dhe të zgjohet kur të ketë mundësi për të ndryshuar rreshtat.
Kështu duket. Është e qartë se të gjithë presin rreshtin e 12-të.
Kjo është ajo që pamë këtu. Këtu është 0/12.
Pra, pasi të miratohet transaksioni i parë, mund të shihni këtu se si funksionon hierarkia. Dhe tani gjithçka bëhet e qartë. Ata të gjithë bëhen të pastër. Dhe në fakt ata janë ende në pritje.
Ja çfarë po ndodh. 702 kryen. Dhe tani 703 merr këtë bllokim rreshti, dhe më pas 704 fillon të presë që 703 të angazhohet. Dhe 705 po pret gjithashtu këtë. Dhe kur e gjithë kjo të përfundojë, ata pastrohen. Dhe dua të theksoj se të gjithë janë në rresht. Dhe kjo është shumë e ngjashme me një situatë në një bllokim trafiku kur të gjithë presin makinën e parë. Makina e parë ndalon dhe të gjithë rreshtohen në një radhë të gjatë. Pastaj lëviz, pastaj makina tjetër mund të ecë përpara dhe të marrë bllokun e saj, etj.
Dhe nëse kjo nuk ju dukej mjaft e ndërlikuar, atëherë ne tani do t'ju flasim për bllokimet. Nuk e di se cili prej jush i ka hasur. Ky është një problem mjaft i zakonshëm në sistemet e bazës së të dhënave. Por ngërçe janë kur një seancë pret një seancë tjetër për të bërë diçka. Dhe në këtë moment një seancë tjetër pret seancën e parë për të bërë diçka.
Dhe, për shembull, nëse Ivan thotë: "Më jep diçka", dhe unë them: "Jo, do ta jap vetëm nëse më jep diçka tjetër". Dhe ai thotë: "Jo, nuk do ta jap ty nëse nuk ma jep mua." Dhe ne përfundojmë në një situatë bllokimi. Unë jam i sigurt që Ivan nuk do ta bëjë këtë, por ju e kuptoni kuptimin që ne kemi dy njerëz që duan të marrin diçka dhe ata nuk janë të gatshëm ta japin atë derisa tjetri t'u japë atë që duan. Dhe nuk ka zgjidhje.
Dhe në thelb, baza e të dhënave juaj duhet ta zbulojë këtë. Dhe pastaj ju duhet të fshini ose mbyllni një nga seancat, sepse përndryshe ato do të mbeten atje përgjithmonë. Dhe ne e shohim atë në bazat e të dhënave, ne e shohim atë në sistemet operative. Dhe në të gjitha vendet ku kemi procese paralele, kjo mund të ndodhë.
Dhe tani do të instalojmë dy bllokime. Do të vendosim 50 dhe 80. Në rreshtin e parë do të përditësoj nga 50 në 50. Do të marr numrin e transaksionit 710.
Dhe pastaj do të ndryshoj 80 në 81 dhe 50 në 51.
Dhe kështu do të duket. Dhe kështu 710 ka një rresht të bllokuar dhe 711 është duke pritur për konfirmim. Këtë e pamë kur përditësuam. 710 është pronari i serisë sonë. Dhe 711 pret që 710 të përfundojë transaksionin.
Dhe madje thotë se në cilin rresht ndodhin bllokimet. Dhe ja ku fillon të bëhet e çuditshme.
Tani po përditësojmë 80 në 80.
Dhe këtu fillojnë ngërçet. 710 është duke pritur për një përgjigje nga 711, dhe 711 është duke pritur për 710. Dhe kjo nuk do të përfundojë mirë. Dhe nuk ka rrugëdalje nga kjo. Dhe ata do të presin një përgjigje nga njëri-tjetri.
Dhe thjesht do të fillojë të vonojë gjithçka. Dhe ne nuk e duam këtë.
Dhe Postgres ka mënyra për të vërejtur kur kjo ndodh. Dhe kur kjo ndodh, ju merrni këtë gabim. Dhe nga kjo është e qartë se ky dhe ai proces është duke pritur për një SHARE LOCK nga një proces tjetër, d.m.th., i cili është i bllokuar nga procesi 711. Dhe ai proces priste që të jepej një SHARE LOCK në një ID transaksioni të tillë dhe u bllokua nga ky dhe ai proces. Prandaj, këtu ka një situatë bllokimi.
A ka ngërçe me tre drejtime? A është e mundur? Po.
Ne i vendosim këta numra në një tabelë. Ndryshojmë 40 me 40, bëjmë bllokim.
Ne ndryshojmë 60 në 61, 80 në 81.
Dhe pastaj ne ndryshojmë 80 dhe pastaj bum!
Dhe 714 tani është duke pritur për 715. 716 është duke pritur për 715. Dhe asgjë nuk mund të bëhet për këtë.
Këtu nuk ka më dy veta, këtu janë tashmë tre veta. Unë dua diçka nga ju, ky kërkon diçka nga një person i tretë dhe personi i tretë kërkon diçka nga unë. Dhe ne përfundojmë në një pritje tre-kahëshe sepse të gjithë presim që personi tjetër të përfundojë atë që duhet të bëjë.
Dhe Postgres e di se në cilin rresht ndodh kjo. Dhe kështu do t'ju japë mesazhin e mëposhtëm, i cili tregon se keni një problem ku tre hyrje bllokojnë njëra-tjetrën. Dhe këtu nuk ka kufizime. Ky mund të jetë rasti kur 20 hyrje bllokojnë njëra-tjetrën.
Problemi tjetër është i serializueshëm.
Nëse bravë speciale e serializueshme.
Dhe kthehemi te 719. Prodhimi i tij është krejt normal.
Dhe mund të klikoni për ta bërë transaksionin nga i serializueshëm.
Dhe ju e kuptoni se tani keni një lloj tjetër bllokimi SA - do të thotë e serializueshme.
Dhe kështu ne kemi një lloj të ri të bllokimit të quajtur SARieadLock, i cili është një bllokues serial dhe ju lejon të futni seriale.
Dhe gjithashtu mund të futni indekse unike.
Në këtë tabelë kemi indekse unike.
Pra, nëse vendos numrin 2 këtu, atëherë kam një 2. Por në krye, vendosa një tjetër 2 in. Dhe ju mund të shihni se 721 ka një bllokim ekskluziv. Por tani 722 pret që 721 të përfundojë funksionimin e tij sepse nuk mund të fusë 2 derisa të dijë se çfarë do të ndodhë me 721.
Dhe nëse bëjmë nëntransaksion.
Këtu kemi 723.
Dhe nëse e ruajmë pikën dhe më pas e përditësojmë, atëherë marrim një ID të re transaksioni. Ky është një model tjetër sjelljeje që duhet të keni parasysh. Nëse e kthejmë këtë, atëherë ID-ja e transaksionit largohet. 724 gjethe. Por tani kemi 725.
Pra, çfarë po përpiqem të bëj këtu? Po përpiqem t'ju tregoj shembuj të bravave të pazakonta që mund të gjeni: qofshin bravë të serializuar ose SAVEPOINT, këto janë lloje të ndryshme bravash që do të shfaqen në tabelën e kyçjeve.
Ky është krijimi i blloqeve eksplicite (eksplicite), të cilat kanë pg_advisory_lock.
Dhe shihni që lloji i bllokimit është renditur si këshillues. Dhe këtu thotë "këshillues" me të kuqe. Dhe mund të bllokoni njëkohësisht si kjo me pg_advisory_unlock.
Dhe në përfundim, unë do të doja t'ju tregoja një gjë tjetër magjepsëse. Unë do të krijoj një pamje tjetër. Por unë do të bashkoj tabelën pg_locks me tabelën pg_stat_activity. Dhe pse dua ta bëj këtë? Sepse kjo do të më lejojë të shikoj dhe të shoh të gjitha seancat aktuale dhe të shoh saktësisht se çfarë lloj bravash presin. Dhe kjo është mjaft interesante kur bashkojmë tabelën e kyçjes dhe tabelën e pyetjeve.
Dhe këtu krijojmë pg_stat_view.
Dhe ne përditësojmë rreshtin nga një. Dhe këtu shohim 724. Dhe pastaj përditësojmë rreshtin tonë në tre. Dhe çfarë shihni këtu tani? Këto janë kërkesa, pra ju shihni të gjithë 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 çfarë krijojnë ato. Dhe mund të jetë më e qartë për ju, në mënyrë që të mos keni nevojë të ktheheni në çdo seancë çdo herë dhe të shihni nëse duhet t'i bashkoheni apo jo. Ata e bëjnë atë për ne.
Një veçori tjetër që është shumë e dobishme është pg_blocking_pids. Ju ndoshta nuk keni dëgjuar kurrë për të. Cfare po ben ajo? Na lejon të tregojmë se për këtë sesion 11740 cilat ID të proceseve specifike pret. Dhe ju mund të shihni se 11740 është duke pritur për 724. Dhe 724 është në krye. Dhe 11306 është ID-ja juaj e procesit. Në thelb, ky funksion kalon nëpër tabelën tuaj të kyçjes. Dhe e di që është pak e ndërlikuar, por ju arrini ta kuptoni. Në thelb, ky funksion kalon nëpër këtë tabelë kyçjeje dhe përpiqet të gjejë se ku i jepen këtij ID-je të procesit kyçet që pret. Dhe gjithashtu përpiqet të kuptojë se cilin ID të procesit ka procesi që pret bllokimin. Kështu që ju mund ta ekzekutoni këtë funksion pg_blocking_pids.
Dhe kjo mund të jetë shumë e dobishme. Ne e shtuam këtë vetëm në versionin 9.6, kështu që kjo veçori është vetëm 5 vjeç, por është shumë, shumë e dobishme. E njëjta gjë vlen edhe për kërkesën e dytë. Ajo tregon saktësisht atë që duhet të shohim.
Kjo është ajo për të cilën doja të flisja me ju. Dhe siç prisja, harxhuam të gjithë kohën sepse kishte shumë rrëshqitje. Dhe sllajdet janë të disponueshme për shkarkim. Do të doja t'ju falënderoja që jeni këtu. Jam i sigurt që do të shijoni pjesën tjetër të konferencës, faleminderit shumë!
pyetje:
Për shembull, nëse po përpiqem të përditësoj rreshtat, dhe sesioni i dytë po përpiqet të fshijë të gjithë tabelën. Me sa kuptoj unë, duhet të ketë diçka si një bllokim qëllimi. A ka një gjë të tillë në Postgres?
Le të kthehemi në fillim. Ju mund të mbani mend se kur bëni diçka, për shembull kur bëni një SELECT, ne lëshojmë një AccessShareLock. Dhe kjo parandalon rënien e tavolinës. Pra, nëse ju, për shembull, dëshironi të përditësoni një rresht në një tabelë ose të fshini një rresht, atëherë dikush nuk mund ta fshijë të gjithë tabelën në të njëjtën kohë sepse ju e mbani këtë AccessShareLock mbi të gjithë tabelën dhe mbi rreshtin. Dhe pasi të keni mbaruar, ata mund ta fshijnë atë. Por ndërsa ju ndryshoni drejtpërdrejt diçka atje, ata nuk do të jenë në gjendje ta bëjnë atë.
Le ta bejme sërisht. Le të kalojmë në shembullin e fshirjes. Dhe ju shihni se si ka një bravë ekskluzive në rreshtin mbi të gjithë tabelën.
Kjo do të duket si një bllokim ekskluziv, apo jo?
Po, duket kështu. Unë e kuptoj se për çfarë po flisni. Ju po thoni që nëse bëj një SELECT atëherë kam një ShareExclusive dhe më pas e bëj atë Row Exclusive, a bëhet kjo një problem? Por çuditërisht kjo nuk përbën problem. Kjo duket si rritja e shkallës së bllokimit, por në thelb unë kam një bllokim që parandalon fshirjen. Dhe tani, kur e bëj këtë bllokues më të fuqishëm, ai ende parandalon fshirjen. Kështu që nuk është se po ngjitem. Kjo do të thotë, ai e pengoi atë të ndodhte kur ishte gjithashtu në një nivel më të ulët, kështu që kur e ngre nivelin e tij, përsëri parandalon fshirjen e tabelës.
Unë e kuptoj se për çfarë po flisni. Nuk ka asnjë rast të përshkallëzimit të bravës këtu, ku po përpiqeni të hiqni dorë nga një bllokim për të futur një më të fortë. Këtu ai thjesht e rrit këtë parandalim në të gjithë bordin, kështu që nuk shkakton asnjë konflikt. Por është një pyetje e mirë. Faleminderit shumë që e pyetët këtë!
Çfarë duhet të bëjmë për të shmangur një situatë bllokimi kur kemi shumë seanca, një numër të madh përdoruesish?
Postgres vëren automatikisht situatat e bllokimit. Dhe automatikisht do të fshijë një nga seancat. Mënyra e vetme për të shmangur bllokimin e vdekur është të bllokoni njerëzit në të njëjtin rend. Pra, kur shikoni aplikacionin tuaj, shpesh arsyeja e bllokimeve... Le të imagjinojmë se dua të bllokoj dy gjëra të ndryshme. Një aplikacion kyç tabelën 1 dhe një aplikacion tjetër kyç 2 dhe më pas tabela 1. Dhe mënyra më e lehtë për të shmangur bllokimet është të shikoni aplikacionin tuaj dhe të përpiqeni të siguroheni që kyçja të ndodhë në të njëjtin rend në të gjitha aplikacionet. Dhe kjo zakonisht eliminon 80% të problemeve, sepse të gjitha llojet e njerëzve i shkruajnë këto aplikacione. Dhe nëse i bllokoni në të njëjtin rend, atëherë nuk do të hasni në një situatë bllokimi.
Faleminderit shumë për performancën tuaj! Ju folët për vakum të plotë dhe, nëse e kuptoj mirë, vakum i plotë shtrembëron rendin e regjistrimeve në ruajtje të veçantë, kështu që ato i mbajnë të dhënat aktuale të pandryshuara. Pse vakum i plotë merr akses ekskluziv të bllokimit dhe pse bie ndesh me operacionet e shkrimit?
Kjo është një pyetje e mirë. Arsyeja është se vakuumi i plotë e merr tryezën. Dhe ne në thelb po krijojmë një version të ri të tabelës. Dhe tabela do të jetë e re. Rezulton se ky do të jetë një version krejtësisht i ri i tabelës. Dhe problemi është se kur e bëjmë këtë, ne nuk duam që njerëzit ta lexojnë atë sepse ne kemi nevojë që ata të shohin tabelën e re. Dhe kështu kjo lidhet me pyetjen e mëparshme. Nëse do të mund të lexonim në të njëjtën kohë, nuk do të ishim në gjendje ta zhvendosnim atë dhe t'i drejtonim njerëzit në një tryezë të re. Ne do të duhet të presim që të gjithë të mbarojnë së lexuari këtë tabelë, dhe kështu është në thelb një situatë ekskluzive e bllokimit.
Thjesht themi që kyçemi nga fillimi sepse e dimë që në fund do të na duhet një bllokim ekskluziv për t'i zhvendosur të gjithë në kopjen e re. Kështu që ne mund ta zgjidhim këtë. Dhe ne e bëjmë atë në këtë mënyrë me indeksimin e njëkohshëm. Por kjo është shumë më e vështirë për t'u bërë. Dhe kjo lidhet shumë me pyetjen tuaj të mëparshme në lidhje me lock ekskluzive.
A është e mundur të shtohet koha e mbylljes në Postgres? Në Oracle, për shembull, mund të shkruaj "select to update" dhe të pres 50 sekonda përpara se të përditësohet. Ishte mirë për aplikimin. Por në Postgres, ose duhet ta bëj menjëherë dhe të mos pres fare, ose të pres deri në ca kohë.
Po, ju mund të zgjidhni një afat kohor në bravat tuaja, në bravat tuaja. Ju gjithashtu mund të lëshoni një komandë "no way", e cila do... nëse nuk mund ta merrni menjëherë bllokimin. Prandaj, ose një skadim i bllokimit ose diçka tjetër që do t'ju lejojë ta bëni këtë. Kjo nuk bëhet në nivel sintaksor. Kjo bëhet si një variabël në server. Ndonjëherë kjo nuk mund të përdoret.
Mund të hapni rrëshqitjen 75?
Po.
Dhe pyetja ime është e mëposhtme. Pse të dy proceset e përditësimit presin 703?
Dhe kjo është një pyetje e madhe. Nuk e kuptoj, meqë ra fjala, pse Postgres e bën këtë. Por kur u krijua 703, ai priste 702. Dhe kur shfaqen 704 dhe 705, duket sikur nuk e dinë se çfarë po presin sepse nuk ka asgjë ende atje. Dhe Postgres e bën këtë në këtë mënyrë: kur nuk mund të marrësh një bravë, ai shkruan "Ç'kuptim ka të të përpunojë?", sepse tashmë jeni duke pritur për dikë. Pra, thjesht do ta lëmë të varet në ajër, nuk do ta përditësojë fare. Por çfarë ndodhi këtu? Sapo 702 përfundoi procesin dhe 703 mori bllokimin e tij, sistemi u kthye përsëri. Dhe ajo tha se tani kemi dy njerëz që presin. Dhe pastaj le t'i përditësojmë së bashku. Dhe le të tregojmë se të dy janë në pritje.
Nuk e di pse Postgres e bën këtë. Por ka një problem që quhet f…. Më duket se ky nuk është një term në rusisht. Kjo është kur të gjithë presin për një kështjellë, edhe nëse janë 20 autoritete që presin kështjellën. Dhe befas të gjithë zgjohen në të njëjtën kohë. Dhe të gjithë fillojnë të përpiqen të reagojnë. Por sistemi e bën atë që të gjithë të presin 703. Sepse të gjithë janë në pritje dhe ne do t'i rreshtojmë menjëherë të gjithë. Dhe nëse shfaqet ndonjë kërkesë tjetër e re që është krijuar pas kësaj, për shembull, 707, atëherë do të ketë përsëri zbrazëti.
Dhe mua më duket se kjo është bërë që të mund të themi se në këtë fazë 702 pret 703 dhe të gjithë ata që vijnë më pas nuk do të kenë asnjë hyrje në këtë fushë. Por sapo kamerieri i parë largohet, të gjithë ata që prisnin në atë moment para përditësimit marrin të njëjtin shenjë. Dhe kështu mendoj se kjo është bërë në mënyrë që ne të mund të përpunojmë në mënyrë që ato të porositen siç duhet.
Gjithmonë e kam parë këtë si një fenomen mjaft të çuditshëm. Sepse këtu, për shembull, nuk i rendisim fare. Por më duket se sa herë japim një bravë të re, shikojmë të gjithë ata që janë në proces pritjeje. Më pas i rreshtojmë të gjitha. Dhe pastaj çdo i ri që vjen futet në radhë vetëm kur personi tjetër ka përfunduar së përpunuari. Pyetje shumë e mirë. Faleminderit shumë për pyetjen tuaj!
Më duket se është shumë më logjike kur 705 pret 704.
Por problemi këtu është si vijon. Teknikisht, ju mund të zgjoheni njërën ose tjetrën. Dhe kështu do të zgjojmë njërën ose tjetrën. Por çfarë ndodh në sistem? Ju mund të shihni se si 703 në krye ka bllokuar ID-në e tij të transaksionit. Kështu funksionon Postgres. Dhe 703 është i bllokuar nga ID-ja e tij e transaksionit, kështu që nëse dikush dëshiron të presë, atëherë ai do të presë për 703. Dhe, në thelb, 703 përfundon. Dhe vetëm pas përfundimit të tij, një nga proceset zgjohet. Dhe ne nuk e dimë se cili do të jetë saktësisht ky proces. Pastaj ne përpunojmë gjithçka gradualisht. Por nuk është e qartë se cili proces zgjohet i pari, sepse mund të jetë ndonjë nga këto procese. Në thelb, ne kishim një programues që thoshte se tani mund të zgjojmë cilindo nga këto procese. Ne zgjedhim vetëm një rastësisht. Pra, të dyja duhet të vihen re sepse ne mund të zgjojmë secilin prej tyre.
Dhe problemi është se ne kemi CP-infinity. Dhe për këtë arsye, ka shumë të ngjarë që ne të mund ta zgjojmë atë më vonë. Dhe nëse, për shembull, zgjojmë atë të mëvonshëm, do të presim atë që sapo ka marrë bllokun, kështu që nuk përcaktojmë se kush saktësisht do të zgjohet i pari. Ne thjesht krijojmë një situatë të tillë dhe sistemi do t'i zgjojë ata në një mënyrë të rastësishme.
Ka . Shikoni, ato janë gjithashtu interesante dhe të dobishme. Tema, natyrisht, është tmerrësisht e ndërlikuar. Faleminderit shumë, Bruce!
Burimi: www.habr.com