Transkrip ceramah Bruce Momjian 2020 "Membuka Kunci Pengurus Kunci Postgres".
(Nota: Semua pertanyaan SQL daripada slaid boleh didapati daripada pautan ini: )
helo! Seronok berada di sini di Rusia sekali lagi. Saya minta maaf saya tidak dapat datang tahun lepas, tetapi tahun ini Ivan dan saya mempunyai rancangan besar. Saya berharap untuk berada di sini lebih kerap. Saya suka datang ke Rusia. Saya akan melawat Tyumen, Tver. Saya sangat gembira kerana saya akan dapat melawat bandar-bandar ini.
Nama saya Bruce Momjian. Saya bekerja di EnterpriseDB dan telah bekerja dengan Postgres selama lebih 23 tahun. Saya tinggal di Philadelphia, Amerika Syarikat. Saya mengembara kira-kira 90 hari setahun. Dan saya menghadiri kira-kira 40 persidangan. saya , yang mengandungi slaid yang saya akan tunjukkan sekarang. Oleh itu, selepas persidangan anda boleh memuat turunnya dari laman web peribadi saya. Ia juga mengandungi kira-kira 30 pembentangan. Terdapat juga video dan sebilangan besar entri blog, lebih daripada 500. Ini adalah sumber yang cukup bermaklumat. Dan jika anda berminat dengan bahan ini, maka saya menjemput anda untuk menggunakannya.
Saya pernah menjadi seorang guru, seorang profesor sebelum saya mula bekerja dengan Postgres. Dan saya sangat gembira kerana saya kini akan dapat memberitahu anda apa yang saya akan beritahu anda. Ini adalah antara pembentangan saya yang paling menarik. Dan pembentangan ini mengandungi 110 slaid. Kami akan mula bercakap dengan perkara yang mudah, dan pada akhirnya laporan akan menjadi lebih dan lebih kompleks, dan akan menjadi agak rumit.
Ini adalah perbualan yang agak tidak menyenangkan. Menyekat bukanlah subjek yang paling popular. Kami mahu ini hilang entah ke mana. Ia seperti pergi ke doktor gigi.
- Mengunci adalah masalah bagi ramai orang yang bekerja dalam pangkalan data dan mempunyai berbilang proses berjalan pada masa yang sama. Mereka perlu menyekat. Iaitu, hari ini saya akan memberi anda pengetahuan asas tentang menyekat.
- ID Transaksi. Ini adalah bahagian pembentangan yang agak membosankan, tetapi mereka perlu difahami.
- Seterusnya kita akan bercakap tentang jenis penyekatan. Ini adalah bahagian yang agak mekanikal.
- Dan di bawah ini kami akan memberikan beberapa contoh menyekat. Dan ia akan menjadi agak sukar untuk difahami.
Mari kita bercakap tentang menyekat.
Istilah kami agak rumit. Berapa ramai daripada anda tahu dari mana petikan ini berasal? Dua orang. Ini adalah dari permainan yang dipanggil Colossal Cave Adventure. Ia adalah permainan komputer berasaskan teks pada tahun 80-an, saya fikir. Di sana anda perlu pergi ke dalam gua, ke dalam labirin, dan teks berubah, tetapi kandungannya hampir sama setiap kali. Itulah bagaimana saya ingat permainan ini.
Dan di sini kita melihat nama kunci yang datang kepada kita dari Oracle. Kami menggunakannya.
Di sini kita melihat istilah yang mengelirukan saya. Contohnya, SHARE UPDATE ECXLUSIVE. Seterusnya KONGSI RAW ECXLUSIVE. Sejujurnya, nama-nama ini tidak begitu jelas. Kami akan cuba mempertimbangkannya dengan lebih terperinci. Ada yang mengandungi perkataan "kongsi", yang bermaksud memisahkan. Ada yang mengandungi perkataan "eksklusif". Ada yang mengandungi kedua-dua perkataan ini. Saya ingin mulakan dengan cara kunci ini berfungsi.
Dan perkataan "akses" juga sangat penting. Dan perkataan "baris" adalah rentetan. Iaitu, pengagihan akses, pengagihan baris.
Satu lagi isu yang perlu difahami dalam Postgres, yang malangnya saya tidak dapat bincangkan dalam ceramah saya, ialah MVCC. Saya mempunyai pembentangan berasingan mengenai topik ini di tapak web saya. Dan jika anda rasa persembahan ini sukar, MVCC mungkin yang paling sukar saya. Dan jika anda berminat, anda boleh menontonnya di laman web. Anda boleh menonton video.
Perkara lain yang perlu kita fahami ialah ID transaksi. Banyak urus niaga tidak boleh berfungsi tanpa pengecam unik. Dan di sini kami mempunyai penjelasan tentang apa itu transaksi. Postgres mempunyai dua sistem penomboran transaksi. Saya tahu ini bukan penyelesaian yang sangat cantik.
Juga perlu diingat bahawa slaid akan agak sukar untuk difahami, jadi apa yang diserlahkan dalam warna merah adalah perkara yang perlu anda perhatikan.
Jom tengok. Nombor transaksi diserlahkan dengan warna merah. Fungsi SELECT pg_back ditunjukkan di sini. Ia mengembalikan transaksi saya dan ID transaksi.
Seperkara lagi, jika anda menyukai pembentangan ini dan ingin menjalankannya pada pangkalan data anda, maka anda boleh pergi ke pautan ini dalam warna merah jambu dan memuat turun SQL untuk pembentangan ini. Dan anda hanya boleh menjalankannya dalam PSQL anda dan keseluruhan pembentangan akan berada di skrin anda serta-merta. Ia tidak akan mengandungi bunga, tetapi sekurang-kurangnya kita dapat melihatnya.
Dalam kes ini kita melihat ID transaksi. Ini adalah nombor yang kami berikan kepadanya. Dan terdapat satu lagi jenis ID transaksi dalam Postgres, yang dipanggil ID transaksi maya
Dan kita mesti faham ini. Ini sangat penting, jika tidak, kami tidak akan dapat memahami penguncian dalam Postgres.
ID transaksi maya ialah ID transaksi yang tidak mengandungi nilai berterusan. Sebagai contoh, jika saya menjalankan arahan SELECT, maka kemungkinan besar saya tidak akan menukar pangkalan data, saya tidak akan mengunci apa-apa. Oleh itu, apabila kami menjalankan SELECT mudah, kami tidak memberikan urus niaga itu ID yang berterusan. Kami hanya memberinya ID maya di sana.
Dan ini meningkatkan prestasi Postgres, meningkatkan keupayaan pembersihan, jadi ID transaksi maya terdiri daripada dua nombor. Nombor pertama sebelum garis miring ialah ID bahagian belakang. Dan di sebelah kanan kita hanya melihat kaunter.
Oleh itu, jika saya menjalankan permintaan, ia mengatakan bahawa ID bahagian belakang ialah 2.
Dan jika saya menjalankan satu siri transaksi sedemikian, maka kita melihat bahawa kaunter meningkat setiap kali saya menjalankan pertanyaan. Sebagai contoh, apabila saya menjalankan pertanyaan 2/10, 2/11, 2/12, dsb.
Perlu diingat bahawa terdapat dua lajur di sini. Di sebelah kiri kita melihat ID transaksi maya - 2/12. Dan di sebelah kanan kami mempunyai ID transaksi kekal. Dan medan ini kosong. Dan transaksi ini tidak mengubah suai pangkalan data. Jadi saya tidak memberikannya ID transaksi kekal.
Sebaik sahaja saya menjalankan arahan analisis ((ANALYZE)), pertanyaan yang sama memberi saya ID transaksi kekal. Lihat bagaimana ini telah berubah untuk kita. Saya tidak mempunyai ID ini sebelum ini, tetapi kini saya memilikinya.
Jadi ini permintaan lain, transaksi lain. Nombor transaksi maya ialah 2/13. Dan jika saya meminta ID transaksi yang berterusan, maka apabila saya menjalankan pertanyaan, saya akan mendapatkannya.
Jadi, sekali lagi. Kami mempunyai ID transaksi maya dan ID transaksi yang berterusan. Hanya faham perkara ini untuk memahami tingkah laku Postgres.
Kami beralih ke bahagian ketiga. Di sini kita hanya akan melalui pelbagai jenis kunci dalam Postgres. Ia tidak begitu menarik. Bahagian terakhir akan menjadi lebih menarik. Tetapi kita mesti mempertimbangkan perkara asas, kerana jika tidak kita tidak akan faham apa yang akan berlaku seterusnya.
Kami akan melalui bahagian ini, kami akan melihat setiap jenis kunci. Dan saya akan menunjukkan kepada anda contoh cara ia dipasang, cara ia berfungsi, saya akan menunjukkan kepada anda beberapa pertanyaan yang boleh anda gunakan untuk melihat cara penguncian berfungsi dalam Postgres.
Untuk membuat pertanyaan dan melihat apa yang berlaku dalam Postgres, kita perlu mengeluarkan pertanyaan dalam paparan sistem. Dalam kes ini, pg_lock diserlahkan dengan warna merah. Pg_lock ialah jadual sistem yang memberitahu kami kunci yang sedang digunakan dalam Postgres.
Walau bagaimanapun, amat sukar bagi saya untuk menunjukkan pg_lock dengan sendirinya kerana ia agak rumit. Jadi saya mencipta pandangan yang menunjukkan pg_locks. Dan ia juga berfungsi untuk saya yang membolehkan saya memahami dengan lebih baik. Iaitu, ia tidak termasuk kunci saya, sesi saya sendiri, dsb. Ia hanya SQL standard dan ia membolehkan anda menunjukkan dengan lebih baik kepada anda apa yang sedang berlaku.
Masalah lain ialah pandangan ini sangat luas, jadi saya perlu mencipta yang kedua - lockview2.
Dan ia menunjukkan kepada saya lebih banyak lajur daripada jadual. Dan satu lagi yang menunjukkan kepada saya lajur yang lain. Ini agak rumit, jadi saya cuba membentangkannya semudah mungkin.
Jadi kami mencipta jadual yang dipanggil Lockdemo. Dan kami mencipta satu baris di sana. Ini adalah jadual sampel kami. Dan kami akan membuat bahagian hanya untuk menunjukkan kepada anda contoh kunci.
Jadi, satu baris, satu lajur. Jenis kunci pertama dipanggil ACCESS SHARE. Ini adalah sekatan yang paling tidak terhad. Ini bermakna ia boleh dikatakan tidak bercanggah dengan kunci lain.
Dan jika kami ingin mentakrifkan kunci secara eksplisit, kami menjalankan perintah "jadual kunci". Dan ia jelas akan menyekat, iaitu dalam mod ACCESS SHARE kami melancarkan jadual kunci. Dan jika saya menjalankan PSQL di latar belakang, maka saya memulakan sesi kedua dari sesi pertama saya dengan cara ini. Iaitu, apa yang akan saya lakukan di sini? Saya pergi ke sesi lain dan memberitahunya "tunjukkan saya paparan kunci untuk permintaan ini." Dan di sini saya mempunyai AccessShareLock dalam jadual ini. Inilah yang saya minta. Dan dia mengatakan bahawa blok itu telah diberikan. Sangat ringkas.
Selanjutnya, jika kita melihat pada lajur kedua, maka tidak ada apa-apa di sana. Mereka kosong.
Dan jika saya menjalankan arahan "SELECT", maka ini adalah cara tersirat (eksplisit) untuk meminta AccessShareLock. Jadi saya melepaskan jadual saya dan menjalankan pertanyaan dan pertanyaan mengembalikan berbilang baris. Dan dalam salah satu baris kita melihat AccessShareLock. Oleh itu, SELECT memanggil AccessShareLock di atas meja. Dan ia tidak bercanggah dengan hampir apa-apa kerana ia adalah kunci peringkat rendah.
Bagaimana jika saya menjalankan SELECT dan mempunyai tiga jadual berbeza? Sebelum ini saya hanya menjalankan satu jadual, kini saya menjalankan tiga: pg_class, pg_namespace dan pg_attribute.
Dan kini apabila saya melihat pertanyaan, saya melihat 9 AccessShareLocks dalam tiga jadual. kenapa? Tiga jadual diserlahkan dengan warna biru: pg_attribute, pg_class, pg_namespace. Tetapi anda juga boleh melihat bahawa semua indeks yang ditakrifkan melalui jadual ini juga mempunyai AccessShareLock.
Dan ini adalah kunci yang boleh dikatakan tidak bertentangan dengan orang lain. Dan apa yang dilakukannya hanyalah menghalang kami daripada menetapkan semula jadual semasa kami memilihnya. Ia masuk akal. Iaitu, jika kita memilih jadual, ia hilang pada masa itu, maka ini salah, jadi AccessShare ialah kunci tahap rendah yang memberitahu kami "jangan jatuhkan jadual ini semasa saya bekerja". Pada asasnya, itu sahaja yang dia lakukan.
ROW SHARE - Kunci ini berbeza sedikit.
Mari kita ambil contoh. SELECT ROW SHARE kaedah mengunci setiap baris secara individu. Dengan cara ini tiada siapa yang boleh memadamkannya atau mengubahnya semasa kami menontonnya.
Jadi apa yang dilakukan SHARE LOCK? Kami melihat bahawa ID transaksi ialah 681 untuk SELECT. Dan ini menarik. Apa yang berlaku di sini? Kali pertama kita melihat nombor itu dalam medan "Kunci". Kami mengambil ID transaksi dan dikatakan ia menyekatnya dalam mod eksklusif. Apa yang dilakukannya ialah ia mengatakan saya mempunyai baris yang secara teknikal dikunci di suatu tempat di dalam jadual. Tetapi dia tidak menyatakan di mana sebenarnya. Kami akan melihat perkara ini dengan lebih terperinci sedikit kemudian.
Di sini kami mengatakan bahawa kunci digunakan oleh kami.
Jadi, kunci eksklusif dengan jelas mengatakan bahawa ia adalah eksklusif. Dan juga jika anda memadamkan baris dalam jadual ini, maka inilah yang akan berlaku, seperti yang anda lihat.
SHARE EXCLUSIVE ialah kunci yang lebih panjang.
Ini ialah perintah penganalisis (ANALYZE) yang akan digunakan.
KUNCI KONGSI β anda boleh mengunci secara eksplisit dalam mod kongsi.
Anda juga boleh membuat indeks unik. Dan di sana anda boleh melihat KUNCI KONGSI, yang merupakan sebahagian daripada mereka. Dan ia mengunci meja dan meletakkan KUNCI SAHAM di atasnya.
Secara lalai, KONGSI KUNCI pada jadual bermakna orang lain boleh membaca jadual, tetapi tiada siapa boleh mengubah suainya. Dan inilah yang berlaku apabila anda mencipta indeks unik.
Jika saya mencipta indeks serentak yang unik, maka saya akan mempunyai jenis penguncian yang berbeza kerana, seperti yang anda ingat, menggunakan indeks serentak mengurangkan keperluan penguncian. Dan jika saya menggunakan kunci biasa, indeks biasa, maka saya akan menghalang penulisan pada indeks jadual semasa ia dibuat. Jika saya menggunakan indeks serentak, maka saya perlu menggunakan jenis penguncian yang berbeza.
SHARE ROW EXCLUSIVE β sekali lagi ia boleh ditetapkan secara eksplisit (secara eksplisit).
Atau kita boleh membuat peraturan, iaitu, mengambil kes tertentu yang akan digunakan.
Penguncian EKSKLUSIF bermakna tiada orang lain boleh menukar jadual.
Di sini kita melihat pelbagai jenis kunci.
ACCESS EXCLUSIVE, sebagai contoh, ialah arahan menyekat. Sebagai contoh, jika anda melakukannya CLUSTER table, maka ini bermakna tiada siapa yang boleh menulis di sana. Dan ia mengunci bukan sahaja jadual itu sendiri, tetapi juga indeks.
Ini ialah halaman kedua penyekatan ACCESS EXCLUSIVE, di mana kita melihat dengan tepat apa yang disekatnya dalam jadual. Ia mengunci baris meja individu, yang agak menarik.
Itu sahaja maklumat asas yang saya ingin berikan. Kami bercakap tentang kunci, tentang ID transaksi, kami bercakap tentang ID transaksi maya, tentang ID transaksi kekal.
Dan sekarang kita akan melalui beberapa contoh menyekat. Ini adalah bahagian yang paling menarik. Kami akan melihat kes yang sangat menarik. Dan matlamat saya dalam pembentangan ini adalah untuk memberi anda pemahaman yang lebih baik tentang perkara yang sebenarnya dilakukan oleh Postgres apabila ia cuba menyekat perkara tertentu. Saya rasa dia sangat pandai menyekat bahagian.
Mari lihat beberapa contoh khusus.
Kita akan mulakan dengan jadual dan satu baris dalam satu jadual. Apabila saya memasukkan sesuatu, saya mempunyai ExclusiveLock, Transaction ID dan ExclusiveLock dipaparkan di atas meja.
Apakah yang berlaku jika saya memasukkan dua baris lagi? Dan sekarang meja kami mempunyai tiga baris. Dan saya memasukkan satu baris dan mendapat ini sebagai output. Dan jika saya memasukkan dua baris lagi, apa yang peliknya? Terdapat perkara yang pelik di sini kerana saya telah menambah tiga baris pada jadual ini, tetapi saya masih mempunyai dua baris dalam meja kunci. Dan ini pada dasarnya adalah tingkah laku asas Postgres.
Ramai orang berfikir bahawa jika dalam pangkalan data anda mengunci 100 baris, maka anda perlu membuat 100 entri kunci. Jika saya menyekat 1 baris sekali gus, maka saya memerlukan 000 pertanyaan sedemikian. Dan jika saya memerlukan satu juta atau satu bilion untuk menyekat. Tetapi jika kita melakukan ini, ia tidak akan berfungsi dengan baik. Jika anda telah menggunakan sistem yang mencipta entri menyekat untuk setiap baris individu, maka anda boleh melihat bahawa ini adalah rumit. Kerana anda perlu segera menentukan jadual kunci yang boleh melimpah, tetapi Postgres tidak melakukannya.
Dan apa yang benar-benar penting tentang slaid ini ialah ia jelas menunjukkan bahawa terdapat sistem lain yang berjalan di dalam MVCC yang mengunci baris individu. Oleh itu, apabila anda mengunci berbilion baris, Postgres tidak mencipta satu bilion perintah mengunci berasingan. Dan ini mempunyai kesan yang sangat baik terhadap produktiviti.
Bagaimana dengan kemas kini? Saya sedang mengemas kini baris sekarang, dan anda boleh melihat bahawa ia telah melakukan dua operasi berbeza sekaligus. Ia mengunci meja pada masa yang sama, tetapi ia juga mengunci indeks. Dan dia perlu mengunci indeks kerana terdapat kekangan unik pada jadual ini. Dan kami ingin memastikan tiada sesiapa yang mengubahnya, jadi kami menyekatnya.
Apakah yang berlaku jika saya ingin mengemas kini dua baris? Dan kita melihat bahawa dia berkelakuan dengan cara yang sama. Kami melakukan kemas kini dua kali lebih banyak, tetapi bilangan garis kunci yang sama.
Jika anda tertanya-tanya bagaimana Postgres melakukan ini, anda perlu mendengar ceramah saya tentang MVCC untuk mengetahui cara Postgres secara dalaman menandakan baris ini bahawa ia berubah. Dan Postgres mempunyai cara di mana ia melakukan ini, tetapi ia tidak melakukannya pada tahap mengunci meja, ia melakukannya pada tahap yang lebih rendah dan lebih cekap.
Bagaimana jika saya mahu memadamkan sesuatu? Jika saya memadam, sebagai contoh, satu baris dan saya masih mempunyai dua input menyekat saya, dan walaupun saya mahu memadamkan semuanya, ia masih ada.
Dan, sebagai contoh, saya ingin memasukkan 1 baris, dan kemudian sama ada memadam atau menambah 000 baris, kemudian baris individu yang saya tambah atau ubah, ia tidak direkodkan di sini. Mereka ditulis pada tahap yang lebih rendah dalam siri itu sendiri. Dan semasa ucapan MVCC saya bercakap tentang perkara ini secara terperinci. Tetapi adalah sangat penting apabila anda menganalisis kunci untuk memastikan anda mengunci pada tahap jadual dan anda tidak melihat cara baris individu direkodkan di sini.
Bagaimana pula dengan penyekatan eksplisit?
Jika saya mengklik muat semula, saya mempunyai dua baris dikunci. Dan jika saya memilih semuanya dan mengklik "kemas kini di mana-mana," maka saya masih mempunyai dua rekod penyekatan.
Kami tidak mencipta rekod berasingan untuk setiap baris individu. Kerana kemudian produktiviti menurun, mungkin terdapat terlalu banyak. Dan kita mungkin mendapati diri kita berada dalam keadaan yang tidak menyenangkan.
Dan perkara yang sama, jika kita berkongsi, kita boleh melakukannya semua 30 kali.
Kami memulihkan jadual kami, padamkan semuanya, kemudian masukkan satu baris lagi.
Satu lagi tingkah laku yang anda lihat dalam Postgres yang sangat terkenal dan tingkah laku yang diingini ialah anda boleh melakukan kemas kini atau pilih. Dan anda boleh melakukan ini pada masa yang sama. Dan pilih tidak menyekat kemas kini dan perkara yang sama dalam arah yang bertentangan. Kami memberitahu pembaca untuk tidak menyekat penulis, dan penulis tidak menyekat pembaca.
Saya akan menunjukkan kepada anda contoh ini. Saya akan membuat pilihan sekarang. Kami kemudian akan melakukan INSERT. Dan kemudian anda boleh melihat - 694. Anda boleh melihat ID transaksi yang melakukan sisipan ini. Dan begitulah caranya.
Dan jika saya melihat pada ID bahagian belakang saya sekarang, ia kini 695.
Dan saya dapat melihat 695 muncul dalam jadual saya.
Dan jika saya mengemas kini di sini seperti ini, maka saya mendapat kes yang berbeza. Dalam kes ini, 695 ialah kunci eksklusif, dan kemas kini mempunyai tingkah laku yang sama, tetapi tidak ada konflik antara mereka, yang agak luar biasa.
Dan anda boleh melihat bahawa di bahagian atas ia adalah ShareLock, dan di bahagian bawah ia adalah ExclusiveLock. Dan kedua-dua transaksi berjaya.
Dan anda perlu mendengar ceramah saya di MVCC untuk memahami bagaimana ini berlaku. Tetapi ini adalah ilustrasi yang anda boleh melakukannya pada masa yang sama, iaitu melakukan SELECT dan UPDATE pada masa yang sama.
Mari kita tetapkan semula dan lakukan satu lagi operasi.
Jika anda cuba menjalankan dua kemas kini serentak pada baris yang sama, ia akan disekat. Dan ingat, saya katakan bahawa pembaca tidak menyekat penulis, dan penulis tidak menyekat pembaca, tetapi seorang penulis menghalang penulis lain. Iaitu, kita tidak boleh mempunyai dua orang mengemas kini baris yang sama pada masa yang sama. Anda perlu menunggu sehingga salah satu daripadanya selesai.
Dan untuk menggambarkan ini, saya akan melihat jadual Lockdemo. Dan kita akan melihat satu baris. Setiap transaksi 698.
Kami telah mengemas kini ini kepada 2. 699 ialah kemas kini pertama. Dan ia berjaya atau dalam transaksi yang belum selesai dan sedang menunggu untuk kami mengesahkan atau membatalkannya.
Tetapi lihat sesuatu yang lain - 2/51 adalah transaksi pertama kami, sesi pertama kami. 3/112 ialah permintaan kedua yang datang dari atas yang menukar nilai itu kepada 3. Dan jika anda perasan, yang teratas mengunci sendiri, iaitu 699. Tetapi 3/112 tidak memberikan kunci itu. Lajur Lock_mode menyatakan apa yang ditunggu. Ia menjangkakan 699. Dan jika anda melihat di mana 699, ia lebih tinggi. Dan apakah yang dilakukan oleh sesi pertama? Dia mencipta kunci eksklusif pada ID transaksinya sendiri. Ini adalah bagaimana Postgres melakukannya. Ia menyekat ID transaksinya sendiri. Dan jika anda ingin menunggu seseorang mengesahkan atau membatalkan, maka anda perlu menunggu sementara terdapat transaksi yang belum selesai. Dan itulah sebabnya kita boleh melihat garis yang pelik.
Jom tengok lagi. Di sebelah kiri kami melihat ID pemprosesan kami. Dalam lajur kedua kami melihat ID transaksi maya kami, dan dalam lajur ketiga kami melihat lock_type. Apakah maksud ini? Pada asasnya apa yang dikatakannya ialah ia menyekat ID transaksi. Tetapi perhatikan bahawa semua baris di bahagian bawah menyatakan hubungan. Jadi anda mempunyai dua jenis kunci di atas meja. Terdapat kunci hubungan. Dan kemudian terdapat penyekatan transactionid, di mana anda menyekat sendiri, iaitu apa yang berlaku pada baris pertama atau di bahagian paling bawah, di mana transactionid berada, di mana kita menunggu 699 untuk menyelesaikan operasinya.
Saya akan lihat apa yang berlaku di sini. Dan di sini dua perkara berlaku serentak. Anda sedang melihat kunci ID transaksi di baris pertama yang mengunci dirinya sendiri. Dan dia menghalang dirinya untuk membuat orang menunggu.
Jika dilihat pada baris ke-6, ia adalah entri yang sama seperti yang pertama. Dan oleh itu transaksi 699 disekat. 700 juga mengunci diri. Dan kemudian di baris bawah anda akan melihat bahawa kami sedang menunggu 699 untuk menyelesaikan operasinya.
Dan dalam lock_type, tupel anda melihat nombor.
Anda boleh lihat ia 0/10. Dan ini ialah nombor halaman, dan juga offset bagi baris tertentu ini.
Dan anda lihat ia menjadi 0/11 apabila kami mengemas kini.
Tetapi pada hakikatnya ia adalah 0/10, kerana terdapat menunggu untuk operasi ini. Kami mempunyai peluang untuk melihat bahawa ini adalah siri yang saya tunggu untuk mengesahkannya.
Sebaik sahaja kami mengesahkannya dan menekan komit, dan apabila kemas kini selesai, inilah yang kami dapat semula. Transaksi 700 adalah satu-satunya kunci, ia tidak menunggu orang lain kerana ia telah dilakukan. Ia hanya menunggu sehingga transaksi selesai. Sebaik sahaja 699 habis, kami tidak menunggu apa-apa lagi. Dan kini transaksi 700 mengatakan bahawa semuanya baik-baik saja, bahawa ia mempunyai semua kunci yang diperlukan pada semua jadual yang dibenarkan.
Dan untuk menjadikan perkara ini lebih rumit, kami mencipta satu lagi pandangan, yang kali ini akan memberikan kami hierarki. Saya tidak mengharapkan anda memahami permintaan ini. Tetapi ini akan memberi kita pandangan yang lebih jelas tentang apa yang sedang berlaku.
Ini ialah pandangan rekursif yang juga mempunyai bahagian lain. Dan kemudian ia menyatukan segala-galanya semula. Jom guna ni.
Bagaimana jika kita melakukan tiga kemas kini serentak dan mengatakan bahawa baris itu kini tiga. Dan kami akan menukar 3 kepada 4.
Dan di sini kita lihat 4. Dan ID transaksi 702.
Dan kemudian saya akan menukar 4 kepada 5. Dan 5 kepada 6, dan 6 kepada 7. Dan saya akan membariskan beberapa orang yang akan menunggu untuk satu transaksi ini tamat.
Dan semuanya menjadi jelas. Apakah baris pertama? Ini ialah 702. Ini ialah ID transaksi yang pada asalnya menetapkan nilai ini. Apakah yang tertulis dalam lajur Diberikan saya? Saya ada markah f. Ini adalah kemas kini saya yang (5, 6, 7) tidak boleh diluluskan kerana kami sedang menunggu ID transaksi 702 tamat. Di sana kami mempunyai penyekatan ID transaksi. Dan ini menghasilkan 5 kunci ID transaksi.
Dan jika anda melihat 704, pada 705, tiada apa yang ditulis di sana lagi, kerana mereka belum tahu apa yang sedang berlaku. Mereka hanya menulis bahawa mereka tidak tahu apa yang berlaku. Dan mereka hanya akan tidur kerana mereka menunggu seseorang selesai dan dikejutkan apabila ada peluang untuk menukar baris.
Beginilah rupanya. Jelas mereka semua sedang menunggu barisan ke-12.
Inilah yang kami lihat di sini. Inilah 0/12.
Jadi sebaik sahaja transaksi pertama diluluskan, anda boleh melihat di sini cara hierarki berfungsi. Dan kini semuanya menjadi jelas. Mereka semua menjadi bersih. Dan mereka sebenarnya masih menunggu.
Inilah yang berlaku. 702 komited. Dan kini 703 mendapat kunci baris ini, dan kemudian 704 mula menunggu 703 untuk melakukan. Dan 705 sedang menunggu ini juga. Dan apabila semua ini selesai, mereka membersihkan diri. Dan saya ingin menegaskan bahawa semua orang sedang beratur. Dan ini hampir sama dengan situasi dalam kesesakan lalu lintas apabila semua orang sedang menunggu kereta pertama. Kereta pertama berhenti dan semua orang beratur dalam barisan panjang. Kemudian ia bergerak, kemudian kereta seterusnya boleh memandu ke hadapan dan mendapatkan bloknya, dsb.
Dan jika ini nampaknya tidak cukup rumit kepada anda, maka kami kini akan bercakap dengan anda tentang kebuntuan. Saya tidak tahu siapa di antara kamu yang pernah menemui mereka. Ini adalah masalah yang agak biasa dalam sistem pangkalan data. Tetapi kebuntuan adalah apabila satu sesi menunggu sesi lain untuk melakukan sesuatu. Dan pada masa ini satu lagi sesi sedang menunggu sesi pertama untuk melakukan sesuatu.
Dan, sebagai contoh, jika Ivan berkata: "Beri saya sesuatu," dan saya berkata: "Tidak, saya hanya akan memberikannya kepada anda jika anda memberi saya sesuatu yang lain." Dan dia berkata, "Tidak, saya tidak akan memberikannya kepada anda jika anda tidak memberikannya kepada saya." Dan kita berakhir dalam keadaan buntu. Saya pasti bahawa Ivan tidak akan melakukan ini, tetapi anda memahami maksud bahawa kita mempunyai dua orang yang ingin mendapatkan sesuatu dan mereka tidak bersedia untuk memberikannya sehingga orang lain memberikan apa yang mereka mahu. Dan tiada penyelesaian.
Dan pada asasnya, pangkalan data anda perlu mengesan ini. Dan kemudian anda perlu memadam atau menutup salah satu sesi, kerana jika tidak, mereka akan kekal di sana selama-lamanya. Dan kita melihatnya dalam pangkalan data, kita melihatnya dalam sistem pengendalian. Dan di semua tempat di mana kita mempunyai proses selari, ini boleh berlaku.
Dan sekarang kita akan memasang dua kebuntuan. Kami akan meletakkan 50 dan 80. Di baris pertama, saya akan mengemas kini daripada 50 kepada 50. Saya akan mendapat nombor transaksi 710.
Dan kemudian saya akan menukar 80 kepada 81, dan 50 kepada 51.
Dan inilah rupanya. Jadi 710 mempunyai baris yang disekat, dan 711 sedang menunggu pengesahan. Kami melihat ini apabila kami mengemas kini. 710 ialah pemilik siri kami. Dan 711 menunggu 710 untuk menyelesaikan transaksi.
Dan ia juga mengatakan pada baris mana kebuntuan berlaku. Dan di sinilah ia mula menjadi pelik.
Sekarang kami mengemas kini 80 hingga 80.
Dan di sinilah kebuntuan bermula. 710 sedang menunggu jawapan daripada 711, dan 711 sedang menunggu 710. Dan ini tidak akan berakhir dengan baik. Dan tidak ada jalan keluar dari ini. Dan mereka akan mengharapkan balasan dari satu sama lain.
Dan ia hanya akan mula melambatkan segala-galanya. Dan kami tidak mahu itu.
Dan Postgres mempunyai cara untuk melihat apabila ini berlaku. Dan apabila ini berlaku, anda mendapat ralat ini. Dan dari sini adalah jelas bahawa proses ini dan itu sedang menunggu KUNCI SAHAM dari proses lain, iaitu, yang disekat oleh proses 711. Dan proses itu sedang menunggu KUNCI SAHAM diberikan pada ID transaksi itu dan ini dan telah disekat oleh proses itu dan itu. Oleh itu, terdapat keadaan kebuntuan di sini.
Adakah terdapat kebuntuan tiga hala? Adakah mungkin? ya.
Kami memasukkan nombor ini ke dalam jadual. Kita tukar 40 kepada 40, kita buat blocking.
Kami menukar 60 kepada 61, 80 kepada 81.
Dan kemudian kita menukar 80 dan kemudian boom!
Dan 714 kini sedang menunggu 715. Yang ke-716 sedang menunggu untuk yang ke-715. Dan tiada apa yang boleh dilakukan mengenainya.
Tiada lagi dua orang di sini, sudah ada tiga orang di sini. Saya mahukan sesuatu daripada awak, yang ini mahukan sesuatu daripada orang ketiga, dan orang ketiga mahukan sesuatu daripada saya. Dan kami akhirnya menunggu tiga hala kerana kami semua menunggu orang lain menyelesaikan apa yang perlu mereka lakukan.
Dan Postgres tahu pada baris mana ini berlaku. Oleh itu, ia akan memberi anda mesej berikut, yang menunjukkan bahawa anda mempunyai masalah di mana tiga input menyekat satu sama lain. Dan tiada sekatan di sini. Ini mungkin berlaku di mana 20 entri menyekat satu sama lain.
Masalah seterusnya boleh bersiri.
Jika kunci boleh bersiri khas.
Dan kita kembali ke 719. Keluarannya agak normal.
Dan anda boleh mengklik untuk membuat transaksi daripada boleh bersiri.
Dan anda sedar bahawa anda kini mempunyai jenis kunci SA yang berbeza - ini bermakna boleh bersiri.
Oleh itu, kami mempunyai jenis kunci baharu yang dipanggil SARieadLock, iaitu kunci bersiri dan membolehkan anda memasukkan bersiri.
Dan juga anda boleh memasukkan indeks unik.
Dalam jadual ini kami mempunyai indeks unik.
Jadi jika saya meletakkan nombor 2 di sini, jadi saya mempunyai 2. Tetapi di bahagian paling atas, saya meletakkan 2 lagi. Dan anda boleh melihat bahawa 721 mempunyai kunci eksklusif. Tetapi sekarang 722 sedang menunggu 721 untuk menyelesaikan operasinya kerana ia tidak boleh memasukkan 2 sehingga ia tahu apa yang akan berlaku kepada 721.
Dan jika kita melakukan subtransaksi.
Di sini kita ada 723.
Dan jika kami menyimpan titik dan kemudian mengemas kininya, maka kami akan mendapat ID transaksi baharu. Ini adalah satu lagi corak tingkah laku yang perlu anda ketahui. Jika kami mengembalikan ini, maka ID transaksi akan hilang. 724 akan pergi. Tetapi sekarang kita mempunyai 725.
Jadi apa yang saya cuba lakukan di sini? Saya cuba menunjukkan kepada anda contoh kunci luar biasa yang mungkin anda temui: sama ada kunci boleh bersiri atau SAVEPOINT, ini ialah jenis kunci berbeza yang akan muncul dalam jadual kunci.
Ini ialah penciptaan kunci eksplisit (eksplisit), yang mempunyai pg_advisory_lock.
Dan anda melihat bahawa jenis penyekatan disenaraikan sebagai nasihat. Dan di sini ia berkata "nasihat" dalam warna merah. Dan anda boleh menyekat secara serentak seperti ini dengan pg_advisory_unlock.
Dan sebagai kesimpulan, saya ingin menunjukkan kepada anda satu lagi perkara yang menakjubkan. Saya akan mencipta pandangan lain. Tetapi saya akan menyertai jadual pg_locks dengan jadual pg_stat_activity. Dan mengapa saya mahu melakukan ini? Kerana ini akan membolehkan saya melihat dan melihat semua sesi semasa dan melihat dengan tepat jenis kunci yang mereka tunggu. Dan ini agak menarik apabila kita menyusun jadual kunci dan jadual pertanyaan.
Dan di sini kita mencipta pg_stat_view.
Dan kami mengemas kini baris demi satu. Dan di sini kita melihat 724. Dan kemudian kita mengemas kini baris kita kepada tiga. Dan apa yang anda lihat di sini sekarang? Ini adalah permintaan, iaitu anda melihat keseluruhan senarai permintaan yang disenaraikan dalam lajur kiri. Dan kemudian di sebelah kanan anda boleh melihat sekatan dan apa yang mereka buat. Dan ia boleh menjadi lebih jelas untuk anda supaya anda tidak perlu kembali ke setiap sesi setiap kali dan melihat sama ada anda perlu menyertainya atau tidak. Mereka melakukannya untuk kita.
Satu lagi ciri yang sangat berguna ialah pg_blocking_pids. Anda mungkin tidak pernah mendengar tentang dia. Apa yang dia sedang buat? Ia membolehkan kami memberitahu bahawa untuk sesi ini 11740 apakah ID proses khusus yang sedang menunggunya. Dan anda boleh melihat bahawa 11740 sedang menunggu 724. Dan 724 berada di bahagian paling atas. Dan 11306 ialah ID proses anda. Pada asasnya, fungsi ini melalui meja kunci anda. Dan saya tahu ia agak rumit, tetapi anda berjaya memahaminya. Pada asasnya fungsi ini melalui jadual kunci ini dan cuba mencari di mana ID proses ini diberikan kunci yang sedang menunggunya. Dan ia juga cuba memikirkan ID proses mana yang dimiliki oleh proses yang sedang menunggu kunci itu. Jadi anda boleh menjalankan fungsi ini pg_blocking_pids.
Dan ini boleh menjadi sangat berguna. Kami hanya menambah ini dalam versi 9.6, jadi ciri ini hanya berusia 5 tahun, tetapi ia sangat, sangat berguna. Dan perkara yang sama berlaku untuk permintaan kedua. Ia menunjukkan dengan tepat apa yang perlu kita lihat.
Inilah yang saya ingin bincangkan dengan anda. Dan seperti yang saya jangka, kami menghabiskan masa kami kerana terdapat banyak slaid. Dan slaid tersedia untuk dimuat turun. Saya ingin mengucapkan terima kasih kerana berada di sini. Saya pasti anda akan menikmati sisa persidangan itu, terima kasih banyak!
Soalan:
Sebagai contoh, jika saya cuba mengemas kini baris, dan sesi kedua cuba memadamkan keseluruhan jadual. Setakat yang saya faham, sepatutnya ada sesuatu seperti kunci niat. Adakah terdapat perkara sedemikian dalam Postgres?
Mari kita kembali ke awal. Anda mungkin ingat bahawa apabila anda melakukan apa-apa, contohnya apabila anda melakukan SELECT, kami mengeluarkan AccessShareLock. Dan ini menghalang jadual daripada dijatuhkan. Jadi, jika anda, sebagai contoh, ingin mengemas kini baris dalam jadual atau memadam baris, maka seseorang tidak boleh memadam keseluruhan jadual pada masa yang sama kerana anda memegang AccessShareLock ini di atas seluruh jadual dan di atas baris. Dan sebaik sahaja anda selesai, mereka boleh memadamkannya. Tetapi semasa anda mengubah sesuatu secara langsung di sana, mereka tidak akan dapat melakukannya.
Jom buat lagi. Mari kita beralih kepada contoh padam. Dan anda melihat bagaimana terdapat kunci eksklusif pada baris di atas keseluruhan meja.
Ini akan kelihatan seperti kunci eksklusif, bukan?
Ya, ia kelihatan seperti itu. Saya faham apa yang awak cakapkan. Anda mengatakan bahawa jika saya melakukan SELECT kemudian saya mempunyai ShareExclusive dan kemudian saya menjadikannya Row Exclusive, adakah itu menjadi masalah? Tetapi yang menghairankan ini tidak menimbulkan masalah. Ini kelihatan seperti meningkatkan tahap kunci, tetapi pada asasnya saya mempunyai kunci yang menghalang pemadaman. Dan sekarang, apabila saya menjadikan kunci ini lebih berkuasa, ia masih menghalang pemadaman. Jadi tidak seperti saya akan naik. Iaitu, ia menghalangnya daripada berlaku apabila ia berada di tahap yang lebih rendah juga, jadi apabila saya menaikkan tahapnya ia masih menghalang jadual daripada dipadamkan.
Saya faham apa yang awak cakapkan. Tiada kes peningkatan kunci di sini, di mana anda cuba melepaskan satu kunci untuk memperkenalkan kunci yang lebih kuat. Di sini ia hanya meningkatkan pencegahan ini secara menyeluruh, jadi ia tidak menyebabkan sebarang konflik. Tetapi ia adalah soalan yang bagus. Terima kasih banyak kerana bertanya ini!
Apakah yang perlu kita lakukan untuk mengelakkan situasi kebuntuan apabila kita mempunyai banyak sesi, bilangan pengguna yang besar?
Postgres secara automatik menyedari situasi kebuntuan. Dan ia akan memadamkan salah satu sesi secara automatik. Satu-satunya cara untuk mengelakkan sekatan mati adalah dengan menyekat orang dalam susunan yang sama. Oleh itu, apabila anda melihat permohonan anda, selalunya sebab kebuntuan ... Cuba bayangkan saya ingin menyekat dua perkara yang berbeza. Satu aplikasi mengunci jadual 1, dan satu lagi aplikasi mengunci 2, dan kemudian jadual 1. Dan cara paling mudah untuk mengelakkan kebuntuan adalah dengan melihat aplikasi anda dan cuba memastikan bahawa penguncian berlaku dalam susunan yang sama merentas semua aplikasi. Dan ini biasanya menghapuskan 80% masalah, kerana semua jenis orang menulis aplikasi ini. Dan jika anda menyekatnya dalam susunan yang sama, maka anda tidak akan menghadapi situasi buntu.
Terima kasih banyak atas persembahan anda! Anda bercakap tentang vakum penuh dan, jika saya faham dengan betul, vakum penuh memesongkan susunan rekod dalam storan berasingan, jadi mereka menyimpan rekod semasa tidak berubah. Mengapakah vakum penuh mengambil akses kunci eksklusif dan mengapa ia bercanggah dengan operasi tulis?
Itu soalan yang bagus. Sebabnya ialah vakum penuh mengambil meja. Dan kami pada asasnya mencipta versi baharu jadual. Dan meja itu akan menjadi baru. Ternyata ini akan menjadi versi jadual yang benar-benar baharu. Dan masalahnya ialah apabila kita melakukan ini, kita tidak mahu orang membacanya kerana kita memerlukan mereka melihat jadual baharu. Jadi ini bersambung dengan soalan sebelumnya. Jika kita boleh membaca pada masa yang sama, kita tidak akan dapat mengalihkannya dan mengarahkan orang ke meja baharu. Kita perlu menunggu sehingga semua orang selesai membaca jadual ini, jadi ia pada dasarnya adalah situasi eksklusif kunci.
Kami hanya mengatakan bahawa kami mengunci dari awal kerana kami tahu bahawa pada akhirnya kami memerlukan kunci eksklusif untuk memindahkan semua orang ke salinan baharu. Jadi kami berpotensi menyelesaikannya. Dan kami melakukannya dengan cara ini dengan pengindeksan serentak. Tetapi ini adalah lebih sukar untuk dilakukan. Dan ini sangat berkaitan dengan soalan anda sebelum ini tentang kunci eksklusif.
Adakah mungkin untuk menambah tamat masa mengunci pada Postgres? Dalam Oracle, saya boleh, sebagai contoh, menulis "pilih untuk mengemas kini" dan tunggu 50 saat sebelum mengemas kini. Ia bagus untuk permohonan itu. Tetapi dalam Postgres, saya sama ada perlu melakukannya dengan segera dan tidak menunggu sama sekali, atau menunggu sehingga beberapa waktu.
Ya, anda boleh memilih tamat masa pada kunci anda, pada kunci anda. Anda juga boleh mengeluarkan arahan no way, yang akan... jika anda tidak boleh mendapatkan kunci dengan segera. Oleh itu, sama ada tamat masa kunci atau perkara lain yang akan membolehkan anda melakukan ini. Ini tidak dilakukan pada peringkat sintaksis. Ini dilakukan sebagai pembolehubah pada pelayan. Kadang-kadang ini tidak boleh digunakan.
Bolehkah anda membuka slaid 75?
Ya.
Dan soalan saya adalah seperti berikut. Mengapakah kedua-dua proses kemas kini menjangkakan 703?
Dan ini adalah soalan yang hebat. Saya tidak faham, dengan cara ini, mengapa Postgres melakukan ini. Tetapi apabila 703 dicipta, ia menjangkakan 702. Dan apabila 704 dan 705 muncul, nampaknya mereka tidak tahu apa yang mereka jangkakan kerana tiada apa-apa lagi di sana. Dan Postgres melakukannya dengan cara ini: apabila anda tidak boleh mendapatkan kunci, ia menulis "Apa gunanya memproses anda?", kerana anda sudah menunggu seseorang. Jadi kami biarkan sahaja ia tergantung di udara, ia tidak akan mengemas kini sama sekali. Tetapi apa yang berlaku di sini? Sebaik sahaja 702 menyelesaikan proses dan 703 menerima kuncinya, sistem itu kembali semula. Dan dia berkata bahawa sekarang kita mempunyai dua orang yang sedang menunggu. Dan kemudian mari kita mengemas kini mereka bersama-sama. Dan marilah kita menunjukkan bahawa kedua-duanya menjangkakan.
Saya tidak tahu mengapa Postgres melakukan ini. Tetapi ada masalah yang dipanggil fβ¦. Nampaknya saya ini bukan istilah dalam bahasa Rusia. Ini adalah ketika semua orang menunggu satu istana, walaupun terdapat 20 pihak berkuasa yang sedang menunggu istana. Dan tiba-tiba mereka semua bangun pada masa yang sama. Dan semua orang mula cuba bertindak balas. Tetapi sistem menjadikannya supaya semua orang menunggu 703. Kerana mereka semua sedang menunggu, dan kami akan segera membariskan mereka semua. Dan jika permintaan baharu lain muncul yang dijana selepas ini, contohnya, 707, maka akan ada kekosongan lagi.
Dan nampaknya saya ini dilakukan supaya kita boleh mengatakan bahawa pada peringkat ini 702 sedang menunggu 703, dan semua orang yang datang selepas itu tidak akan mempunyai sebarang penyertaan dalam bidang ini. Tetapi sebaik sahaja pelayan pertama pergi, semua mereka yang menunggu pada masa itu sebelum kemas kini menerima token yang sama. Jadi saya fikir ini dilakukan supaya kita boleh memproses dengan teratur supaya mereka dipesan dengan betul.
Saya selalu melihat ini sebagai fenomena yang agak pelik. Kerana di sini, sebagai contoh, kami tidak menyenaraikannya sama sekali. Tetapi nampaknya saya setiap kali kita memberi kunci baru, kita melihat semua orang yang sedang menunggu. Kemudian kami membariskan mereka semua. Dan kemudian mana-mana yang baharu yang masuk hanya masuk ke dalam baris gilir apabila orang seterusnya telah selesai diproses. Soalan yang sangat bagus. Terima kasih banyak atas soalan anda!
Nampaknya saya lebih logik apabila 705 menjangkakan 704.
Tetapi masalah di sini adalah seperti berikut. Secara teknikal, anda boleh bangun satu atau yang lain. Jadi kita akan bangun satu atau yang lain. Tetapi apa yang berlaku dalam sistem? Anda boleh melihat bagaimana 703 di bahagian paling atas telah menyekat ID transaksinya sendiri. Beginilah cara Postgres berfungsi. Dan 703 disekat oleh ID transaksinya sendiri, jadi jika seseorang mahu menunggu, maka mereka akan menunggu 703. Dan, pada dasarnya, 703 selesai. Dan hanya selepas selesai, salah satu daripada proses itu terjaga. Dan kita tidak tahu apa sebenarnya proses ini. Kemudian kami memproses semuanya secara beransur-ansur. Tetapi tidak jelas proses mana yang dibangkitkan dahulu, kerana ia boleh menjadi mana-mana proses ini. Pada asasnya, kami mempunyai penjadual yang mengatakan bahawa kami kini boleh membangunkan mana-mana proses ini. Kami hanya memilih satu secara rawak. Jadi kedua-duanya perlu diberi perhatian kerana kita boleh menyedarkan salah satu daripada mereka.
Dan masalahnya ialah kita mempunyai CP-infiniti. Oleh itu, kemungkinan besar kita boleh bangun yang lebih lewat. Dan jika, sebagai contoh, kita membangkitkan yang kemudian, kita akan menunggu orang yang baru menerima blok itu, jadi kita tidak menentukan siapa sebenarnya yang akan dikejutkan terlebih dahulu. Kami hanya mencipta situasi sedemikian, dan sistem akan membangkitkan mereka dalam susunan rawak.
Terdapat . Lihat, mereka juga menarik dan berguna. Topiknya, tentu saja, sangat kompleks. Terima kasih banyak, Bruce!
Sumber: www.habr.com