Oversigt over Bruce Momjian's rapport fra 2020 "Unlocking the Postgres Lock Manager".
(BemĂŠrk: Alle SQL-forespĂžrgsler fra diasene kan hentes via dette link: )
Hej! Det er fantastisk at vÊre tilbage her i Rusland. Jeg beklager, at jeg ikke kunne komme sidst Är, men i Är har Ivan og jeg store planer. Jeg hÄber, at jeg vil vÊre her meget oftere. Jeg elsker at besÞge Rusland. Jeg vil besÞge Tyumen og Tver. Jeg er meget glad for, at jeg fÄr mulighed for at vÊre i disse byer.
Mit navn er Bruce Momjian. Jeg arbejder hos EnterpriseDB og har arbejdet med Postgres i over 23 Är. Jeg bor i Philadelphia, USA. Jeg rejser ca. 90 dage om Äret og deltager i omkring 40 konferencer. Min , som indeholder de dias, jeg snart vil vise jer. SÄ efter konferencen kan I downloade dem fra min personlige hjemmeside. Der er ogsÄ omkring 30 prÊsentationer samt videoer og et stort antal blogindlÊg, over 500. Det er en ret omfattende ressource. Og hvis I er interesserede i dette materiale, inviterer jeg jer til at bruge det.
Jeg har tidligere vÊret underviser, professor fÞr jeg begyndte at arbejde med Postgres. Og jeg er meget glad for at fÄ mulighed for at fortÊlle jer det, jeg vil dele nu. Det er en af de mest interessante prÊsentationer, jeg har lavet. Denne prÊsentation indeholder 110 dias. Vi vil starte med simple emner, og jo lÊngere vi kommer ind i foredraget, desto svÊrere bliver det, og til sidst bliver det temmelig komplekst.
Det er et ret ubehageligt emne. LÄse er ikke det mest populÊre emne. Vi Þnsker, at det skal forsvinde et sted. Det er ligesom at gÄ til tandlÊgen.
- LÄse er et problem for mange mennesker, der arbejder med databaser, hvor flere processer kÞrer samtidigt. De har brug for lÄsning. Dvs. i dag vil jeg give jer grundlÊggende kendskab til lÄsning.
- Transaktionsidentifikatorer. Dette er en ret kedelig del af prÊsentationen, men de er nÞdvendige at forstÄ.
- Derefter vil vi tale om lÄsetyper. Dette er en ret mekanisk del.
- Og derefter vil vi give nogle eksempler pÄ lÄse. Og det vil vÊre ret svÊrt at forstÄ.
Lad os tale om lÄse.
Terminologien er ret komplicerede. Hvor mange af jer ved, hvor dette citat er fra? To personer. Det er fra et spil, der hedder "Kolosalt eventyr i hulen". Det var et tekstbaseret computerspil i 80'erne, synes jeg. Man skulle gÄ ind i en hule, i en labyrint, og teksten Êndrede sig, men indholdet var cirka det samme hver gang. SÄdan husker jeg dette spil.
Her ser vi navnet pÄ lÄse, der kommer fra Oracle. Vi bruger dem.
Her ser vi termer, der forvirrer mig. For eksempel SHARE UPDATE EXCLUSIVE. Derudover SHARE RAW EXCLUSIVE. Ărligt talt er disse navne ikke sĂŠrlig klare. Vi vil forsĂžge at undersĂžge dem mere detaljeret. Nogle indeholder ordet "share", som betyder â at dele. Nogle indeholder ordet "exclusive" â eksklusiv. I nogle indeholder begge disse ord. Jeg vil gerne begynde med, hvordan disse lĂ„se fungerer.
Og det er ogsĂ„ meget vigtigt med ordet "adgang" â access. Og ordet "row" â rĂŠkke. Det vil sige, adgangsfordeling, rĂŠkkefordeling.
Et andet problem, der skal forstÄs i Postgres, som jeg desvÊrre ikke kan forklare i min prÊsentation, er MVCC. Jeg har en separat prÊsentation om dette emne pÄ min hjemmeside. Og hvis du synes, at denne prÊsentation er svÊr, sÄ er MVCC nok den svÊreste for mig. Og hvis du er interesseret, kan du se den pÄ hjemmesiden. Du kan se videoen.
En anden ting, vi skal forstĂ„ â er transaktionsidentifikatorer. Mange transaktioner kan ikke fungere uden unikke identifikatorer. Og her forklarer vi, hvad en transaktion er. I Postgres er der to systemer til nummerering af transaktioner. Jeg ved, det er ikke en sĂŠrlig pĂŠn lĂžsning.
VÊr ogsÄ opmÊrksom pÄ, at slides vil vÊre ret svÊre at forstÄ, sÄ det, der er fremhÊvet med rÞdt, er det, man virkelig skal lÊgge mÊrke til.
Lad os se. Nummeret pÄ transaktionen er fremhÊvet med rÞdt. Her vises funktionen SELECT pg_back. Den returnerer min transaktion og ID'en pÄ denne transaktion.
En anden ting, hvis du kan lide denne prÊsentation, og du vil have den i din database, kan du fÞlge dette link, der er fremhÊvet i pink, og downloade SQL til denne prÊsentation. Du kan bare kÞre det i dit PSQL, og hele prÊsentationen vises pÄ din skÊrm Þjeblikkeligt. Den vil ikke indeholde farver, men i det mindste vil vi kunne se den.
I dette tilfĂŠlde ser vi transaktions-ID'et. Det er det nummer, vi har tildelt det. Og der er en anden type transaktions-ID i Postgres, som kaldes virtuel transaktions-ID.
Og vi skal forstÄ dette. Det er meget vigtigt, ellers kan vi ikke forstÄ lÄsningen i Postgres.
Virtuel transaktions-ID er et transaktions-ID, der ikke indeholder permanente vÊrdier. For eksempel, hvis jeg kÞrer en SELECT-kommando, sÄ Êndrer jeg sandsynligvis ikke databasen, jeg vil ikke lÄse noget. Derfor, nÄr vi kÞrer en simpel SELECT, tildeler vi ikke denne transaktion et permanent ID. Vi giver den kun et virtuelt ID.
Og det forbedrer ydeevnen i Postgres, forbedrer mulighederne for oprydning, sÄ det virtuelle transaktions-ID bestÄr af to tal. Det fÞrste tal fÞr skrÄstregen er backend-id'et. Og til hÞjre ser vi bare en tÊller.
SĂ„ hvis jeg kĂžrer en forespĂžrgsel, siger den, at backend-id'et er 2.
Og hvis jeg kÞrer en serie af sÄdanne transaktioner, ser vi, at tÊlleren hver gang Þges, nÄr jeg kÞrer forespÞrgslen. For eksempel nÄr jeg kÞrer forespÞrgslerne 2/10, 2/11, 2/12 osv.
VĂŠr opmĂŠrksom pĂ„, at der her er to kolonner. Til venstre ser vi det virtuelle transaktions-ID â 2/12. Og til hĂžjre har vi det permanente transaktions-ID. Og dette felt er tomt. Denne transaktion ĂŠndrer ikke databasen. Derfor tildeler jeg ikke et permanent transaktions-ID til den.
SÄ snart jeg kÞrer analysér-kommandoen (ANALYZE), giver den samme forespÞrgsel mig et permanent transaktions-ID. Se hvordan det har Êndret sig. Jeg havde ikke dette ID fÞr, nu er det til stede.
SÄ her er endnu en forespÞrgsel, endnu en transaktion. Det virtuelle transaktionsnummer er 2/13. Og hvis jeg beder om det permanente transaktions-ID, sÄ vil jeg fÄ det, nÄr jeg kÞrer forespÞrgslen.
SÄ endnu en gang. Vi har det virtuelle transaktions-ID og det permanente transaktions-ID. Bare forstÄ dette punkt for at forstÄ Postgres' adfÊrd.
Vi gÄr videre til det tredje afsnit. Her vil vi kort gennemgÄ de forskellige typer af lÄsninger i Postgres. Det er ikke meget interessant. Det sidste afsnit bliver langt mere interessant. Men vi skal tage de grundlÊggende ting i betragtning, for ellers vil vi ikke forstÄ, hvad der kommer nÊste gang.
Vi vil dÊkke dette afsnit, vi vil se pÄ hver type lÄsning. Og jeg vil vise jer eksempler pÄ, hvordan de etableres, hvordan de fungerer, og vise jer nogle forespÞrgsler, som kan bruges til at se, hvordan lÄsning fungerer i Postgres.
For at oprette en forespÞrgsel og se, hvad der sker i Postgres, skal vi kÞre en forespÞrgsel pÄ systemvisningen. I dette tilfÊlde er pg_lock markeret med rÞdt. Pg_lock er en systemtabel, der fortÊller os, hvilke lÄsninger der i Þjeblikket er aktive i Postgres.
Det er dog meget svÊrt for mig at vise jer pg_lock i sig selv, fordi det er ret komplekst. Derfor har jeg oprettet en visning, der viser pg_locks. Og det udfÞrer ogsÄ noget arbejde for mig, som gÞr det lettere for mig at forstÄ. Det vil sige, at det udelukker mine egne lÄsninger, min egen session osv. Dette er blot standard SQL, og det giver mig bedre mulighed for at vise jer, hvad der foregÄr.
En anden udfordring er, at denne visning er meget bred, sĂ„ jeg mĂ„ oprette en anden â lockview2.
Og den viser mig flere kolonner fra tabellen. Og endnu en, der viser mig de Þvrige kolonner. Det er temmelig kompliceret, sÄ jeg har forsÞgt at prÊsentere det sÄ simpelt som muligt.
SÄ vi har oprettet en tabel kaldet Lockdemo. Og vi har oprettet én rÊkke der. Det er vores eksempel tabel. Og vi vil oprette afsnit for blot at vise jer eksempler pÄ lÄsninger.
SÄ en rÊkke, en kolonne. Den fÞrste type lÄsning kaldes ACCESS SHARE. Dette er den mindst begrÊnsende lÄsning. Det betyder, at den nÊsten ikke konflikter med andre lÄsninger.
Og hvis vi vil eksplicit definere lÄsningen, kÞrer vi kommandoen «lock table». Den vil tydeligt lÄse, dvs. i ACCESS SHARE-tilstand kÞrer vi lock table. Hvis jeg kÞrer PSQL i baggrunden, starter jeg dermed en anden session fra min fÞrste session. Hvad gÞr jeg her? Jeg skifter til den anden session og siger til den «vis mig lockview for denne forespÞrgsel». Her har jeg AccessShareLock i denne tabel. Det er lige prÊcis, hvad jeg bad om. Og den siger, at lÄsen er tildelt. Meget enkelt.
Derefter, hvis vi ser pÄ den anden kolonne, er der intet. De er tomme.
Og hvis jeg kÞrer kommandoen «SELECT», er det en implicit (explicit) mÄde at anmode om AccessShareLock. SÄ jeg lÄser min tabel og kÞrer forespÞrgslen, og forespÞrgslen returnerer flere rÊkker. Og i en af rÊkkerne ser vi AccessShareLock. SÄledes udlÞser SELECT AccessShareLock i tabellen. Og den konflikter stort set med ingenting, fordi det er en lav-niveau lÄs.
Hvad hvis jeg kĂžrer SELECT, og jeg har tre forskellige tabeller? Tidligere kĂžrte jeg kun en tabel, nu kĂžrer jeg tre: pg_class, pg_namespace og pg_attribute.
Og nu, nÄr jeg ser pÄ forespÞrgslen, ser jeg 9 AccessShareLocks i de tre tabeller. Hvorfor? Tre tabeller er fremhÊvet med blÄ: pg_attribute, pg_class, pg_namespace. Men du kan ogsÄ se, at alle indekser, der er defineret gennem disse tabeller, ogsÄ har AccessShareLock.
Og det er en lÄs, der stort set ikke konflikter med andre. Alt, hvad den gÞr, er at forhindre os i at nulstille tabellen, mens vi vÊlger den. Det giver mening. Dvs. hvis vi vÊlger en tabel, sÄ forsvinder den pÄ det tidspunkt, hvilket ville vÊre forkert, derfor AccessShare er en lav-niveau lÄs, der siger "slet ikke denne tabel, mens jeg arbejder". I bund og grund er det alt, hvad den gÞr.
ROW SHARE er en lidt anderledes lÄs.
Lad os tage et eksempel. SELECT ROW SHARE er en mÄde at lÄse hver rÊkke enkeltvis pÄ.. SÄledes kan ingen slette eller Êndre dem, mens vi ser pÄ dem.
SÄ, hvad gÞr SHARE LOCK? Vi ser, at transaktions-ID 681 er brugt til SELECT. Og det er interessant. Hvad er der sket her? For fÞrste gang ser vi et nummer i 'Lock'-feltet. Vi tager transaktions-ID'et, og det siger, at det lÄser den eksklusivt. Alt, hvad det gÞr, er at sige, at jeg har en rÊkke, der teknisk set er lÄst et sted i tabellen. Men det siger ikke, hvor prÊcist. Senere vil vi se nÊrmere pÄ dette.
Her siger vi, at lÄsningen bruges af os.
SÄ den eksklusive lÄs siger eksplicit, at den er eksklusiv. Og hvis du sletter en rÊkke i denne tabel, sÄ vil det ogsÄ ske, som du kan se.
SHARE EXCLUSIVE â det er en lĂŠngere lĂ„s.
Dette (ANALYZE) er en analysekommando, der vil blive brugt.
SHARE LOCK â du kan eksplicit lĂ„se i delingsmode.
Du kan ogsÄ oprette en unik indeks. Og der kan du se SHARE LOCK, som er en del af dem. Og den lÄser tabellen og sÊtter en SHARE LOCK pÄ den.
Som standard betyder SHARE LOCK pÄ tabellen, at andre kan lÊse tabellen, men ingen kan Êndre den. Og det er prÊcis, hvad der sker, nÄr du opretter en unik indeks.
Hvis jeg opretter en unik concurrently indeks, sÄ vil jeg have en anden type lÄs, fordi, som du husker, reducerer brugen af concurrently indekser lÄsekravene. Og hvis jeg bruger normal lÄs, normal indeks, sÄ forhindrer jeg dermed skrivning til indeks-tabellen under dens oprettelse. Hvis jeg bruger concurrently indeks, sÄ skal jeg bruge en anden type lÄs.
SHARE ROW EXCLUSIVE â den kan igen angives eksplicit.
Eller vi kan oprette en regel, dvs. tage en bestemt situation, hvor den vil blive brugt.
EXCLUSIVE-lÄs betyder, at ingen andre kan Êndre tabellen.
Her ser vi forskellige typer lÄse.
ACCESS EXCLUSIVE, for eksempel, er en lÄsekommando. For eksempel, hvis du laver CLUSTER table, sÄ betyder det, at ingen vil kunne skrive til det. Og den lÄser ikke kun selve tabellen, men ogsÄ indeksene.
Dette er den anden side af ACCESS EXCLUSIVE-lÄs, hvor vi prÊcist ser, hvad den lÄser i tabellen. Den lÄser individuelle rÊkker i tabellen, hvilket er ret interessant.
Dette er alle de grundlĂŠggende oplysninger, jeg Ăžnskede at give. Vi har talt om blokeringer, om transaktions-ID'er, vi talte om virtuelle transaktions-ID'er, om permanente transaktions-ID'er.
Og nu vil vi gennemgÄ eksempler pÄ blokeringer. Dette er den mest interessante del. Vi vil se pÄ meget interessante tilfÊlde. Og mit mÄl med denne prÊsentation er at give dig en bedre forstÄelse af, hvad Postgres faktisk gÞr, nÄr det forsÞger at blokere visse ting. Jeg synes, det klarer at blokere individuelle dele meget godt.
Lad os se pÄ nogle konkrete eksempler.
Vi starter med tabeller og en enkelt rÊkke i tabellen. NÄr jeg indsÊtter noget, fÄr jeg vist ExclusiveLock, transaktions-ID'et og ExclusiveLock pÄ tabellen.
Hvad sker der, hvis jeg indsÊtter to rÊkker mere? Og nu har vi tre rÊkker i vores tabel. Jeg indsatte én rÊkke og fik dette som output. Og hvis jeg indsÊtter to rÊkker mere, hvad er der sÄ mÊrkeligt ved dette? Der er en underlighed, fordi jeg har tilfÞjet tre rÊkker til denne tabel, men jeg har stadig to rÊkker i blokeringstabellen. Og det er i bund og grund det grundlÊggende adfÊrdsmÞnster i Postgres.
Mange tror, at hvis du i databasen blokerer 100 rÊkker, sÄ skal du lave 100 blokeringer. Hvis jeg blokerer 1.000 rÊkker pÄ én gang, sÄ er jeg nÞdt til at lave 1.000 sÄdanne forespÞrgsler. Og hvis jeg har brug for at blokere en million eller milliard. Men hvis vi gÞr det, vil det ikke fungere sÊrlig godt. Hvis du har brugt et system, der opretter blokeringer for hver enkelt rÊkke, kan du se, at det er kompliceret. Fordi du skal definere blokeringstabellen pÄ én gang, som kan lÞbe over, men Postgres gÞr ikke sÄdan.
Og pÄ denne slide er det meget vigtigt, at det her tydeligt viser, at der er et andet system, der arbejder indenfor MVCC, som blokerer individuelle rÊkker. Derfor, nÄr du blokerer milliarder af rÊkker, skaber Postgres ikke en milliard separate blokeringer. Og det pÄvirker ydeevnen meget positivt.
Hvordan er det med opdatering? Jeg opdaterer lige nu en rÊkke, og du kan mÄske bemÊrke, at den straks udfÞrte to forskellige operationer. Den har samtidig lÄst tabellen, men den har ogsÄ lÄst indekset. Og den skulle lÄse indekset, fordi der er unikke begrÊnsninger pÄ denne tabel. Vi vil sikre os, at ingen Êndrer det, derfor lÄser vi det.
Hvad hvis jeg vil opdatere to rÊkker? Og vi ser, at den opfÞrer sig det samme. Vi udfÞrer dobbelt sÄ mange opdateringer, men det samme antal lÄserÊkker.
Hvis du er interesseret i, hvordan Postgres gÞr det, skal du lytte til mine prÊsentationer om MVCC for at lÊre, hvordan Postgres internt markerer de rÊkker, den Êndrer. Og Postgres har en mÄde, hvorpÄ den gÞr det, men den gÞr det ikke pÄ tabelniveau, men pÄ et lavere og mere effektivt niveau.
Og hvis jeg vil slette noget? Hvis jeg sletter for eksempel én rÊkke, og jeg stadig har mine to lÄseindgange, sÄ selvom jeg Þnsker at slette dem alle, er de stadig der.
For eksempel, hvis jeg vil indsÊtte 1.000 rÊkker, og derefter slette eller tilfÞje 1.000 rÊkker, sÄ registreres de individuelle rÊkker, jeg tilfÞjer eller Êndrer, ikke her. De registreres pÄ et lavere niveau inden i selve rÊkken. Og under prÊsentationen om MVCC talte jeg om dette i detaljer. Men det er meget vigtigt, nÄr du analyserer lÄse, at sikre, at du har en lÄs pÄ tabelniveau, og at du ikke ser, hvordan individuelle rÊkker registreres her.
Hvad med eksplicit lÄsning?
Hvis jeg trykker pÄ 'opdater', har jeg to lÄste rÊkker. Og hvis jeg markerer dem alle og trykker pÄ 'opdater alle', har jeg stadig to lÄseposter tilbage.
Vi opretter ikke separate poster for hver enkelt rĂŠkke. For ellers falder ydeevnen, der kan blive for meget af det. Og vi kan havne i en uheldig situation.
Og det samme, hvis vi gÞr det shared, kan vi gÞre det pÄ alle 30 gange.
Vi gendanner vores tabel, sletter alt, og sÄ indsÊtter vi én rÊkke igen.
En anden opfĂžrsel, som du ser i Postgres, er en meget velkendt og Ăžnsket adfĂŠrd â det vil sige, at du kan udfĂžre update eller select. Og du kan gĂžre det samtidigt. Og select blokerer ikke update, og det samme gĂŠlder omvendt. Vi siger, at lĂŠseren ikke blokerer for den, der skriver, og den, der skriver, blokerer ikke lĂŠseren.
Jeg vil vise dig et eksempel pĂ„ dette. Jeg vil nu lave et valg. Vi vil senere lave et INSERT. Og du vil derefter kunne se â 694. Du vil kunne se ID for den transaktion, der udfĂžrte denne indsĂŠttelse. Og det er sĂ„dan, det fungerer.
Og hvis jeg nu kigger pĂ„ mit backend ID, sĂ„ er det blevet â 695.
Og jeg kan se, at 695 vises i min tabel.
Og hvis jeg udfÞrer en opdatering her pÄ denne mÄde, sÄ fÄr jeg et andet tilfÊlde. I dette tilfÊlde er 695 en eksklusiv lÄs, og opdateringen har samme adfÊrd, men der opstÄr ikke konflikt mellem dem, hvilket er ret usÊdvanligt.
Og du kan bemĂŠrke, at Ăžverst â det er ShareLock, og nederst â det er ExclusiveLock. Og begge transaktioner blev gennemfĂžrt.
Og du bÞr lytte til mit foredrag om MVCC for at forstÄ, hvordan det sker. Men dette er en illustration af, at du kan gÞre dette samtidigt, dvs. bÄde udfÞre SELECT og UPDATE.
Lad os nulstille og lave en operation Ă©n gang til.
Hvis du prĂžver at kĂžre to updates pĂ„ samme rĂŠkke samtidigt, sĂ„ vil det blive lĂ„st. Og husk, jeg sagde, at lĂŠseren ikke blokerer for skribenten, men skribenten blokerer for lĂŠseren, men Ă©n skribent blokerer en anden skribent. Det vil sige, at vi ikke kan have to personer, der samtidig opdaterer den samme rĂŠkke. Vi skal vente, indtil en af ââdem er fĂŠrdig.
Og for at illustrere dette vil jeg kigge pÄ Lockdemo-tabellen. Og vi vil se pÄ én rÊkke. PÄ transaktion 698.
Vi opdaterede det til 2. 699 â det fĂžrste opdatering. Og det blev gennemfĂžrt med succes, eller det er i en ventende transaktion og venter pĂ„, at vi bekrĂŠfter eller annullerer.
Men se pĂ„ noget andet â 2/51 â det er vores fĂžrste transaktion, vores fĂžrste session. 3/112 â det er den anden forespĂžrgsel, der dukkede op ovenfor og som ĂŠndrede denne vĂŠrdi til 3. Og hvis du bemĂŠrker, sĂ„ blokerede den Ăžverste sig selv, som er 699. Men 3/112 gav ikke nogen blokering. I kolonnen Lock_mode stĂ„r der, at den venter. Den venter pĂ„ 699. Og hvis du ser, hvor 699 er, er det ovenover. Og hvad gjorde den fĂžrste session? Den oprettede en eksklusiv blokering pĂ„ sin egen transaktions-ID. Det er sĂ„dan, Postgres gĂžr det. Den blokerer sin egen transaktions-ID. Og hvis du vil vente pĂ„, at nogen bekrĂŠfter eller annullerer, skal du vente, indtil der er en ventende transaktion. Og derfor kan vi se den mĂŠrkelige linje.
Lad os se pÄ det igen. Til venstre ser vi vores behandlings-ID. I den anden kolonne ser vi vores virtuelle transaktions-ID, og i den tredje ser vi lock_type. Hvad betyder det? I bund og grund siger den, at den blokerer transaktions-ID'et. Men bemÊrk, at der i alle rÊkkerne nedenunder stÄr relation. Og derfor har du to slags blokering i tabellen. Der er relation blokering. Og der er ogsÄ transactionid blokering, hvor du blokerer dig selv, det er netop hvad der sker i den fÞrste rÊkke eller i bunden, hvor transationid er, hvor vi venter pÄ, at 699 afslutter sin operation.
Jeg ser, hvad der sker her. Og der sker to ting pÄ én gang. Du ser pÄ blokeringen af transaktions-ID'et i den fÞrste rÊkke, som blokerer sig selv. Og den blokerer sig selv for at fÄ folk til at vente.
Hvis du ser pÄ den 6. rÊkke, sÄ er det samme optegnelse som den fÞrste. Og derfor blokeres transaktion 699. 700 blokerer ogsÄ sig selv. Og sÄ vil du i den nederste rÊkke se, at vi venter pÄ, at 699 afslutter sin operation.
Og i lock_type, tuple kan du se numrene.
Du kan se, at det er 0/10. Og det er sidenummeret, og ogsÄ offset for denne specifikke rÊkke.
Og du ser, at det bliver 0/11, nÄr vi opdaterer.
Men i virkeligheden â det er 0/10, fordi denne operation venter. Vi har mulighed for at se, at det er den rĂŠkke, som jeg venter pĂ„ at bekrĂŠfte.
SÄ snart vi bekrÊfter det og klikker pÄ commit, og nÄr opdateringen er fÊrdig, er dette, hvad vi fÄr tilbage. Transaktion 700 er den eneste lÄs, den venter ikke pÄ nogen, fordi den er blevet bekrÊftet. Den venter blot pÄ, at transaktionen afsluttes. SÄ snart 699 er fÊrdig, venter vi ikke lÊngere. Og nu siger transaktion 700, at alt er i orden, at alle de nÞdvendige lÄse er tilgÊngelige i alle tilladte tabeller.
Og for at gÞre det hele endnu mere kompliceret, opretter vi endnu en view, der denne gang vil give os hierarkiet. Jeg forventer ikke, at du forstÄr denne forespÞrgsel. Men det vil give os et klarere billede af, hvad der foregÄr.
Dette er et rekursivt view, som ogsÄ har endnu en sektion. Og det samler sÄ alt sammen igen. Lad os bruge det.
Hvad hvis vi laver tre samtidige opdateringer og siger, at rĂŠkken nu er lig med tre. Og vi ĂŠndrer 3 til 4.
Og her ser vi 4. Og transaktions-ID 702.
Og sÄ Êndrer jeg 4 til 5. Og 5 til 6, og 6 til 7. Og jeg stiller en rÊkke mennesker i kÞ, der venter pÄ, at denne ene transaktion bliver afsluttet.
Og alt bliver klart. Hvad er den fÞrste rÊkke? Det er 702. Det er transaktions-ID'et, der oprindeligt satte denne vÊrdi. Og hvad stÄr der i kolonnen Granted? Jeg har bemÊrkninger f. Det er mine opdateringer, der (5, 6, 7) ikke kan godkendes, fordi vi venter pÄ, at transaktions-ID 702 afslutter. Der har vi en lÄs pÄ transaktions-ID. Og der resulterer i 5 transaktionslÄs-ID'er.
Og hvis du ser pÄ 704, pÄ 705, sÄ er der stadig ikke skrevet noget, fordi de stadig ikke ved, hvad der foregÄr. De skriver bare, at de ikke aner, hvad der sker. Og de vil bare gÄ i dvale, fordi de venter pÄ, at nogen afslutter og vÊkker dem, nÄr det bliver muligt at Êndre rÊkken.
SÄdan ser det ud. Det er klart, at de alle venter pÄ rÊkke 12.
Det er hvad vi sÄ her. Her er 0/12.
Og sÄ snart den fÞrste transaktion er godkendt, kan du her se, hvordan hierarkiet fungerer. Og nu bliver alt klart. De alle bliver rene. Og de er faktisk stadig i venteposition.
Dette er, hvad der sker. 702 begynder at committe. Og nu fÄr 703 denne rÊkke-lÄs, og sÄ begynder 704 at vente pÄ, at 703 committer. 705 venter ogsÄ pÄ dette. Og nÄr det hele afsluttes, rydder de selv op. Jeg vil gerne pÄpege, at alle stiller sig i kÞ. Det ligner meget en trafikprop, hvor alle venter pÄ den fÞrste bil. Den fÞrste bil stopper, og alle stiller sig i en lang rÊkke. SÄ bevÊger den sig, hvorefter den nÊste bil kan kÞre frem og fÄ sin lÄs osv.
Og hvis du syntes, det var ikke kompliceret nok, sÄ skal vi nu tale om deadlocks. Jeg ved ikke, hvem af jer der har oplevet dette. Det er et ret almindeligt problem i databasesystemer. Men deadlocks opstÄr, nÄr en session venter pÄ, at en anden session udfÞrer noget. I mellemtiden venter den anden session pÄ, at den fÞrste session udfÞrer noget.
For eksempel, hvis Ivan siger: âGiv mig nogetâ, og jeg siger: âNej, jeg giver dig kun dette, hvis du giver mig noget andetâ. Og han siger: âNej, jeg giver dig ikke dette, medmindre du giver migâ. SĂ„ ender vi i en dĂžd lĂ„sesituation. Jeg er sikker pĂ„, at Ivan ikke ville gĂžre det, men du forstĂ„r pointen, at vi har to personer, der Ăžnsker at fĂ„ noget, og de er ikke villige til at give det, fĂžr den anden person giver dem, hvad de Ăžnsker. Og der er ingen lĂžsning.
I det vÊsentlige skal din database opdage dette. Og sÄ skal den lukke eller afslutte en af sessionerne, fordi ellers bliver de hÊngende der for evigt. Dette ser vi i databaser, vi ser det i operativsystemer. Og alle steder, hvor vi har parallelle processer, kan dette ske.
Og nu vil vi sÊtte to deadlocks. Vi vil sÊtte 50 og 80. I fÞrste rÊkke vil jeg udfÞre en opdatering fra 50 til 50. Jeg fÄr transaktionsnummeret 710.
Og sÄ vil jeg Êndre 80 til 81, og 50 til 51.
Og sÄdan vil det se ud. Derfor har 710 en rÊkke-lÄs, og 711 venter pÄ bekrÊftelse. Vi sÄ det, da vi opdaterede. 710 er ejer af vores rÊkke. Og 711 venter pÄ, at 710 afslutter transaktionen.
Og der stÄr endda angivet prÊcist pÄ hvilken rÊkke, vi oplever deadlocks. Og det er her, det begynder at blive mÊrkeligt.
Nu opdaterer vi 80 til 80.
Og her begynder deadlocks. 710 venter pÄ respons fra 711, mens 711 venter pÄ 710. Og dette vil ikke ende godt. Der er ingen vej ud. De vil vente pÄ hinanden.
Og det vil bare begynde at forsinke det hele. Det Ăžnsker vi ikke.
Og i Postgres er der mÄder at opdage, nÄr dette sker. NÄr det sker, fÄr du en fejl som denne. Det bliver klart, at en proces venter pÄ en SHARE LOCK fra en anden proces, der blokkeres af proces 711. Den proces Þnskede en SHARE LOCK pÄ en given transaktions-ID og blev blokkeret af en anden proces. SÄ her er der tale om en deadlock.
Kan der vĂŠre en trevej deadlock? Er det muligt? Ja.
Vi indtaster disse tal i tabellen. Vi ĂŠndrer 40 til 40, vi laver en blokering.
Ăndrer 60 til 61, 80 til 81.
Og sĂ„ ĂŠndrer vi 80, og sĂ„ â bam!
Og 714 venter nu pÄ 715. 716 venter pÄ 715. Og der er ikke noget at gÞre ved det.
Her er der ikke blot to personer, men tre. Jeg Þnsker noget fra dig, denne Þnsker noget fra den tredje person, og den tredje person Þnsker noget fra mig. Og vi ender i en trevejsventesituation, fordi vi alle venter pÄ, at den anden skal fÊrdiggÞre, hvad de skal gÞre.
Og Postgres ved, hvilken rĂŠkke dette sker i. Derfor giver den dig den fĂžlgende besked, der viser, at du har et problem, hvor tre input blokerer hinanden. Og der er ingen begrĂŠnsninger. Dette kan vĂŠre i tilfĂŠlde, hvor 20 optegnelser blokerer hinanden.
Det nĂŠste problem er serializable.
Hvis der er en sĂŠrlig serializable blokering.
Og vi vender tilbage til 719. Den har en helt normal udgave.
Og du kan klikke for at gĂžre transaktionen serializable.
Og du forstĂ„r, at du nu har en anden form for blokering SA â det betyder serializable.
Derfor har vi en ny form for blokering, der kaldes SARieadLock, som er en serieblokering og tillader indtĂŠgt af serier.
Og du kan ogsÄ indsÊtte unikke indekser.
I denne tabel har vi unikke indekser.
SÄ hvis jeg indtaster tallet 2 her, har jeg 2. Men helt Þverst indsÊtter jeg endnu et 2. Og du kan se, at 721 har en eksklusiv lÄs. Men nu venter 722 pÄ, at 721 skal fÊrdiggÞre sin operation, fordi den ikke kan indsÊtte 2, fÞr den ved, hvad der sker med 721.
Og hvis vi laver en subtransaction.
Her har vi 723.
Og hvis vi gemmer punktet og derefter opdaterer det, fÄr vi et nyt transaktions-ID. Dette er endnu en adfÊrd, du skal kende til. Hvis vi returnerer dette, forsvinder transaktions-ID'et. 724 forsvinder. Men nu har vi 725.
Og hvad prĂžver jeg at gĂžre her? Jeg prĂžver at vise dig eksempler pĂ„ usĂŠdvanlige lĂ„se, som du kan finde: uanset om det er serializable lĂ„se eller SAVEPOINT â disse er forskellige typer lĂ„se, der vil blive vist i lĂ„setabellen.
Dette er oprettelsen af eksplicitte (Äbne) lÄse, hvor pg_advisory_lock.
Og du kan se, at lÄsetypen her er angivet som advisory. Og det stÄr med rÞdt 'advisory'. Og du kan samtidig lÄse med pg_advisory_unlock.
Og for at afslutte vil jeg gerne vise dig endnu en fantastisk ting. Jeg vil lave en anden type. Men jeg vil forbinde tabellen pg_locks med tabellen pg_stat_activity. Og hvorfor vil jeg gÞre dette? Fordi det vil give mig mulighed for at se og overvÄge alle nuvÊrende sessioner og se, hvilke specifikke lÄse de venter pÄ. Og det er ret interessant, nÄr vi samler lÄsetabellen og forespÞrgsels-tabellen.
Og her opretter vi pg_stat_view.
Og vi opdaterer rÊkken med én. Og her ser vi 724. Og derefter opdaterer vi vores rÊkke til tre. Og hvad ser du her nu? Dette er forespÞrgsler, altsÄ ser du hele listen over forespÞrgsler, der er angivet i den venstre kolonne. Og derefter kan du se lÄsene og hvad de skaber pÄ hÞjre side. Og dette kan vÊre mere forstÄeligt for dig, sÄ du ikke behÞver at vende tilbage til hver session hver gang for at se, om du skal tilslutte dig eller ej. Dette gÞr de for os.
En anden funktion, der er meget nyttig â er pg_blocking_pidsDu har nok aldrig hĂžrt om det. Hvad gĂžr det? Det tillader os at sige, at for denne session 11740, hvilke specifikke proces-ID'er den forventer. Og du kan se, at 11740 forventer 724. Og 724 er Ăžverst. Mens 11306 er dit proces-ID. I bund og grund gĂ„r denne funktion igennem din lĂ„ntabel. Jeg ved, det er lidt svĂŠrt, men du fĂ„r det til at forstĂ„. I bund og grund gĂ„r denne funktion gennem denne lĂ„ntabel og forsĂžger at finde, hvor dette proces-ID er, baseret pĂ„ de lĂ„sninger, den venter pĂ„. Og det forsĂžger ogsĂ„ at beregne, hvilket specifikt proces-ID der tilhĂžrer den proces, der venter pĂ„ lĂ„sninger. Derfor kan du kĂžre denne funktion. pg_blocking_pids.
Og det kan vÊre meget nyttigt. Vi tilfÞjede det fÞrst med version 9.6, sÄ denne funktion er kun fem Är gammel, men den er meget, meget nyttig. Det samme gÊlder for den anden forespÞrgsel. Den viser prÊcist det, vi har brug for at se.
Det er, hvad jeg ville tale med dig om. Og som jeg forventede, brugte vi al vores tid, fordi der var sÄ mange dias. Diasene kan downloades. Jeg vil gerne takke dig for at du var her. Jeg er sikker pÄ, at du vil nyde resten af konferencen, tusind tak!
SpÞrgsmÄl:
For eksempel, hvis jeg prÞver at opdatere rÊkkerne, mens den anden session prÞver at slette hele tabellen. SÄ vidt jeg forstÄr, burde der vÊre noget som en intent lock. Findes der noget sÄdan i Postgres?
Lad os gÄ tilbage til begyndelsen. MÄske husker du, at nÄr du laver hvad som helst, for eksempel nÄr du laver en SELECT, sÄ giver vi en AccessShareLock. Og det forhindrer sletning af tabellen. Derfor, hvis du for eksempel vil opdatere en rÊkke i tabellen eller slette en rÊkke, sÄ kan nogen ikke slette hele tabellen samtidig, fordi du holder denne AccessShareLock over hele tabellen og over rÊkken. Og sÄ snart du er fÊrdig, kan de slette det. Men mens du direkte Êndrer noget der, kan de ikke gÞre det.
Lad os gÞre det igen. Lad os gÄ til eksemplet med sletning. Og du ser, hvordan der er en eksklusiv lock over hele tabellen pÄ rÊkken.
Det vil se ud som en eksklusiv lÄs, ikke?
Ja, det lyder som det. Jeg forstÄr, hvad du siger. Du siger, at hvis jeg udfÞrer SELECT, sÄ fÄr jeg ShareExclusive, og hvis jeg derefter Êndrer det til Row Exclusive, bliver det et problem? Men overraskende nok skaber det ikke et problem. Det ligner en stigende lÄsningsgrad, men i bund og grund har jeg en lÄs, der forhindrer sletning. Og nu, nÄr jeg gÞr denne lÄs stÊrkere, forhindrer den stadig sletning. SÄ det er ikke sÄdan, at jeg hÊver det. Det vil sige, den forhindrede det, selv da den var pÄ et lavere niveau, sÄ nÄr jeg hÊver den, forhindrer den stadig sletning af tabellen.
Jeg forstÄr, hvad du siger. Der er ikke et tilfÊlde af stigende lÄsningsgrad, hvor du prÞver at afgive én lÄs for at indfÞre en mere kraftfuld. Her Þger det bare generelt forhindringen, sÄ det forÄrsager ingen konflikt. Men det er et godt spÞrgsmÄl. Tak fordi du stillede det!
Hvad skal vi gÞre for at undgÄ deadlock-situationer, nÄr vi har mange sessioner og et stort antal brugere?
Postgres registrerer automatisk deadlock-situationer. Og vil automatisk fjerne en af sessionerne. Den eneste mĂ„de at undgĂ„ deadlock-situationen pĂ„ er at lĂ„se folk i den samme rĂŠkkefĂžlge. SĂ„ nĂ„r du ser pĂ„ din applikation, er Ă„rsagen til deadlocks ofte... Lad os forestille os, at jeg vil lĂ„se to forskellige ting. Ăn applikation lĂ„ser tabel 1, mens en anden applikation lĂ„ser tabel 2 og derefter tabel 1. Den nemmeste mĂ„de at undgĂ„ deadlocks pĂ„ er at se pĂ„ din applikation og sĂžrge for, at lĂ„sningen sker i den samme rĂŠkkefĂžlge i alle applikationer. Og det fjerner som regel 80 % af problemerne, fordi meget forskellige mennesker skriver disse applikationer. Og hvis du lĂ„ser dem i den samme rĂŠkkefĂžlge, sĂ„ stĂ„r du ikke over for en deadlock-situation.
Mange tak for dit indlÊg! Du talte om vacuum full, og hvis jeg forstÄr det korrekt, omformer vacuum full rÊkkefÞlgen af poster i det enkelte opbevaringsomrÄde, sÄ de nuvÊrende poster forbliver uÊndrede. Men hvorfor tager vacuum full en eksklusiv lÄs, og hvorfor kommer det i konflikt med skriveoperationer?
Det er et godt spĂžrgsmĂ„l. Ă
rsagen er, at vacuum full tager tabellen. Og vi skaber i princippet en ny version af tabellen. Tabellen vil vÊre ny. Det resulterer i, at det bliver en helt ny version af tabellen. Og problemet er, at nÄr vi gÞr det, vil vi ikke have, at folk lÊser det, fordi vi har brug for, at de ser den nye tabel. Og derfor hÊnger det sammen med det tidligere spÞrgsmÄl. Hvis vi kunne lÊse samtidig, ville vi ikke kunne flytte det og dirigere folk til den nye tabel. Vi ville vÊre nÞdt til at vente, indtil alle fÊrdiggjorde med at lÊse denne tabel, og derfor, i princippet, er det en eksklusiv lÄsesituation.
Vi siger bare, at vi lÄser fra starten, fordi vi ved, at vi i slutningen har brug for en eksklusiv lÄs for at flytte alle til den nye kopi. Derfor kan vi potentielt lÞse det. Og vi gÞr det med samtidig indeksering. Men det er meget mere kompleks at gÞre. Og det relaterer meget til dit tidligere spÞrgsmÄl om eksklusiv lÄs.
Er det muligt at tilfĂžje locking timeout i Postgres? I Oracle kan jeg for eksempel skrive 'vĂŠlg til opdatering' og vente 50 sekunder fĂžr opdateringen. Det var godt for applikationen. Men i Postgres skal jeg enten gĂžre det med det samme og slet ikke vente, eller vente i en vis tid.
Ja, du kan vÊlge timeout for dine lÄs. Du kan ogsÄ give kommandoen no way, som vil vÊre ..., hvis du ikke kan fÄ lÄsen med det samme. SÄ enten lock timeout eller noget andet, der giver dig mulighed for at gÞre det. Det gÞres ikke pÄ syntaksniveau. Det gÞres som en variabel pÄ serveren. Nogle gange kan det ikke bruges.
Kan du Ă„bne 75. slide?
Ja.
Og mit spÞrgsmÄl er fÞlgende. Hvorfor venter begge opdateringsprocesser pÄ 703?
Og det er et fantastisk spÞrgsmÄl. Jeg forstÄr ikke, hvorfor Postgres gÞr det. Men da 703 blev oprettet, forventede den 702. Og nÄr 704 og 705 dukker op, ser det ud til, at de ikke ved, hvad de venter pÄ, fordi der ikke er noget der endnu. Og Postgres gÞr det sÄdan: nÄr du ikke kan fÄ en lÄs, sÄ siger den "Hvad er meningen med at behandle dig?", fordi du allerede venter pÄ nogen. SÄ lad os bare lade det hÊnge i luften, det opdaterer slet ikke. Men hvad skete der her? SÄ snart 702 afsluttede processen, og 703 fik sin lÄs, gik systemet tilbage. Og sagde, at nu har vi to personer, der venter. SÄ lad os opdatere dem sammen. Og indikere, at begge venter.
Jeg ved ikke, hvorfor Postgres gĂžr det. Men der er et problem, der kaldes fâŠ. Jeg tror, det ikke er et term pĂ„ russisk. Det er, nĂ„r alle venter pĂ„ en lĂ„s, selvom der er 20 instanser, der venter pĂ„ lĂ„sen. Og pludselig vĂ„gner de alle op samtidigt. Og alle begynder at forsĂžge at reagere. Men systemet gĂžr det sĂ„dan, at alle venter pĂ„ 703. Fordi de alle venter, sĂ„ stiller vi dem straks i kĂž. Og hvis der dukker en anden ny anmodning op, som blev dannet efter dette, for eksempel 707, sĂ„ vil der igen vĂŠre tomhed.
Og jeg tror, det gÞres, sÄ vi kan sige, at pÄ dette tidspunkt venter 702 pÄ 703, og alle dem, der kommer efter dette, vil ikke have nogen registrering i dette felt. Men sÄ snart den fÞrste ventende forlader, fÄr alle dem, der ventede pÄ det tidspunkt op til opdateringen, den samme markÞr. Og derfor tror jeg, det er gjort, sÄ vi kan behandle i rÊkkefÞlge, sÄ de bliver korrekt ordnet.
Jeg har altid set pÄ dette som et ret mÊrkeligt fÊnomen. Fordi her nÊvner vi for eksempel slet ikke dem. Men jeg fÞler, hver gang vi giver en ny lock, ser vi pÄ alle dem, der er i ventemodus. SÄ stiller vi dem alle i kÞ. Og derefter kommer enhver ny, som ankommer, kun i kÞ, nÄr den nÊste person er fÊrdig med at blive behandlet. Meget godt spÞrgsmÄl. Tak fordi du stillede spÞrgsmÄlet!
Jeg synes, det er meget mere logisk, nÄr 705 venter pÄ 704.
Men problemet er fÞlgende. Teknisk set kan du vÊkke enten den ene eller den anden. Og derfor vÊkker vi den ene eller den anden. Men hvad sker der i systemets arbejde? Du kan se, at 703 Þverst har lÄst sin egen transaktions-ID. Det er, hvordan Postgres fungerer. Og 703 lÄses af sin egen transaktions-ID, sÄ hvis nogen vil vente, sÄ venter de pÄ 703. Og i det vÊsentlige afslutter 703. Og fÞrst efter at den er afsluttet, bliver en af processerne vÊkket. Og vi ved ikke, hvilken proces det bliver. Derefter behandler vi langsomt alle. Men det er uklart, hvilken proces der vÊkkes fÞrst, fordi det kan vÊre en hvilken som helst af disse processer. I bund og grund havde vi en scheduler, der sagde, at vi nu kan vÊkke en hvilken som helst af disse processer. Vi vÊlger bare en tilfÊldigt. Derfor skal begge markeres, fordi vi kan vÊkke en hvilken som helst af dem.
Og problemet er, at vi har CP-uendelighed. Og derfor kan vi meget vel vÊkke den senere. Og hvis vi for eksempel vÊkker den senere, sÄ vil vi vente pÄ den, der netop har fÄet lÄsen, sÄ vi kan ikke bestemme, hvem der prÊcist bliver vÊkket fÞrst. Vi skaber simpelthen en sÄdan situation, og systemet vil vÊkke dem i vilkÄrlig rÊkkefÞlge.
Der er . Se, de er ogsÄ interessante og nyttige. Emnet er selvfÞlgelig skrÊmmende komplekst. Mange tak, Bruce!
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish