Postgres lukuhalduri avamine. Bruce Momjian

Bruce Momjani 2020. aasta ettekande "Postgres lukuhalduri avamine" kokkuvõte.

(Märkuseks: Kõik SQL-küsimused slaididelt saate selle lingi kaudu: http://momjian.us/main/writings/pgsql/locking.sql)

Tere! On suurepärane taas olla siin Venemaal. Palun vabandage, et ma ei saanud eelmisel aastal tulla, kuid sel aastal on Ivanil ja mul suured plaanid. Loodan, et olen siin palju sagedamini. Armastan Venemaale reisida. Kavatse sel külastada Tjumenit ja Tveri. Olen väga õnnelik, et saan nende linnadega tutvuda.

Minu nimi on Bruce Momjian. Töötan EnterpriseDB-s ja olen töötanud Postgresi kallal üle 23 aasta. Elan Filadelfias, Ameerika Ühendriikides. Reisitan umbes 90 päeva aastas ja käin umbes 40 konverentsil. Minu veebileht, kus on slaidid, mida ma teile nüüd näitan. Seega pärast konverentsi võite need minu isiklikult veebilehelt alla laadida. Seal on ka umbes 30 presentatsiooni, videoid ja palju blogipostitusi — üle 500. See on piisavalt sisukas ressurss. Ja kui teid huvitab see materjal, siis kutsun teid seda kasutama.

Olen varem olnud õppejõud ja professor, enne kui alusin töötama Postgresiga. Olen väga rõõmus, et saan teiega jagada seda, mida kavatseme arutada. See on üks minu kõige põnevamaid ettekandeid ning see sisaldab 110 slaidi. Alustame lihtsatest asjadest ning lõpuks muutub arutelu üha keerulisemaks ja keerulisemaks.

See on üsna ebameeldiv jutt. Lukustus ei ole kõige populaarsem teema. Me soovime, et see kaoks kuhugi. See on nagu hambaarsti juurde minemine.

1. Lukustus on probleem paljudele, kes töötavad andmebaasidega ja kellel on samaaegselt mitu protsessi. Neile on lukustus vajalik. Täna annan teile põhiteadmised lukustamisest.
2. Tehingu identifikaatorid. See on üsna igav osa esitlust, kuid need tuleb mõista.
3. Järgnevalt räägime lukustamise tüüpidest. See on piisavalt mehaaniline osa.
4. Seejärel toome mõned näited lukustamisest. See osutub piisavalt keeruliseks arusaamiseks.

Räägime lukustustest.

Meie terminoloogia on üsnagi keeruline. Kui paljud teist teavad, kust see lõik pärit on? Kaks inimest. See on mängust nimega „Kohutav seiklus koopas“. See oli tekstipõhine videomäng 80ndatel aastatel, nii et mulle tundub. Seal pidid minema koopasse, labürinti ja tekst muutus, kuid sisu oli sisuliselt iga kord sama. Nii mäletan ma seda mängu.

Ja siin näeme blokeerimise nimetusi, mis on meieni tulnud Oracle'ilt. Me kasutame neid.

Siin näeme mõisteid, mis mind segadusse ajavad. Näiteks SHARE UPDATE EXCLUSIVE. Järgmiseks SHARE RAW EXCLUSIVE. Ausalt öeldes ei ole need nimetused väga arusaadavad. Proovime need põhjalikumalt läbi vaadata. Mõned sisaldavad sõna „share“, mis tähendab – eralduma. Mõned sisaldavad sõna „exclusive“ — eksklusiivne. Mõned sisaldavad mõlemat sõna. Tahaksin alustada sellest, kuidas need blokeeringud töötavad.

Ja ka väga tähtis on sõna „juurdepääs“ — access. Ja sõna „row“ — rida. St juurdepääsu ja ridade jaotamine.

Teine probleem, mida tuleb Postgresis mõista, on MVCC, millest ma kahjuks oma ettekandes rääkida ei saa. Mul on sellel teemal eraldi esitus minu veebisaidil. Ja kui arvate, et see esitus on keeruline, siis MVCC on tõenäoliselt minu kõige keerulisem. Kui teid huvitab, võite selle veebisaidilt vaadata. Vaadata saate ka videot.

Veel üks punkt, mida peame mõistma, on tehinguidentifikaatorid. Paljud tehingud ei saa töötada ilma unikaalsete identifikaatoriteta. Siin seletataksegi, mis asi on tehing. Postgresis on kaks tehingu numbrite süsteemi. Tean, et see ei ole eriti ilus lahendus.

Samuti pidage meeles, et slaidid on piisavalt keerulised, et neid mõista, seega peate tähelepanu pöörama sellele, mis on punasega esile tõstetud.

http://momjian.us/main/writings/pgsql/locking.sql

Vaatame. Punasega on esile tõstetud tehingu number. Siin on kuvatud funktsioon SELECT pg_back. See tagastab minu tehingu ja selle tehingu ID.

Veel üks punkt — kui teile meeldib see esitlus ja soovite selle oma andmebaasi käivitada, siis saate minna läbi selle roosa värviga esile tõstetud lingi ning alla laadida esituse SQL-i. Ja saate selle lihtsalt oma PSQL-is käivitada ning kogu esitlus ilmub teie ekraanile koheselt. See ei sisalda värve, kuid vähemalt saame selle näha.

Antud juhul näeme tehingu ID-d. See on number, mille oleme talle määranud. Ja Postgresis on veel üks tehingu ID tüüp, mida nimetatakse virtuaalseks tehingu ID-ks.

Peame seda mõistma. See on väga oluline, vastasel juhul ei saa me Postgresis blokeeringut mõista.

Virtuaalne tehingu ID on tehingu ID, mis ei sisalda püsivaid väärtusi. Näiteks, kui ma käivitan käsu SELECT, siis on tõenäoline, et ma ei muuda andmebaasi, ma ei blokeeri midagi. Seega, kui me käivitame lihtsa SELECT-i, ei anna me sellele tehingule püsivat ID-d. Anname talle seal ainult virtuaalse ID.

Ja see parandab Postgresi jõudlust ning täiustab puhastusvõimalusi, mistõttu virtuaalne tehingu ID koosneb kahest numbrist. Esimene number kaldkriipsu ees on tagasihoidliku ID. Ja paremal näeme lihtsalt loendurit.

Seetõttu, kui käitan päringu, ütleb see, et tagasihoidlik ID on 2.

Ja kui käitan selliseid tehingute seeriaid, näeme, et loendur suureneb iga kord, kui käitan päringu. Näiteks, kui käitan päringut 2/10, 2/11, 2/12 jne.

Pange tähele, et siin on kaks veergu. Vasakul näeme virtuaalset tehingu ID-d – 2/12. Ja paremal on meil püsiv tehingu ID. Ja see väli on tühi. See tehing ei muuda andmebaasi. Seetõttu ei omista ma sellele püsivat tehingu ID-d.

Kuna olen käivitanud analüüsimis käsu (ANALYZE), annab sama päring mulle püsiva tehingu ID. Vaadake, kuidas see on muutunud. Varem ei olnud mul seda ID-d, nüüd see on olemas.

Nii et siin on veel üks päring, veel üks tehing. Virtuaalne tehingu number – 2/13. Ja kui palun püsivat tehingu ID-d, siis kui käitan päringu, saan selle.

Nii et, veel kord. Meil on virtuaalne tehingu ID ja püsiv tehingu ID. Lihtsalt mõistke seda punkti, et aru saada Postgres'i käitumisest.

Liigume kolmandasse sektsiooni. Siin käime lihtsalt läbi erinevad lukustustüübid Postgres'is. See pole väga huvitav. Viimane sektsioon tuleb palju huvitavam. Kuid me peame uurima põhiasju, vastasel juhul ei saa me aru, mis edasi tuleb.

Me vaatame selle sektsiooni läbi, vaatame iga lukustustüübi. Ja ma näitan teile näiteid, kuidas need kehtestatakse, kuidas need töötavad, ning tutvustan teile mõned päringud, mida saab kasutada, et näha, kuidas lukustus Postgres'is töötab.

Küsimuse esitamiseks ja selle nägemiseks, mis Postgres'is toimub, peame esitama päringu süsteemi vaatesse. Antud juhul on meil punasega esile tõstetud pg_lock. Pg_lock on süsteemtablett, mis ütleb meile, millised lukustused on hetkel Postgres'is kasutusel.

Siiski on mul väga raske näidata teile pg_lock'i endast, sest see on üsna keeruline. Seetõttu lõin vaate, mis näitab pg_locks'i. Ja see teeb ka minu jaoks teatud tööd, mis aitab mul paremini mõista. St. see välistab minu lukustused, minu enda sessiooni jne. See on lihtsalt standardne SQL ja see võimaldab paremini näidata, mis toimub.

Teine probleem on see, et see vaade on väga lai, seega pean looma teise – lockview2.

Ja see näitab mulle veel veerge tabelist. Ja veel üks, mis näitab mulle ülejäänud veerge. See on piisavalt keeruline, seega püüdsin seda esitada nii lihtsalt kui võimalik.

Nii et lõime tabeli nimega Lockdemo. Ja lõime seal ühe rea. See on meie näidistabel. Ja loome sektsioonid, et lihtsalt näidata teile lukustuse näiteid.

Nii et üks rida, üks veerg. Esimene lukustustüüp nimetatakse ACCESS SHARE. See on kõige vähem piirav lukustus. See tähendab, et see praktiliselt ei konflikti teiste lukustustega.

Ja kui me tahame blokeerimist selgelt määratleda, käivitame käsu «lock table». See blokeerib selgelt, st ACCESS SHARE režiimis käivitame lock table. Ja kui käivitan PSQL taustal, siis käivitan seega oma esimesest sessioonist teise seansi. Mida ma siin teen? Liigun teise seansi juurde ja ütlen, et näitaks mulle lockview antud päringu jaoks. Siin on mul AccessShareLock selles tabelis. See on just see, mida ma küsisin. Ja ta ütleb, et blokeering on määratud. Väga lihtne.

Kui vaatame teist veergu, siis seal pole midagi. Need on tühjad.

Ja kui ma käivitan käsu «SELECT», siis see on kaudne (ilmne) viis AccessShareLocki taotlemiseks. Seetõttu vabastan oma tabeli ja käivitan päringu ning päring tagastab mitu rida. Ja ühes neist ridadest näeme AccessShareLocki. Seega kutsub SELECT tabelis esile AccessShareLocki. Ja see ei konflikti praktiliselt millegagi, kuna on madala tasemega blokeering.

Kuidas oleks, kui ma käivitan SELECTi ja mul on kolm erinevat tabelit? Varasemalt käivitasin ainult ühe tabeli, nüüd käivitan kolm: pg_class, pg_namespace ja pg_attribute.

Ja nüüd, kui ma vaatan päringut, näen 9 AccessShareLocks kolme tabeliga. Miks? Sinise värviga on esile tõstetud kolm tabelit: pg_attribute, pg_class, pg_namespace. Kuid näete ka, et kõik indekseerimised, mis on määratletud nende tabelite kaudu, omavad samuti AccessShareLock'i.

Ja tegemist on lukustusega, mis praktiliselt ei tekita konflikte teistega. Kõik, mida see teeb, on see, et see ei luba meil tabelit tagasi tõmmata, kuni me seda valime. See on mõistetav. St kui me valime tabeli ja see hetk äkki kaob, siis see oleks vale, seega AccessShare on madalama taseme lukustus, mis ütleb meile 'ärge kustutage seda tabelit, kuni ma töötan'. Põhimõtteliselt on see kõik, mida ta teeb.

ROW SHARE on lukustus, mis erineb veidi.

Võtame näite. SELECT ROW SHARE on lukustusmeetod, mis lukustab iga rida eraldi. Sel viisil ei saa keegi neid kustutada või muuta seni, kuni me neid vaatame.

Nii et, mis teeb SHARE LOCK? Näeme, et tehingu ID on 681 SELECT'i jaoks. Ja see on huvitav. Mis siin juhtus? Esmakordselt näeme numbrit välja „Lock“. Me võtame tehingu ID ja see ütleb, et see lukustab selle eksklusiivses režiimis. Kõik, mida ta ütleb, on see, et mul on rida, mis on tehniliselt kuskil tabelis lukustatud. Aga ei ütle, kus täpselt. Veidi hiljem vaatame seda lähemalt.

Siin räägime, et lukustus on meie poolt kasutusel.

Nii et eksklusiivne lukustus ütleb selgelt, et see on eksklusiivne. Ja samuti, kui kustutate selle tabeli rea, siis see juhtub, nagu te näete.

SHARE EXCLUSIVE – see on pikem lukustus.

See (ANALYZE) on analüüsikäsk, mida kasutatakse.

SHARE LOCK – saate seda selgelt lukustada jagamises.

Saate ka luua unikaalse indeksi. Ja seal näete SHARE LOCK'i, mis on nende osa. Ja see lukustab tabeli ning seab sellele SHARE LOCK'i.

Vaikimisi SHARE LOCK tabelis tähendab, et teised inimesed saavad tabelit lugeda, kuid keegi ei saa seda modifitseerida. Just nii käibki, kui loote unikaalse indeksi.

Kui ma loon unikaalse indeksi concurrently, siis mul on teine ​​tüüp lukku, sest nagu te mäletate, vähendab concurrently indeksite kasutamine lukustusnõudeid. Ja kui ma kasutan tavalist lukku, tavalist indeksit, takistab see kirjutamist indeksitabelisse selle loomise ajal. Kui ma kasutan concurrently indeksit, tuleb mul kasutada teistsugust lukku.

SHARE ROW EXCLUSIVE – selle saab samuti määrata eksplicitset (selgelt).

Või võime luua reegli, st võtta mingi kindel juhtum, millega seda kasutatakse.

EXCLUSIVE lukustus tähendab, et keegi teine ei saa tabelit muuta.

Siin näeme erinevaid lukustuside tüüpe.

ACCESS EXCLUSIVE, näiteks, see on lukustamise käsk. Näiteks, kui teete CLUSTER table, siis see tähendab, et keegi ei saa sinna kirjutada. Ja see lukustab mitte ainult tabeli enda, vaid ka indeksid.

See on ACCESS EXCLUSIVE blokeerimise teine leht, kus me näeme täpselt, mida see tabelis blokeerib. See blokeerib tabeli üksikud read, mis on piisavalt huvitav.

See on kogu põhiteave, mida ma tahtsin anda. Rääkisime blokeeringutest, tehingu ID-dest, rääkisime virtuaalsetest tehingu ID-dest ja püsivatest tehingu ID-dest.

Ja nüüd vaatame blokeerimise näiteid. See on kõige huvitavam osa. Vaatame väga huvitavaid juhtumeid. Ja minu ülesanne selles ettekandes on anda teile parem ülevaade sellest, mida Postgres tegelikult teeb, kui ta püüab teisi asju blokeerida. Mul on tunne, et ta oskab väga hästi blokeerida üksikuid osi.

Vaatame kindlaid näiteid.

Alustame tabelitest ja ühest reast tabelis. Kui ma midagi sisestan, kuvatakse mulle ExclusiveLock, tehingu ID ja ExclusiveLock tabelis.

Entä mitä tapahtuu, jos lisään vielä kaksi riviä? Nyt taulukossamme on kolme riviä. Lisäsin yhden rivin ja sain tällaisen tuloksen. Ja jos lisään vielä kaksi riviä, mikä tässä on outoa? Tässä on outous, sillä olen lisännyt kolme riviä tähän taulukkoon, mutta minulla on silti vain kaksi riviä lukitus-taulukossa. Ja tämä on itse asiassa Postgresin perus käyttäytyminen.

Monet ajattelevat, että jos tietokannassa lukitset 100 riviä, niin tarvitset 100 lukitusmerkintää. Jos lukitsen samanaikaisesti 1 000 riviä, tarvitsen 1 000 tällaista pyyntöä. Ja jos minun täytyy lukita miljoona tai miljardi. Mutta jos teemme niin, se ei toimi kovin hyvin. Jos olit käyttänyt järjestelmää, joka luo lukitusmerkinnät jokaiselle erilliselle riville, huomaat, että se on hankalaa. Koska sinun on määritettävä heti lukitus-taulukko, joka voi ylittyä, mutta Postgres ei toimi niin.

Ja sellel slaidil on väga oluline, et on selgelt näha, et on veel üks süsteem, mis töötab MVCC sees, mis lukustab üksikuid ridu. Seega, kui lukustate miljardeid ridu, ei loo Postgres miljardit eraldi lukustuskommandot. See avaldab väga head mõju jõudlusele.

Aga kuidas on uuendustega? Ma uuendan praegu rida ja võite märgata, et see tegi kohe kaks erinevat operatsiooni. Ta lukustas samaaegselt tabeli, kuid lukustas ka indeksi. Ja tal oli vaja lukustada indeks, kuna sellel tabelil on unikaalsed piirangud. Soovime veenduda, et keegi seda ei muuda, seetõttu me lukustame selle.

Aga mis juhtub, kui tahan uuendada kahte rida? Näeme, et ta käitub samamoodi. Teeme kaks korda rohkem uuendusi, kuid lukustame endiselt sama arvu ridu.

Kui te soovite teada, kuidas Postgres seda teeb, siis peate kuulama minu ettekandeid MVCC-st, et mõista, kuidas Postgres sisemiselt markeerib neid ridu, mida ta muudab. Ja Postgresil on meetod, millega ta seda teeb, kuid see ei toimu tabelite lukustamise tasemel; see toimub madalamal ja efektiivsemal tasemel.

Ent kui ma tahan midagi kustutada? Kui ma kustutan näiteks ühe rea, ja mul on ikka veel kaks lukustust, ja isegi kui ma tahan need kõik kustutada, on need ikkagi olemas.

Ja näiteks, kui ma tahan sisestada 1 000 rida, ja siis kas kustutada või lisada veel 1 000 rida, siis need individuaalsed read, mida ma lisan või muudan, ei salvestata siia. Need salvestatakse madalamal tasemel, ridade enda sees. Ja MVCC ettekandes rääkisin sellest üksikasjalikult. Kuid on väga oluline, et kui analüüsite lukustusi, veenduge, et teil on tabeli taseme lukustus ning et te ei näe siin, kuidas individuaalsete ridade salvestamine toimub.

Aga kuidas on eksplicitse lukustamisega?

Kui ma klikkin «värskenda», on mul kaks lukustatud rida. Ja kui ma valin need kõik ja klikkin «värskenda kõikjal», on mul ikkagi kaks lukustatud kirjet.

Me ei loo eraldi kirjeid iga rida jaoks. Sest siis langeb jõudlus, seal võib olla liiga palju. Ja me võime sattuda ebamugavasse olukorda.

Ja sama asi, kui me teeme jagatud, saame teha seda 30 korda.

Me taastame oma tabeli, kustutame kõik, seejärel lisame uuesti ühe rea.

Teine käitumisviis, mida te näete Postgreses, on väga hästi tuntud ja soovitav käitumine – see on see, et saate täita uuendust või valimist. Ja saate seda teha samaaegselt. Ja valimine ei blokeeri uuendust ja sama on vastupidine. Me ütleme lugejale, et ärge blokeerige kirjutajat, ja kirjutaja ei blokeeri lugejat.

Ma näitan teile selle näidet. Ma teen nüüd valiku. Seejärel teeme INSERTi. Ja te saate näha – 694. Te näete tehingu ID-d, mis viis selle lisamise läbi. Ja see on see, kuidas see töötab.

Ja kui ma nüüd vaatan oma taustarakenduse ID-d, on see nüüd – 695.

Ja näen, et 695 ilmub minu tabelisse.

Ja kui ma värskendan seda siit nii, siis saan ma teise juhtumi. Sel juhul on 695 ainulaadne lukustus, ja uuel on sama käitumine, kuid nende vahel ei teki konflikti, mis on üsna ebatavaline.

Ja te võite märgata, et ülalpool on ShareLock ja allpool on ExclusiveLock. Ja mõlemad tehingud toimisid.

Ja peate kuulama minu esitluse MVCC-st, et mõista, kuidas see toimub. Aga see illustreerib, et te saate seda teha samaaegselt, s.t. samal ajal teha SELECT ja UPDATE.

Lähme tagasi ja teeme veel ühe tehingu.

Kui proovite samaaegselt käivitada kaks uuendust samal real, siis see lukustub. Ja pidage meeles, et ma rääkisin, et lugemise ajal ei blokeeri see kirja, kuid kirjutaja blokeerib lugejat, kuid üks kirjutaja blokeerib teise kirjutaja. S.t. me ei saa lasta kahel inimesel sama rida samaaegselt uuendada. Peame ootama, kuni üks neist lõpetab.

Ja selle üles näitamiseks vaatan Lockdemo tabelit. Ja vaatame ühte rida. Tehingut 698.

Oleme selle uuendanud kuni 2. 699 - see on esimene uuendamine. Ja see on läinud edukalt või see on ooteolekus ja ootab, kuni me kinnitame või tühistame.

Aga vaadake midagi muud - 2/51 - see on meie esimene tehing, meie esimene sessioon. 3/112 - see on järgmine päring, mis ilmus üleval ja mis muutis selle väärtuse 3-ks. Ja kui te märkate, siis ülemine blokeeris ise ennast, nimelt 699. Kuid 3/112 ei andnud lukku. Lock_mode veerus on kirjas, et see ootab. See ootab 699. Ja kui vaatate, kus 699 on, siis see on üleval. Ja mida esimene sessioon tegi? Ta lõi eksklusiivse lukustuse omaenda tehingu ID-le. Just nii teeb Postgres. See blokeerib omaenda tehingu ID. Ja kui soovite oodata, kuni keegi kinnitab või tühistab, peate ootama, kuni on ooteolekus tehing. Ja seetõttu saame näha kummalist rida.

Vaadake veel kord. Vasakul näeme meie töötlemise ID-d. Teises veerus on meie virtuaalne tehingu ID, kolmandas veerus aga lock_type. Mida see tähendab? Tegelikult ütleb see, et see blokeerib tehingu ID. Kuid pange tähele, et kõikides ridades allpool on märgitud relation. Seetõttu on teil tabelis kaks tüüpi blokeeringut. On relation blokeering. Samuti on olemas transactionid blokeering, kus blokeerite iseseisvalt, see on täpselt see, mis toimub esimeses reas või allpool, kus transactionid ootab, et 699 lõpetaks oma operatsiooni.

Ma vaatan, mis siin toimub. Ja siin toimuvad samal ajal kaks asja. Te vaatate tehingu ID-blokeeringut esimeses reas, mis blokeerib iseennast. Ja see blokeerib iseennast, et panna inimesi ootama.

Kui vaatate 6. rida, siis see on sama kirje, mis esimene. Seetõttu blokeeritakse tehing 699. 700 blokeerib samuti iseennast. Ja siis allosas näete, et me ootame, kuni 699 lõpetab oma operatsiooni.

Ja lock_type, tuple näete numbreid.

Saate näha, et see on 0/10. Ja see on lehekülje number, samuti selle konkreetse rea offset.

Ja näete, et see muutub 0/11, kui me uuendame.

Aga tegelikult on see 0/10, kuna see toiming on ootel. Meil on võimalus näha, et see on see rida, mida ma ootan kinnitamiseks.

Niikaua, kuni me selle kinnitame ja vajutame commit, ning kui uuendamine on finished, siis see, mida me taas saame. Tehing 700 on ainus lukustus, see ei oota kedagi, kuna see on juba commiteeritud. See lihtsalt ootab, et tehing lõpetataks. Kui 699 lõpeb, ei oota me enam kedagi. Ja nüüd ütleb tehing 700, et kõik on korras, et kõik lukustused, mis vajalikud, on tal olemas kõikides lubatud tabelites.

Ja et seda kõike veel keerukamaks muuta, loome veel ühe view, mis seekord annab meile hierarhia. Ma ei oota, et te selle päringu mõistaksite. Kuid see annab meile selgema ülevaate sellest, mis toimub.

See on rekursiivne view, millel on ka teine sektsioon. Ja see tagastab kõik koos. Kasutame seda.

Mis siis, kui teeme kolm samal ajal olevat uuendust ja ütleme, et rida on nüüd kolm. Ja me muudame 3 neljaks.

Ja näeme numbrit 4. Ja tehingu ID on 702.

Seejärel vahetan 4 5 vastu. Ja 5 6, ning 6 7 vastu. Ma seon inimesed järjekorda, et oodata, kuni see üks tehing lõpetatakse.

Kõik muutub selgeks. Mis on esimene rida? See on 702. See on tehingu ID, mis algselt määras selle väärtuse. Mis mul on Granted veerus? Mul on tähised f. Need on minu uuendused (5, 6, 7), mida ei saa heaks kiita, sest me ootame, kuni tehingu ID 702 lõpetatakse. Siin on tehingu ID lukustus. Ja meil on 5 tehingu ID lukustust.

Ja kui vaatate 704 ja 705, siis seal pole veel midagi kirjas, sest nad ei tea veel, mis toimub. Nad kirjutavad lihtsalt, et ei ole aimugi, mis toimub. Ja nad lähevad lihtsalt magama, sest nad ootavad, kuni keegi lõpetab ja äratab nad, kui võimalus rida vahetada tekib.

Nii see välja näeb. Selge on, et nad kõik ootavad 12. rida.

See on see, mida me siin nägime. Siin on 0/12.

Nii et niipea, kui esimene tehing on heaks kiidetud, saate siin näha, kuidas hierarhia töötab. Ja nüüd on kõik selge. Nad kõik saavad puhtaks. Ja nad on tegelikult ikka veel ootel.

Nii juhtub. 702 kinnitatakse. Ja nüüd 703 saab selle rea lukustuse, seejärel hakkab 704 ootama, kuni 703 kinnitatakse. Ja 705 ootab samuti seda. Ja kui see kõik on lõppenud, puhastavad nad end ise. Tahaksin rõhutada, et kõik järjekorda seadistatakse. See on väga sarnane olukorraga ummikus, kus kõik ootavad esimest autot. Esimene auto peatub ja kõik seisavad pikaks read. Siis see liigub edasi, järgmisel autol on võimalus edasi sõita ja saada oma lukustus jne.

Ja kui see tundub teile ebapiisavalt keeruline, siis räägime nüüd deadlockidest. Ma ei tea, kes teist on nendega kokku puutunud. See on üsna levinud probleem andmebaasisüsteemides. Deadlockid on olukord, kus üks sessioon ootab, et midagi teeks teine sessioon. Ja samal ajal ootab teine sessioon, et esimene sessioon teeks midagi.

Ja näiteks, kui Ivan ütleb: "Anna mulle midagi," aga mina ütlen: "Ei, ma annaksin sul seda ainult siis, kui sa annaksid mulle midagi muud." Ja ta ütleb: "Ei, ma ei anna sulle seda, kui sa ei anna mulle midagi." Ja me satume surnud ummikusse. Ma olen kindel, et Ivan seda ei tee, aga sa saad aru mõttest, et meil on kaks inimest, kes tahavad midagi saada ja nad ei ole valmis seda andma, kuni teine inimene neile ei anna, mida nad soovivad. Ja siin pole lahendust.

Ja tegelikult peab teie andmebaas selle tuvastama. Ja siis on vaja eemaldada või sulgeda üks sessioon, sest vastasel juhul jäävad nad sinna igaveseks. Ja me näeme seda andmebaasides, me näeme seda operatsioonisüsteemides. Ja kõigis kohtades, kus meil on paralleelsed protsessid, võib see juhtuda.

Ja nüüd seame sisse kaks deadlocki. Seame ühe 50 ja teise 80. Esimeses reas teen uuenduse 50 pealt 50 peale. Mul tuleb transaktsiooni number 710.

Ja siis vahetan 80 81 vastu ja 50 51 vastu.

Ja nii see välja näeb. Seetõttu on 710 blokaadis rea, samas kui 711 ootab kinnitust. Me nägime seda, kui uuendame. 710 on meie rea omanik. Ja 711 ootab, kuni 710 lõpetab transaktsiooni.

Ja isegi kirjutatakse, millises reas meil deadlock’id toimuvad. Ja siin hakkab see kummaliseks minema.

Nüüd värskendame 80 80 peale.

Ja siin hakkavad deadlock’id pihta. 710 ootab vastust 711-lt, samas kui 711 ootab 710-lt. Ja see ei lõppe hästi. Ainult üks tee on, et nad ootavad üksteiselt vastust.

See hakkab lihtsalt kõike aeglustama. Ja me ei soovi seda.

Postgreses on viise, kuidas märgata, kui see toimub. Ja kui see juhtub, saate sellise vea. Selge on see, et mingi protsess ootab SHARE LOCK’i teiselt protsessilt, st see, keda blokeerib protsess 711. Ja see protsess ootas SHARE LOCK’i teatud tehingu ID-le ja oli blokeeritud teise protsessi poolt. Seega oleme deadlock’i olukorras.

Kas on olemas ka kolmandat tüüpi deadlock’id? Kas see on võimalik? Jah.

Sisestame need numbrid tabelisse. Me muudame 40 40-ks, loome blokeeringu.

Muudame 60 61-ks, 80 81-ks.

Siis muudame 80, ja seejärel – bum!

Ja nüüd ootab 714 715 vastust. 716 ootab 715-d. Ja sellega ei saa enam midagi teha.

Siin ei ole enam kahte inimest, siin on juba kolm inimest. Ma tahan sinult midagi, see tahab midagi kolmandalt inimeselt, ja kolmas inimene tahab midagi minult. Ja me jõuame kolmnurkse ootuse olukorda, sest kõik ootame, et teine inimene lõpetaks, mida ta peab tegema.

Ja Postgres teab, millisel real see toimub. Seetõttu annab ta teile järgmise teate, mis näitab, et teil on probleem, kus kolm sisendit blokeerivad üksteist. Ja siin ei ole piiranguid. See võib olla olukord, kus 20 kirjet blokeerivad üksteist.

Järgmine probleem on serialiseeritavus.

Kui on eriline serialiseeritavus blokeering.

Ja naaseme 719 juurde. Sellel on täiesti normaalne väljund.

Ja saate vajutada, et teostada transaction serialiseeritavuses.

Ja te mõistate, et teil on nüüd teine ​​tüüp blokeeringut SA - see tähendab serialiseeritavat.

Seetõttu on meil uus tüüp blokeeringut, mida nimetatakse SARieadLock, mis on seerianumbrite blokeering ja võimaldab seerianumbrite sisestamist.

Samuti saate sisestada unikaalseid indekseid.

Selles tabelis on meil unikaalsed indekssid.

Seega, kui ma siia sisestan numbri 2, siis mul on 2. Kuid ülalpool sisestan veel ühe 2. Ja te näete, et 721-l on ainulaadne lukustus. Nüüd ootab 722, et 721 lõpetaks oma toimingu, kuna ta ei saa 2-d sisestada, enne kui ei tea, mis 721-ga juhtub.

Ja kui me teeme subtehingu.

Siin on meil 723.

Kui me salvestame punkti ja seejärel seda värskendame, siis saame uue tehingu ID. See on veel üks käitumise iseloom, millest peate teadma. Kui me selle tagasi anname, siis tehingu ID kaob. 724 kaob. Kuid nüüd on meil 725.

Ja mida ma siin üritan teha? Püüan näidata teile näiteid ebatavalistest lukustustest, mida võite leida: olgu need serialiseeritavad lukustused või SAVEPOINT – need on erinevad lukustustüübid, mis ilmuvad lukustuste tabelis.

See on eksplitsiitsete (selgete) lukustuste loomine, mille puhul on pg_advisory_lock.

Ja te näete, et lukustuse tüüp on siin loetletud kui nõuanne. Ja siin on punaselt kirjutatud "nõuanne". Ja te võite samaaegselt lukustada pg_advisory_unlockiga.

Ja lõpetuseks tahaksin teile näidata veel üht üllatavat asja. Loomin veel ühe vaate. Kuid ma ühendan tabeli pg_locks tabeliga pg_stat_activity. Ja miks ma seda teha tahan? Sest see võimaldab mul vaadata ja näha kõiki aktiivseid sessioone ning milliste lukustusde nad ootavad. See on üsna huvitav, kui meil on koos lukustus tabel ja päringute tabel.

Ja siin loome pg_stat_view.

Ja värskendame rida ühe võrra. Siin näeme 724. Ja siis värskendame meie rida kolme võrra. Ja mida te siin nüüd näete? Need on päringud, st näete kogu päringute nimekirja, mis on loetletud vasakus veerus. Ja siis paremal poolel näete lukustusi ja seda, mida nad loovad. Ja see võib olla teile selgem, et te ei pea iga kord tagasi minema iga sessiooni juurde ja vaatama, kas sellele tuleks liituda või mitte. Meie eest teevad seda.

Veel üks funktsioon, mis on väga kasulik, on pg_blocking_pids. Te olete tõenäoliselt sellest kunagi kuulnud. Mida see teeb? See võimaldab meil öelda, milliseid protsesside ID-sid ootab seanss 11740. Ja te võite näha, et 11740 ootab 724. Ja 724 on kõige peal. Ja 11306 on teie protsesside ID. Sisuliselt läbib see funktsioon teie lukustustabelit. Ma tean, et see on veidi keeruline, kuid te suudate seda mõista. Sisuliselt läbib see funktsioon seda lukustustabelit ja püüab leida, kus see protsessi ID asub, arvestades lukustusi, mida ta ootab. Ta üritab ka arvutada, milline protsesside ID on selle protsessi, mis ootab lukustust. Seetõttu võite selle funktsiooni käivitada. pg_blocking_pids.

Ja see osutub väga kasulikuks. Me lisasime selle alles versiooniga 9.6, seega on sellel funktsioonil vaid 5 aastat, aga see on väga ja väga kasulik. Sama kehtib ka teise päringu kohta. See näitab täpselt seda, mida me peame nägema.

See on see, millest ma tahtsin teiega rääkida. Ja nagu ma ootasinki, kasutasime kogu meie aega, kuna släide oli nii palju. Ja släide on allalaadimiseks saadaval. Soovin tänada teid, et olite kohal. Olen kindel, et teile meeldib konverentsi ülejäänud osa, suur aitäh!

Küsimused:

Näiteks, kui üritan ridu uuendada, samal ajal kui teine sessioon püüab kogu tabeli kustutada. Nii palju kui ma tean, peab seal olema midagi nagu intent lock. Kas see on olemas Postgreses?

Käime tagasi algusesse. Võib-olla mäletate, et kui teete midagi, näiteks SELECT, siis laseme välja AccessShareLock'i. Ja see takistab tabeli kustutamist. Seega, kui soovite näiteks uuendada rida tabelis või kustutada rida, ei saa keegi samal ajal kogu tabelit kustutada, sest te hoiate selle AccessShareLock'i kogu tabeli ja rea kohal. Ja kui olete lõpetanud, saavad nad selle kustutada. Kuid seni, kuni te seal midagi muudate, ei saa nad seda teha.

Teeme seda veel kord. Liigume kustutamise näite juurde. Ja näete, kuidas real on eksklusiivne lock kogu tabeli üle.

Kas see näeb välja nagu eksklusiivne lukustus, eks?

Jah, see näeb tõepoolest välja nii. Ma saan aru, millest te räägite. Te ütlete, et kui ma teen SELECT-i, siis on mul jagatud eksklusiivne lukustus, ja kui ma muudan selle rida eksklusiivseks, kas see on probleem? Üllataval kombel ei tekita see probleemi. See on nagu lukustuse taseme tõstmine, kuid põhimõtteliselt on mul lukustus, mis takistab kustutamist. Ja nüüd, kui ma teen selle lukustuse tugevamaks, siis takistab see endiselt kustutamist. Seega see ei tähenda, et ma läheksin kõrgemale. T. e. see takistas seda ka madalamal tasemel, seega, kui ma tõstan taset, takistab see endiselt tabeli kustutamist.

Ma saan aru, millest te räägite. Siin ei ole lukustuse taseme tõstmise juhtumit, kus üritate loobuda ühest lukustusest, et sisse viia tugevam. Siin toimub lihtsalt üleüldine takistuse suurendamine, seega see ei tekita mingit konflikti. Kuid see on hea küsimus. Suur aitäh, et küsisite!

Mida me peame tegema, et vältida deadlock olukorda, kui meil on palju sessioone ja suur hulk kasutajaid?

Postgres tuvastab automaatselt deadlock'i olukorrad ja eemaldab automaatselt ühe sessiooni. Ainus võimalus, mis aitab vältida murtud lukustusi, on blokeerida inimesi samas järjekorras. Seetõttu, kui vaatate oma rakendusele, siis sageli on deadlock'i põhjuseks… Kujutame ette, et ma tahan blokeerida kahte erinevat asja. Üks rakendus blokeerib tabeli 1 ja teine rakendus blokeerib tabeli 2 ning seejärel tabeli 1. Ja kõige lihtsam viis deadlock'e vältida on vaadata oma rakendusele ja tagada, et lukustus toimub kõigis rakendustes sama järjekorra järgi. See eemaldab tavaliselt 80% probleemidest, sest erinevad inimesed kirjutavad neid rakendusi. Kui blokeerite need samas järjekorras, siis ei puutu te kokku deadlock'i olukordadega.

Suur tänu teie ettekande eest! Rääkisite vacuum full'ist ja kui ma õigesti aru saan, siis vacuum full deformeerib kirje järjekorda eraldi salvestuses, seega säilitavad praegused kirjed muutumatuna. Miks vacuum full aga võtab eksklusiivse lukustuse ja miks see konfliktib kirjutamisoperatsioonidega?

See on hea küsimus. Põhjuseks on see, et vacuum full haarab tabeli. Ja me loome põhimõtteliselt uue versiooni tabelist. Tabel on seega uus. Saame, et see on täiesti uus versioon tabelist. Probleem on aga selles, et kui me seda teeme, ei taha me, et inimesed seda loeksid, kuna peame kindlustama, et nad näevad uut tabelit. Seega seondub see varasema küsimusega. Kui me saaksime samaaegselt lugeda, ei saaks me seda ümber paigutada ja suunata inimesi uuele tabelile. Me peaks ootama, kuni kõik lõpetavad selle tabeli lugemise, ja seetõttu on see põhimõtteliselt eksklusiivsete lukustuse olukord.
Me lihtsalt ütlem, et blokeerime algusest peale, kuna me teame, et lõpuks vajame eksklusiivset lukku, et kõik uuele koopiale üle viia. Seetõttu saame selle potentsiaalselt lubada. Ja me teeme seda samaaegse indekseerimisega. Kuid see on palju keerulisem. See on tugevalt seotud teie eelneva küsimusega eksklusiivse lukustuse kohta.

Kas on võimalik lisada locking timeout’i Postgresis? Oracle’is saan näiteks kirjutada 'vali uuendamiseks' ja oodata 50 sekundit enne uuendamist. See töötas hästi rakenduse jaoks. Kuid Postgresis pean seda kas tegema kohe ja mitte üldse ootama või ootama mingi aja.

Jah, saate valida lukustuste, lockingute jaoks timeout’i. Samuti saate anda käsu no way, mis …, kui te ei saa kohe lukku. Seega on kas lock timeout või midagi muud, mis lubab teil seda teha. Seda ei tehta süntaktilisel tasandil. See toimub serveri muutuja tasemel. Mõnikord ei saa seda kasutada.

Kas saate avada 75 slaidi?

Jah.

Ja minu järgmine küsimus. Miks ootavad mõlemad uuendamisprotsessid 703?

See on suurepärane küsimus. Ma ei saa aru, miks Postgres seda teeb. Kui 703 loodi, oodati 702. Ja kui 704 ja 705 ilmuvad, tundub, et nad ei tea, mida nad ootavad, sest seal pole veel midagi. Postgres teeb seda järgmiste seaduste kohaselt: kui te ei saa lukku, ütleb ta: "Milleks teid üldse töötlema hakata?" sest te juba ootate kedagi. Seetõttu laseme tal lihtsalt õhku jääda, ta ei uuenda seda üldse. Aga mis siin juhtus? Niipea kui 702 lõpetas protsessi ja 703 sai oma lukustuse, naasis süsteem tagasi. Ja ütles, et nüüd on meid kaks, kes ootavad. Laseme neil seejärel üheskoos uuendada. Ja märkime, et mõlemad ootavad.

Ma ei tea, miks Postgres nii käitub. Kuid on probleem, mida nimetatakse f.... Minu arvates ei ole see vene termín. See juhtub, kui kõik ootavad üht lukku, isegi kui on 20 instantsi, kes ootavad lukku. Ja äkki nad kõik ärkavad korraga. Ja kõik hakkavad üritama reageerida. Kuid süsteem teeb nii, et kõik ootavad 703. Kuna nad kõik ootavad, paneme nad kohe järjekorda. Ja kui ilmub mõni uus päring, mis on tehtud pärast seda, näiteks 707, siis seal tuleb jälle tühjus.

Ja mulle tundub, et seda tehakse selleks, et saaks öelda, et sellel hetkel ootab 702 703, ja kõik, kes tulevad pärast seda, ei saa mingit kirjet selles väljas. Kuid niipea, kui esimene ootaja lahkub, saavad kõik, kes sel hetkel ootasid enne uuendust, sama märgise. Ja seetõttu arvan, et see on tehtud, et saaksime järjest töödelda, et nad oleksid õigesti järjekorras.

Olen alati vaadanud seda kui üsna kummalist nähtust. Sest siin, näiteks, me ei loetle neid üldse. Kuid mulle tundub, et iga kord, kui anname uue lukustuse, vaatame kõiki neid, kes ootamisprotsessis on. Siis joondame nad kõik järjekorda. Ja siis pääseb iga uus, kes saabub, järjekorda alles siis, kui järgmine inimene on lõpetanud. Väga hea küsimus. Aitäh teile küsimuse eest!

Mulle tundub, et on palju loogilisem, kui 705 ootab 704.

Kuid probleem on järgmine. Tehniliselt saate äratada kas seda või seda. Ja seetõttu äratame kas ühe või teise. Aga mis toimub süsteemi töös? Näete, kuidas 703 ülal blokeeris oma tehingu ID. See on see, kuidas Postgres töötab. Ja 703 on blokeeritud oma tehingu ID tõttu, seega, kui keegi tahab oodata, siis ta ootab 703. Ja põhimõtteliselt lõpetab 703. Ja alles pärast selle lõpetamist äratatakse mõni protsess. Me ei tea, milline täpselt see protsess olema saab. Seejärel töötleme järk-järgult kõik. Kuid pole selge, milline protsess esimesena äratatakse, sest see võib olla ükskõik milline neist protsessidest. Põhimõtteliselt oli meil ajakava, mis ütles, et me võime nüüd äratada ükskõik millise neist protsessidest. Me valime lihtsalt ühe juhuslikult. Seetõttu tuleb mõlemad märgistada, sest me võime äratada ükskõik millise neist.

Probleem on selles, et meil on CP-lõpmatus. Seetõttu on üsna tõenäoline, et saame äratada hilisema. Ja kui me näiteks äratame hilisema, siis me ootame seda, kes just sai lukustuse. Seetõttu me ei määra, kes esimesena äratatakse. Loome lihtsalt sellise olukorra ja süsteem äratab neid juhuslikus järjekorras.

On Egor Rogovi lukustusartiklid. Vaadake, need on samuti huvitavad ja kasulikud. Teema on muidugi ulme keeruline. Suur tänu, Bruce!

Allikas: habr.com