Transkrip wicara Bruce Momjian 2020 "Mbukak Kunci Manajer Kunci Postgres".
(Cathetan: Kabeh pitakon SQL saka slide bisa dipikolehi saka tautan iki: )
Hello! Apik banget yen ana ing Rusia maneh. Nyuwun sewu taun kepungkur ora bisa teka, nanging taun iki aku lan Ivan duwe rencana gedhe. Muga-muga bisa luwih kerep ana ing kene. Aku seneng teka ing Rusia. Aku bakal ngunjungi Tyumen, Tver. Aku bungah banget yen aku bisa ngunjungi kutha-kutha kasebut.
Jenengku Bruce Momjian. Aku kerja ing EnterpriseDB lan wis kerja karo Postgres luwih saka 23 taun. Aku manggon ing Philadelphia, USA. Aku lelungan udakara 90 dina saben taun. Lan aku melu udakara 40 konferensi. Kula , sing ngemot slide sing saiki bakal daktuduhake. Mulane, sawise konferensi sampeyan bisa ngundhuh saka situs web pribadiku. Uga ngemot babagan 30 presentasi. Ana uga video lan akeh entri blog, luwih saka 500. Iki minangka sumber sing cukup informatif. Lan yen sampeyan kasengsem ing materi iki, aku ngajak sampeyan nggunakake.
Aku biyen dadi guru, profesor sadurunge miwiti nggarap Postgres. Lan aku bungah banget yen aku saiki bakal bisa ngandhani apa sing bakal dakkandhakake. Iki minangka salah sawijining presentasi sing paling menarik. Lan presentasi iki ngemot 110 slide. Kita bakal miwiti ngomong kanthi prasaja, lan ing pungkasan laporan bakal dadi luwih rumit, lan bakal dadi cukup rumit.
Iki obrolan sing rada ora nyenengake. Pamblokiran dudu subyek sing paling populer. Kita pengin iki ilang nang endi wae. Kaya arep menyang dokter gigi.
- Ngunci minangka masalah kanggo akeh wong sing kerja ing basis data lan duwe pirang-pirang proses sing mlaku bebarengan. Dheweke butuh pamblokiran. Yaiku, dina iki aku bakal menehi kawruh dhasar babagan pamblokiran.
- ID Transaksi. Iki minangka bagean presentasi sing rada mboseni, nanging kudu dingerteni.
- Sabanjure kita bakal ngomong babagan jinis pamblokiran. Iki minangka bagean sing cukup mekanik.
- Lan ing ngisor iki kita bakal menehi sawetara conto pamblokiran. Lan bakal angel dingerteni.
Ayo dadi pirembagan bab pamblokiran.
Terminologi kita cukup rumit. Pira sampeyan ngerti saka ngendi asale wacana iki? wong loro. Iki saka game disebut Colossal Cave Adventure. Iku game komputer basis teks ing 80s, Aku. Ana sampeyan kudu mlebu guwa, menyang labirin, lan teks diganti, nanging isine kira-kira padha saben wektu. Sing carane aku elinga game iki.
Lan ing kene kita ndeleng jeneng kunci sing teka saka Oracle. Kita nggunakake.
Ing kene kita ndeleng istilah sing mbingungake aku. Contone, SHARE UPDATE ECXLUSIVE. Sabanjure SHARE RAW ECXLUSIVE. Jujur, jeneng-jeneng iki ora pati jelas. Kita bakal nyoba nimbang kanthi luwih rinci. Sawetara ngemot tembung "share", sing tegese misahake. Sawetara ngemot tembung "eksklusif". Sawetara ngemot loro tembung kasebut. Aku pengin miwiti karo carane kunci iki bisa digunakake.
Lan tembung "akses" uga penting banget. Lan tembung "baris" minangka senar. Yaiku, distribusi akses, distribusi baris.
Masalah liyane sing kudu dimangerteni ing Postgres, sing sayangΓ© ora bakal bisa dibahas ing obrolanku, yaiku MVCC. Aku duwe presentasi kapisah babagan topik iki ing situs webku. Lan yen sampeyan mikir presentation iki hard, MVCC mbokmenawa sandi paling angel. Lan yen sampeyan kasengsem, sampeyan bisa nonton ing situs web. Sampeyan bisa nonton video.
Bab liya sing kudu dingerteni yaiku ID transaksi. Akeh transaksi ora bisa mlaku tanpa pengenal unik. Lan ing kene kita duwe panjelasan babagan transaksi kasebut. Postgres duwe rong sistem penomoran transaksi. Aku ngerti iki dudu solusi sing apik banget.
Uga elinga yen slide kasebut bakal angel dimangerteni, mula sing disorot kanthi warna abang yaiku sing kudu digatekake.
Ayo ndeleng. Nomer transaksi disorot abang. Fungsi SELECT pg_back ditampilake ing kene. Iki ngasilake transaksi lan ID transaksi.
Siji liyane, yen sampeyan seneng presentasi iki lan pengin mbukak ing database, sampeyan bisa pindhah menyang link iki ing jambon lan download SQL kanggo presentation iki. Lan sampeyan mung bisa mbukak ing PSQL lan kabeh presentation bakal langsung ing layar. Ora bakal ngemot kembang, nanging paling ora kita bisa ndeleng.
Ing kasus iki kita ndeleng ID transaksi. Iki nomer sing diwenehake dheweke. Lan ana jinis ID transaksi liyane ing Postgres, sing diarani ID transaksi virtual
Lan kita kudu ngerti iki. Iki penting banget, yen ora, kita ora bakal bisa ngerti ngunci ing Postgres.
ID transaksi virtual minangka ID transaksi sing ora ngemot nilai sing terus-terusan. Contone, yen aku mbukak printah SELECT, banjur aku paling kamungkinan ora ngganti database, Aku ora bakal ngunci apa-apa. Dadi nalika kita mbukak PILIH prasaja, kita ora menehi transaksi sing ID terus-terusan. Kita mung menehi dheweke ID virtual ing kana.
Lan iki nambah kinerja Postgres, nambah kapabilitas ngresiki, supaya ID transaksi virtual kasusun saka rong nomer. Nomer pisanan sadurunge garis miring yaiku ID backend. Lan ing sisih tengen kita ndeleng mung counter.
Dadi, yen aku njaluk panjaluk, ujar manawa ID backend yaiku 2.
Lan yen aku mbukak seri transaksi kasebut, banjur kita weruh yen counter mundhak saben-saben aku mbukak pitakonan. Contone, nalika aku mbukak query 2/10, 2/11, 2/12, etc.
Elinga yen ana rong kolom ing kene. Ing sisih kiwa kita ndeleng ID transaksi virtual - 2/12. Lan ing sisih tengen kita duwe ID transaksi permanen. Lan lapangan iki kosong. Lan transaksi iki ora ngowahi database. Dadi aku ora menehi ID transaksi permanen.
Sanalika aku mbukak printah analisis ((ANALYZE)), pitakonan padha menehi ID transaksi permanen. Delengen carane iki wis diganti kanggo kita. Aku ora duwe ID iki sadurunge, nanging saiki aku duwe.
Dadi iki panjalukan liyane, transaksi liyane. Nomer transaksi virtual yaiku 2/13. Lan yen aku njaluk ID transaksi sing terus-terusan, banjur nalika aku mbukak pitakon, aku bakal entuk.
Dadi, sepisan maneh. Kita duwe ID transaksi virtual lan ID transaksi sing terus-terusan. Cukup ngerti titik iki kanggo ngerti prilaku Postgres.
Kita pindhah menyang bagean katelu. Ing kene kita bakal mlaku liwat macem-macem jinis kunci ing Postgres. Iku ora menarik banget. Bagian pungkasan bakal luwih menarik. Nanging kita kudu nimbang perkara dhasar, amarga yen ora, kita ora bakal ngerti apa sing bakal kelakon sabanjure.
Kita bakal ngliwati bagean iki, kita bakal ndeleng saben jinis kunci. Lan aku bakal nuduhake sampeyan conto carane diinstal, cara kerjane, aku bakal nuduhake sawetara pitakon sing bisa digunakake kanggo ndeleng cara ngunci ing Postgres.
Kanggo nggawe pitakon lan ndeleng apa sing kedadeyan ing Postgres, kita kudu ngetokake pitakon ing tampilan sistem. Ing kasus iki, pg_lock disorot abang. Pg_lock minangka tabel sistem sing ngandhani apa kunci sing saiki digunakake ing Postgres.
Nanging, angel banget kanggo aku nuduhake sampeyan pg_lock dhewe amarga cukup rumit. Dadi aku nggawe tampilan sing nuduhake pg_locks. Lan uga nindakake sawetara karya kanggo aku sing ngidini aku luwih ngerti. Yaiku, ora kalebu kunciku, sesiku dhewe, lsp. Iku mung SQL standar lan ngidini sampeyan nuduhake apa sing kedadeyan.
Masalah liyane yaiku tampilan iki amba banget, mula aku kudu nggawe sing kapindho - lockview2.
Lan nuduhake kula liyane kolom saka meja. Lan siji liyane sing nuduhake kula liyane saka kolom. Iki cukup rumit, mula aku nyoba nampilake kanthi gampang.
Dadi, kita nggawe tabel sing diarani Lockdemo. Lan kita nggawe siji baris ana. Iki tabel sampel kita. Lan kita bakal nggawe bagean mung kanggo nuduhake conto kunci.
Dadi, siji baris, siji kolom. Jinis kunci pisanan diarani ACCESS SHARE. Iki minangka pamblokiran sing paling ora mbatesi. Iki tegese praktis ora konflik karo kunci liyane.
Lan yen kita pengin tegas nemtokake kunci, kita mbukak printah "meja kunci". Lan temenan bakal mblokir, yaiku ing mode ACCESS SHARE kita miwiti meja kunci. Lan yen aku mbukak PSQL ing latar mburi, banjur aku miwiti sesi kapindho saka sesi pisanan cara iki. Yaiku, apa sing bakal daklakoni ing kene? Aku menyang sesi liyane lan marang iku "nuduhake kula lockview kanggo panjalukan iki." Lan ing kene aku duwe AccessShareLock ing tabel iki. Iki persis sing dakjaluk. Lan ngandika sing pemblokiran wis diutus. Prasaja banget.
Salajengipun, yen kita ndeleng kolom kapindho, banjur ora ana apa-apa. Padha kosong.
Lan yen aku mbukak printah "PILIH", banjur iki cara implisit (eksplisit) kanggo njaluk AccessShareLock. Dadi aku ngeculake tabel lan mbukak pitakon lan pitakon ngasilake pirang-pirang baris. Lan ing salah sawijining garis kita ndeleng AccessShareLock. Mangkono, SELECT nelpon AccessShareLock ing meja. Lan ora konflik karo apa wae amarga iki minangka kunci tingkat rendah.
Apa yen aku mbukak PILIH lan duwe telung tabel beda? Sadurunge aku mung mbukak siji meja, saiki aku mlaku telung: pg_class, pg_namespace lan pg_attribute.
Lan saiki nalika ndeleng pitakon, aku ndeleng 9 AccessShareLocks ing telung tabel. Kenging punapa? Telung tabel disorot biru: pg_attribute, pg_class, pg_namespace. Nanging sampeyan uga bisa ndeleng manawa kabeh indeks sing ditetepake liwat tabel kasebut uga duwe AccessShareLock.
Lan iki minangka kunci sing praktis ora konflik karo wong liya. Lan kabeh sing ditindakake mung nyegah kita ngreset tabel nalika kita milih. Iku ndadekake pangertèn. Sing, yen kita milih Tabel, iku ilang ing wayahe, banjur iki salah, supaya AccessShare minangka kunci tingkat rendah sing ngandhani "aja nyelehake meja iki nalika aku kerja". Ateges, mung kuwi sing ditindakake.
ROW SHARE - Kunci iki rada beda.
Ayo dadi conto. PILIH ROW SHARE cara ngunci saben baris individu. Kanthi cara iki ora ana sing bisa mbusak utawa ngganti nalika kita nonton.
Dadi apa fungsi SHARE LOCK? Kita weruh yen ID transaksi yaiku 681 kanggo SELECT. Lan iki menarik. Apa sing kedadeyan ing kene? Sepisanan kita ndeleng nomer kasebut ing kolom "Kunci". We njupuk ID transaksi lan ngandika iku mblokir ing mode eksklusif. Kabeh iku ngandika aku duwe larik sing teknis dikunci nang endi wae ing meja. Nanging dheweke ora ngandhani ngendi persis. Kita bakal nliti iki kanthi luwih rinci mengko.
Ing kene kita ngomong yen kunci digunakake dening kita.
Dadi, kunci eksklusif kanthi tegas nyatakake yen iku eksklusif. Lan uga yen sampeyan mbusak baris ing tabel iki, banjur iki bakal kelakon, minangka sampeyan bisa ndeleng.
SHARE EXCLUSIVE minangka kunci sing luwih dawa.
Iki minangka perintah analisa (ANALYZE) sing bakal digunakake.
KUNCI SHARE - sampeyan bisa ngunci kanthi jelas ing mode bareng.
Sampeyan uga bisa nggawe indeks unik. Lan ing kana sampeyan bisa ndeleng KUNCI SHARE, yaiku bagean saka dheweke. Lan ngunci meja lan sijine KUNCI SHARE ing.
Kanthi gawan, SHARE LOCK ing meja tegese wong liya bisa maca tabel kasebut, nanging ora ana sing bisa ngowahi. Lan iki persis apa sing kedadeyan nalika sampeyan nggawe indeks unik.
Yen aku nggawe indeks bebarengan sing unik, aku bakal duwe jinis ngunci sing beda amarga, sing sampeyan elinga, nggunakake indeks bebarengan nyuda syarat ngunci. Lan yen aku nggunakake kunci normal, indeks normal, banjur aku bakal nyegah nulis kanggo indeks meja nalika lagi digawe. Yen aku nggunakake indeks bebarengan, aku kudu nggunakake macem-macem jinis ngunci.
SHARE ROW EXCLUSIVE - maneh bisa disetel kanthi jelas (jelas).
Utawa kita bisa nggawe aturan, yaiku, njupuk kasus tartamtu sing bakal digunakake.
Ngunci EKSKLUSIF tegese ora ana wong liya sing bisa ngganti meja.
Ing kene kita ndeleng macem-macem jinis kunci.
ACCESS EXCLUSIVE, contone, minangka perintah pamblokiran. Contone, yen sampeyan nindakake CLUSTER table, banjur iki tegese ora ana sing bisa nulis ing kana. Lan ngunci ora mung meja dhewe, nanging uga indeks.
Iki minangka kaca kapindho pamblokiran ACCESS EXCLUSIVE, ing ngendi kita bisa ndeleng persis apa sing diblokir ing tabel. Ngunci larik meja individu, sing cukup menarik.
Iku kabeh informasi dhasar aku wanted kanggo menehi. Kita ngomong babagan kunci, babagan ID transaksi, kita ngomong babagan ID transaksi virtual, babagan ID transaksi permanen.
Lan saiki kita bakal ngliwati sawetara conto pamblokiran. Iki minangka bagΓ©an sing paling menarik. Kita bakal nliti kasus sing menarik banget. Lan tujuanku ing presentasi iki yaiku kanggo menehi pangerten sing luwih apik babagan apa sing ditindakake Postgres nalika nyoba ngalangi sawetara perkara. Aku rumangsa apik banget kanggo ngalangi bagean.
Ayo katon ing sawetara conto tartamtu.
Kita bakal miwiti karo tabel lan siji baris ing meja. Nalika aku masang soko aku ExclusiveLock, ID Transaksi lan ExclusiveLock ditampilake ing meja.
Apa sing kedadeyan yen aku nglebokake rong larik maneh? Lan saiki meja kita wis telung larik. Lan aku nglebokake siji baris lan entuk iki minangka output. Lan yen aku nglebokake rong larik maneh, apa sing aneh? Ana bab aneh kene amarga aku wis nambah telung larik kanggo meja iki, nanging aku isih duwe rong larik ing meja kunci. Lan iki ateges prilaku dhasar Postgres.
Akeh wong sing mikir yen ing database sampeyan ngunci 100 larik, mula sampeyan kudu nggawe 100 entri kunci. Yen aku mblokir 1 baris bebarengan, aku bakal mbutuhake 000 pitakon kasebut. Lan yen aku butuh yuta utawa milyar kanggo mblokir. Nanging yen kita nindakake iki, iku ora bakal bisa banget. Yen sampeyan wis nggunakake sistem sing nggawe entri pamblokiran kanggo saben baris individu, sampeyan bisa ndeleng manawa iki rumit. Amarga sampeyan kudu langsung nemtokake tabel kunci sing bisa kebanjiran, nanging Postgres ora nindakake.
Lan sing paling penting babagan slide iki yaiku kanthi jelas nuduhake manawa ana sistem liyane sing mlaku ing MVCC sing ngunci baris individu. Dadi yen sampeyan ngunci milyaran baris, Postgres ora nggawe milyaran perintah ngunci sing kapisah. Lan iki nduwe pengaruh apik banget ing produktivitas.
Kepiye babagan nganyari? Aku nganyari baris saiki, lan sampeyan bisa ndeleng sing wis nindakake rong operasi beda bebarengan. Iku ngunci meja ing wektu sing padha, nanging uga ngunci indeks. Lan dheweke kudu ngunci indeks amarga ana kendala unik ing meja iki. Lan kita pengin nggawe manawa ora ana sing ngganti, mula kita mblokir.
Apa sing kedadeyan yen aku pengin nganyari rong baris? Lan kita weruh yen dheweke tumindak kanthi cara sing padha. Kita nindakake kaping pindho minangka akeh nganyari, nanging persis padha nomer garis kunci.
Yen sampeyan kepingin weruh kepiye Postgres nindakake iki, sampeyan kudu ngrungokake omonganku ing MVCC kanggo mangerteni carane Postgres menehi tandha internal yen garis kasebut diganti. Lan Postgres wis cara kang nindakake iki, nanging ora nindakake ing tingkat ngunci meja, iku ing tingkat ngisor lan luwih efisien.
Apa yen aku pengin mbusak soko? Yen aku mbusak, contone, siji baris lan aku isih duwe loro input Watesan sandi, lan malah yen aku pengin mbusak kabeh, padha isih ana.
Lan, contone, aku pengin nglebokake 1 garis, lan banjur mbusak utawa nambah 000 baris, banjur sing garis individu sing aku nambah utawa ngganti, padha ora direkam ing kene. Dheweke ditulis ing tingkat ngisor ing seri kasebut. Lan sajrone pidato MVCC aku ngomong babagan iki kanthi rinci. Nanging penting banget nalika sampeyan nganalisa kunci kanggo mesthekake yen sampeyan ngunci ing tingkat meja lan sampeyan ora weruh carane saben baris direkam ing kene.
Apa babagan pamblokiran eksplisit?
Yen aku klik refresh, aku duwe rong larik dikunci. Lan yen aku milih kabeh lan klik "nganyari nang endi wae," banjur aku isih duwe rong cathetan pamblokiran.
Kita ora nggawe rekaman kapisah kanggo saben baris individu. Amarga banjur produktivitas mudhun, bisa uga akeh banget. Lan kita bisa nemokake awake dhewe ing kahanan sing ora nyenengake.
Lan bab sing padha, yen kita nuduhake, kita bisa nindakake kabeh kaping 30.
Kita mulihake tabel, mbusak kabeh, banjur lebokake siji baris maneh.
Prilaku liyane sing ndeleng ing Postgres sing banget kondhang lan prilaku dikarepake iku sampeyan bisa nindakake nganyari utawa pilih. Lan sampeyan bisa nindakake iki ing wektu sing padha. Lan pilih ora mblokir nganyari lan bab sing padha ing arah ngelawan. Kita ngandhani maca supaya ora ngalangi panulis, lan panulis ora ngalangi sing maca.
Aku bakal nuduhake sampeyan conto iki. Aku bakal nggawe pilihan saiki. Banjur kita bakal nindakake INSERT. Banjur sampeyan bisa ndeleng - 694. Sampeyan bisa ndeleng ID transaksi sing nindakake sisipan iki. Lan cara kerjane.
Lan yen aku ndeleng ID backend saiki, saiki dadi 695.
Lan aku bisa ndeleng 695 katon ing mejaku.
Lan yen aku nganyari kene kaya iki, banjur aku njaluk kasus liyane. Ing kasus iki, 695 minangka kunci eksklusif, lan nganyari nduweni prilaku sing padha, nanging ora ana konflik ing antarane, sing ora biasa.
Lan sampeyan bisa ndeleng manawa ing sisih ndhuwur yaiku ShareLock, lan ing sisih ngisor ExclusiveLock. Lan loro transaksi bisa metu.
Lan sampeyan kudu ngrungokake omonganku ing MVCC kanggo ngerti kepiye kedadeyan kasebut. Nanging iki minangka ilustrasi sing bisa ditindakake bebarengan, yaiku nindakake PILIH lan UPDATE bebarengan.
Ayo ngreset lan nindakake siji operasi maneh.
Yen sampeyan nyoba mbukak rong nganyari bebarengan ing baris sing padha, bakal diblokir. Lan elinga, Aku ngandika sing maca ora ngalangi penulis, lan penulis ora ngalangi maca, nanging siji penulis ngalangi penulis liyane. Sing, kita ora bisa duwe wong loro nganyari baris padha ing wektu sing padha. Sampeyan kudu ngenteni nganti salah sijine rampung.
Lan kanggo ilustrasi iki, aku bakal katon ing meja Lockdemo. Lan kita bakal ndeleng siji baris. Saben transaksi 698.
Kita wis nganyari iki kanggo 2. 699 minangka nganyari pisanan. Lan sukses utawa ana ing transaksi sing ditundha lan nunggu kita konfirmasi utawa mbatalake.
Nanging deleng liyane - 2/51 minangka transaksi pertama kita, sesi pertama kita. 3/112 minangka panyuwunan kapindho sing teka saka ndhuwur sing ngganti nilai kasebut dadi 3. Lan yen sampeyan ngelingi, sing paling dhuwur ngunci dhewe, yaiku 699. Nanging 3/112 ora menehi kunci. Kolom Lock_mode ngandika apa sing nunggu. Iku nyana 699. Lan yen katon ing ngendi 699 punika, iku luwih dhuwur. Lan apa sing ditindakake ing sesi pisanan? Dheweke nggawe kunci eksklusif ing ID transaksi dhewe. Iki carane Postgres nindakake. Iki mblokir ID transaksi dhewe. Lan yen sampeyan pengin ngenteni wong konfirmasi utawa mbatalake, sampeyan kudu ngenteni nalika ana transaksi sing ditundha. Lan mulane kita bisa ndeleng garis aneh.
Ayo dideleng maneh. Ing sisih kiwa kita ndeleng ID pangolahan. Ing kolom kapindho kita ndeleng ID transaksi virtual kita, lan ing katelu kita ndeleng lock_type. Apa tegese iki? Ateges apa sing dikandhakake yaiku mblokir ID transaksi. Nanging sok dong mirsani sing kabeh larik ing ngisor ngandika hubungan. Lan sampeyan duwe rong jinis kunci ing meja. Ana kunci hubungan. Lan banjur ana pamblokiran transactionid, ing ngendi sampeyan mblokir dhewe, yaiku apa sing kedadeyan ing baris pisanan utawa ing sisih ngisor, ing ngendi transactionid, ing ngendi kita ngenteni 699 rampung operasi.
Aku bakal weruh apa sing kedadeyan ing kene. Lan ing kene ana rong perkara sing kedadeyan bebarengan. Sampeyan lagi ndeleng kunci ID transaksi ing baris pisanan sing ngunci dhewe. Lan dheweke mblokir awake dhewe kanggo nggawe wong ngenteni.
Yen katon ing baris 6, iku entri padha karo pisanan. Lan mulane transaksi 699 diblokir. 700 uga ngunci dhewe. Banjur ing baris ngisor sampeyan bakal weruh yen kita ngenteni 699 rampung operasi.
Lan ing lock_type, tuple sampeyan ndeleng nomer.
Sampeyan bisa ndeleng iku 0/10. Lan iki nomer kaca, lan uga ngimbangi baris tartamtu iki.
Lan sampeyan ndeleng iku dadi 0/11 nalika kita nganyari.
Nanging ing kasunyatan iku 0/10, amarga ana ngenteni operasi iki. Kita duwe kesempatan kanggo ndeleng manawa iki seri sing aku ngenteni konfirmasi.
Sawise kita wis dikonfirmasi lan menet tundhuk, lan nalika nganyari wis rampung, iki apa kita njaluk maneh. Transaksi 700 mung kunci, ora ngenteni wong liya amarga wis setya. Iku mung ngenteni transaksi rampung. Sawise 699 entek, kita ora ngenteni apa-apa maneh. Lan saiki transaksi 700 ngandika sing kabeh iku nggoleki, sing wis kabeh kunci perlu ing kabeh tabel diijini.
Lan supaya kabeh iki luwih rumit, kita nggawe tampilan liyane, sing wektu iki bakal menehi hierarki. Aku ora nyana sampeyan ngerti panjaluk iki. Nanging iki bakal menehi kita tampilan sing luwih jelas babagan apa sing kedadeyan.
Iki minangka tampilan rekursif sing uga duwe bagean liyane. Lan banjur ndadekke kabeh bali bebarengan maneh. Ayo nganggo iki.
Apa yen kita nindakake telung nganyari bebarengan lan ujar manawa baris kasebut saiki dadi telung. Lan kita bakal ngganti 3 dadi 4.
Lan ing kene kita ndeleng 4. Lan ID transaksi 702.
Banjur aku bakal ngganti 4 kanggo 5. Lan 5 kanggo 6, lan 6 kanggo 7. Lan aku bakal baris munggah sawetara wong sing bakal ngenteni kanggo transaksi siji iki rampung.
Lan kabeh dadi cetha. Apa baris pisanan? Iki 702. Iki ID transaksi sing asline nyetel nilai iki. Apa sing ditulis ing kolom Diwenehake? Aku duwe tandha f. Iki minangka nganyari sing (5, 6, 7) ora bisa disetujoni amarga kita ngenteni ID transaksi 702 rampung. Ing kana kita duwe pamblokiran ID transaksi. Lan iki nyebabake 5 kunci ID transaksional.
Lan yen sampeyan ndeleng 704, ing 705, durung ana sing ditulis, amarga dheweke durung ngerti apa sing kedadeyan. Dheweke mung nulis yen dheweke ora ngerti apa sing kedadeyan. Lan dheweke mung bakal turu amarga ngenteni wong rampung lan bakal tangi nalika ana kesempatan kanggo ngganti baris.
Iki kaya apa. Sing jelas kabeh padha ngenteni baris 12.
Iki sing kita deleng ing kene. Iki 0/12.
Dadi yen transaksi pisanan disetujoni, sampeyan bisa ndeleng ing kene kepiye hirarki kasebut. Lan saiki kabeh dadi cetha. Kabeh mau dadi resik. Lan sejatine dheweke isih ngenteni.
Mangkene kedadeyane. 702 prasetya. Lan saiki 703 entuk kunci baris iki, banjur 704 wiwit ngenteni 703 komitmen. Lan 705 uga nunggu iki. Lan nalika kabeh iki rampung, padha ngresiki awake dhewe. Lan aku pengin nuduhake yen kabeh wong wis antri. Lan iki meh padha karo kahanan macet nalika kabeh wong nunggu mobil pisanan. Mobil pisanan mandheg lan kabeh wong baris ing baris dawa. Banjur obah, banjur mobil sabanjurΓ© bisa maju lan njaluk blok sawijining, etc.
Lan yen iki ora katon cukup rumit kanggo sampeyan, saiki kita bakal ngomong karo sampeyan babagan deadlocks. Aku ora ngerti sapa sing nemoni wong-wong mau. Iki minangka masalah sing cukup umum ing sistem database. Nanging deadlocks nalika siji sesi nunggu sesi liyane kanggo nindakake soko. Lan ing wayahe iki sesi liyane nunggu sesi pisanan kanggo nindakake soko.
Lan, contone, yen Ivan kandha: "Wenehana aku soko," lan aku kandha: "Ora, aku mung bakal menehi sampeyan yen sampeyan menehi kula soko liyane." Lan ngandika, "Ora, aku ora bakal menehi sampeyan yen sampeyan ora menehi kula." Lan kita mungkasi ing kahanan deadlock. Aku yakin yen Ivan ora bakal nindakake iki, nanging sampeyan ngerti tegese kita duwe wong loro sing pengin entuk apa-apa lan dheweke ora siap menehi nganti wong liya menehi apa sing dikarepake. Lan ora ana solusi.
Lan ateges, database sampeyan kudu ndeteksi iki. Banjur sampeyan kudu mbusak utawa nutup salah sawijining sesi, amarga yen ora bakal tetep ana ing salawas-lawase. Lan kita ndeleng ing database, kita ndeleng ing sistem operasi. Lan ing kabeh panggonan sing ana proses paralel, iki bisa kedadeyan.
Lan saiki kita bakal nginstal loro deadlocks. Kita bakal nyelehake 50 lan 80. Ing baris pisanan, aku bakal nganyari saka 50 dadi 50. Aku bakal entuk nomer transaksi 710.
Banjur aku bakal ngganti 80 dadi 81, lan 50 dadi 51.
Lan iki bakal katon kaya. Dadi 710 duwe baris diblokir, lan 711 nunggu konfirmasi. Kita weruh iki nalika kita nganyari. 710 minangka pemilik saka seri kita. Lan 711 ngenteni 710 kanggo ngrampungake transaksi kasebut.
Lan malah ngandika ing baris kang deadlocks dumadi. Lan ing kene wiwit aneh.
Saiki kita nganyari 80 nganti 80.
Lan iki ngendi deadlocks diwiwiti. 710 ngenteni respon saka 711, lan 711 ngenteni 710. Lan iki ora bakal rampung kanthi apik. Lan ora ana cara metu saka iki. Lan dheweke bakal ngarepake tanggapan saka saben liyane.
Lan mung bakal miwiti tundha kabeh. Lan kita ora pengin.
Lan Postgres duwe cara kanggo sok dong mirsani nalika kedadeyan kasebut. Lan nalika iki kedaden, sampeyan njaluk kesalahan iki. Lan saka iki cetha yen proses kasebut lan iki nunggu KUNCI SHARE saka proses liyane, yaiku, sing diblokir dening proses 711. Lan proses kasebut ngenteni KUNCI SHARE diwenehi ing ID transaksi kasebut lan diblokir dening proses kasebut. Mulane, ana kahanan buntu ing kene.
Apa ana deadlock telung arah? Apa bisa? ya wis.
Kita ngetik angka kasebut menyang meja. Kita ngganti 40 dadi 40, kita mblokir.
Kita ngganti 60 dadi 61, 80 dadi 81.
Banjur kita ngganti 80 lan banjur boom!
Lan 714 saiki ngenteni 715. 716 ngenteni 715. Lan ora ana sing bisa ditindakake.
Ora ana wong loro maneh, wis ana wong telu. Aku njaluk soko saka sampeyan, siji iki pengin soko saka wong katelu, lan wong katelu pengin soko saka kula. Lan kita pungkasane ngenteni telung arah amarga kita kabeh ngenteni wong liya ngrampungake apa sing kudu ditindakake.
Lan Postgres ngerti ing baris endi iki kedadeyan. Lan bakal menehi pesen ing ngisor iki, sing nuduhake yen sampeyan duwe masalah ing ngendi telung input mblokir saben liyane. Lan ora ana watesan ing kene. Iki bisa uga ana 20 entri mblokir saben liyane.
Masalah sabanjure yaiku serializable.
Yen kunci serializable khusus.
Lan kita bali menyang 719. Outpute cukup normal.
Lan sampeyan bisa klik kanggo nggawe transaksi saka serializable.
Lan sampeyan ngerti yen sampeyan saiki duwe macem-macem kunci SA - tegese bisa serial.
Dadi, kita duwe jinis kunci anyar sing diarani SARieadLock, yaiku kunci serial lan ngidini sampeyan ngetik serial.
Lan uga sampeyan bisa nglebokake indeks unik.
Ing tabel iki kita duwe indeks unik.
Dadi yen aku sijine ing nomer 2 kene, supaya aku duwe 2. Nanging ing ndhuwur banget, aku sijine liyane 2 lan sampeyan bisa ndeleng sing 721 wis kunci eksklusif. Nanging saiki 722 ngenteni 721 kanggo ngrampungake operasi amarga ora bisa nglebokake 2 nganti ngerti apa sing bakal kelakon ing 721.
Lan yen kita nindakake subtransaksi.
Ing kene kita duwe 723.
Lan yen kita nyimpen titik banjur nganyari, banjur entuk ID transaksi anyar. Iki minangka pola prilaku liyane sing kudu dingerteni. Yen kita bali iki, banjur ID transaksi ilang. 724 godhong. Nanging saiki duwe 725.
Dadi apa aku nyoba kanggo nindakake kene? Aku nyoba kanggo nuduhake conto kunci mboten umum sing sampeyan bisa nemokake: apa iku kunci serializable utawa SAVEPOINT, iki macem-macem jinis kunci sing bakal katon ing meja kunci.
Iki nggawe kunci eksplisit (eksplisit), sing duwe pg_advisory_lock.
Lan sampeyan ndeleng manawa jinis pamblokiran kadhaptar minangka saran. Lan kene ngandika "penasehat" ing abang. Lan sampeyan bisa bebarengan mblokir kaya iki karo pg_advisory_unlock.
Lan ing kesimpulan, aku pengin nuduhake sampeyan siji bab liyane sing nyenengake. Aku bakal nggawe tampilan liyane. Nanging aku bakal nggabungake tabel pg_locks karo tabel pg_stat_activity. Lan kenapa aku pengin nindakake iki? Amarga iki bakal ngidini kula kanggo ndeleng lan ndeleng kabeh sesi saiki lan ndeleng persis apa jenis kunci lagi nunggu. Lan iki cukup menarik nalika kita nggabungake tabel kunci lan tabel pitakon.
Lan ing kene kita nggawe pg_stat_view.
Lan kita nganyari baris siji. Lan ing kene kita ndeleng 724. Banjur kita nganyari baris dadi telu. Lan apa sing sampeyan deleng ing kene saiki? Iki minangka panjaluk, yaiku sampeyan ndeleng kabeh dhaptar panjaluk sing didaftar ing kolom kiwa. Banjur ing sisih tengen sampeyan bisa ndeleng pamblokiran lan apa sing digawe. Lan bisa dadi luwih cetha kanggo sampeyan supaya sampeyan ora kudu bali menyang saben sesi saben wektu lan ndeleng apa sampeyan kudu melu utawa ora. Padha nindakake kanggo kita.
Fitur liyane sing migunani banget yaiku pg_blocking_pids. Sampeyan mbokmenawa ora tau krungu bab dheweke. Dheweke lagi ngopo? Iku ngidini kita marang sing kanggo sesi iki 11740 apa ID proses tartamtu nunggu. Lan sampeyan bisa ndeleng sing 11740 nunggu 724. Lan 724 ing paling ndhuwur. Lan 11306 minangka ID proses sampeyan. Ateges, fungsi iki ngliwati meja kunci sampeyan. Lan aku ngerti iki rada rumit, nanging sampeyan bisa ngerti. Ateges fungsi iki liwat meja kunci iki lan nyoba kanggo nemokake ngendi ID proses iki diwenehi kunci sing nunggu ing. Lan uga nyoba kanggo mangerteni kang proses ID proses sing nunggu kunci wis. Supaya sampeyan bisa mbukak fungsi iki pg_blocking_pids.
Lan iki bisa migunani banget. Kita mung nambahake iki ing versi 9.6, mula fitur iki mung 5 taun, nanging migunani banget. Lan padha ditrapake kanggo request kapindho. Iku nuduhake persis apa kita kudu ndeleng.
Iki sing dakkarepake kanggo ngomong karo sampeyan. Lan kaya sing dakkarepake, kita nggunakake kabeh wektu amarga ana akeh slide. Lan minger kasedhiya kanggo download. Aku arep matur nuwun kanggo wis kene. Aku manawa sampeyan bakal seneng liyane saka konferensi, matur nuwun banget!
Pitakonan:
Contone, yen aku nyoba nganyari baris, lan sesi kapindho nyoba mbusak kabeh tabel. Satemene aku ngerti, kudu ana sing kaya kunci maksud. Apa ana sing kaya ngono ing Postgres?
Ayo bali menyang wiwitan. Sampeyan bisa uga ngelingi yen sampeyan nindakake apa wae, umpamane nalika sampeyan nindakake PILIH, kita ngetokake AccessShareLock. Lan iki ngalangi meja saka dropped. Dadi yen sampeyan, contone, pengin nganyari baris ing tabel utawa mbusak baris, banjur wong ora bisa mbusak kabeh tabel ing wektu sing padha amarga sampeyan nyekel AccessShareLock iki liwat kabeh meja lan liwat baris. Lan yen sampeyan wis rampung, padha bisa mbusak. Nanging nalika sampeyan langsung ngganti soko ana, padha ora bakal bisa nindakake iku.
Ayo dadi maneh. Ayo pindhah menyang conto mbusak. Lan sampeyan ndeleng carane ana kunci eksklusif ing baris ndhuwur kabeh meja.
Iki bakal katon kaya kunci eksklusif, ta?
Ya, katon kaya ngono. Aku ngerti apa sing sampeyan omongake. Sampeyan lagi ngomong yen aku nindakake SELECT banjur aku duwe ShareExclusive banjur aku nggawe Row Exclusive, apa sing dadi masalah? Nanging nggumunake iki ora nyebabake masalah. Iki katon kaya nambah gelar kunci, nanging ateges aku duwe kunci sing nyegah pambusakan. Lan saiki, nalika aku nggawe kunci iki luwih kuat, isih ngalangi pambusakan. Dadi ora kaya aku munggah. Tegese, nyegah kedadeyan kasebut nalika ana ing tingkat sing luwih murah, mula nalika aku mundhakake level kasebut, mula tabel kasebut ora bisa dibusak.
Aku ngerti apa sing sampeyan omongake. Ora ana kasus eskalasi kunci ing kene, ing ngendi sampeyan nyoba nyerahake siji kunci kanggo ngenalake sing luwih kuwat. Ing kene mung nambah pencegahan iki ing papan, saengga ora nyebabake konflik. Nanging pitakonan sing apik. Matur nuwun kanthi sanget kanggo takon iki!
Apa sing kudu kita lakoni kanggo ngindhari kahanan buntu nalika kita duwe akeh sesi, akeh pangguna?
Postgres kanthi otomatis ngerteni kahanan buntu. Lan bakal kanthi otomatis mbusak salah sawijining sesi. Cara mung kanggo nyegah pamblokiran mati yaiku mblokir wong kanthi urutan sing padha. Dadi yen sampeyan ndeleng aplikasi sampeyan, asring alesan kanggo deadlocks ... Coba bayangake yen aku pengin mblokir rong perkara sing beda. Siji aplikasi ngunci meja 1, lan aplikasi liyane ngunci 2, banjur tabel 1. Lan cara paling gampang kanggo nyegah deadlocks iku kanggo ndeleng aplikasi lan nyoba kanggo mesthekake yen penguncian dumadi ing urutan sing padha ing kabeh aplikasi. Lan iki biasane ngilangi 80% masalah, amarga kabeh jinis wong nulis aplikasi kasebut. Lan yen sampeyan mblokir kanthi urutan sing padha, sampeyan ora bakal nemoni kahanan buntu.
Matur nuwun kanthi sanget kanggo kinerja sampeyan! Sampeyan ngomong babagan vakum kebak lan, yen aku ngerti kanthi bener, vakum lengkap ngrusak urutan rekaman ing panyimpenan sing kapisah, supaya cathetan saiki ora owah. Napa vakum lengkap njupuk akses kunci eksklusif lan kenapa konflik karo operasi nulis?
Iku pitakonan sing apik. Alasane yaiku vakum kebak njupuk meja. Lan kita ateges nggawe versi anyar saka meja. Lan meja bakal anyar. Pranyata metu iki bakal dadi versi rampung anyar saka Tabel. Lan masalah iku nalika kita nindakake iki, kita ora pengin wong maca amarga kita kudu ndeleng tabel anyar. Dadi iki nyambung menyang pitakonan sadurunge. Yen kita bisa maca ing wektu sing padha, kita ora bakal bisa mindhah lan ngarahake wong menyang meja anyar. Kita kudu ngenteni kabeh wong rampung maca tabel iki, lan mulane pancen kahanan eksklusif kunci.
Kita mung ngomong yen kita ngunci saka wiwitan amarga kita ngerti yen ing pungkasan kita butuh kunci eksklusif kanggo mindhah kabeh wong menyang salinan anyar. Supaya kita duweni potensi bisa ngatasi iki. Lan kita nindakake kanthi cara iki kanthi indeksasi bebarengan. Nanging iki luwih angel ditindakake. Lan iki ana hubungane karo pitakonan sadurunge babagan kunci eksklusif.
Apa bisa nambah wektu entek kanggo Postgres? Ing Oracle, aku bisa, contone, nulis "pilih kanggo nganyari" lan ngenteni 50 detik sadurunge nganyari. Iku apik kanggo aplikasi. Nanging ing Postgres, aku kudu nindakake langsung lan ora ngenteni, utawa ngenteni nganti sawetara wektu.
Ya, sampeyan bisa milih wektu entek ing kunci sampeyan, ing kunci sampeyan. Sampeyan uga bisa ngetokake printah no way, sing bakal ... yen sampeyan ora bisa langsung entuk kunci. Mulane, salah siji wektu entek kunci utawa liya sing bakal ngidini sampeyan nindakake iki. Iki ora ditindakake ing tataran sintaksis. Iki rampung minangka variabel ing server. Kadhangkala iki ora bisa digunakake.
Sampeyan bisa mbukak slide 75?
Ya.
Lan pitakonanku ing ngisor iki. Napa loro pangolahan nganyari ngarepake 703?
Lan iki pitakonan gedhe. Aku ora ngerti, kok Postgres nindakake iki. Nanging nalika 703 digawe, wis dikarepake 702. Lan nalika 704 lan 705 katon, kayane ora ngerti apa sing dikarepake amarga durung ana apa-apa. Lan Postgres nindakake kanthi cara iki: nalika sampeyan ora bisa ngunci, dheweke nulis "Apa gunane ngolah sampeyan?", Amarga sampeyan wis ngenteni wong. Dadi kita mung bakal nggantung ing udhara, ora bakal nganyari kabeh. Nanging apa sing kedadeyan ing kene? Sanalika 702 ngrampungake proses kasebut lan 703 entuk kunci, sistem kasebut bali maneh. Lan dheweke kandha yen saiki ana wong loro sing nunggu. Banjur ayo padha nganyari bebarengan. Lan supaya kita nuduhake yen loro-lorone ngarepake.
Aku ora ngerti kenapa Postgres nindakake iki. Nanging ana masalah sing diarani fβ¦. Kayane aku iki dudu istilah ing basa Rusia. Iki nalika saben wong ngenteni siji kastil, sanajan ana 20 panguwasa sing nunggu kastil kasebut. Lan dumadakan kabeh padha tangi bebarengan. Lan kabeh wong wiwit nyoba nanggepi. Nanging sistem ndadekake supaya kabeh wong ngenteni 703. Amarga kabeh padha ngenteni, lan kita bakal langsung baris kabeh. Lan yen ana panjalukan anyar liyane sing muncul sawise iki, contone, 707, banjur bakal ana kekosongan maneh.
Lan misale jek aku iki wis rampung supaya kita bisa ngomong sing ing tataran iki 702 nunggu 703, lan kabeh sing teka sawise iku ora duwe entri ing lapangan iki. Nanging sanalika pelayan pisanan lunga, kabeh wong sing nunggu ing wayahe sadurunge nganyari nampa token sing padha. Lan aku mikir iki wis rampung supaya kita bisa proses supaya padha bener dhawuh.
Aku tansah nyawang iki minangka fenomena sing rada aneh. Amarga ing kene, contone, kita ora dhaptar kabeh. Nanging misale jek kula sing saben-saben kita menehi kunci anyar, kita katon ing kabeh sing ana ing proses nunggu. Banjur kita baris kabeh. Banjur sing anyar sing mlebu mung mlebu antrian nalika wong sabanjure wis rampung diproses. Pitakonan sing apik banget. Matur nuwun kanthi sanget kanggo pitakonan sampeyan!
Kayane aku luwih logis yen 705 ngarepake 704.
Nanging masalah ing kene yaiku ing ngisor iki. Secara teknis, sampeyan bisa tangi siji utawa liyane. Lan supaya kita bakal tangi siji utawa liyane. Nanging apa sing kedadeyan ing sistem kasebut? Sampeyan bisa ndeleng carane 703 ing paling ndhuwur wis mblokir ID transaksi dhewe. Iki cara kerjane Postgres. Lan 703 diblokir dening ID transaksi dhewe, dadi yen ana wong sing pengin ngenteni, banjur bakal ngenteni 703. Lan, intine, 703 rampung. Lan mung sawise rampung, salah sawijining proses tangi. Lan kita ora ngerti apa persis proses iki. Banjur kita proses kabeh kanthi bertahap. Nanging ora jelas proses endi sing luwih dhisik, amarga bisa uga ana proses kasebut. Ateges, kita duwe panjadwal sing ujar manawa saiki bisa tangi kabeh proses kasebut. Kita mung milih siji kanthi acak. Mula sakarone kudu digatekake amarga bisa nggugah salah sijine.
Lan masalah iku kita duwe CP-tanpa wates. Lan mulane, kemungkinan kita bisa tangi mengko. Lan yen, contone, kita tangi sing mengko, kita bakal ngenteni wong sing nembe nampa blok kasebut, mula kita ora nemtokake sapa sing bakal ditangekake dhisik. Kita mung nggawe kahanan kaya mengkono, lan sistem bakal awaken ing urutan acak.
Ana . Deleng, dheweke uga menarik lan migunani. Topik, mesthi, rumit banget. Matur nuwun kanthi sanget, Bruce!
Source: www.habr.com