Bruce Momjian-en 2020ko "Postgres Lock Manager desblokeatzen" hitzaldiaren transkripzioa.
(Oharra: diapositibetako SQL kontsulta guztiak esteka honetatik lor daitezke: )
Kaixo! Oso ona da Errusian berriro hemen egotea. Sentitzen dut iaz ezin izan nuelako etorri, baina aurten Ivanek eta biok plan handiak ditugu. Espero dut hemen askoz maizago egotea. Errusiara etortzea gustatzen zait. Tyumen bisitatuko dut, Tver. Oso pozik nago hiri hauek bisitatu ahal izango ditudalako.
Nire izena Bruce Momjian da. EnterpriseDB-n lan egiten dut eta 23 urte baino gehiago daramatzat Postgresekin lanean. Filadelfian bizi naiz, AEB. Urtean 90 egun inguru bidaiatzen dut. Eta 40 bat hitzalditara joaten naiz. Nire , orain erakutsiko dizkizudan diapositibak biltzen dituena. Hori dela eta, hitzaldiaren ondoren nire webgune pertsonaletik deskargatu ditzakezu. 30 bat aurkezpen ere baditu. Bideoak eta blogeko sarrera ugari ere badaude, 500 baino gehiago. Baliabide nahiko informatiboa da. Eta material hau interesatzen bazaizu, erabiltzera gonbidatzen zaitut.
Irakaslea izan nintzen, irakaslea Postgresekin lanean hasi aurretik. Eta oso pozik nago orain esango dizudana kontatzeko aukera izango dudalako. Hau da nire aurkezpen interesgarrienetako bat. Eta aurkezpen honek 110 diapositiba ditu. Gauza sinpleekin hitz egiten hasiko gara, eta amaieran txostena gero eta konplexuagoa izango da, eta nahiko konplexua izango da.
Elkarrizketa nahiko desatsegina da hau. Blokeatzea ez da gairik ezagunena. Hau nonbait desagertzea nahi dugu. Dentistarenera joatea bezalakoa da.
- Blokeatzea arazo bat da datu-baseetan lan egiten duten eta aldi berean hainbat prozesu exekutatzen dituzten jende askorentzat. Blokeoa behar dute. Hau da, gaur blokeoari buruzko oinarrizko ezagutzak emango dizkizut.
- Transakzio IDak. Aurkezpenaren zati aspergarria da hau, baina ulertu egin behar dira.
- Jarraian blokeo motei buruz hitz egingo dugu. Hau zati nahiko mekanikoa da.
- Eta jarraian blokeoaren adibide batzuk emango ditugu. Eta ulertzea nahiko zaila izango da.
Hitz egin dezagun blokeoari buruz.
Gure terminologia nahiko konplexua da. Zenbatek dakizue nondik datorren pasarte hau? Bi pertsona. Hau Colossal Cave Adventure izeneko joko batekoa da. 80ko hamarkadan testuetan oinarritutako ordenagailu joko bat zen, nire ustez. Han kobazulo batean sartu behar zen, labirinto batean, eta testua aldatu egiten zen, baina edukia gutxi gorabehera berdina zen aldi bakoitzean. Horrela gogoratzen dut joko hau.
Eta hemen ikusten dugu Oracletik heldu zitzaizkigun sarrailen izena. Guk erabiltzen ditugu.
Hemen nahasten nauten terminoak ikusten ditugu. Adibidez, PARTEKATU EGUNERATZEA ECXLUSIVE. Hurrengoa PARTEKATU RAW ECXLUSIVE. Egia esateko, izen hauek ez daude oso argi. Saiatuko gara zehatzago kontuan hartzen. Batzuek "partekatu" hitza dute, hau da, bereiztea esan nahi du. Batzuek "esklusibo" hitza dute. Batzuek bi hitz hauek dituzte. Sarraila hauek nola funtzionatzen duten ikusten hasi nahiko nuke.
Eta βsarbideβ hitza ere oso garrantzitsua da. Eta βerrankaβ hitzak kate bat dira. Hau da, sarbide banaketa, errenkaden banaketa.
Postgres-en ulertu behar den beste gai bat, zoritxarrez ezin izango dudan hitzaldian landu, MVCC da. Gai honi buruzko aurkezpen bat daukat nire webgunean. Eta aurkezpen hau gogorra dela uste baduzu, ziurrenik MVCC da nire gogorrena. Eta interesatzen bazaizu, webgunean ikus dezakezu. Bideoa ikus dezakezu.
Ulertu behar dugun beste gauza bat transakzio IDak dira. Transakzio askok ezin dute funtzionatu identifikatzaile esklusiborik gabe. Eta hemen transakzio bat zer den azaltzen dugu. Postgres-ek bi transakzio-zenbaketa-sistema ditu. Badakit hau ez dela oso irtenbide polita.
Kontuan izan, gainera, diapositibak ulertzea nahiko zaila izango dela, beraz, gorriz nabarmentzen dena arreta jarri behar zaiona da.
Ikus dezagun. Transakzio-zenbakia gorriz nabarmenduta dago. Hautatu pg_back funtzioa hemen erakusten da. Nire transakzioa eta transakzioaren IDa itzultzen ditu.
Beste gauza bat, aurkezpen hau gustatzen bazaizu eta zure datu-basean exekutatu nahi baduzu, arrosa koloreko esteka honetara joan zaitezke eta aurkezpen honetarako SQL-a deskargatu dezakezu. Eta zure PSQL-n exekutatu dezakezu eta aurkezpen osoa berehala agertuko da zure pantailan. Ez du lorerik izango, baina guk behintzat ikus dezakegu.
Kasu honetan transakzio IDa ikusiko dugu. Hau da esleitu genion zenbakia. Eta beste transakzio ID mota bat dago Postgres-en, transakzio ID birtuala deritzona
Eta hau ulertu behar dugu. Hau oso garrantzitsua da, bestela ezingo dugu ulertu Postgres-en blokeatzea.
Transakzio-ID birtuala balio iraunkorrik ez duen transakzio-ID bat da. Adibidez, SELECT komando bat exekutatzen badut, ziurrenik ez dut datu-basea aldatuko, ez dut ezer blokeatuko. Beraz, SELECT soil bat exekutatzen dugunean, ez diogu transakzio horri ID iraunkorrik ematen. Han NAN birtuala baino ez diogu ematen.
Eta honek Postgres-en errendimendua hobetzen du, garbiketa-gaitasunak hobetzen ditu, beraz, transakzio-ID birtuala bi zenbakiz osatuta dago. Barraren aurreko lehen zenbakia backend IDa da. Eta eskuinaldean kontagailu bat besterik ez dugu ikusten.
Hori dela eta, eskaera bat exekutatzen badut, backend IDa 2 dela esaten du.
Eta horrelako transakzio batzuk exekutatzen baditut, kontsulta bat egiten dudan bakoitzean kontagailua handitzen dela ikusiko dugu. Adibidez, 2/10, 2/11, 2/12, etab.
Kontuan izan hemen bi zutabe daudela. Ezkerrean transakzio birtualaren IDa ikusiko dugu - 2/12. Eta eskuinaldean transakzio ID iraunkor bat dugu. Eta eremu hau hutsik dago. Eta transakzio honek ez du datu-basea aldatzen. Beraz, ez diot transakzio ID iraunkorrik ematen.
Analisi komandoa ((ANALYZE) exekutatu bezain laster, kontsulta berak transakzio ID iraunkor bat ematen dit. Begira nola aldatu zaigun hau. Lehen ez nuen NAN hau, baina orain daukat.
Beraz, hona beste eskaera bat, beste transakzio bat. Transakzio birtualaren zenbakia 2/13 da. Eta transakzio ID iraunkor bat eskatzen badut, kontsulta exekutatzen dudanean, lortuko dut.
Beraz, beste behin. Transakzio ID birtuala eta transakzio ID iraunkor bat ditugu. Ulertu puntu hau Postgres-en portaera ulertzeko.
Hirugarren atalera joango gara. Hemen Postgres-eko sarraila mota ezberdinetatik ibiliko gara. Ez da oso interesgarria. Azken atala askoz interesgarriagoa izango da. Baina oinarrizko gauzak kontuan hartu behar ditugu, bestela ez baitugu ulertuko gero zer gertatuko den.
Atal hau zeharkatuko dugu, blokeo mota bakoitza aztertuko dugu. Eta nola instalatu diren, nola funtzionatzen duten, zenbait kontsulta erakutsiko dizkizut Postgres-en blokeoa nola funtzionatzen duen ikusteko erabil ditzakezun kontsulta batzuk.
Kontsulta bat sortzeko eta Postgres-en zer gertatzen den ikusteko, kontsulta sistemaren ikuspegian igorri behar dugu. Kasu honetan, pg_lock gorriz nabarmentzen da. Pg_lock sistema-taula bat da, une honetan Postgres-en zer blokeo erabiltzen ari diren esaten diguna.
Hala ere, oso zaila egiten zait pg_lock berez erakustea nahiko konplexua delako. Beraz, pg_locks erakusten duen ikuspegi bat sortu nuen. Eta hobeto ulertzeko aukera ematen didan lan batzuk ere egiten dizkit. Hau da, nire sarrailak, nire saioa eta abar baztertzen ditu. SQL estandarra besterik ez da eta gertatzen ari dena hobeto erakusteko aukera ematen dizu.
Beste arazo bat ikuspegi hau oso zabala dela da, beraz, bigarren bat sortu behar dut - lockview2.
Eta taulako zutabe gehiago erakusten dizkit. Eta gainerako zutabeak erakusten dizkidan beste bat. Hau nahiko konplexua da, beraz, ahalik eta errazen aurkezten saiatu naiz.
Beraz, Lockdemo izeneko taula sortu genuen. Eta hor lerro bat sortu genuen. Hau da gure eredu-taula. Eta atalak sortuko ditugu blokeoen adibideak erakusteko.
Beraz, errenkada bat, zutabe bat. Lehenengo blokeo motari ACCESS SHARE deitzen zaio. Hau da blokeo murrizte txikiena. Horrek esan nahi du ia ez duela gatazkarik beste sarrailekin.
Eta blokeo bat esplizituki definitu nahi badugu, "blokeatu taula" komandoa exekutatzen dugu. Eta, jakina, blokeatu egingo da, hau da, ACCESS SHARE moduan blokeo-taula abiarazten dugu. Eta atzeko planoan PSQL exekutatzen badut, nire lehen saiotik bigarren saioa hasten dut horrela. Hau da, zer egingo dut hemen? Beste saio batera joaten naiz eta "erakutsi eskaera honen blokeo-ikuspegia" esaten diot. Eta hemen AccessShareLock dut taula honetan. Hauxe da nik eskatu nuena. Eta blokea esleitu dela dio. Oso sinplea.
Gainera, bigarren zutabeari erreparatzen badiogu, hor ez dago ezer. Hutsik daude.
Eta "SELECT" komandoa exekutatzen badut, hau da AccessShareLock eskatzeko modu inplizitua (esplizitua). Beraz, nire taula askatu eta kontsulta exekutatzen dut eta kontsultak hainbat errenkada itzultzen ditu. Eta lerroetako batean AccessShareLock ikusiko dugu. Horrela, SELECT-ek AccessShareLock deitzen du mahai gainean. Eta ez du ia ezerrekin gatazkan, maila baxuko blokeoa delako.
Zer gertatzen da SELECT bat exekutatzen badut eta hiru taula ezberdin baditut? Lehen taula bakarra exekutatzen nuen, orain hiru exekutatzen ari naiz: pg_class, pg_namespace eta pg_attribute.
Eta orain kontsultara begiratzen dudanean, 9 AccessShareLocks ikusten ditut hiru tauletan. Zergatik? Hiru taula urdinez nabarmentzen dira: pg_attribute, pg_class, pg_namespace. Baina, gainera, ikus dezakezu taula hauen bidez definitzen diren indize guztiek AccessShareLock ere badutela.
Eta ia besteekin gatazkarik ez duen blokeoa da. Eta egiten duen guztia, hautatzen dugun bitartean, taula berrezartzea eragozten digu. Zentzuzkoa du. Hau da, taula bat hautatzen badugu, momentu horretan desagertzen da, orduan hau gaizki dago, beraz AccessShare maila baxuko blokeoa da, "ez utzi taula hau lanean nagoen bitartean" esaten diguna.. Funtsean, hori da egiten duen guztia.
ROW SHARE - Blokeo hau apur bat desberdina da.
Har dezagun adibide bat. SELECT ROW SHARE errenkada bakoitza banan-banan blokeatzeko metodoa. Horrela inork ezin ditu ezabatu edo aldatu ikusten ari garen bitartean.
Beraz, zer egiten du SHARE LOCK-ek? Transakzio IDa 681 dela ikusten dugu SELECT for. Eta hau interesgarria da. Zer gertatu da hemen? Zenbakia ikusten dugun lehen aldia "Blokeatu" eremuan dago. Transakzio IDa hartzen dugu eta modu esklusiboan blokeatzen ari dela esaten du. Egiten duen guztia taularen nonbait teknikoki blokeatuta dagoen errenkada bat daukadala esaten du. Baina ez du non zehazki esaten. Geroxeago aztertuko dugu zehatzago hau.
Hemen esaten dugu sarraila guk erabiltzen dugula.
Beraz, blokeo esklusibo batek esplizituki esaten du esklusiboa dela. Eta, gainera, taula honetako errenkada bat ezabatzen baduzu, horixe gertatuko da, ikus dezakezun bezala.
SHARE EXCLUSIVE blokeo luzeagoa da.
Hau da (ANALISI) erabiliko den analizatzailearen komandoa.
BLOKEA PARTEKATU - partekatzeko moduan esplizituki blokea dezakezu.
Indize esklusibo bat ere sor dezakezu. Eta han parte den SHARE LOCK ikus dezakezu. Eta mahaia blokeatzen du eta SHARE LOCK bat jartzen du.
Lehenespenez, taula batean SHARE LOCK-ek esan nahi du beste pertsonek taula irakur dezaketela, baina inork ezin duela aldatu. Eta horixe gertatzen da indize esklusibo bat sortzen duzunean.
Aldi berean indize esklusibo bat sortzen badut, beste blokeo mota bat izango dut, gogoratzen duzunez, aldi berean indizeak erabiltzeak blokeo-eskakizuna murrizten duelako. Eta blokeo normal bat erabiltzen badut, indize normal bat, orduan eragotziko dut taula-indizean idaztea sortzen den bitartean. Aldi berean indize bat erabiltzen badut, beste blokeo mota bat erabili behar dut.
SHARE ROW EXCLUSIVE - berriro ere esplizituki ezar daiteke (esplizituki).
Edo arau bat sor dezakegu, hau da, erabiliko den kasu zehatz bat hartu.
Blokeatze esklusiboak esan nahi du inork ezin duela mahaia aldatu.
Hemen sarraila mota desberdinak ikusten ditugu.
ACCESS EXCLUSIVE, adibidez, blokeatzeko komando bat da. Adibidez, egiten baduzu CLUSTER table, orduan horrek esan nahi du ezingo duela han inork idatzi. Eta taula bera ez ezik, aurkibideak ere blokeatzen ditu.
Hau ACCESS BAKARRIZKO blokeoaren bigarren orrialdea da, eta bertan ikusten dugu zehazki zer blokeatzen duen taulan. Banakako mahai errenkadak blokeatzen ditu, eta hori nahiko interesgarria da.
Hori da eman nahi nuen oinarrizko informazio guztia. Sarrailei buruz hitz egin dugu, transakzio IDei buruz, transakzio ID birtualei buruz hitz egin dugu, transakzio ID iraunkorrei buruz.
Eta orain blokeo-adibide batzuen bidez joango gara. Hau da parterik interesgarriena. Oso kasu interesgarriak aztertuko ditugu. Eta nire helburua aurkezpen honetan Postgres-ek benetan egiten ari dena hobeto ulertzea da zenbait gauza blokeatzen saiatzen denean. Nire ustez, oso ona da zatiak blokeatzen.
Ikus ditzagun adibide zehatz batzuk.
Taulekin eta errenkada batekin hasiko gara taula batean. Zerbait sartzen dudanean ExclusiveLock, Transaction ID eta ExclusiveLock bistaratzen ditut taulan.
Zer gertatzen da beste bi errenkada sartzen baditut? Eta orain gure taulak hiru errenkada ditu. Eta errenkada bat txertatu nuen eta irteera gisa lortu nuen. Eta beste bi errenkada sartzen baditut, zer da arraroa? Hemen gauza arraro bat dago, hiru errenkada gehitu ditudalako taula honetan, baina oraindik bi errenkada dauzkat blokeo-taulan. Eta hau da, funtsean, Postgres-en oinarrizko jokabidea.
Jende askok uste du datu-base batean 100 errenkada blokeatzen badituzu, 100 blokeo sarrera sortu beharko dituzula. 1 errenkada aldi berean blokeatzen baditut, 000 kontsulta beharko ditut. Eta blokeatzeko milioi bat edo mila milioi behar baditut. Baina hau egiten badugu, ez du oso ondo funtzionatuko. Errenkada bakoitzerako blokeo sarrerak sortzen dituen sistema bat erabili baduzu, hori konplikatua dela ikusiko duzu. Berehala definitu behar duzulako gainezka egin dezakeen blokeo-taula bat, baina Postgresek ez du hori egiten.
Eta diapositiba honi buruz benetan garrantzitsua dena da argi eta garbi erakusten duela MVCC barruan exekutatzen den beste sistema bat errenkada indibidualak blokeatzen dituena. Beraz, milaka milioi errenkada blokeatzen dituzunean, Postgres-ek ez ditu mila milioi bereizi blokeatzeko komandoak sortzen. Eta horrek oso eragin ona du produktibitatean.
Zer gertatzen da eguneratze batekin? Errenkada eguneratzen ari naiz orain, eta aldi berean bi eragiketa ezberdin egin dituela ikusten duzu. Taula blokeatu zuen aldi berean, baina indizea ere blokeatu zuen. Eta indizea blokeatu behar zuen, mahai honetan muga bereziak daudelako. Eta inork ez duela aldatzen ziurtatu nahi dugu, beraz, blokeatzen dugu.
Zer gertatzen da bi errenkada eguneratu nahi baditut? Eta ikusten dugu berdin jokatzen duela. Eguneratze bikoitza egiten ditugu, baina blokeo-lerro kopuru berdina.
Postgresek hau nola egiten duen galdetzen ari bazara, MVCCri buruzko nire hitzaldiak entzun beharko dituzu Postgres-ek aldatzen dituen lerro hauek nola markatzen dituen barnean jakiteko. Eta Postgres-ek badu hori egiteko modu bat, baina ez du mahaiaren blokeo mailan egiten, maila baxuago eta eraginkorrago batean egiten du.
Zerbait ezabatu nahi badut? Esaterako, errenkada bat ezabatzen badut eta oraindik nire bi sarrera blokeatzaileak baditut, eta denak ezabatu nahi baditut ere, hor daude oraindik.
Eta, adibidez, 1 lerro sartu nahi ditut, eta gero 000 lerro ezabatu edo gehitu, gero gehitzen edo aldatzen ditudan lerro indibidual horiek, ez dira hemen grabatzen. Maila baxuago batean idatzita daude seriearen barruan. Eta MVCCren hitzaldian honetaz hitz egin nuen zehatz-mehatz. Baina oso garrantzitsua da blokeoak aztertzen ari zarenean ziurtatzea taula mailan blokeatzen ari zarela eta hemen errenkada indibidualak nola grabatzen diren ikusten ez duzula.
Zer gertatzen da blokeo esplizitua?
Freskatu sakatzen badut, bi errenkada blokeatuta dauzkat. Eta denak hautatzen baditut eta "eguneratu nonahi" sakatzen baditut, bi bloke-erregistro dauzkat oraindik.
Ez dugu erregistro bereizirik sortzen errenkada bakoitzerako. Gero produktibitatea jaisten delako, gehiegi egon daitekeelako. Eta baliteke egoera desatsegin batean aurkitzea.
Eta gauza bera, partekatua egiten badugu, 30 aldiz egin dezakegu.
Gure taula leheneratzen dugu, dena ezabatzen dugu eta, ondoren, berriro errenkada bat txertatzen dugu.
Postgres-en ikusten duzun beste portaera bat oso ezaguna eta nahi den jokaera da eguneraketa bat edo hautaketa bat egin dezakezula. Eta hau egin dezakezu aldi berean. Eta hautatzeak ez du blokeatzen eguneratzea eta gauza bera kontrako norabidean. Irakurleari esaten diogu idazlea ez blokeatzeko, eta idazleak ez zuen irakurlea blokeatu.
Honen adibide bat erakutsiko dizut. Aukera bat egingo dut orain. Ondoren txertaketa egingo dugu. Eta gero ikus dezakezu - 694. Txertaketa hau egin duen transakzioaren IDa ikus dezakezu. Eta horrela funtzionatzen du.
Eta nire backend IDa aztertzen badut, orain 695 da.
Eta nire taulan 695 agertzen direla ikus dezaket.
Eta hemen horrela eguneratzen badut, beste kasu bat jasoko dut. Kasu honetan, 695 blokeo esklusibo bat da, eta eguneratzeak portaera bera du, baina ez dago haien arteko gatazkarik, eta hori nahiko ezohikoa da.
Eta ikus dezakezu goiko aldean ShareLock dela, eta behealdean ExclusiveLock dela. Eta bi transakzioak ondo atera ziren.
Eta MVCCn nire hitzaldia entzun behar duzu hau nola gertatzen den ulertzeko. Baina hau aldi berean egin dezakezun ilustrazio bat da, hau da, HAUTATU eta EGUNERATU aldi berean egin.
Berrezarri dezagun eta egin dezagun beste eragiketa bat.
Bi eguneraketa aldi berean errenkada berean exekutatzen saiatzen bazara, blokeatu egingo da. Eta gogoratu, esan nuen irakurleak ez duela idazlea blokeatzen, eta idazleak ez duela irakurlea blokeatzen, baina idazle batek beste idazle bat blokeatzen duela. Hau da, ezin dugu bi pertsona errenkada bera aldi berean eguneratu. Horietako bat amaitu arte itxaron behar duzu.
Eta hori ilustratzeko, Lockdemo taula aztertuko dut. Eta errenkada bat ikusiko dugu. 698 transakzio bakoitzeko.
Hau 2ra eguneratu dugu. 699 da lehen eguneraketa. Eta arrakastatsua izan da edo transakzio baten zain dago eta gurekin berresteko edo bertan behera uzteko zain dago.
Baina begiratu beste zerbait - 2/51 da gure lehen transakzioa, gure lehen saioa. 3/112 balio hori 3ra aldatu zuen goitik datorren bigarren eskaera da. Eta ohartzen bazara, goikoak bere burua blokeatu zuen, hau da, 699. Baina 3/112k ez zuen blokeoa eman. Lock_mode zutabeak zer zain dagoen esaten du. 699 espero du. Eta 699 non dagoen begiratuz gero, handiagoa da. Eta zer egin zuen lehen saioak? Blokeo esklusibo bat sortu zuen bere transakzio IDan. Honela egiten du Postgresek. Bere transakzio ID propioa blokeatzen du. Eta norbaitek baieztatu edo bertan behera uzteko itxaron nahi baduzu, orduan itxaron beharko duzu transakzio bat dagoen bitartean. Eta horregatik lerro arraro bat ikus dezakegu.
Begira dezagun berriro. Ezkerrean gure prozesatzeko IDa ikusiko dugu. Bigarren zutabean gure transakzio ID birtuala ikusiko dugu, eta hirugarrenean lock_type ikusiko dugu. Zer esan nahi du honek? Funtsean, transakzio IDa blokeatzen ari dela dioena da. Baina konturatu beheko errenkada guztiek erlazioa esaten dutela. Eta beraz, bi sarraila mota dituzu mahai gainean. Erlazio blokeoa dago. Eta gero, transakzioid blokeoa dago, non zure kabuz blokeatzen duzun, hau da, zehazki, lehenengo errenkadan edo behealdean gertatzen dena, non transakzioid-a dagoen, non 699 itxaroten dugu bere funtzionamendua amaitzeko.
Ikusiko dut hemen zer gertatzen den. Eta hemen bi gauza gertatzen dira aldi berean. Bere burua blokeatzen duen lehen errenkadan transakzio ID blokeoa ikusten ari zara. Eta bere burua blokeatzen du jendea itxaroteko.
6. lerroari begiratuz gero, lehenengoaren sarrera bera da. Eta, beraz, 699 transakzioa blokeatuta dago. 700 ere autoblokeagarria da. Eta gero beheko lerroan ikusiko duzu 699aren zain gaudela bere funtzionamendua amaitzeko.
Eta lock_typen, tuplak zenbakiak ikusten dituzu.
0/10 dela ikus dezakezu. Eta hau orri-zenbakia da, eta baita errenkada zehatz honen desplazamendua ere.
Eta ikusten duzu 0/11 bihurtzen dela eguneratzen dugunean.
Baina errealitatean 0/10 da, eragiketa honetarako itxaronaldia dagoelako. Baieztatzeko zain nagoen seriea dela ikusteko aukera dugu.
Behin baieztatu eta konprometitu sakatu ondoren, eta eguneratzea amaitzen denean, hau da berriro lortzen duguna. 700. transakzioa da blokeo bakarra, ez du beste inor itxarongo konprometituta zegoelako. Transakzioa amaitu arte itxaron besterik ez du. Behin 699 agortuta, ez dugu ezer itxaron. Eta orain 700 transakzioak dio dena ondo dagoela, baimendutako mahai guztietan behar dituen blokeo guztiak dituela.
Eta hori guztia are gehiago zailtzeko, beste ikuspegi bat sortzen dugu, oraingoan hierarkia bat emango diguna. Ez dut espero eskaera hau ulertzea. Baina honek gertatzen ari denaren ikuspegi argiagoa emango digu.
Ikuspegi errekurtsibo bat da eta beste atal bat ere badu. Eta gero dena berriro elkartzen du. Erabili dezagun hau.
Zer gertatzen da aldi berean hiru eguneraketa egiten badugu eta errenkada orain hirukoa dela esaten badugu. Eta 3tik 4ra aldatuko dugu.
Eta hemen ikusten dugu 4. Eta transakzio ID 702.
Eta gero 4tik 5era aldatuko dut. Eta 5etik 6ra, eta 6tik 7ra. Eta transakzio hau amaitzeko zain egongo diren hainbat pertsona lerrokatuko ditut.
Eta dena argi geratzen da. Zein da lehen ilara? Hau 702 da. Hasiera batean balio hau ezarri zuen transakzioaren IDa da. Zer dago idatzita nire Emandako zutabean? markak ditut f. Hauek dira nire eguneraketak (5, 6, 7) onartu ezin direnak, 702 transakzio IDaren amaieraren zain gaudelako. Bertan transakzio ID blokeatzea dugu. Eta horrek 5 transakzio ID blokeoak eragiten ditu.
Eta 704an, 705ean begiratuz gero, oraindik ez da ezer idatzi han, oraindik ez baitakite zer gertatzen ari den. Zer gertatzen ari den ideiarik ez dutela idazten dute, besterik gabe. Eta lotara joango dira, norbait amaitu eta errenkadak aldatzeko aukera dagoenean esnatzeko zain daudelako.
Honela dirudi. Argi dago denak 12. lerroaren zain daudela.
Hau da hemen ikusi duguna. Hona hemen 0/12.
Beraz, lehen transakzioa onartu ondoren, hemen ikus dezakezu hierarkiak nola funtzionatzen duen. Eta orain dena argi geratzen da. Guztiak garbi bihurtzen dira. Eta, egia esan, oraindik zain daude.
Hona hemen gertatzen ari dena. 702 konpromisoa hartzen du. Eta orain 703-k errenkada-blokeo hau lortzen du, eta gero 704 703-k konprometitu arte itxaroten hasten da. Eta horren zain dago 705a ere. Eta hori guztia amaitutakoan, beren burua garbitzen dute. Eta denak ilaran daudela adierazi nahi nuke. Eta hori oso antzekoa da auto-ilarak denak lehen autoaren zain daudenean. Lehenengo kotxea gelditzen da eta denak lerro luze batean ilaran jartzen dira. Gero mugitzen da, hurrengo autoak aurrera egin dezake eta bere blokea lortu, etab.
Eta hau nahikoa konplikatua iruditu ez bazaizu, orain blokeoei buruz hitz egingo dizugu. Ez dakit zuetako zeinek topatu dituen. Datu-base sistemetan arazo nahiko ohikoa da. Baina blokeoak dira saio bat beste saio baten zain dagoenean zerbait egiteko. Eta momentu honetan beste saio bat lehen saioaren zain dago zerbait egiteko.
Eta, adibidez, Ivanek esaten badu: Β«Emaidazu zerbaitΒ», eta nik esaten badut: Β«Ez, beste zerbait ematen badidazu bakarrik emango dizutΒ». Eta berak esaten du: "Ez, ez dizut emango, zuk ematen ez badidazu". Eta blokeo egoera batean geratzen gara. Ziur nago Ivanek ez duela hori egingo, baina ulertzen duzu zer esanahia duen bi pertsona ditugula zerbait lortu nahi dutenak eta ez daudela prest emateko beste pertsonak nahi duena eman arte. Eta ez dago irtenbiderik.
Eta funtsean, zure datu-baseak hori detektatu behar du. Eta gero saioren bat ezabatu edo itxi behar duzu, bestela betirako geratuko direlako. Eta datu-baseetan ikusten dugu, sistema eragileetan ikusten dugu. Eta prozesu paraleloak ditugun toki guztietan, hori gerta daiteke.
Eta orain bi blokeo blokeo instalatuko ditugu. 50 eta 80 jarriko ditugu. Lehen lerroan, 50etik 50era eguneratuko dut. 710 transakzio zenbakia jasoko dut.
Eta gero 80tik 81era aldatuko dut, eta 50etik 51ra.
Eta hauxe izango da itxura. Beraz, 710ak errenkada bat blokeatuta dauka, eta 711 berrespenaren zain dago. Hau eguneratu genuenean ikusi genuen. 710 da gure seriearen jabea. Eta 711 710aren zain dago transakzioa amaitzeko.
Eta blokeoak zein ilaratan gertatzen diren ere esaten du. Eta hemen hasten da arraroa egiten.
Orain 80tik 80era eguneratzen ari gara.
Eta hor hasten dira blokeoak. 710 711ren erantzunaren zain dago, eta 711 710aren zain. Eta hau ez da ondo amaituko. Eta honetatik ez dago aterabiderik. Eta elkarrengandik erantzuna esperoko dute.
Eta dena atzeratzen hasiko da. Eta ez dugu hori nahi.
Eta Postgresek hori gertatzen denean ohartzeko moduak ditu. Eta hori gertatzen denean, errore hau jasoko duzu. Eta hortik argi dago halako prozesu bat beste prozesu bateko SHARE LOCK baten zain dagoela, hau da, 711 prozesuak blokeatuta dagoena. Eta prozesu hori SHARE LOCK bat emateko zain zegoen transakzio ID batean eta halako batean blokeatuta zegoen. Beraz, blokeo egoera bat dago hemen.
Hiru norabideko blokeoak daude? Posible al da? Bai.
Zenbaki hauek taula batean sartzen ditugu. 40tik 40ra aldatzen dugu, blokeoak egiten ditugu.
60tik 61era aldatzen dugu, 80tik 81era.
Eta gero 80 aldatu eta gero boom!
Eta 714 715aren zain dago orain. 716. 715.aren zain dago. Eta ezin da ezer egin horri buruz.
Hemen jada ez dago bi pertsona, dagoeneko hiru lagun daude hemen. Nik zuregandik zerbait nahi dut, honek hirugarren pertsona batengandik zerbait nahi du, eta hirugarren pertsonak nigandik zerbait nahi du. Eta hiruko itxaronean amaitzen dugu, denok gaudelako beste pertsonak egin behar duena noiz amaituko zain.
Eta Postgresek badaki zein errenkadan gertatzen den. Eta, beraz, hurrengo mezua emango dizu, hiru sarrerak elkar blokeatzen ari diren arazo bat duzula erakusten duena. Eta hemen ez dago murrizketarik. 20 sarrerak elkar blokeatzen duten kasua izan daiteke.
Hurrengo arazoa serializagarria da.
Serializatu daitekeen blokeo berezia bada.
Eta 719ra itzuliko gara. Bere irteera nahiko normala da.
Eta sakatu dezakezu transakzioa serializagarritik egiteko.
Eta konturatzen zara orain beste mota bateko SA blokeoa duzula - serializagarria esan nahi du.
Beraz, SARieadLock izeneko blokeo mota berri bat dugu, serieko blokeoa dena eta serieak sartzeko aukera ematen duena.
Eta indize bereziak ere txerta ditzakezu.
Taula honetan indize bereziak ditugu.
Beraz, hemen 2 zenbakia jartzen badut, 2 bat dut. Baina goialdean, beste 2 bat jarri dut. Eta ikus dezakezu 721 blokeo esklusiboa duela. Baina orain 722 721 bere funtzionamendua amaitzeko zain dago, ezin duelako 2 sartu 721ekin zer gertatuko den jakin arte.
Eta azpitransakzioa egiten badugu.
Hemen 723 ditugu.
Eta puntua gordetzen badugu eta gero eguneratzen badugu, transakzio ID berri bat jasoko dugu. Hau da kontziente izan behar duzun beste portaera eredu bat. Hau itzultzen badugu, transakzioaren IDa desagertu egingo da. 724 irteten ari da. Baina orain 725 ditugu.
Beraz, zer egiten saiatzen ari naiz hemen? Aurki ditzakezun ezohiko blokeoen adibideak erakusten saiatzen ari naiz: serializagarriak diren blokeoak edo SAVEPOINT izan, hauek blokeo-taulan agertuko diren blokeo mota desberdinak dira.
Hau blokeo esplizituak (esplizituak) sortzea da, pg_advisory_lock dutenak.
Eta blokeo mota aholku gisa zerrendatuta dagoela ikusten duzu. Eta hemen gorriz "aholkularitza" dio. Eta aldi berean blokeatu dezakezu pg_advisory_unlock-ekin.
Eta bukatzeko, beste gauza hunkigarri bat erakutsi nahiko nizuke. Beste ikuspegi bat sortuko dut. Baina pg_locks taularekin bat egingo dut pg_stat_activity taularekin. Eta zergatik egin nahi dut hau? Honek oraingo saio guztiak begiratu eta ikusteko aukera emango dit eta zehatz-mehatz nolako sarrailak zain dauden ikusteko. Eta hau nahiko interesgarria da blokeo-taula eta kontsulta-taula bateratzen ditugunean.
Eta hemen pg_stat_view sortzen dugu.
Eta errenkada bat eguneratzen dugu. Eta hemen 724 ikusiko dugu. Eta gero gure errenkada eguneratzen dugu hirura. Eta zer ikusten duzu orain hemen? Hauek eskaerak dira, hau da, ezkerreko zutabean agertzen diren eskaeren zerrenda osoa ikusten duzu. Eta gero eskuinaldean blokeoak eta sortzen dutena ikus daitezke. Eta argiagoa izan daiteke zuretzako, saio bakoitzera itzuli beharrik izan ez dezazun aldiro eta bertan sartu behar duzun edo ez ikusteko. Guregatik egiten dute.
Oso erabilgarria den beste ezaugarri bat da pg_blocking_pids. Sekula ez duzu haren berririk entzun. Zer egiten ari da? Saio honetarako 11740 zein prozesu ID zehatzen zain dagoen esatea ahalbidetzen digu. Eta ikus dezakezu 11740 724ren zain dagoela. Eta 724 goialdean dago. Eta 11306 da zure prozesuaren IDa. Funtsean, funtzio hau zure blokeo-taulatik igarotzen da. Eta badakit pixka bat konplikatua dela, baina ulertzea lortzen duzu. Funtsean, funtzio hau blokeo-taula honetatik igarotzen da eta prozesu ID honi itxaroten ari den blokeoak non ematen zaizkion bilatzen saiatzen da. Eta blokeoaren zain dagoen prozesuak zein prozesu ID duen jakiten ere saiatzen da. Beraz, funtzio hau exekutatu dezakezu pg_blocking_pids.
Eta hau oso erabilgarria izan daiteke. Hau 9.6 bertsioan bakarrik gehitu dugu, beraz, funtzio honek 5 urte baino ez ditu, baina oso-oso erabilgarria da. Eta gauza bera gertatzen da bigarren eskaerarekin. Ikusi behar duguna zehatz-mehatz erakusten du.
Honetaz hitz egin nahi nizun. Eta espero nuen bezala, denbora guztia erabili genuen txirrista asko zeudelako. Eta diapositibak deskargatu daitezke. Eskerrak eman nahi nizkizuke hemen egoteagatik. Ziur gainontzeko hitzaldian gozatuko duzula, eskerrik asko!
galderak:
Adibidez, errenkadak eguneratzen saiatzen ari banaiz eta bigarren saioan taula osoa ezabatzen saiatzen ari naiz. Ulertzen dudanez, intentzio blokeoa bezalako zerbait egon beharko litzateke. Ba al dago horrelakorik Postgresen?
Itzuli gaitezen hasiera-hasierara. Gogoan izan dezakezu ezer egiten duzunean, adibidez SELECT bat egiten duzunean, AccessShareLock bat igortzen dugula. Eta horrek mahaia erortzea eragozten du. Beraz, adibidez, taula bateko errenkada bat eguneratu nahi baduzu edo errenkada bat ezabatu nahi baduzu, norbaitek ezingo du taula osoa ezabatu aldi berean, AccessShareLock hau mahai osoan eta errenkadaren gainean mantentzen duzulako. Eta amaitutakoan, ezabatu ahal izango dute. Baina zuzenean zerbait aldatzen duzun bitartean, ezin izango dute egin.
Egin dezagun berriro. Goazen ezabatzeko adibidera. Eta ikusten duzu nola blokeo esklusibo bat dagoen mahai osoaren gaineko errenkadan.
Blokeo esklusiboaren itxura izango du, ezta?
Bai, badirudi. Ulertzen dut zertaz ari zaren. Esaten ari zara SELECT bat egiten badut ShareExclusive bat daukadala eta gero Row Exclusive egiten badut, hori arazo bihurtzen al da? Baina harrigarria bada ere, honek ez du arazorik sortzen. Horrek blokeo-maila handitzea dirudi, baina funtsean ezabatzea eragozten duen blokeoa dut. Eta orain, blokeo hau indartsuagoa egiten dudanean, oraindik ezabatzea eragozten du. Beraz, ez da igotzen naizen bezala. Hau da, maila baxuagoan zegoenean ere gertatzea eragotzi zuen, beraz, maila igotzen dudanean oraindik mahaia ezabatzea eragozten du.
Ulertzen dut zertaz ari zaren. Hemen ez dago blokeoa handitzeko kasurik, non blokeo bat uzten saiatzen ari zaren indartsuagoa sartzeko. Hemen prebentzio hori areagotzen du, beraz, ez du inolako gatazkarik sortzen. Baina galdera ona da. Mila esker hau galdetzeagatik!
Zer egin behar dugu blokeo egoera saihesteko saio asko, erabiltzaile kopuru handia dugunean?
Postgres-ek automatikoki antzematen ditu blokeo egoerak. Eta automatikoki ezabatuko du saioetako bat. Hildako blokeoak saihesteko modu bakarra pertsonak ordena berean blokeatzea da. Beraz, zure aplikazioa begiratzen duzunean, askotan blokeoen arrazoia... Imajina dezagun bi gauza ezberdin blokeatu nahi ditudala. Aplikazio batek 1. taula blokeatzen du eta beste aplikazio batek 2. eta gero 1. taula. Eta blokeoak saihesteko modurik errazena zure aplikazioa begiratu eta aplikazio guztietan blokeoa ordena berean gertatzen dela ziurtatzen saiatzea da. Eta honek normalean arazoen %80a kentzen du, mota guztietako jendeak idazten dituelako aplikazio hauek. Eta ordena berean blokeatzen badituzu, ez duzu blokeo egoerarik aurkituko.
Mila esker zure emanaldiagatik! Hutsean beteta hitz egin duzu eta, ondo ulertzen badut, hutsean beteak biltegiratze bereizitako erregistroen ordena desitxuratzen du, beraz, uneko erregistroak aldatu gabe mantentzen dituzte. Zergatik hartzen du hutsuneak blokeo-sarbide esklusiboa eta zergatik sortzen da gatazka idazteko eragiketekin?
Hori galdera ona da. Arrazoia da hutsean betetako mahaia hartzen duela. Eta funtsean taularen bertsio berri bat sortzen ari gara. Eta mahaia berria izango da. Ematen du hau taularen bertsio guztiz berria izango dela. Eta arazoa da hau egiten dugunean ez dugula nahi jendeak irakurtzea, mahai berria ikusteko behar dugulako. Eta, beraz, aurreko galderarekin lotzen da. Aldi berean irakurriko bagenu, ezingo genuke mugitu eta jendea mahai berri batera bideratu. Guztiek taula hau irakurtzen amaitu arte itxaron beharko genuke, eta beraz, funtsean, blokeo esklusiboa da.
Hasieratik blokeatzen dugula esaten dugu, badakigulako amaieran blokeo esklusibo bat beharko dugula denak kopia berrira eramateko. Beraz, potentzialki hau konpondu dezakegu. Eta horrela egiten dugu aldibereko indexazioarekin. Baina hori egitea askoz zailagoa da. Eta hori oso lotuta dago blokeo esklusiboari buruzko aurreko galderarekin.
Posible al da blokeatzeko denbora-muga gehitzea Postgres-i? Oracle-n, adibidez, "hautatu eguneratzeko" idatzi eta 50 segundo itxaron dezaket eguneratu aurretik. Aplikaziorako ona izan zen. Baina Postgres-en, edo berehala egin behar dut eta ez dut batere itxaron, edo noizbait arte itxaron.
Bai, denbora-muga bat hauta dezakezu zure sarrailetan, zure sarrailetan. Inolako komando bat ere eman dezakezu, horrek... blokeoa berehala lortu ezin baduzu. Hori dela eta, blokeo-denbora bat edo hori egiteko aukera emango dizun beste zerbait. Hau ez da maila sintaktikoan egiten. Hau zerbitzarian aldagai gisa egiten da. Batzuetan hau ezin da erabili.
Ireki dezakezu 75. diapositiba?
Bai.
Eta nire galdera honakoa da. Zergatik espero dute bi eguneratze prozesuek 703?
Eta hau galdera bikaina da. Ez dut ulertzen, bide batez, zergatik egiten duen Postgresek hau. Baina 703 sortu zenean, 702 espero zen. Eta 704 eta 705 agertzen direnean, badirudi ez dakitela zer espero duten oraindik ez dagoelako ezer. Eta Postgres-ek horrela egiten du: ezin duzunean sarrailarik lortu, "Zertarako prozesatzeak?" idazten du, dagoeneko norbaiten zain zaudelako. Beraz, airean zintzilik utziko dugu, ez du batere eguneratuko. Baina zer gertatu da hemen? 702k prozesua amaitu eta 703k blokeoa jaso bezain laster, sistema itzuli zen. Eta esan zuen orain bi pertsona ditugula zain. Eta gero egunera ditzagun elkarrekin. Eta adierazi dezagun biak espero direla.
Ez dakit zergatik egiten duen Postgresek. Baina bada f izeneko arazo bat... Iruditzen zait hau ez dela errusierazko terminoa. Hau da denak gaztelu baten zain daudenean, nahiz eta gazteluaren zain dauden 20 agintari egon. Eta bat-batean denak aldi berean esnatzen dira. Eta denak erreakzionatzen saiatzen hasten dira. Baina sistemak egiten du denak 703aren zain egotea. Denak zain daudelako, eta berehala lerrokatuko ditugu guztiak. Eta honen ondoren sortutako beste eskaera berriren bat agertzen bada, adibidez, 707, orduan hutsunea egongo da berriro.
Eta hori egiten dela iruditzen zait, etapa honetan 702 703aren zain dagoela esan dezagun, eta ondoren datozen guztiek ez dutela inolako sarrerarik izango eremu honetan. Baina lehen zerbitzaria irten bezain laster, eguneraketaren aurretik une horretan itxaroten zeuden guztiek token bera jasotzen dute. Eta, beraz, uste dut hori egin dela ordenan prozesatu ahal izateko, behar bezala ordenatu daitezen.
Fenomeno arraro samarra bezala ikusi nuen beti. Hemen, adibidez, ez ditugu batere zerrendatzen. Baina iruditzen zait sarraila berri bat ematen dugun bakoitzean itxarotean dauden guztiei begiratzen diela. Ondoren, guztiak lerrokatuko ditugu. Eta, gero, sartzen den edozein berria ilaran sartzen da hurrengo pertsonak prozesatzen amaitzen duenean. Oso galdera ona. Mila esker zure galderagatik!
Iruditzen zait askoz logikoagoa dela 705ak 704 espero duenean.
Baina hemen arazoa honako hau da. Teknikoki, bata edo bestea esna dezakezu. Eta horrela esnatuko gara bata edo bestea. Baina zer gertatzen da sisteman? Goiko 703-k bere transakzio ID propioa nola blokeatu duen ikus dezakezu. Honela funtzionatzen du Postgresek. Eta 703 bere transakzio ID propioak blokeatuta dago, beraz, norbaitek itxaron nahi badu, 703 itxarongo du. Eta, funtsean, 703 osatzen da. Eta amaitu ondoren soilik esnatzen da prozesuetako bat. Eta ez dakigu zehazki zein izango den prozesu hau. Gero dena pixkanaka prozesatzen dugu. Baina ez dago argi zein prozesu esnatzen den lehenengo, prozesu horietako edozein izan daitekeelako. Funtsean, orain prozesu horietako edozein esnatu dezakegula esaten zuen programatzaile bat genuen. Bat aukeratzen dugu ausaz. Beraz, biak kontuan hartu behar dira bietako bat esna dezakegulako.
Eta arazoa da CP-infinity dugula. Eta, beraz, litekeena da gerokoa esnatzea. Eta, adibidez, gerokoa esnatzen badugu, blokea jaso berri duenaren zain egongo gara, beraz, ez dugu zehatz-mehatz nor esnatuko den lehenik zehazten. Horrelako egoera bat besterik ez dugu sortzen, eta sistemak ausazko ordena batean esnatuko ditu.
Ez dago . Begira, interesgarriak eta erabilgarriak ere badira. Gaia, noski, izugarri konplexua da. Mila esker, Bruce!
Iturria: www.habr.com