Transkriptio Bruce Momjianin vuoden 2020 puheesta "Unlocking the Postgres Lock Manager".
(Huomaa: Kaikki diojen SQL-kyselyt saa tästä linkistä: )
Hei! On hienoa olla taas täällä Venäjällä. Olen pahoillani, etten päässyt tulemaan viime vuonna, mutta tänä vuonna Ivanilla ja minulla on suuria suunnitelmia. Toivon olevani täällä paljon useammin. Rakastan tulla Venäjälle. Vierailen Tjumenissa, Tverissä. Olen erittäin iloinen, että saan vierailla näissä kaupungeissa.
Nimeni on Bruce Momjian. Työskentelen EnterpriseDB:ssä ja olen työskennellyt Postgresin kanssa yli 23 vuotta. Asun paikassa Philadelphia, USA. Matkustan noin 90 päivää vuodessa. Ja osallistun noin 40 konferenssiin. Minun , joka sisältää diat, jotka nyt näytän sinulle. Siksi voit ladata ne konferenssin jälkeen henkilökohtaiselta verkkosivustoltani. Se sisältää myös noin 30 esitystä. Siellä on myös videoita ja suuri määrä blogimerkintöjä, yli 500. Tämä on melko informatiivinen lähde. Ja jos olet kiinnostunut tästä materiaalista, pyydän sinua käyttämään sitä.
Olin opettaja, professori ennen kuin aloin työskennellä Postgresin kanssa. Ja olen erittäin iloinen, että voin nyt kertoa teille, mitä aion kertoa teille. Tämä on yksi mielenkiintoisimmista esityksistäni. Ja tämä esitys sisältää 110 diaa. Aloitamme puhumisen yksinkertaisista asioista, ja loppua kohden mietinnöstä tulee yhä monimutkaisempi ja melko monimutkaisempi.
Tämä on melko epämiellyttävä keskustelu. Estäminen ei ole suosituin aihe. Haluamme tämän katoavan jonnekin. Se on kuin hammaslääkärissä käynti.
- Lukitus on ongelma monille ihmisille, jotka työskentelevät tietokannoissa ja joilla on useita prosesseja käynnissä samanaikaisesti. Ne tarvitsevat eston. Eli tänään annan sinulle perustiedot estämisestä.
- Tapahtumatunnukset. Tämä on melko tylsä osa esitystä, mutta ne on ymmärrettävä.
- Seuraavaksi puhumme estotyypeistä. Tämä on melko mekaaninen osa.
- Ja alla annamme joitain esimerkkejä estämisestä. Ja se tulee olemaan melko vaikea ymmärtää.
Puhutaanpa estämisestä.
Terminologiamme on melko monimutkainen. Kuinka moni teistä tietää, mistä tämä kohta tulee? Kaksi henkilöä. Tämä on pelistä nimeltä Colossal Cave Adventure. Se oli mielestäni tekstipohjainen tietokonepeli 80-luvulla. Siellä piti mennä luolaan, labyrinttiin, ja teksti vaihtui, mutta sisältö oli joka kerta suunnilleen sama. Näin minä tämän pelin muistan.
Ja tässä näemme Oraclesta meille tulleiden lukkojen nimet. Käytämme niitä.
Tässä näemme termejä, jotka hämmentävät minua. Esimerkiksi SHARE UPDATE ECXLUSIVE. Seuraava JAA RAW ECXLUSIVE. Rehellisesti sanottuna nämä nimet eivät ole kovin selkeitä. Yritämme tarkastella niitä yksityiskohtaisemmin. Jotkut sisältävät sanan "share", joka tarkoittaa erottamista. Jotkut sisältävät sanan "yksinomainen". Jotkut sisältävät molemmat sanat. Haluaisin aloittaa siitä, kuinka nämä lukot toimivat.
Ja sana "pääsy" on myös erittäin tärkeä. Ja sanat "rivi" ovat merkkijono. Eli pääsyn jakelu, rivijako.
Toinen asia, joka on ymmärrettävä Postgresissa, jota en valitettavasti voi käsitellä puheessani, on MVCC. Minulla on tästä aiheesta erillinen esitys verkkosivullani. Ja jos tämä esitys on mielestäsi vaikea, MVCC on luultavasti vaikein. Ja jos kiinnostaa, voit katsoa sen nettisivuilta. Voit katsoa videon.
Toinen asia, joka meidän on ymmärrettävä, ovat tapahtumatunnukset. Monet tapahtumat eivät voi toimia ilman yksilöllisiä tunnisteita. Ja tässä meillä on selitys siitä, mitä liiketoimi on. Postgresilla on kaksi tapahtumanumerointijärjestelmää. Tiedän, että tämä ei ole kovin kaunis ratkaisu.
Muista myös, että dioja on melko vaikea ymmärtää, joten sinun on kiinnitettävä huomiota siihen, mikä on korostettu punaisella.
Katsotaan. Tapahtuman numero on korostettu punaisella. SELECT pg_back -toiminto näkyy tässä. Se palauttaa tapahtumani ja tapahtumatunnuksen.
Vielä yksi asia, jos pidät tästä esityksestä ja haluat käyttää sitä tietokannassasi, voit siirtyä tähän pinkkiin linkkiin ja ladata esityksen SQL:n. Ja voit yksinkertaisesti suorittaa sen PSQL:ssäsi ja koko esitys näkyy näytölläsi välittömästi. Se ei sisällä kukkia, mutta ainakin voimme nähdä sen.
Tässä tapauksessa näemme tapahtumatunnuksen. Tämä on numero, jonka annoimme hänelle. Ja Postgresissa on toisenlainen tapahtumatunnus, jota kutsutaan virtuaaliseksi tapahtumatunnukseksi
Ja tämä meidän on ymmärrettävä. Tämä on erittäin tärkeää, muuten emme voi ymmärtää lukitsemista Postgresissa.
Virtuaalinen tapahtumatunnus on tapahtumatunnus, joka ei sisällä pysyviä arvoja. Jos esimerkiksi suoritan SELECT-komennon, en todennäköisesti muuta tietokantaa, en lukitse mitään. Joten kun suoritamme yksinkertaisen SELECT-toiminnon, emme anna tälle tapahtumalle pysyvää tunnusta. Annamme hänelle vain virtuaalisen tunnuksen.
Ja tämä parantaa Postgresin suorituskykyä, parantaa puhdistusominaisuuksia, joten virtuaalinen tapahtumatunnus koostuu kahdesta numerosta. Ensimmäinen numero ennen kauttaviivaa on taustajärjestelmän tunnus. Ja oikealla näemme vain laskurin.
Siksi, jos suoritan pyynnön, se sanoo, että taustajärjestelmän tunnus on 2.
Ja jos suoritan sarjan tällaisia tapahtumia, huomaamme, että laskuri kasvaa joka kerta, kun suoritan kyselyn. Esimerkiksi kun suoritan kyselyn 2/10, 2/11, 2/12 jne.
Muista, että tässä on kaksi saraketta. Vasemmalla näemme virtuaalisen tapahtumatunnuksen – 2/12. Ja oikealla meillä on pysyvä tapahtumatunnus. Ja tämä kenttä on tyhjä. Tämä tapahtuma ei muuta tietokantaa. Joten en anna sille pysyvää tapahtumatunnusta.
Heti kun suoritan analyysikomennon ((ANALYSOI)), sama kysely antaa minulle pysyvän tapahtumatunnuksen. Katso, kuinka tämä on muuttunut meille. Minulla ei ollut tätä tunnusta ennen, mutta nyt minulla on se.
Joten tässä on toinen pyyntö, toinen kauppa. Virtuaalinen tapahtumanumero on 2/13. Ja jos pyydän pysyvää tapahtumatunnusta, saan sen, kun suoritan kyselyn.
Eli vielä kerran. Meillä on virtuaalinen tapahtumatunnus ja pysyvä tapahtumatunnus. Ymmärrä tämä kohta ymmärtääksesi Postgresin käyttäytymisen.
Siirrymme kolmanteen osaan. Täällä käymme läpi Postgresin erityyppiset lukot. Se ei ole kovin mielenkiintoista. Viimeinen osa on paljon mielenkiintoisempi. Mutta meidän on otettava huomioon perusasiat, koska muuten emme ymmärrä mitä tapahtuu seuraavaksi.
Käymme läpi tämän osion ja tarkastelemme jokaista lukkotyyppiä. Ja näytän sinulle esimerkkejä siitä, kuinka ne asennetaan, miten ne toimivat, näytän sinulle joitain kyselyitä, joiden avulla voit nähdä kuinka lukitus toimii Postgresissa.
Jotta voimme luoda kyselyn ja nähdä, mitä Postgresissa tapahtuu, meidän on suoritettava kysely järjestelmänäkymässä. Tässä tapauksessa pg_lock on korostettu punaisella. Pg_lock on järjestelmätaulukko, joka kertoo, mitkä lukot ovat tällä hetkellä käytössä Postgresissa.
Minun on kuitenkin hyvin vaikeaa näyttää sinulle pg_lockia sellaisenaan, koska se on melko monimutkainen. Joten loin näkymän, joka näyttää pg_locks. Ja se myös tekee minulle työtä, jonka avulla voin ymmärtää paremmin. Toisin sanoen se ei sisällä lukot, oma istuntoni jne. Se on vain tavallinen SQL ja sen avulla voit näyttää sinulle paremmin, mitä tapahtuu.
Toinen ongelma on, että tämä näkymä on hyvin laaja, joten minun on luotava toinen - lockview2.
Ja se näyttää minulle lisää sarakkeita taulukosta. Ja toinen, joka näyttää minulle loput sarakkeet. Tämä on melko monimutkaista, joten yritin esittää sen mahdollisimman yksinkertaisesti.
Joten loimme taulukon nimeltä Lockdemo. Ja loimme yhden rivin sinne. Tämä on esimerkkitaulukkomme. Ja luomme osioita vain näyttääksemme esimerkkejä lukoista.
Eli yksi rivi, yksi sarake. Ensimmäisen tyyppinen lukko on nimeltään ACCESS SHARE. Tämä on vähiten rajoittava esto. Tämä tarkoittaa, että se ei käytännössä ole ristiriidassa muiden lukkojen kanssa.
Ja jos haluamme nimenomaisesti määritellä lukon, suoritamme "lock table" -komennon. Ja se ilmeisesti estää, eli ACCESS SHARE -tilassa käynnistämme lukituspöydän. Ja jos käytän PSQL:ää taustalla, aloitan toisen istunnon ensimmäisestä istunnosta tällä tavalla. Eli mitä minä teen täällä? Siirryn toiseen istuntoon ja sanon sille "näytä tämän pyynnön lukitusnäkymä". Ja tässä minulla on AccessShareLock tässä taulukossa. Juuri tätä pyysin. Ja hän sanoo, että lohko on määritetty. Erittäin yksinkertainen.
Lisäksi, jos katsomme toista saraketta, siellä ei ole mitään. Ne ovat tyhjiä.
Ja jos suoritan "SELECT"-komennon, tämä on implisiittinen (eksplisiittinen) tapa pyytää AccessShareLockia. Joten vapautan taulukkoni ja suoritan kyselyn ja kysely palauttaa useita rivejä. Ja yhdessä riveistä näemme AccessShareLockin. Siten SELECT kutsuu AccessShareLockin pöydälle. Ja se ei ole ristiriidassa käytännössä minkään kanssa, koska se on matalan tason lukko.
Entä jos käytän SELECT:tä ja minulla on kolme erilaista pöytää? Aiemmin pyöritin vain yhtä taulukkoa, nyt käytän kolmea: pg_class, pg_namespace ja pg_attribute.
Ja nyt kun katson kyselyä, näen 9 AccessShareLockia kolmessa taulukossa. Miksi? Kolme taulukkoa on korostettu sinisellä: pg_attribute, pg_class, pg_namespace. Mutta voit myös nähdä, että kaikissa näissä taulukoissa määritellyissä indekseissä on myös AccessShareLock.
Ja tämä on lukko, joka ei käytännössä ole ristiriidassa muiden kanssa. Ja se vain estää meitä nollaamasta taulukkoa, kun valitsemme sen. Se on järkevää. Eli jos valitsemme taulukon, se katoaa sillä hetkellä, niin tämä on väärin AccessShare on matalan tason lukko, joka kertoo meille "älä pudota tätä pöytää, kun olen töissä". Pohjimmiltaan se on kaikki mitä hän tekee.
ROW SHARE - Tämä lukko on hieman erilainen.
Otetaan esimerkki. SELECT ROW SHARE -menetelmä jokaisen rivin lukitsemiseksi erikseen. Tällä tavalla kukaan ei voi poistaa tai muuttaa niitä katsellessasi niitä.
Joten mitä SHARE LOCK tekee? Näemme, että SELECT tapahtumatunnus on 681. Ja tämä on mielenkiintoista. Mitä täällä tapahtui? Ensimmäistä kertaa näemme numeron "Lukitse" -kentässä. Otamme tapahtumatunnuksen ja se sanoo, että se estää sen eksklusiivisessa tilassa. Se vain sanoo, että minulla on rivi, joka on teknisesti lukittu jonnekin taulukosta. Mutta hän ei kerro tarkalleen missä. Tarkastellaan tätä tarkemmin hieman myöhemmin.
Tässä sanomme, että lukko on meidän käytössämme.
Joten eksklusiivinen lukko sanoo nimenomaisesti, että se on eksklusiivinen. Ja myös jos poistat rivin tästä taulukosta, niin tapahtuu, kuten näet.
SHARE EXCLUSIVE on pidempi lukko.
Tämä on (ANALYSOI) analysaattorikomento, jota käytetään.
SHARE LOCK – voit lukita jakamistilassa.
Voit myös luoda yksilöllisen indeksin. Ja siellä voit nähdä SHARE LOCK, joka on osa niitä. Ja se lukitsee pöydän ja asettaa siihen SHARE LOCKin.
Oletuksena taulukon JAALUKO tarkoittaa, että muut ihmiset voivat lukea taulukkoa, mutta kukaan ei voi muokata sitä. Ja juuri näin tapahtuu, kun luot ainutlaatuisen indeksin.
Jos luon yksilöllisen samanaikaisen indeksin, minulla on erilainen lukitus, koska kuten muistat, samanaikaisten indeksien käyttö vähentää lukitusvaatimusta. Ja jos käytän normaalia lukkoa, normaalia indeksiä, estän siten kirjoittamisen taulukkoindeksiin sen luomisen aikana. Jos käytän samanaikaisesti indeksiä, minun on käytettävä erilaista lukitusta.
SHARE ROW EXCLUSIVE – se voidaan jälleen asettaa eksplisiittisesti (eksplisiittisesti).
Tai voimme luoda säännön, eli ottaa tietyn tapauksen, jossa sitä käytetään.
EXCLUSIIVINEN lukitus tarkoittaa, että kukaan muu ei voi vaihtaa pöytää.
Täällä näemme erilaisia lukkoja.
ACCESS EXCLUSIVE on esimerkiksi estokomento. Esimerkiksi jos teet CLUSTER table, tämä tarkoittaa, että kukaan ei voi kirjoittaa sinne. Ja se ei vain lukitse itse taulukkoa, vaan myös indeksit.
Tämä on ACCESS EXCLUSIVE -eston toinen sivu, jossa näemme tarkalleen mitä se estää taulukosta. Se lukitsee yksittäiset taulukon rivit, mikä on varsin mielenkiintoista.
Siinä kaikki perustiedot, jotka halusin antaa. Puhuimme lukoista, tapahtumatunnuksista, puhuimme virtuaalisista tapahtumatunnuksista, pysyvistä tapahtumatunnuksista.
Ja nyt käymme läpi joitakin estäviä esimerkkejä. Tämä on mielenkiintoisin osa. Tarkastellaan erittäin mielenkiintoisia tapauksia. Tavoitteeni tässä esityksessä on antaa sinulle parempi käsitys siitä, mitä Postgres todella tekee, kun se yrittää estää tiettyjä asioita. Mielestäni hän on erittäin hyvä estämään osia.
Katsotaanpa joitain konkreettisia esimerkkejä.
Aloitamme taulukoista ja yhdestä taulukon rivistä. Kun lisään jotain, taulukossa näkyy ExclusiveLock, Transaction ID ja ExclusiveLock.
Mitä tapahtuu, jos lisään kaksi riviä lisää? Ja nyt taulukossamme on kolme riviä. Ja lisäsin yhden rivin ja sain tämän tulosteena. Ja jos lisään kaksi riviä lisää, mitä outoa siinä on? Tässä on outo asia, koska olen lisännyt kolme riviä tähän taulukkoon, mutta minulla on edelleen kaksi riviä lukitustaulukossa. Ja tämä on pohjimmiltaan Postgresin peruskäyttäytyminen.
Monet ihmiset ajattelevat, että jos lukitset tietokannassa 100 riviä, sinun on luotava 100 lukitusmerkintää. Jos estän 1 000 riviä kerralla, tarvitsen 1 000 tällaista kyselyä. Ja jos tarvitsen miljoonan tai miljardin estettäväksi. Mutta jos teemme tämän, se ei toimi kovin hyvin. Jos olet käyttänyt järjestelmää, joka luo estomerkinnät jokaiselle yksittäiselle riville, voit nähdä, että tämä on monimutkaista. Koska sinun on heti määritettävä lukitustaulukko, joka voi vuotaa yli, mutta Postgres ei tee sitä.
Ja mikä tässä diassa on todella tärkeää, on se, että se osoittaa selvästi, että MVCC:n sisällä toimii toinen järjestelmä, joka lukitsee yksittäiset rivit. Joten kun lukitset miljardeja rivejä, Postgres ei luo miljardia erillistä lukituskomentoa. Ja tällä on erittäin hyvä vaikutus tuottavuuteen.
Entä päivitys? Päivitän riviä nyt, ja näet, että se on suorittanut kaksi eri toimintoa kerralla. Se lukitsi samalla pöydän, mutta myös indeksin. Ja hänen täytyi lukita indeksi, koska tässä taulukossa on ainutlaatuisia rajoituksia. Ja haluamme varmistaa, että kukaan ei muuta sitä, joten estämme sen.
Mitä tapahtuu, jos haluan päivittää kaksi riviä? Ja näemme, että hän käyttäytyy samalla tavalla. Teemme kaksi kertaa enemmän päivityksiä, mutta täsmälleen saman määrän lukitusrivejä.
Jos mietit, miten Postgres tekee tämän, sinun on kuunneltava puheeni MVCC:stä oppiaksesi, kuinka Postgres merkitsee sisäisesti nämä rivit, joita se muuttaa. Ja Postgresilla on tapa, jolla se tekee tämän, mutta se ei tee sitä pöydän lukitustasolla, se tekee sen alemmalla ja tehokkaammalla tasolla.
Entä jos haluan poistaa jotain? Jos poistan esimerkiksi yhden rivin ja minulla on edelleen kaksi estotuloani, ja vaikka haluaisin poistaa ne kaikki, ne ovat edelleen olemassa.
Ja esimerkiksi haluan lisätä 1 000 riviä ja sitten joko poistaa tai lisätä 1 000 riviä, sitten niitä yksittäisiä rivejä, jotka lisään tai muutan, niitä ei tallenneta tähän. Ne on kirjoitettu alemmalla tasolla itse sarjassa. Ja MVCC-puheen aikana puhuin tästä yksityiskohtaisesti. Mutta kun analysoit lukkoja, on erittäin tärkeää varmistaa, että lukittuminen tapahtuu taulukkotasolla ja että et näe, kuinka yksittäisiä rivejä tallennetaan tähän.
Entä selkeä esto?
Jos napsautan Päivitä, minulla on kaksi riviä lukittuina. Ja jos valitsen ne kaikki ja napsautan "päivitä kaikkialla", minulla on edelleen kaksi estotietuetta.
Emme luo erillisiä tietueita jokaiselle yksittäiselle riville. Koska silloin tuottavuus laskee, sitä voi olla liikaa. Ja saatamme joutua epämiellyttävään tilanteeseen.
Ja sama asia, jos jaamme, voimme tehdä sen kaikki 30 kertaa.
Palautamme taulukkomme, poistamme kaiken ja lisäämme sitten yhden rivin uudelleen.
Toinen Postgresissa näkemäsi käyttäytyminen, joka on hyvin tunnettu ja toivottu, on se, että voit tehdä päivityksen tai valita. Ja voit tehdä tämän samanaikaisesti. Ja valitse ei estä päivitystä ja sama asia päinvastaiseen suuntaan. Pyydämme lukijaa olemaan estämättä kirjoittajaa, ja kirjoittaja ei estänyt lukijaa.
Näytän sinulle esimerkin tästä. Teen valinnan nyt. Teemme sitten INSERT:n. Ja sitten näet - 694. Näet tämän lisäyksen suorittaneen tapahtuman tunnuksen. Ja niin se toimii.
Ja jos katson taustatunnustani nyt, se on nyt 695.
Ja näen 695 näkyvän taulukossani.
Ja jos päivitän tänne näin, saan toisenlaisen tapauksen. Tässä tapauksessa 695 on eksklusiivinen lukko, ja päivitykset käyttäytyvät samalla tavalla, mutta niiden välillä ei ole ristiriitaa, mikä on melko epätavallista.
Ja näet, että yläosassa on ShareLock ja alareunassa ExclusiveLock. Ja molemmat kaupat onnistuivat.
Ja sinun täytyy kuunnella puheeni MVCC:ssä ymmärtääksesi, kuinka tämä tapahtuu. Mutta tämä on esimerkki siitä, että voit tehdä sen samanaikaisesti, eli tehdä SELECT ja UPDATE samanaikaisesti.
Nollataan ja tehdään vielä yksi toimenpide.
Jos yrität suorittaa kaksi päivitystä samanaikaisesti samalla rivillä, se estetään. Ja muistakaa, sanoin, että lukija ei estä kirjoittajaa, eikä kirjoittaja estä lukijaa, mutta yksi kirjoittaja estää toisen kirjoittajan. Eli emme voi saada kahta henkilöä päivittämään samaa riviä samaan aikaan. Sinun on odotettava, kunnes yksi niistä on valmis.
Ja tämän havainnollistamiseksi katson Lockdemo-taulukkoa. Ja katsotaan yhtä riviä. Kauppaa kohden 698.
Olemme päivittäneet tämän numeroon 2. 699 on ensimmäinen päivitys. Ja se onnistui tai se on vireillä ja odottaa meidän vahvistavan tai peruuttavan.
Mutta katsokaa jotain muuta - 2/51 on ensimmäinen tapahtumamme, ensimmäinen istuntomme. 3/112 on toinen ylhäältä tullut pyyntö, joka muutti arvon 3:ksi. Ja jos huomaat, ylin lukittui itsensä, mikä on 699. Mutta 3/112 ei myöntänyt lukitusta. Lock_mode-sarake kertoo, mitä se odottaa. Se odottaa 699:ää. Ja jos katsot missä 699 on, se on korkeampi. Ja mitä ensimmäinen istunto teki? Hän loi eksklusiivisen lukon omalle tapahtumatunnukselleen. Näin Postgres tekee sen. Se estää oman tapahtumatunnuksensa. Ja jos haluat odottaa, että joku vahvistaa tai peruuttaa, sinun on odotettava odottavaa tapahtumaa. Ja siksi voimme nähdä oudon linjan.
Katsotaanpa uudestaan. Vasemmalla näemme käsittelytunnuksemme. Toisessa sarakkeessa näemme virtuaalisen tapahtumatunnuksemme ja kolmannessa lock_type. Mitä tämä tarkoittaa? Pohjimmiltaan se sanoo, että se estää tapahtumatunnuksen. Mutta huomaa, että kaikki alaosan rivit sanovat suhteen. Pöydälläsi on siis kahdenlaisia lukkoja. Siellä on suhdelukko. Ja sitten on transaktioiden esto, jossa estät itse, mikä on täsmälleen mitä tapahtuu ensimmäisellä rivillä tai aivan alareunassa, missä transaktiotunnus on, missä odotamme 699:n lopettamista.
Katson mitä täällä tapahtuu. Ja tässä tapahtuu kaksi asiaa samanaikaisesti. Katsot tapahtumatunnuksen lukitusta ensimmäisellä rivillä, joka lukitsee itsensä. Ja hän estää itsensä saadakseen ihmiset odottamaan.
Jos katsot kuudetta riviä, se on sama merkintä kuin ensimmäinen. Ja siksi tapahtuma 6 on estetty. 699 on myös itselukittuva. Ja sitten alarivillä näet, että odotamme 700:n lopettavan toimintansa.
Ja lock_type, tuple näet numerot.
Näet, että se on 0/10. Ja tämä on sivunumero ja myös tämän rivin offset.
Ja näet, että siitä tulee 0/11, kun päivitämme.
Mutta todellisuudessa se on 0/10, koska tätä operaatiota odotetaan. Meillä on mahdollisuus nähdä, että tämä on sarja, jonka vahvistusta odotan.
Kun olemme vahvistaneet sen ja painaneet commit-painiketta, ja kun päivitys on valmis, saamme jälleen tämän. Transaction 700 on ainoa lukko, se ei odota ketään muuta, koska se tehtiin. Se vain odottaa kaupan valmistumista. Kun 699 loppuu, emme enää odota mitään. Ja nyt tapahtuma 700 sanoo, että kaikki on hyvin, että siinä on kaikki tarvitsemansa lukot kaikissa sallituissa pöydissä.
Ja tehdäksemme tästä koko asiasta vielä monimutkaisemman, luomme toisen näkymän, joka tällä kertaa antaa meille hierarkian. En odota sinun ymmärtävän tätä pyyntöä. Mutta tämä antaa meille selkeämmän kuvan siitä, mitä tapahtuu.
Tämä on rekursiivinen näkymä, jossa on myös toinen osio. Ja sitten se kokoaa kaiken takaisin yhteen. Käytetään tätä.
Mitä jos teemme kolme samanaikaista päivitystä ja sanomme, että rivi on nyt kolme. Ja vaihdamme 3:sta 4:ään.
Ja tässä näemme 4. Ja tapahtumatunnus 702.
Ja sitten muutan 4:stä 5:een. Ja 5:stä 6:een ja 6:een 7:ään. Ja panen jonoon joukon ihmisiä, jotka odottavat tämän yhden tapahtuman päättymistä.
Ja kaikki tulee selväksi. Mikä on ensimmäinen rivi? Tämä on 702. Tämä on tapahtumatunnus, joka alun perin asetti tämän arvon. Mitä Myönnetty-sarakkeessani on kirjoitettu? Minulla on merkkejä f. Nämä ovat päivitykseni, joita (5, 6, 7) ei voida hyväksyä, koska odotamme tapahtumatunnuksen 702 päättymistä. Siellä meillä on tapahtumatunnuksen esto. Tämä johtaa 5 tapahtumatunnuksen lukitukseen.
Ja jos katsot numeroa 704, numeroa 705, siellä ei ole vielä kirjoitettu mitään, koska he eivät vielä tiedä mitä tapahtuu. He vain kirjoittavat, etteivät he tiedä, mitä tapahtuu. Ja he vain menevät nukkumaan, koska he odottavat jonkun lopettavan ja herättävän, kun on mahdollisuus vaihtaa riviä.
Tältä se näyttää. On selvää, että he kaikki odottavat 12. riviä.
Tämän näimme täällä. Tässä 0/12.
Joten kun ensimmäinen tapahtuma on hyväksytty, voit nähdä täällä, kuinka hierarkia toimii. Ja nyt kaikki tulee selväksi. Ne kaikki tulevat puhtaiksi. Ja itse asiassa he odottavat edelleen.
Tässä on mitä tapahtuu. 702 sitoutumista. Ja nyt 703 saa tämän rivilukon, ja sitten 704 alkaa odottaa 703:n sitoutumista. Ja 705 odottaa myös tätä. Ja kun tämä kaikki on suoritettu, he siivoavat itsensä. Ja haluan huomauttaa, että kaikki ovat jonossa. Ja tämä on hyvin samanlainen kuin tilanne liikenneruuhkassa, kun kaikki odottavat ensimmäistä autoa. Ensimmäinen auto pysähtyy ja kaikki asettuvat pitkään jonoon. Sitten se liikkuu, sitten seuraava auto voi ajaa eteenpäin ja saada lohkonsa jne.
Ja jos tämä ei tuntunut sinusta tarpeeksi monimutkaiselta, puhumme nyt kanssasi umpikujasta. En tiedä kumpi teistä on tavannut heidät. Tämä on melko yleinen ongelma tietokantajärjestelmissä. Mutta umpikuja on, kun yksi istunto odottaa toisen istunnon tekemistä. Ja tällä hetkellä toinen istunto odottaa ensimmäistä istuntoa tehdäkseen jotain.
Ja esimerkiksi, jos Ivan sanoo: "Anna minulle jotain", ja minä sanon: "Ei, annan sen sinulle vain, jos annat minulle jotain muuta." Ja hän sanoo: "Ei, en anna sitä sinulle, jos et anna sitä minulle." Ja päädymme umpikujaan. Olen varma, että Ivan ei tee tätä, mutta ymmärrät sen merkityksen, että meillä on kaksi ihmistä, jotka haluavat saada jotain, eivätkä he ole valmiita luovuttamaan sitä ennen kuin toinen henkilö antaa heille mitä he haluavat. Ja ratkaisua ei ole.
Ja pohjimmiltaan tietokantasi on havaittava tämä. Ja sitten sinun on poistettava tai suljettava yksi istunnoista, koska muuten ne pysyvät siellä ikuisesti. Ja näemme sen tietokannoissa, näemme sen käyttöjärjestelmissä. Ja kaikissa paikoissa, joissa meillä on rinnakkaisia prosesseja, tämä voi tapahtua.
Ja nyt asennamme kaksi umpikujaa. Laitamme 50 ja 80. Ensimmäiselle riville päivitän 50:stä 50:een. Saan tapahtumanumeron 710.
Ja sitten vaihdan 80 81:een ja 50 51:een.
Ja tältä se tulee näyttämään. Ja niin 710:ssä on rivi tukossa ja 711 odottaa vahvistusta. Näimme tämän, kun päivitimme. 710 on sarjamme omistaja. Ja 711 odottaa, että 710 suorittaa tapahtuman.
Ja se jopa kertoo, millä rivillä umpikuja tapahtuu. Ja tässä se alkaa mennä oudoksi.
Nyt päivitämme 80:stä 80:een.
Ja tästä umpikuja alkaa. 710 odottaa vastausta numerolta 711 ja 711 odottaa numeroa 710. Eikä tämä lopu hyvin. Eikä tästä ole ulospääsyä. Ja he odottavat vastausta toisiltaan.
Ja se vain alkaa viivyttää kaikkea. Ja me emme halua sitä.
Ja Postgresilla on tapoja huomata, kun tämä tapahtuu. Ja kun näin tapahtuu, saat tämän virheen. Ja tästä on selvää, että tällainen ja sellainen prosessi odottaa SHARE LOCKia toiselta prosessilta, eli jonka 711-prosessi estää. Ja se prosessi odotti SHARE LOCK:n antamista sellaiselle ja sellaiselle tapahtumatunnukselle ja esti sellainen ja sellainen prosessi. Siksi tässä on umpikuja.
Onko olemassa kolmisuuntaisia lukkiutumia? Onko se mahdollista? Joo.
Kirjoitamme nämä luvut taulukkoon. Vaihdamme 40:stä 40:een, teemme eston.
Muutamme 60:sta 61:een, 80:sta 81:een.
Ja sitten vaihdetaan 80 ja sitten buumi!
Ja 714 odottaa nyt 715:tä. 716. odottaa 715:tä. Eikä sille voi mitään.
Täällä ei ole enää kahta ihmistä, täällä on jo kolme ihmistä. Haluan jotain sinulta, tämä haluaa jotain kolmannelta henkilöltä ja kolmas henkilö haluaa jotain minulta. Ja päädymme kolmisuuntaiseen odotukseen, koska odotamme kaikki toisen henkilön suorittavan sen, mitä hänen on tehtävä.
Ja Postgres tietää, millä rivillä tämä tapahtuu. Ja niin se antaa sinulle seuraavan viestin, joka osoittaa, että sinulla on ongelma, jossa kolme tuloa estävät toisensa. Eikä tässä ole rajoituksia. Näin voi käydä, kun 20 merkintää estää toisensa.
Seuraava ongelma on serialoitava.
Jos erityinen sarjoitettava lukko.
Ja palaamme kohtaan 719. Sen tulos on melko normaali.
Ja voit napsauttaa tehdäksesi tapahtumasta sarjoitettavan.
Ja huomaat, että sinulla on nyt toisenlainen SA-lukko - se tarkoittaa sarjoitettavaa.
Ja niin meillä on uudentyyppinen lukko nimeltä SARieadLock, joka on sarjalukko ja jonka avulla voit syöttää sarjanumeroita.
Ja voit myös lisätä ainutlaatuisia indeksejä.
Tässä taulukossa meillä on yksilölliset indeksit.
Joten jos laitan tähän numeron 2, niin minulla on 2. Mutta aivan ylhäällä laitan vielä 2 tuumaa. Ja näet, että 721:ssä on ainutlaatuinen lukko. Mutta nyt 722 odottaa 721:n suorittavan toimintansa loppuun, koska se ei voi lisätä numeroa 2 ennen kuin se tietää mitä 721:lle tapahtuu.
Ja jos teemme alitransaktiota.
Tässä meillä on 723.
Ja jos tallennamme pisteen ja päivitämme sen, saamme uuden tapahtumatunnuksen. Tämä on toinen käyttäytymismalli, joka sinun on oltava tietoinen. Jos palautamme tämän, tapahtumatunnus katoaa. 724 lehteä. Mutta nyt meillä on 725.
Joten mitä yritän tehdä täällä? Yritän näyttää sinulle esimerkkejä epätavallisista lukoista, joita saatat löytää: olivatpa kyseessä sarjoitettavat lukot tai SAVEPOINT, nämä ovat erityyppisiä lukkoja, jotka näkyvät lukkotaulukossa.
Tämä on eksplisiittisten (eksplisiittisten) lukkojen luominen, joissa on pg_advisory_lock.
Ja näet, että estotyyppi on listattu neuvoa-antavana. Ja tässä lukee "neuvoa" punaisella. Ja voit samanaikaisesti estää näin pg_advisory_unlockilla.
Ja lopuksi haluan näyttää sinulle vielä yhden mieltä räjäyttävän asian. Luon toisen näkymän. Mutta liitän pg_locks-taulukon pg_stat_activity-taulukkoon. Ja miksi haluan tehdä tämän? Koska tämän avulla voin katsoa ja nähdä kaikki nykyiset istunnot ja nähdä tarkalleen, millaisia lukkoja he odottavat. Ja tämä on varsin mielenkiintoista, kun kokoamme lukkotaulukon ja kyselytaulukon.
Ja tässä luomme pg_stat_view.
Ja päivitämme rivin yksi kerrallaan. Ja tässä näemme 724. Ja sitten päivitämme rivimme kolmeen. Ja mitä sinä näet tässä nyt? Nämä ovat pyyntöjä, eli näet koko luettelon pyynnöistä, jotka on lueteltu vasemmassa sarakkeessa. Ja sitten oikealla puolella näet tukokset ja mitä ne aiheuttavat. Ja se voi olla sinulle selkeämpää, jotta sinun ei tarvitse palata jokaiseen istuntoon joka kerta ja katsoa, tarvitseeko sinun liittyä siihen vai ei. He tekevät sen puolestamme.
Toinen erittäin hyödyllinen ominaisuus on pg_blocking_pids. Et varmaan ole koskaan kuullut hänestä. Mitä hän tekee? Sen avulla voimme kertoa, että tälle istunnolle 11740, mitä tiettyjä prosessitunnuksia se odottaa. Ja näet, että 11740 odottaa numeroa 724. Ja 724 on aivan huipulla. Ja 11306 on prosessitunnuksesi. Pohjimmiltaan tämä toiminto kulkee lukituspöytäsi läpi. Ja tiedän, että se on hieman monimutkaista, mutta sinä onnistut ymmärtämään sen. Pohjimmiltaan tämä toiminto käy tämän lukitustaulukon läpi ja yrittää selvittää, missä tälle prosessitunnukselle annetaan lukot, joita se odottaa. Se myös yrittää selvittää, mikä prosessitunnus lukkoa odottavalla prosessilla on. Joten voit suorittaa tämän toiminnon pg_blocking_pids.
Ja tämä voi olla erittäin hyödyllistä. Lisäsimme tämän vain versiossa 9.6, joten tämä ominaisuus on vain 5 vuotta vanha, mutta se on erittäin, erittäin hyödyllinen. Ja sama koskee toista pyyntöä. Se näyttää tarkalleen, mitä meidän täytyy nähdä.
Tästä halusin puhua kanssasi. Ja kuten odotin, käytimme kaiken aikamme, koska liukumäkiä oli niin paljon. Ja diat ovat ladattavissa. Haluaisin kiittää sinua siitä, että olet täällä. Olen varma, että nautit konferenssin loppuosasta, kiitos paljon!
Kysymykset:
Esimerkiksi, jos yritän päivittää rivejä ja toinen istunto yrittää poistaa koko taulukon. Ymmärtääkseni siellä pitäisi olla jotain tarkoituslukkoa. Onko Postgresissa sellaista?
Palataanpa aivan alkuun. Saatat muistaa, että kun teet mitä tahansa, esimerkiksi kun teet SELECT, annamme AccessShareLockin. Ja tämä estää pöytää putoamasta. Joten jos esimerkiksi haluat päivittää taulukon rivin tai poistaa rivin, joku ei voi poistaa koko taulukkoa samanaikaisesti, koska pidät tätä AccessShareLockia koko taulukon ja rivin päällä. Ja kun olet valmis, he voivat poistaa sen. Mutta vaikka muutat jotain siellä suoraan, he eivät voi tehdä sitä.
Tehdään se uudestaan. Siirrytään poistoesimerkkiin. Ja näet, kuinka koko pöydän yläpuolella olevalla rivillä on ainutlaatuinen lukko.
Tämä näyttää yksinoikeudelta, eikö?
Kyllä, siltä näyttää. Ymmärrän mistä puhut. Sanot, että jos teen SELECT-toiminnon, minulla on ShareExclusive ja sitten teen siitä Row Exclusiven, tuleeko siitä ongelma? Mutta yllättävää kyllä, tämä ei aiheuta ongelmia. Tämä näyttää lukitusasteen nostamiselta, mutta käytännössä minulla on lukko, joka estää poistamisen. Ja nyt, kun teen tästä lukosta tehokkaamman, se silti estää poistamisen. Joten ei ole kuin nousen ylös. Eli se esti sitä tapahtumasta, kun se oli myös alemmalla tasolla, joten kun nostan sen tasoa, se estää silti taulukon poistamisen.
Ymmärrän mistä puhut. Tässä ei ole lukon eskalointitapausta, jossa yrität luopua yhdestä lukosta ottaaksesi käyttöön vahvemman. Tässä se vain lisää tätä ennaltaehkäisyä kautta linjan, joten se ei aiheuta konflikteja. Mutta se on hyvä kysymys. Kiitos paljon tämän kysymisestä!
Mitä meidän tulee tehdä, jotta vältytään umpikujalta, kun meillä on monta istuntoa ja paljon käyttäjiä?
Postgres huomaa automaattisesti lukkiutumistilanteet. Ja se poistaa automaattisesti yhden istunnoista. Ainoa tapa välttää kuollut esto on estää ihmisiä samassa järjestyksessä. Joten kun katsot hakemustasi, usein syy umpikujaan... Kuvitellaan, että haluan estää kaksi eri asiaa. Yksi sovellus lukitsee taulukon 1, toinen sovellus lukitsee taulukon 2 ja sitten taulukon 1. Ja helpoin tapa välttää umpikuja on katsoa sovellustasi ja yrittää varmistaa, että lukitus tapahtuu samassa järjestyksessä kaikissa sovelluksissa. Ja tämä yleensä poistaa 80% ongelmista, koska kaikenlaiset ihmiset kirjoittavat näitä hakemuksia. Ja jos estät ne samassa järjestyksessä, et kohtaa umpikujatilannetta.
Lämmin kiitos esityksestäsi! Puhuit tyhjiötäydestä ja, jos oikein ymmärrän, tyhjiötäys vääristää erilliseen varastoon tallennettujen tietueiden järjestystä, joten ne pitävät nykyiset tietueet ennallaan. Miksi tyhjiötäysi ottaa yksinomaisen lukon pääsyn ja miksi se on ristiriidassa kirjoitustoimintojen kanssa?
Se on hyvä kysymys. Syynä on se, että tyhjiö täyttää pöydän. Ja olemme pohjimmiltaan luomassa uutta versiota taulukosta. Ja pöytä on uusi. Osoittautuu, että tämä on täysin uusi versio taulukosta. Ja ongelma on, että kun teemme tämän, emme halua ihmisten lukevan sitä, koska tarvitsemme heidän näkevän uuden taulukon. Ja tämä liittyy siis edelliseen kysymykseen. Jos osaisimme lukea samaan aikaan, emme voisi siirtää sitä ja ohjata ihmisiä uuteen pöytään. Meidän olisi odotettava, että kaikki lukevat tämän taulukon loppuun, joten se on pohjimmiltaan lukko-ainoastaan tilanne.
Sanomme vain, että lukitsemme alusta alkaen, koska tiedämme, että aivan lopussa tarvitsemme eksklusiivisen lukon siirtääksemme kaikki uuteen kopioon. Joten voimme mahdollisesti ratkaista tämän. Ja teemme sen tällä tavalla samanaikaisella indeksoinnilla. Mutta tämä on paljon vaikeampi tehdä. Ja tämä liittyy hyvin pitkälti edelliseen kysymykseesi koskien lukkoa.
Onko mahdollista lisätä lukituksen aikakatkaisu Postgresiin? Oraclessa voin esimerkiksi kirjoittaa "select to update" ja odottaa 50 sekuntia ennen päivitystä. Se oli hyvä sovellukselle. Mutta Postgresissa minun on joko tehtävä se heti eikä odotettava ollenkaan tai odotettava jonkin aikaa.
Kyllä, voit valita aikakatkaisun lukoistasi, lukoistasi. Voit myös antaa no way -komennon, joka... jos et saa heti lukkoa. Siksi joko lukituksen aikakatkaisu tai jokin muu, jonka avulla voit tehdä tämän. Tätä ei tehdä syntaktisella tasolla. Tämä tehdään muuttujana palvelimella. Joskus tätä ei voi käyttää.
Voitko avata dian 75?
Kyllä.
Ja kysymykseni on seuraava. Miksi molemmat päivitysprosessit odottavat 703:a?
Ja tämä on hieno kysymys. En muuten ymmärrä, miksi Postgres tekee tämän. Mutta kun 703 luotiin, se odotti 702:ta. Ja kun 704 ja 705 ilmestyvät, näyttää siltä, että he eivät tiedä mitä he odottavat, koska siellä ei ole vielä mitään. Ja Postgres tekee sen näin: kun et saa lukkoa, se kirjoittaa "Mitä järkeä on käsitellä sinua?", koska odotat jo jotakuta. Joten annamme sen vain roikkua ilmassa, se ei päivitä sitä ollenkaan. Mutta mitä tässä tapahtui? Heti kun 702 suoritti prosessin ja 703 sai lukituksensa, järjestelmä palasi takaisin. Ja hän sanoi, että nyt meillä on kaksi ihmistä, jotka odottavat. Ja sitten päivitetään ne yhdessä. Ja osoittakaamme, että molemmat odottavat.
En tiedä miksi Postgres tekee tämän. Mutta on ongelma nimeltä f…. Minusta tämä ei ole venäjänkielinen termi. Silloin kaikki odottavat yhtä linnaa, vaikka linnaa odottaisi 20 viranomaista. Ja yhtäkkiä he kaikki heräävät samaan aikaan. Ja kaikki alkavat yrittää reagoida. Mutta järjestelmä tekee sen niin, että kaikki odottavat numeroa 703. Koska he kaikki odottavat, ja me laitamme heidät kaikki heti riviin. Ja jos jokin muu uusi pyyntö, joka on luotu tämän jälkeen, esimerkiksi 707, tulee taas tyhjäksi.
Ja minusta näyttää, että tämä tehdään siksi, että voimme sanoa, että tässä vaiheessa 702 odottaa 703:a, ja kaikilla sen jälkeen tulevilla ei ole merkintää tälle kentällä. Mutta heti kun ensimmäinen tarjoilija lähtee, kaikki ne, jotka odottivat sillä hetkellä ennen päivitystä, saavat saman merkin. Ja niin luulen, että tämä tehdään, jotta voimme käsitellä järjestyksessä niin, että ne ovat asianmukaisesti tilattuja.
Olen aina pitänyt tätä melko outona ilmiönä. Koska esimerkiksi täällä emme luettele niitä ollenkaan. Mutta minusta näyttää siltä, että joka kerta kun annamme uuden lukon, katsomme kaikkia niitä, jotka ovat odottamassa. Sitten laitamme ne kaikki riviin. Ja sitten kaikki uusi, joka tulee sisään, joutuu jonoon vasta, kun seuraavan henkilön käsittely on valmis. Erittäin hyvä kysymys. Kiitos paljon kysymyksestäsi!
Minusta on paljon loogisempaa, kun 705 odottaa 704:ää.
Mutta ongelma tässä on seuraava. Teknisesti voit herättää yhden tai toisen. Ja niin me herätämme yhtä tai toista. Mutta mitä järjestelmässä tapahtuu? Voit nähdä, kuinka 703 yläosassa on estänyt oman tapahtumatunnuksensa. Näin Postgres toimii. Ja 703 on estetty sen omalla tapahtumatunnuksella, joten jos joku haluaa odottaa, hän odottaa 703:a. Ja pohjimmiltaan 703 valmistuu. Ja vasta sen valmistumisen jälkeen yksi prosesseista herää. Ja emme tiedä, mikä tämä prosessi tarkalleen tulee olemaan. Sitten käsittelemme kaiken vähitellen. Mutta ei ole selvää, mikä prosessi herää ensin, koska se voi olla mikä tahansa näistä prosesseista. Pohjimmiltaan meillä oli ajastin, joka sanoi, että voimme nyt herättää minkä tahansa näistä prosesseista. Valitsemme yhden sattumanvaraisesti. Joten molemmat on huomioitava, koska voimme herättää jommankumman.
Ja ongelma on, että meillä on CP-infinity. Ja siksi on melko todennäköistä, että voimme herätä myöhemmin. Ja jos esimerkiksi herätämme myöhemmän, odotamme sitä, joka juuri sai lohkon, joten emme määritä, kuka tarkalleen herää ensimmäisenä. Luomme yksinkertaisesti tällaisen tilanteen, ja järjestelmä herättää heidät satunnaisessa järjestyksessä.
On . Katso, ne ovat myös mielenkiintoisia ja hyödyllisiä. Aihe on tietysti hirvittävän monimutkainen. Kiitos paljon, Bruce!
Lähde: will.com