Transkripsie van Bruce Momjian se 2020-toespraak "Ontsluit die Postgres-slotbestuurder".
(Let wel: Jy kan alle SQL-navrae vanaf die skyfies by hierdie skakel kry: )
Hallo! Dit is wonderlik om weer hier in Rusland te wees. Ek is jammer dat ek nie verlede jaar kon kom nie, maar hierdie jaar het ek en Ivan groot planne. Ek hoop om baie meer gereeld hier te wees. Ek hou daarvan om na Rusland te kom. Ek sal Tyumen, Tver besoek. Ek is baie bly dat ek hierdie stede sal kan besoek.
My naam is Bruce Momjian. Ek werk by EnterpriseDB en werk al meer as 23 jaar saam met Postgres. Ek woon in Philadelphia, VSA. Ek reis ongeveer 90 dae per jaar. En ek woon ongeveer 40 konferensies by. My , wat die skyfies bevat wat ek jou nou sal wys. Daarom kan u dit na die konferensie van my persoonlike webwerf aflaai. Dit bevat ook sowat 30 aanbiedings. En daar is ook video's en 'n groot aantal bloginskrywings, meer as 500. Dit is 'n redelik insiggewende hulpbron. En as jy belangstel in hierdie materiaal, dan nooi ek jou uit om dit te gebruik.
Ek was 'n onderwyser, 'n professor voordat ek met Postgres begin werk het. En ek is baie bly dat ek nou vir jou kan sê wat ek vir jou gaan sê. Hierdie is een van my interessantste aanbiedings. En hierdie aanbieding bevat 110 skyfies. Ons sal met eenvoudige dinge begin praat, en teen die einde van die verslag sal dit meer en meer ingewikkeld raak, en dit sal nogal ingewikkeld raak.
Dit is 'n taamlik onaangename gesprek. Blokkering is nie die gewildste onderwerp nie. Ons wil hê dit moet iewers verdwyn. Dit is soos om na die tandarts te gaan.
- Sluiting is 'n probleem vir baie mense wat op databasisse werk en verskeie prosesse op dieselfde tyd loop. Hulle het blokkering nodig. Dit wil sê, vandag sal ek jou basiese kennis van blokkering gee.
- Transaksie-ID's. Dit is 'n taamlik vervelige deel van die aanbieding, maar hulle moet verstaan word.
- Vervolgens sal ons praat oor die tipes blokkering. Dit is nogal 'n meganiese deel.
- En dan sal ons 'n paar voorbeelde van blokkering gee. En dit sal nogal moeilik wees om te verstaan.
Kom ons praat oor blokkering.
Ons terminologie is nogal ingewikkeld. Hoeveel van julle weet waar hierdie gedeelte vandaan kom? Twee mense. Dit is van 'n speletjie genaamd Colossal Cave Adventure. Dit was 'n teksgebaseerde rekenaarspeletjie in die 80's, dink ek. Daar was dit nodig om in die grot in te gaan, in die labirint en die teks het verander, maar die inhoud was elke keer ongeveer dieselfde. Dis hoe ek hierdie speletjie onthou.
En hier sien ons die naam van die slotte wat van Oracle na ons toe gekom het. Ons gebruik hulle.
Hier sien ons terme wat my verwar. Byvoorbeeld, SHARE UPDATE ECXLUSIVE. Volgende DEEL ROU EKXLUSIEF. Eerlik gesê, hierdie name is nie baie duidelik nie. Ons sal probeer om hulle in meer besonderhede te oorweeg. Sommige bevat die woord "deel", wat beteken om te skei. Sommige bevat die woord "eksklusief" - eksklusief. Sommige bevat albei hierdie woorde. Ek wil graag begin met hoe hierdie slotte werk.
En die woord "toegang" is ook baie belangrik. En die woorde "ry" - 'n reël. Dit is toegangsverspreiding, ryverspreiding.
Nog 'n probleem wat in Postgres verstaan moet word, wat ek ongelukkig nie in my praatjie sal kan dek nie, is MVCC. Ek het 'n aparte aanbieding oor hierdie onderwerp op my webwerf. En as jy dink hierdie aanbieding is moeilik, dan is MVCC seker my moeilikste. En as jy belangstel, kan jy dit op die webwerf sien. Jy kan die video kyk.
Nog iets wat ons moet verstaan, is transaksie-ID's. Baie transaksies kan nie werk sonder unieke identifiseerders nie. En hier het ons 'n verduideliking van wat 'n transaksie is. Postgres het twee transaksienommerstelsels. Ek weet dit is nie 'n baie mooi oplossing nie.
Hou ook in gedagte dat die skyfies nogal moeilik sal wees om te lees, dus wat in rooi uitgelig word, is waarna jy moet aandag gee.
Ons kyk. Die transaksienommer word in rooi uitgelig. Hier word die SELECT pg_back-funksie gewys. Dit gee my transaksie en die ID van daardie transaksie terug.
Nog een ding, as jy van hierdie aanbieding hou en dit in jou databasis wil laat loop, dan kan jy hierdie skakel volg wat in pienk uitgelig is en die SQL vir hierdie aanbieding aflaai. En jy kan dit net in jou PSQL laat loop en die hele aanbieding sal binne ’n japtrap op jou skerm wees. Dit sal nie blomme bevat nie, maar ons kan dit ten minste sien.
In hierdie geval sien ons die transaksie-ID. Dit is die nommer wat ons aan haar toegeken het. En daar is 'n ander soort transaksie-ID in Postgres wat virtuele transaksie-ID genoem word
En ons moet dit verstaan. Dit is baie belangrik, anders sal ons nie die sluiting in Postgres kan verstaan nie.
'n Virtuele transaksie-ID is 'n transaksie-ID wat nie konstante waardes bevat nie. Byvoorbeeld, as ek 'n SELECT-opdrag uitvoer, sal ek waarskynlik nie die databasis verander nie, ek sal niks sluit nie. So wanneer ons 'n eenvoudige SELECT uitvoer, gee ons nie daardie transaksie 'n permanente ID nie. Ons gee haar net 'n virtuele ID daar.
En dit verbeter die werkverrigting van Postgres, verbeter die vermoë om skoon te maak, so die virtuele transaksie-ID bestaan uit twee nommers. Die eerste nommer voor die skuinsstreep is die agterkant-ID. En aan die regterkant sien ons net 'n toonbank.
Daarom, as ek 'n versoek uitvoer, sê dit dat die backend ID 2 is.
En as ek 'n reeks sulke transaksies uitvoer, dan sien ons dat die teller elke keer as ek die navraag uitvoer, verhoog word. Byvoorbeeld wanneer ek navraag 2/10, 2/11, 2/12 ens.
Hou in gedagte dat hier twee kolomme is. Aan die linkerkant sien ons die virtuele transaksie-ID - 2/12. En aan die regterkant het ons 'n permanente transaksie-ID. En hierdie veld is leeg. En hierdie transaksie verander nie die databasis nie. Daarom ken ek nie 'n permanente transaksie-ID daaraan toe nie.
Sodra ek die ontleed-opdrag ((ANALIZE)) uitvoer, gee dieselfde navraag my 'n permanente transaksie-ID. Kyk hoe ons verander het. Voorheen het ek nie hierdie ID gehad nie, nou het ek.
So hier is nog 'n versoek, nog 'n transaksie. Die virtuele transaksienommer is 2/13. En as ek vir 'n permanente transaksie-ID vra, sal ek dit kry wanneer ek die versoek uitvoer.
So, nog een keer. Ons het 'n virtuele transaksie-ID en 'n permanente transaksie-ID. Neem net hierdie punt om die gedrag van Postgres te verstaan.
Ons gaan aan na die derde afdeling. Hier gaan ons net deur die verskillende tipes slotte in Postgres stap. Dit is nie baie interessant nie. Die laaste gedeelte sal baie interessanter wees. Maar ons moet die basiese dinge oorweeg, want anders sal ons nie verstaan wat volgende gaan gebeur nie.
Ons sal deur hierdie afdeling gaan, ons sal na elke tipe blokkering kyk. En ek sal jou voorbeelde wys van hoe hulle geïnstalleer is, hoe hulle werk, jou 'n paar navrae wys wat jy kan gebruik om te sien hoe blokkering in Postgres werk.
Om 'n navraag te skep en te sien wat in Postgres aangaan, moet ons die navraag na die stelselaansig uitreik. In hierdie geval word pg_lock in rooi uitgelig. pg_lock is 'n stelseltabel wat ons vertel watter slotte tans in Postgres gebruik word.
Dit is egter vir my baie moeilik om vir jou pg_lock op sigself te wys, want dit is nogal ingewikkeld. So ek het 'n aansig geskep wat pg_locks wys. En dit doen ook 'n bietjie werk vir my wat my toelaat om beter te verstaan. Dit wil sê, dit sluit my slotte, my eie sessie, ens uit. Dit is net standaard SQL en dit laat jou toe om beter te wys wat aangaan.
Nog 'n probleem is dat hierdie aansig baie wyd is, so ek moet 'n tweede een skep - lockview2.
En dit wys vir my meer kolomme uit die tabel. En nog een wat vir my die res van die kolomme wys. Dit is nogal ingewikkeld, so ek het probeer om dit so eenvoudig as moontlik aan te bied.
So, ons het 'n tabel genaamd Lockdemo geskep. En ons het een lyn daar geskep. Dit is ons voorbeeldtabel. En ons sal afdelings skep net om u voorbeelde van blokkering te wys.
Dus, een ry, een kolom. Die eerste tipe slot word TOEGANGSDEEL genoem. Dit is die minste beperkende blokkering. Dit beteken dat dit feitlik nie bots met ander slotte nie.
En as ons 'n slot uitdruklik wil definieer, voer ons die "slot tabel" opdrag uit. En dit sal eksplisiet blokkeer, dit wil sê in die TOEGANGSHANDELING-modus, loop ons die slottabel. En as ek PSQL in die agtergrond begin, dan begin ek die tweede sessie vanaf my eerste sessie op hierdie manier. Dit is, wat sal ek hier doen? Ek gaan na 'n ander sessie en sê dit moet "wys my die lockview vir hierdie versoek". En hier het ek 'n AccessShareLock op hierdie tafel. Dit is net wat ek versoek het. En hy sê die slot is toegewys. Baie eenvoudig.
Verder, as ons na die tweede kolom kyk, dan is daar niks daar nie. Hulle is leeg.
En as ek die "SELECT" opdrag uitvoer, dan is dit die implisiete (eksplisiete) manier om AccessShareLock aan te vra. So ek stel my tabel vry en voer 'n navraag uit en die navraag gee veelvuldige rye terug. En in een van die reëls sien ons AccessShareLock. So SELECT roep AccessShareLock op die tafel. En dit bots nie met amper enigiets nie, want dit is 'n laevlak-slot.
Wat as ek 'n SELECT hardloop en ek het drie verskillende tabelle? Voorheen het ek net een tabel bestuur, nou hardloop ek drie: pg_class, pg_namespace en pg_attribute.
En nou as ek na die navraag kyk, sien ek 9 AccessShareLocks in XNUMX tabelle. Hoekom? Drie tabelle word in blou uitgelig: pg_attribute, pg_class, pg_namespace. Maar jy kan ook sien dat alle indekse wat deur hierdie tabelle gedefinieer word, ook AccessShareLock het.
En dit is 'n blokkering wat feitlik nie bots met ander nie. En al wat dit doen, is om net te verhoed dat ons die tafel laat val terwyl ons dit kies. Dit maak sin. Dit wil sê, as ons 'n tabel kies, verdwyn dit op daardie oomblik, dan is dit dus verkeerd AccessShare is 'n lae vlak slot wat vir ons sê "moenie hierdie tabel uitvee terwyl ek werk nie". Eintlik is dit al wat sy doen.
RY DEEL - Hierdie slot is 'n bietjie anders.
Kom ons neem 'n voorbeeld. KIES RY DEEL manier om elke ry individueel te sluit. Op dié manier kan niemand hulle uitvee of verander terwyl ons na hulle kyk nie.
So, wat doen SHARE LOCK? Ons sien dat die transaksie-ID 681 is vir die SELECT. En dit is interessant. Wat het hier gebeur? Vir die eerste keer sien ons die nommer in die "Lock"-veld. Ons neem die transaksie-ID, en hy sê dat hy dit in eksklusiewe modus blokkeer. Al wat dit doen, is dat dit sê ek het 'n ry wat tegnies iewers in die tabel gesluit is. Maar hy sê nie presies waar nie. Ons sal 'n bietjie later in meer detail hierna kyk.
Hier sê ons dat die slot deur ons gebruik word.
Dus, 'n eksklusiewe slot sê uitdruklik (eksplisiet) dat dit eksklusief is. En ook as jy 'n ry in hierdie tabel uitvee, is dit wat gebeur, soos jy kan sien.
SHARE EXCLUSIVE is 'n langer slot.
Dit is (ANALISEER) die ontleder-opdrag wat gebruik moet word.
DEELSLOT - Jy kan uitdruklik in deelmodus sluit.
Jy kan ook 'n unieke indeks skep. En daar kan jy SHARE LOCK sien, wat deel van hulle is. En dit sluit die tafel en stel 'n SHARE LOCK-slot daarop.
Die verstek DEELSLOT op 'n tabel beteken dat ander mense die tabel kan lees, maar niemand kan dit wysig nie. En dit is presies wat gebeur wanneer jy 'n unieke indeks skep.
As ek 'n unieke gelyktydige indeks skep, sal ek 'n ander tipe slot hê, want onthou, die gebruik van gelyktydige indekse verminder die slotvereiste. En as ek 'n normale slot, 'n normale indeks gebruik, dan verhoed ek dus om na die indeks van die tabel te skryf tydens die skepping daarvan. As ek 'n gelyktydige indeks gebruik, moet ek 'n ander tipe slot gebruik.
DEEL RY EKSKLUSIEF - weereens kan dit eksplisiet (eksplisiet) gestel word.
Of ons kan 'n reël skep, dit wil sê, 'n spesifieke geval neem waarin dit gebruik sal word.
EKSKLUSIEWE slot beteken dat niemand anders die tafel kan verander nie.
Hier sien ons verskillende tipes slotte.
ACCESS EXCLUSIVE, byvoorbeeld, is 'n sluitopdrag. Byvoorbeeld, as jy dit doen CLUSTER table, dan sal dit beteken dat niemand daar sal kan skryf nie. En dit sluit nie net die tafel self nie, maar ook die indekse.
Hierdie is die tweede bladsy van die ACCESS EXCLUSIVE-slot waar ons spesifiek sien wat dit in die tabel sluit. Dit sluit individuele tabelrye, wat interessant genoeg is.
Dit is al die basiese inligting wat ek wou gee. Ons het gepraat oor slotte, oor transaksie-ID's, ons het gepraat oor virtuele transaksie-ID's, oor permanente transaksie-ID's.
En nou gaan ons deur die blokkerende voorbeelde. Dit is die interessantste deel. Ons sal baie interessante gevalle sien. En my doel in hierdie aanbieding is om jou 'n beter idee te gee van wat Postgres eintlik doen wanneer dit probeer om dinge te blokkeer. Dit lyk vir my of hy baie goed is om individuele dele te blokkeer.
Kom ons kyk na 'n paar spesifieke voorbeelde.
Ons begin met tabelle en een ry per tabel. Wanneer ek iets insit, kry ek ExclusiveLock, Transaction ID en ExclusiveLock op die tafel.
Wat gebeur as ek nog twee rye invoeg? En nou het ons tabel drie rye. En ek het een ry ingevoeg en dit as 'n uitset gekry. En as ek nog twee rye insit, wat is vreemd hier? Daar is 'n eienaardigheid hier, want ek het drie rye by hierdie tabel gevoeg, maar ek het nog twee rye in die slottabel. En dit is in werklikheid die fundamentele gedrag van Postgres.
Baie mense dink dat as jy 100 rye in 'n databasis sluit, jy 100 slotinskrywings sal moet skep. As ek 1 000 rye op een slag blokkeer, sal ek 1 000 sulke versoeke nodig hê. En as ek 'n miljoen of 'n miljard nodig het om te blokkeer. Maar as ons dit doen, sal dit nie baie goed werk nie. As jy 'n stelsel gebruik het wat blokkeerinskrywings vir elke individuele ry skep, dan kan jy sien dat dit ingewikkeld is. Omdat jy dadelik die slottafel moet definieer, wat kan oorloop, maar Postgres doen dit nie.
En dit is baie belangrik op hierdie skyfie dat dit duidelik demonstreer dat daar 'n ander stelsel is wat binne MVCC werk wat individuele lyne blokkeer. So wanneer jy miljarde rye sluit, skep Postgres nie 'n miljard afsonderlike sluitinstruksies nie. En dit is baie goed vir prestasie.
Wat van 'n opdatering? Ek is besig om die reeks nou op te dateer en jy kan sien dat dit twee verskillende bewerkings gelyktydig gedoen het. Dit het die tabel terselfdertyd gesluit, maar dit het ook die indeks gesluit. En hy moes die indeks sluit omdat daar unieke beperkings op daardie tabel is. En ons wil seker maak dat niemand dit verander nie, daarom blokkeer ons dit.
Wat gebeur as ek twee rye wil opdateer? En ons sien dat hy op dieselfde manier optree. Ons doen twee keer soveel opdaterings, maar presies dieselfde aantal blokkeerlyne.
As jy wonder hoe Postgres dit doen, moet jy na my praatjies oor MVCC luister om uit te vind hoe Postgres intern hierdie lyne merk dat dit verander. En Postgres het 'n manier om dit te doen, maar dit doen dit nie op die tafelsluitvlak nie, dit doen dit op 'n laer en doeltreffender vlak.
Wat as ek iets wil uitvee? As ek byvoorbeeld een ry uitvee en ek het nog my twee insette by die slot, en al wil ek almal uitvee, is hulle steeds daar.
En, byvoorbeeld, ek wil 1 000 reëls invoeg, en dan óf skrap óf 1 000 reëls byvoeg, dan word die individuele reëls wat ek byvoeg of verander, hulle nie hier aangeteken nie. Hulle word op 'n laer vlak binne die ry self geskryf. En tydens die MVCC-praatjie het ek in detail daaroor gepraat. Maar dit is baie belangrik wanneer jy slotte ontleed om seker te maak jy het 'n tafelvlak-slot en dat jy nie kan sien hoe individuele rye hier geskryf word nie.
Wat van eksplisiete blokkering?
As ek op "refresh" klik dan het ek twee rye gesluit. En as ek hulle almal selekteer en op "update oral" klik, dan het ek nog twee slotrekords.
Ons skep nie afsonderlike inskrywings vir elke individuele ry nie. Want dan daal prestasie, kan daar te veel daarvan wees. En ons kan onsself in 'n onaangename situasie bevind.
En dieselfde ding, as ons gedeel doen, kan ons alles 30 keer doen.
Ons herstel ons tabel, vee alles uit en voeg dan weer een ry in.
Nog 'n soort gedrag wat jy in Postgres sien wat baie bekende en gewenste gedrag is, is dat jy 'n opdatering of 'n keuse kan doen. En jy kan dit terselfdertyd doen. En kies blokkeer nie opdatering nie en dieselfde ding in die teenoorgestelde rigting. Ons sê vir die leser om nie die skrywer te blokkeer nie, en die skrywer het nie die leser geblokkeer nie.
Ek sal jou 'n voorbeeld hiervan wys. Ek sal nou 'n keuse maak. Ons sal dan 'n INSERT doen. En dan kan jy sien - 694. Jy kan die ID van die transaksie sien wat hierdie insetsel gemaak het. En dit is hoe dit werk.
En as ek nou na my backend ID kyk, het dit geword - 695.
En ek kan sien dat 695 in my tabel verskyn.
En as ek so hier opdateer, dan kry ek 'n ander saak. In hierdie geval is 695 'n eksklusiewe slot, en opdatering het dieselfde gedrag, maar daar is geen konflik tussen hulle nie, wat nogal ongewoon is.
En jy kan sien dat ShareLock bo is en ExclusiveLock onderaan. En albei transaksies het geslaag.
En jy moet na my praatjie by MVCC luister om te verstaan hoe dit gebeur. Maar dit is 'n illustrasie van die feit dat jy dit op dieselfde tyd kan doen, dit wil sê SELECT en UPDATE op dieselfde tyd.
Kom ons herstel en doen weer een bewerking.
As jy probeer om twee opdaterings op dieselfde tyd op dieselfde ry uit te voer, sal dit blokkeer. En onthou, ek het gesê dat die leser nie die skrywer blokkeer nie, maar die skrywer van die leser, maar een skrywer blokkeer 'n ander skrywer. Dit wil sê, ons kan nie twee mense dieselfde ry op dieselfde tyd laat opdateer nie. Jy moet wag totdat een van hulle klaar is.
En om dit te illustreer, sal ek na die Lockdemo-tabel kyk. En ons sal na een ry kyk. Vir transaksie 698.
Ons het dit opgegradeer na 2. 699 is die eerste opdatering. En dit was suksesvol of dit is in 'n hangende transaksie wat wag vir ons om te verbind of te kanselleer.
Maar kyk na iets anders - 2/51 is ons eerste transaksie, ons eerste sessie. 3/112 is die tweede versoek wat van bo af gekom het en daardie waarde na 3 verander het. En as jy agterkom, het die boonste een homself gesluit, wat 699 is. Maar 3/112 het nie 'n slot toegestaan nie. Die Lock_mode-kolom sê dat dit wag. Hy verwag 699. En as jy kyk waar 699 is, is hy hoër. En wat het die eerste sessie gedoen? Sy het 'n eksklusiewe slot op haar eie transaksie-ID geskep. Dit is hoe Postgres dit doen. Dit blokkeer sy eie transaksie-ID. En as jy wil wag vir iemand om te verbind of te kanselleer, dan moet jy wag terwyl daar 'n hangende transaksie is. En so kan ons 'n vreemde lyn sien.
Kom ons kyk weer. Aan die linkerkant sien ons ons verwerkings-ID. In die tweede kolom sien ons ons virtuele transaksie-ID, en in die derde sien ons die lock_type. Wat beteken dit? Trouens, sy sê dat sy die transaksie-ID blokkeer. Maar let op dat in al die rye onderaan 'n verhouding geskryf is. En so het jy twee soorte slotte op die tafel. Daar is 'n verhoudingslot. En daar is ook 'n transaksie-ID-slot waar jy ons op ons eie sluit, dit is presies wat gebeur op die eerste ry of heel onder waar die transaksie-ID is waar ons verwag dat 699 sy werking sal voltooi.
Ek sien wat hier gebeur. En hier gebeur twee dinge op dieselfde tyd. Jy kyk na die transaksie-ID-slot in die eerste ry, wat homself sluit. En sy blokkeer haarself om mense te laat wag.
As jy na die 6de reël kyk, is dit dieselfde inskrywing as die eerste. En so word transaksie 699 geblokkeer. 700 is ook selfsluitend. En dan in die onderste ry sal jy sien dat ons wag vir 699 om sy operasie te voltooi.
En in lock_type, tuple sien jy getalle.
Jy kan sien dit is 0/10. En dit is die bladsynommer, en ook die afwyking van daardie spesifieke ry.
En jy sien wat 0/11 word wanneer ons opdateer.
Maar eintlik is dit 0/10, want daar is 'n verwagting vir hierdie operasie. Ons het die geleentheid om te sien dat dit die ry is wat ek wag om te bevestig.
Sodra ons dit bevestig het en commit gedruk het, en wanneer die opdatering klaar is, is dit wat ons weer kry. Transaksie 700 is die enigste slot, dit wag nie vir iemand anders nie, want dit is gepleeg. Dit wag net vir die transaksie om te voltooi. Sodra 699 eindig, wag ons vir niks anders nie. En nou sê transaksie 700 dat alles in orde is, dat dit al die slotte het wat dit nodig het in alle toegelate tafels.
En om die hele ding verder te kompliseer, skep ons 'n ander siening, wat hierdie keer vir ons 'n hiërargie sal verskaf. Ek verwag nie dat jy hierdie versoek sal verstaan nie. Maar dit sal ons 'n duideliker siening gee van wat aangaan.
Dit is 'n rekursiewe siening wat ook nog een afdeling het. En dan bring dit alles weer bymekaar. Kom ons gebruik dit.
Wat as ons drie gelyktydige opdaterings doen en sê die ry is nou drie. En ons sal 3 na 4 verander.
En hier sien ons 4. En transaksie-ID 702.
En dan ruil ek 4 vir 5. En 5 vir 6, en 6 vir 7. En ek stel 'n aantal mense in die ry om te wag vir hierdie een transaksie om te voltooi.
En alles word duidelik. Wat is die eerste ry? Dit is 702. Dit is die transaksie-ID wat oorspronklik hierdie waarde gestel het. Wat het ek in die Granted-kolom? Ek het merke f. Dit is my opdaterings wat (5, 6, 7) nie goedgekeur kan word nie, want ons wag vir transaksie-ID 702 om te verval. Daar het ons 'n transaksie-ID-slot. En dit blyk 5 transaksieslotte ID.
En as jy kyk na 704, na 705, is daar nog niks geskryf nie, want hulle weet nog nie wat aangaan nie. Hulle skryf net dat hulle geen idee het wat aangaan nie. En hulle sal maar gaan slaap, want hulle wag vir iemand om klaar te maak en hulle sal wakker gemaak word wanneer dit moontlik is om die ry te verander.
Dit is hoe dit lyk. Dit is duidelik dat hulle almal wag vir die 12de lyn.
Dit is wat ons hier gesien het. Hier is 0/12.
So, sodra die eerste transaksie goedgekeur is, kan u hier sien hoe die hiërargie werk. En nou is dit alles duidelik. Hulle word almal skoon. En hulle wag eintlik nog.
Hier is wat gebeur. 702 is gepleeg. En nou kry 703 hierdie ryslot, en dan begin 704 wag vir 703 om te pleeg. En die 705 wag ook hiervoor. En wanneer dit alles afgehandel is, maak hulle hulself skoon. En ek wil graag daarop wys dat almal toustaan. En dit is baie soortgelyk aan die verkeersknoopsituasie waar almal wag vir die eerste motor. Die eerste motor het gestop en almal staan in 'n lang ry. Dan beweeg dit, dan kan die volgende kar vorentoe kom en sy blok kry, ens.
En as dit vir jou nie moeilik genoeg gelyk het nie, dan praat ons nou met jou oor dooiepunte. Ek weet nie wie van julle het hulle ervaar nie. Dit is 'n redelik algemene probleem in databasisstelsels. Maar dooiepunte is wanneer een sessie wag vir 'n ander sessie om iets te doen. En op daardie oomblik wag nog 'n sessie vir die eerste sessie om iets te doen.
En, byvoorbeeld, as Ivan sê: "Gee my iets," en ek sê: "Nee, ek sal dit net vir jou gee as jy vir my iets anders gee." En hy sê: "Nee, ek sal dit nie vir jou gee as jy dit nie vir my gee nie." En ons beland in 'n dooiepunt situasie. Ek is seker Ivan sal dit nie doen nie, maar jy kry die punt dat ons twee mense het wat iets wil hê en hulle is nie gereed om dit weg te gee totdat die ander persoon vir hulle gee wat hulle wil hê nie. En daar is geen oplossing nie.
En om die waarheid te sê, jou databasis moet dit opspoor. En dan moet jy een van die sessies uitvee of sluit, want anders bly hulle vir altyd daar. En ons sien dit in databasisse, ons sien dit in bedryfstelsels. En op alle plekke waar ons parallelle prosesse het, kan dit gebeur.
En ons sal nou twee dooiepunte plaas. Ons sal 50 en 80 plaas. In die eerste ry sal ek opdateer van 50 na 50. Ek sal transaksienommer 710 kry.
En dan verander ek 80 na 81, en 50 na 51.
En hier is hoe dit sal lyk. En so het 710 'n ryslot, en 711 wag vir bevestiging. Ons het dit gesien toe ons opgedateer het. 710 - is die eienaar van ons reeks. En 711 wag vir 710 om die transaksie te voltooi.
En dit sê selfs op watter ry ons dooiepunte het. En dit is hier waar dit vreemd begin raak.
Nou werk ons 80 op na 80.
En dis waar die dooiepunte begin. 710 wag vir 'n antwoord van 711, en 711 wag vir 710. En dit sal nie goed eindig nie. En daar is geen uitweg hieruit nie. En hulle sal 'n reaksie van mekaar verwag.
En dit begin net alles uitstel. En ons wil dit nie hê nie.
En Postgres het maniere om op te let wanneer dit gebeur. En wanneer dit gebeur, kry jy hierdie fout. En hieruit is dit duidelik dat so en so 'n proses wag vir 'n DEELSLOT van 'n ander proses, dit wil sê, wat deur die 711-proses geblokkeer word. En daardie proses het gewag vir 'n DEELSLOT om aan so en so 'n transaksie-ID gegee te word en deur so en so 'n proses geblokkeer te word. Daarom is daar 'n situasie van dooie blokkering.
Is daar drie-rigting dooiepunte? Is dit moontlik? Ja.
Ons skryf hierdie getalle in die tabel. Ons verander 40 na 40, ons maak 'n slot.
Verander 60 na 61, 80 na 81.
En dan verander ons 80 en dan boom!
En 714 wag nou vir 715. 716 wag vir 715. En daar is niks om daaraan te doen nie.
Daar is nie meer twee mense nie, daar is reeds drie mense. Ek wil iets van jou hê, hierdie een wil iets van die derde persoon hê, en die derde persoon wil iets van my hê. En ons beland in 'n drierigtingwag, want ons wag almal vir die ander persoon om te voltooi wat hulle moet doen.
En Postgres weet op watter ry dit gebeur. En so sal dit vir jou die volgende boodskap gee wat wys jy het 'n probleem waar die drie insette mekaar blokkeer. En daar is geen beperkings nie. Dit kan die geval wees waar 20 inskrywings mekaar blokkeer.
Die volgende uitgawe is serieelbaar.
As 'n spesiale serialiseerbare slot.
En ons keer terug na 719. Hy het 'n heeltemal normale probleem.
En jy kan druk om transaksie van serialiseerbaar te maak.
En jy verstaan dat jy nou 'n ander soort SA blokkering het - dit beteken serialiseerbaar.
En so het ons 'n nuwe soort slot genaamd SARieadLock, wat 'n reeksslot is en jou toelaat om reeksnommers in te voer.
En jy kan ook unieke indekse invoeg.
In hierdie tabel het ons unieke indekse.
So as ek die nommer 2 hier insit, is dit hoekom ek 'n 2 het. Maar heel bo sit ek nog 2 in. En jy kan sien dat die 721 'n eksklusiewe slot het. Maar nou wag 722 vir 721 om sy operasie te voltooi, want dit kan nie 2 invoeg totdat dit weet wat met 721 gaan gebeur nie.
En as ons subtransaksie doen.
Hier het ons 723.
En as ons die punt stoor en dit dan opdateer, kry ons 'n nuwe transaksionele ID. Dit is nog 'n gedrag waarvan jy bewus moet wees. As ons dit terugstuur, is die transaksie-ID weg. 724 vertrek. Maar nou het ons 725.
En wat probeer ek hier doen? Ek probeer vir jou voorbeelde wys van ongewone slotte wat jy kan vind: of dit nou serialiseerbare slotte of SAVEPOINT-slotte is, dit is verskillende soorte slotte wat in die slottabel sal verskyn.
Dit is die skepping van eksplisiete (eksplisiete) slotte, wat pg_advisory_lock het.
En jy kan sien dat die slottipe hier as adviserende gelys word. En hier staan “adviserende” in rooi. En jy kan gelyktydig blokkeer met pg_advisory_unlock.
En ten slotte wil ek vir jou nog 'n wonderlike ding wys. Ek sal 'n ander siening skep. Maar ek sal by die pg_locks-tabel aansluit by die pg_stat_activity-tabel. En hoekom wil ek dit doen? Want dit sal my toelaat om al die huidige sessies te kyk en te sien en te sien vir watter soort slotte hulle wag. En dit is interessant genoeg wanneer ons 'n slottabel en 'n navraagtabel saamstel.
En hier skep ons pg_stat_view.
En ons werk die ry vir een op. En hier sien ons 724. En dan werk ons ons ry op na drie. En wat sien jy nou hier? Dit is versoeke, dit wil sê jy sien die hele lys van versoeke wat in die linkerkolom gelys is. En dan aan die regterkant kan jy slotte sien en wat hulle skep. En dit kan vir jou meer verstaanbaar wees sodat jy nie elke keer na elke sessie hoef terug te gaan en te kyk of jy daarby moet aansluit of nie. Hulle doen dit vir ons.
Nog 'n kenmerk wat baie nuttig is, is pg_blocking_pids. Jy het seker nog nooit van haar gehoor nie. Wat doen sy? Dit laat ons toe om te sê dat vir hierdie sessie 11740 vir watter proses ID's dit wag. En jy kan sien dat 11740 724 verwag. En 724 is heel bo. En 11306 is jou proses ID. In wese gaan hierdie funksie oor jou slottafel. En ek weet dit is 'n bietjie ingewikkeld, maar jy kry die idee. In wese gaan hierdie funksie deur hierdie slottabel en probeer om uit te vind waar hierdie proses-ID is, gegewe die slotte waarvoor dit wag. En dit probeer ook uitvind watter proses-ID die proses het wat op die slot wag. So jy kan hierdie funksie laat loop pg_blocking_pids.
En dit is baie nuttig. Ons het dit eers sedert weergawe 9.6 bygevoeg, so hierdie kenmerk is net 5 jaar oud, maar dit is baie, baie nuttig. En dieselfde geld vir die tweede versoek. Dit wys presies wat ons moet sien.
Dit is waaroor ek met jou wou praat. En soos ek verwag het, het ons al ons tyd opgebruik omdat daar so baie glybane was. En die skyfies is beskikbaar vir aflaai. Ek wil jou graag bedank dat jy hier is. Ek is seker jy sal die res van die konferensie geniet, baie dankie!
Vrae:
Byvoorbeeld, as ek probeer om die rye op te dateer, en die tweede sessie probeer om die hele tabel te verwyder. Sover ek verstaan, behoort daar iets soos 'n opsetslot te wees. Is daar so iets in Postgres?
Ons keer terug na die heel begin. Jy kan onthou dat wanneer jy enigiets doen, soos wanneer jy 'n SELECT doen, ons 'n AccessShareLock uitreik. En dit keer dat die tafel laat val word. So as jy byvoorbeeld 'n ry in 'n tabel wil opdateer of 'n ry wil uitvee, dan kan iemand nie die hele tabel op dieselfde tyd uitvee nie, want jy hou hierdie AccessShareLock oor die hele tabel en oor die ry. En sodra jy klaar is, kan hulle dit verwyder. Maar solank jy iets direk daar verander, sal hulle dit nie kan doen nie.
Kom ons doen dit weer. Kom ons gaan aan na die delete-voorbeeld. En jy sien hoe die ry 'n eksklusiewe slot oor die hele tafel het.
Dit sal soos 'n eksklusiewe slot lyk, reg?
Ja, dit lyk so. Ek verstaan waarvan jy praat. Sê jy dat as ek 'n SELECT doen, ek 'n ShareExclusive het en dan plaas ek dit in 'n Row Exclusive-toestand, word dit 'n probleem? Maar verbasend genoeg is dit nie 'n probleem nie. Dit is soos om die graad van die slot te verhoog, maar in wese het ek 'n slot wat verhoed dat dit uitgevee word. En nou, wanneer ek hierdie slot kragtiger maak, verhoed dit steeds uitvee. Dit is dus nie asof ek opgaan nie. D.w.s. dit het dit ook verhoed toe dit op 'n laer vlak was, so wanneer ek dit verhef, verhoed dit steeds dat die tafel laat val word.
Ek verstaan waarvan jy praat. Daar is geen geval van verhoging van die graad van blokkering, waar jy probeer om een blok prys te gee om 'n kragtiger een in te voer nie. Hier verhoog dit net hierdie vermyding oral, so dit veroorsaak geen konflik nie. Maar dit is 'n goeie vraag. Baie dankie dat jy gevra het!
Wat moet ons doen om 'n dooiepunt situasie te vermy wanneer ons baie sessies, 'n groot aantal gebruikers het?
Postgres merk outomaties dooiepuntsituasies op. En dit sal outomaties een van die sessies uitvee. Die enigste manier om 'n dooie punt te vermy, is om mense in dieselfde volgorde te blokkeer. As jy dus na jou aansoek kyk, is dit dikwels die oorsaak van dooiepunte... Kom ons sê ek wil twee verskillende goed blokkeer. Een toepassing sluit tabel 1 en 'n ander toepassing sluit tabel 2 en dan tabel 1. En die maklikste manier om dooiepunte te vermy, is om na jou aansoek te kyk en te probeer seker maak dat die slot in dieselfde volgorde in alle toepassings plaasvind. En dit verwyder gewoonlik 80% van die probleme, want alle soorte mense skryf hierdie aansoeke. En as jy hulle in dieselfde volgorde blokkeer, dan loop jy nie in 'n dooiepunt situasie nie.
Baie dankie vir jou prestasie! Jy het gepraat van vakuum vol en, as ek reg verstaan, verdraai vakuum vol die volgorde van rekords in 'n aparte winkel, so dit hou die huidige rekords onveranderd. Waarom neem vakuum vol eksklusiewe slottoegang en hoekom bots dit met skryfbewerkings?
Dis 'n goeie vraag. Die rede is dat vakuum vol 'n tafel neem. En ons skep in wese 'n nuwe weergawe van die tabel. En die tafel sal nuut wees. Dit blyk dat dit 'n heeltemal nuwe weergawe van die tabel sal wees. En die probleem is dat wanneer ons dit doen, ons nie wil hê mense moet dit lees nie, want ons wil hê hulle moet die nuwe tabel sien. En so sluit dit aan by die vorige vraag. As ons terselfdertyd kon lees, dan sou ons dit nie kon skuif en mense na 'n nuwe tafel kon lei nie. Ons sal moet wag vir almal om hierdie tabel klaar te lees, en dus is dit in wese 'n slot-eksklusiewe situasie.
Ons sê net ons sluit van die begin af, want ons weet ons sal 'n eksklusiewe slot aan die einde nodig hê om almal na die nuwe kopie te skuif. So potensieel kan ons dit oplos. En dit is hoe ons dit doen met gelyktydige indeksering. Maar dit is baie moeiliker om te doen. En dit geld baie sterk vir jou vorige vraag oor slot eksklusief.
Is dit moontlik om sluittyd in Postgres by te voeg? In Oracle kan ek byvoorbeeld "kies om op te dateer" skryf en 50 sekondes wag voordat ek opdateer. Dit was goed vir die toepassing. Maar in Postgres moet ek dit óf dadelik doen en glad nie wag nie, óf wag tot 'n geruime tyd.
Ja, jy kan kies om jou slotte, jou slotte, uit te laat. Jy kan ook die no way-opdrag uitreik, wat sal wees ... as jy nie dadelik die slot kan kry nie. Sluit dus uitteltyd, of iets anders wat jou sal toelaat om dit te doen. Dit word nie op sintaktiese vlak gedoen nie. Dit word gedoen as 'n veranderlike op die bediener. Soms kan dit nie gebruik word nie.
Kan jy skyfie 75 oopmaak?
Ja.
En my vraag is volgende. Waarom wag albei opdateringsprosesse vir 703?
En dit is 'n wonderlike vraag. Ek verstaan terloops nie hoekom Postgres dit doen nie. Maar toe 703 geskep is, het dit gewag vir 702. En wanneer 704 en 705 opdaag, lyk dit of hulle nie weet waarvoor hulle wag nie, want daar is nog niks daar nie. En Postgres doen dit so: wanneer jy nie 'n slot kan kry nie, sê dit "Wat is die punt om jou te verwerk?", Want jy wag reeds vir iemand. So laat dit maar in die lug hang, dit werk dit glad nie op nie. Maar wat het hier gebeur? Sodra 702 die proses voltooi het en 703 sy slot ontvang het, het die stelsel teruggekeer. En sy het gesê dat ons nou twee mense het wat wag. En kom ons werk hulle dan saam op. En dui aan dat albei verwag word.
Ek weet nie hoekom Postgres dit doen nie. Maar daar is 'n probleem genaamd f…. Dit lyk vir my of dit nie 'n term in Russies is nie. Dit is wanneer almal vir een kasteel wag, selfs al is daar 20 gevalle wat vir die kasteel wag. En skielik word hulle almal op dieselfde tyd wakker. En almal begin probeer reageer. Maar die stelsel maak dit so dat almal wag vir 703. Want hulle wag almal, en ons sal hulle almal dadelik in ry. En as daar enige ander nuwe versoek verskyn wat daarna gevorm is, byvoorbeeld 707, dan sal daar weer 'n leemte wees.
En dit lyk vir my of dit gedoen word om te kan sê dat 702 op hierdie stadium vir 703 wag, en almal wat daarna kom, hulle sal geen inskrywing in hierdie veld hê nie. Maar sodra die eerste kelner vertrek, en almal wat op daardie oomblik voor die opdatering gewag het, ontvang dieselfde teken. En so lyk dit vir my of dit gedoen word sodat ons in volgorde kan verwerk, sodat hulle behoorlik georden is.
Ek het dit altyd as 'n nogal vreemde verskynsel beskou. Want hier word hulle byvoorbeeld glad nie gelys nie. Maar, lyk dit vir my, elke keer as ons 'n nuwe slot gee, kyk ons na almal wat in die proses is om te wag. Dan ry ons hulle almal in lyn. En dan word enige nuwe een wat inkom, eers in die tou gestel wanneer die volgende persoon klaar verwerk het. 'n Baie goeie vraag. Baie dankie vir jou vraag!
Dit lyk vir my baie meer logies as 705 704 verwag.
Maar die probleem hier is die volgende. Tegnies kan jy óf een óf daardie een wakker maak. En so word ons die een of die ander wakker. Maar wat gebeur in die werking van die stelsel? Jy kan sien hoe 703 heel bo sy eie transaksie-ID geblokkeer het. Dit is hoe Postgres werk. En 703 word geblokkeer deur sy eie transaksie-ID, so as iemand wil wag, dan sal hy wag vir 703. En, in werklikheid, 703 voltooi. En eers na die voltooiing daarvan word een van die prosesse wakker. En ons weet nie watter soort proses dit sal wees nie. Dan verwerk ons alles geleidelik. Maar dit is nie duidelik watter proses eerste wakker word nie, want dit kan enige van hierdie prosesse wees. Basies het ons 'n skeduleerder gehad wat gesê het dat ons nou enige van hierdie prosesse kan wakker maak. Ons kies net een lukraak. Daarom moet op albei van hulle gelet word, want ons kan enige van hulle wakker maak.
En die probleem is dat ons CP-oneindigheid het. En daarom is dit heel waarskynlik dat ons die latere een kan wakker maak. En as ons byvoorbeeld later wakker word, dan sal ons wag vir die een wat pas die slot ontvang het, so ons bepaal nie wie presies eerste wakker gemaak gaan word nie. Ons skep net so 'n situasie, en die stelsel sal hulle lukraak wakker maak.
Daar is . Kyk, hulle is ook interessant en nuttig. Die onderwerp is natuurlik verskriklik kompleks. Baie dankie Bruce!
Bron: will.com