Transkrip pembicaraan Bruce Momjian tahun 2020 "Membuka Kunci Manajer Kunci Postgres".
(Catatan: Semua kueri SQL dari slide dapat diperoleh dari tautan ini: )
Halo! Senang rasanya bisa berada di sini lagi di Rusia. Maaf saya tidak bisa datang tahun lalu, tapi tahun ini Ivan dan saya punya rencana besar. Saya berharap bisa berada di sini lebih sering lagi. Saya senang datang ke Rusia. Saya akan mengunjungi Tyumen, Tver. Saya sangat senang bisa mengunjungi kota-kota ini.
Nama saya Bruce Momjian. Saya bekerja di EnterpriseDB dan telah bekerja dengan Postgres selama lebih dari 23 tahun. Saya tinggal di Philadelphia, AS. Saya bepergian sekitar 90 hari setahun. Dan saya menghadiri sekitar 40 konferensi. -ku , yang berisi slide yang sekarang akan saya tunjukkan kepada Anda. Oleh karena itu, setelah konferensi Anda dapat mendownloadnya dari situs pribadi saya. Ini juga berisi sekitar 30 presentasi. Ada juga video dan entri blog dalam jumlah besar, lebih dari 500. Ini adalah sumber yang cukup informatif. Dan jika Anda tertarik dengan materi ini, maka saya mengundang Anda untuk menggunakannya.
Saya pernah menjadi guru, profesor sebelum mulai bekerja dengan Postgres. Dan saya sangat senang bahwa sekarang saya dapat memberi tahu Anda apa yang akan saya sampaikan kepada Anda. Ini adalah salah satu presentasi saya yang paling menarik. Dan presentasi ini berisi 110 slide. Kami akan mulai berbicara dengan hal-hal sederhana, dan pada akhirnya laporan akan menjadi semakin kompleks, dan akan menjadi sangat kompleks.
Ini adalah percakapan yang tidak menyenangkan. Pemblokiran bukanlah topik yang paling populer. Kami ingin ini hilang entah kemana. Ini seperti pergi ke dokter gigi.
- Penguncian adalah masalah bagi banyak orang yang bekerja di database dan menjalankan banyak proses secara bersamaan. Mereka perlu pemblokiran. Artinya, hari ini saya akan memberikan pengetahuan dasar tentang pemblokiran.
- ID Transaksi. Ini adalah bagian presentasi yang agak membosankan, namun perlu dipahami.
- Selanjutnya kita akan berbicara tentang jenis pemblokiran. Ini adalah bagian yang cukup mekanis.
- Dan dibawah ini kami akan memberikan beberapa contoh pemblokiran. Dan itu akan sangat sulit untuk dipahami.
Mari kita bicara tentang pemblokiran.
Terminologi kami cukup rumit. Berapa banyak dari Anda yang mengetahui dari mana ayat ini berasal? Dua orang. Ini dari game bernama Colossal Cave Adventure. Menurut saya, itu adalah permainan komputer berbasis teks di tahun 80an. Di sana Anda harus masuk ke dalam gua, ke dalam labirin, dan teksnya berubah, tetapi isinya kira-kira sama setiap saat. Begitulah cara saya mengingat pertandingan ini.
Dan di sini kita melihat nama kunci yang datang kepada kita dari Oracle. Kami menggunakannya.
Di sini kita melihat istilah-istilah yang membingungkan saya. Misalnya, SHARE UPDATE ECXLUSIVE. Berikutnya BAGIKAN MENTAH ECXLUSIVE. Sejujurnya, nama-nama ini tidak begitu jelas. Kami akan mencoba mempertimbangkannya lebih detail. Ada pula yang mengandung kata “berbagi” yang artinya memisahkan. Beberapa mengandung kata “eksklusif”. Beberapa mengandung kedua kata ini. Saya ingin memulai dengan cara kerja kunci ini.
Dan kata “akses” juga sangat penting. Dan kata “baris” adalah sebuah string. Artinya, distribusi akses, distribusi baris.
Masalah lain yang perlu dipahami di Postgres, yang sayangnya tidak dapat saya bahas dalam ceramah saya, adalah MVCC. Saya memiliki presentasi terpisah tentang topik ini di situs web saya. Dan jika menurut Anda presentasi ini sulit, MVCC mungkin adalah yang tersulit menurut saya. Dan jika Anda tertarik, Anda bisa menontonnya di website. Anda dapat menonton videonya.
Hal lain yang perlu kita pahami adalah ID transaksi. Banyak transaksi tidak dapat berjalan tanpa pengidentifikasi unik. Dan berikut kami ada penjelasan mengenai apa itu transaksi. Postgres memiliki dua sistem penomoran transaksi. Saya tahu ini bukanlah solusi yang bagus.
Perlu diingat juga bahwa slide akan cukup sulit untuk dipahami, sehingga yang disorot dengan warna merah itulah yang perlu Anda perhatikan.
Mari kita lihat. Nomor transaksi disorot dengan warna merah. Fungsi SELECT pg_back ditampilkan di sini. Ini mengembalikan transaksi saya dan ID transaksi.
Satu hal lagi, jika Anda menyukai presentasi ini dan ingin menjalankannya di database Anda, maka Anda dapat membuka link berwarna pink ini dan mendownload SQL untuk presentasi ini. Dan Anda cukup menjalankannya di PSQL Anda dan seluruh presentasi akan segera muncul di layar Anda. Itu tidak akan berisi bunga, tapi setidaknya kita bisa melihatnya.
Dalam hal ini kita melihat ID transaksi. Ini adalah nomor yang kami berikan padanya. Dan ada jenis ID transaksi lain di Postgres, yang disebut ID transaksi virtual
Dan kita harus memahami hal ini. Ini sangat penting, jika tidak, kita tidak akan bisa memahami penguncian di Postgres.
ID transaksi virtual adalah ID transaksi yang tidak berisi nilai persisten. Misalnya, jika saya menjalankan perintah SELECT, kemungkinan besar saya tidak akan mengubah database, saya tidak akan mengunci apa pun. Jadi saat kami menjalankan SELECT sederhana, kami tidak memberikan ID persisten pada transaksi tersebut. Kami hanya memberinya ID virtual di sana.
Dan ini meningkatkan kinerja Postgres, meningkatkan kemampuan pembersihan, sehingga ID transaksi virtual terdiri dari dua angka. Angka pertama sebelum garis miring adalah ID backend. Dan di sebelah kanan kita hanya melihat sebuah counter.
Oleh karena itu, jika saya menjalankan permintaan, dikatakan bahwa ID backend adalah 2.
Dan jika saya menjalankan serangkaian transaksi seperti itu, maka kita melihat bahwa penghitungnya bertambah setiap kali saya menjalankan kueri. Misalnya, ketika saya menjalankan kueri 2/10, 2/11, 2/12, dll.
Perlu diingat bahwa ada dua kolom di sini. Di sebelah kiri kita melihat ID transaksi virtual – 2/12. Dan di sebelah kanan kami memiliki ID transaksi permanen. Dan bidang ini kosong. Dan transaksi ini tidak mengubah database. Jadi saya tidak memberikannya ID transaksi permanen.
Segera setelah saya menjalankan perintah analisis ((ANALYZE)), kueri yang sama memberi saya ID transaksi permanen. Lihat bagaimana hal ini berubah bagi kita. Saya tidak memiliki ID ini sebelumnya, tetapi sekarang saya memilikinya.
Jadi inilah permintaan lain, transaksi lain. Nomor transaksi virtual adalah 2/13. Dan jika saya meminta ID transaksi persisten, maka ketika saya menjalankan kueri, saya akan mendapatkannya.
Jadi, sekali lagi. Kami memiliki ID transaksi virtual dan ID transaksi persisten. Pahami saja poin ini untuk memahami perilaku Postgres.
Kami melanjutkan ke bagian ketiga. Di sini kita hanya akan membahas berbagai jenis kunci di Postgres. Itu tidak terlalu menarik. Bagian terakhir akan jauh lebih menarik. Tapi kita harus mempertimbangkan hal-hal mendasar, karena kalau tidak kita tidak akan mengerti apa yang akan terjadi selanjutnya.
Kita akan membahas bagian ini, kita akan melihat setiap jenis kunci. Dan saya akan menunjukkan kepada Anda contoh cara pemasangannya, cara kerjanya, saya akan menunjukkan beberapa pertanyaan yang dapat Anda gunakan untuk melihat cara kerja penguncian di Postgres.
Untuk membuat kueri dan melihat apa yang terjadi di Postgres, kita perlu mengeluarkan kueri di tampilan sistem. Dalam hal ini, pg_lock disorot dengan warna merah. Pg_lock adalah tabel sistem yang memberi tahu kita kunci apa yang sedang digunakan di Postgres.
Namun, sangat sulit bagi saya untuk menampilkan pg_lock sendiri karena cukup rumit. Jadi saya membuat tampilan yang menunjukkan pg_locks. Dan itu juga bermanfaat bagi saya yang memungkinkan saya untuk memahaminya dengan lebih baik. Artinya, ini tidak termasuk kunci saya, sesi saya sendiri, dll. Ini hanya SQL standar dan memungkinkan Anda menunjukkan dengan lebih baik apa yang terjadi.
Masalah lainnya adalah tampilan ini sangat luas, jadi saya harus membuat tampilan kedua - lockview2.
Dan itu menunjukkan lebih banyak kolom dari tabel. Dan satu lagi yang menunjukkan kolom lainnya. Ini cukup rumit, jadi saya mencoba menyajikannya sesederhana mungkin.
Jadi kami membuat tabel bernama Lockdemo. Dan kami membuat satu baris di sana. Ini adalah tabel sampel kami. Dan kami akan membuat bagian hanya untuk menunjukkan contoh kunci.
Jadi, satu baris, satu kolom. Jenis kunci pertama disebut ACCESS SHARE. Ini adalah pemblokiran yang paling tidak ketat. Artinya praktis tidak bertentangan dengan kunci lainnya.
Dan jika kita ingin mendefinisikan kunci secara eksplisit, kita menjalankan perintah “lock table”. Dan itu jelas akan memblokir, mis. dalam mode ACCESS SHARE kami meluncurkan tabel kunci. Dan jika saya menjalankan PSQL di latar belakang, maka saya memulai sesi kedua dari sesi pertama saya dengan cara ini. Artinya, apa yang akan saya lakukan di sini? Saya pergi ke sesi lain dan memberitahunya "tunjukkan lockview untuk permintaan ini." Dan di sini saya memiliki AccessShareLock di tabel ini. Inilah yang saya minta. Dan dia mengatakan bahwa blok tersebut telah ditetapkan. Sangat sederhana.
Selanjutnya jika kita lihat kolom kedua, maka disana tidak ada apa-apa. Mereka kosong.
Dan jika saya menjalankan perintah "PILIH", maka ini adalah cara implisit (eksplisit) untuk meminta AccessShareLock. Jadi saya melepaskan tabel saya dan menjalankan kueri dan kueri mengembalikan beberapa baris. Dan di salah satu baris kita melihat AccessShareLock. Jadi, SELECT memanggil AccessShareLock di atas meja. Dan itu tidak bertentangan dengan apa pun karena ini adalah kunci tingkat rendah.
Bagaimana jika saya menjalankan SELECT dan memiliki tiga tabel berbeda? Sebelumnya saya hanya menjalankan satu tabel, sekarang saya menjalankan tiga: pg_class, pg_namespace dan pg_attribute.
Dan sekarang ketika saya melihat kuerinya, saya melihat 9 AccessShareLocks dalam tiga tabel. Mengapa? Tiga tabel disorot dengan warna biru: pg_attribute, pg_class, pg_namespace. Namun Anda juga dapat melihat bahwa semua indeks yang ditentukan melalui tabel ini juga memiliki AccessShareLock.
Dan ini adalah kunci yang praktis tidak bertentangan dengan yang lain. Dan yang dilakukannya hanyalah mencegah kita menyetel ulang tabel saat kita memilihnya. Masuk akal. Maksudnya kalau kita pilih suatu tabel, seketika itu juga hilang, berarti ini salah ya AccessShare adalah kunci tingkat rendah yang memberitahu kita "jangan jatuhkan tabel ini saat saya sedang bekerja". Intinya, hanya itu yang dia lakukan.
BARIS BAGI - Kunci ini sedikit berbeda.
Mari kita ambil contoh. Metode SELECT ROW SHARE mengunci setiap baris satu per satu. Dengan cara ini tidak ada yang bisa menghapus atau mengubahnya saat kita menontonnya.
Jadi apa fungsi SHARE LOCK? Kami melihat bahwa ID transaksi adalah 681 untuk SELECT. Dan ini menarik. Apa yang terjadi disini? Pertama kali kita melihat nomor tersebut ada di kolom “Kunci”. Kami mengambil ID transaksi dan dikatakan memblokirnya dalam mode eksklusif. Yang dilakukannya hanyalah dikatakan saya memiliki baris yang secara teknis terkunci di suatu tempat di tabel. Namun dia tidak menyebutkan di mana tepatnya. Kita akan melihatnya lebih detail nanti.
Di sini kami mengatakan bahwa kunci itu digunakan oleh kami.
Jadi, kunci eksklusif secara eksplisit menyatakan bahwa itu eksklusif. Dan juga jika Anda menghapus satu baris dalam tabel ini, maka inilah yang akan terjadi, seperti yang Anda lihat.
SHARE EXCLUSIVE adalah kunci yang lebih panjang.
Ini adalah perintah penganalisis (ANALYZE) yang akan digunakan.
SHARE LOCK – Anda dapat mengunci secara eksplisit dalam mode berbagi.
Anda juga dapat membuat indeks unik. Dan di sana Anda dapat melihat SHARE LOCK, yang merupakan bagian darinya. Dan itu mengunci meja dan memasang SHARE LOCK di atasnya.
Secara default, SHARE LOCK pada suatu tabel berarti orang lain dapat membaca tabel tersebut, tetapi tidak ada yang dapat memodifikasinya. Dan inilah yang terjadi saat Anda membuat indeks unik.
Jika saya membuat indeks bersamaan yang unik, maka saya akan memiliki jenis penguncian yang berbeda karena, seperti yang Anda ingat, menggunakan indeks bersamaan mengurangi persyaratan penguncian. Dan jika saya menggunakan kunci normal, indeks normal, maka saya akan mencegah penulisan ke indeks tabel saat sedang dibuat. Jika saya menggunakan indeks secara bersamaan, maka saya perlu menggunakan jenis penguncian yang berbeda.
SHARE ROW EXCLUSIVE – lagi-lagi dapat diatur secara eksplisit (eksplisit).
Atau kita dapat membuat aturan, yaitu mengambil kasus tertentu yang akan digunakan.
Penguncian EKSKLUSIF berarti tidak ada orang lain yang dapat mengubah tabel.
Di sini kita melihat berbagai jenis kunci.
ACCESS EXCLUSIVE, misalnya, adalah perintah pemblokiran. Misalnya, jika Anda melakukannya CLUSTER table, maka ini berarti tidak ada seorang pun yang bisa menulis di sana. Dan itu tidak hanya mengunci tabel itu sendiri, tetapi juga indeksnya.
Ini adalah halaman kedua dari pemblokiran ACCESS EXCLUSIVE, di mana kita melihat dengan tepat apa yang diblokir di tabel. Ini mengunci baris tabel individual, yang cukup menarik.
Itu saja informasi dasar yang ingin saya berikan. Kita berbicara tentang kunci, tentang ID transaksi, kita berbicara tentang ID transaksi virtual, tentang ID transaksi permanen.
Dan sekarang kita akan membahas beberapa contoh pemblokiran. Ini adalah bagian yang paling menarik. Kami akan melihat kasus-kasus yang sangat menarik. Dan tujuan saya dalam presentasi ini adalah memberi Anda pemahaman yang lebih baik tentang apa yang sebenarnya dilakukan Postgres ketika mencoba memblokir hal-hal tertentu. Menurutku dia sangat pandai memblokir bagian-bagian.
Mari kita lihat beberapa contoh spesifik.
Kita akan mulai dengan tabel dan satu baris dalam sebuah tabel. Saat saya memasukkan sesuatu, saya memiliki ExclusiveLock, ID Transaksi, dan ExclusiveLock yang ditampilkan di tabel.
Apa yang terjadi jika saya menyisipkan dua baris lagi? Dan sekarang meja kita memiliki tiga baris. Dan saya menyisipkan satu baris dan mendapatkan ini sebagai output. Dan jika saya menyisipkan dua baris lagi, apa yang aneh? Ada yang aneh di sini karena saya telah menambahkan tiga baris ke tabel ini, tetapi saya masih memiliki dua baris di tabel kunci. Dan ini pada dasarnya adalah perilaku mendasar Postgres.
Banyak orang berpikir jika dalam database Anda mengunci 100 baris, maka Anda perlu membuat 100 entri kunci. Jika saya memblokir 1 baris sekaligus, maka saya memerlukan 000 pertanyaan seperti itu. Dan jika saya membutuhkan satu juta atau satu miliar untuk diblokir. Namun jika kita melakukan hal ini, hasilnya tidak akan baik. Jika Anda telah menggunakan sistem yang membuat entri pemblokiran untuk setiap baris, Anda dapat melihat bahwa ini rumit. Karena Anda perlu segera mendefinisikan tabel kunci yang bisa meluap, tetapi Postgres tidak melakukan itu.
Dan apa yang benar-benar penting tentang slide ini adalah bahwa slide ini dengan jelas menunjukkan bahwa ada sistem lain yang berjalan di dalam MVCC yang mengunci setiap baris. Jadi ketika Anda mengunci miliaran baris, Postgres tidak membuat satu miliar perintah penguncian terpisah. Dan ini berdampak sangat baik terhadap produktivitas.
Bagaimana dengan pembaruan? Saya memperbarui barisnya sekarang, dan Anda dapat melihat bahwa baris tersebut telah melakukan dua operasi berbeda sekaligus. Itu mengunci tabel pada saat yang sama, tetapi juga mengunci indeks. Dan dia perlu mengunci indeks karena ada batasan unik pada tabel ini. Dan kami ingin memastikan tidak ada yang mengubahnya, jadi kami memblokirnya.
Apa yang terjadi jika saya ingin memperbarui dua baris? Dan kita melihat bahwa dia berperilaku sama. Kami melakukan pembaruan dua kali lebih banyak, tetapi jumlah garis kuncinya sama persis.
Jika Anda bertanya-tanya bagaimana Postgres melakukan ini, Anda harus mendengarkan pembicaraan saya di MVCC untuk mempelajari bagaimana Postgres secara internal menandai baris-baris yang diubahnya. Dan Postgres memiliki cara untuk melakukan hal ini, tetapi ia tidak melakukannya pada tingkat penguncian tabel, ia melakukannya pada tingkat yang lebih rendah dan lebih efisien.
Bagaimana jika saya ingin menghapus sesuatu? Jika saya menghapus, misalnya, satu baris dan saya masih memiliki dua input pemblokiran, dan meskipun saya ingin menghapus semuanya, keduanya masih ada.
Dan, misalnya, saya ingin menyisipkan 1 baris, lalu menghapus atau menambahkan 000 baris, maka setiap baris yang saya tambahkan atau ubah, tidak dicatat di sini. Mereka ditulis pada tingkat yang lebih rendah dalam seri itu sendiri. Dan pada pidato MVCC saya membicarakan hal ini secara detail. Namun sangat penting ketika Anda menganalisis kunci untuk memastikan bahwa Anda mengunci di tingkat tabel dan Anda tidak melihat bagaimana setiap baris dicatat di sini.
Bagaimana dengan pemblokiran eksplisit?
Jika saya mengklik segarkan, dua baris saya terkunci. Dan jika saya memilih semuanya dan mengklik “perbarui di mana saja”, maka saya masih memiliki dua catatan pemblokiran.
Kami tidak membuat catatan terpisah untuk setiap baris individual. Karena produktivitas turun, mungkin jumlahnya terlalu banyak. Dan kita mungkin mendapati diri kita berada dalam situasi yang tidak menyenangkan.
Dan hal yang sama, jika kita berbagi, kita bisa melakukannya sebanyak 30 kali.
Kami memulihkan tabel kami, menghapus semuanya, lalu memasukkan satu baris lagi.
Perilaku lain yang Anda lihat di Postgres yang merupakan perilaku yang sangat terkenal dan diinginkan adalah Anda dapat melakukan pembaruan atau pemilihan. Dan Anda dapat melakukan ini secara bersamaan. Dan pilih tidak memblokir pembaruan dan hal yang sama sebaliknya. Kami memberitahu pembaca untuk tidak memblokir penulis, dan penulis tidak memblokir pembaca.
Saya akan menunjukkan contohnya kepada Anda. Saya akan membuat pilihan sekarang. Kami kemudian akan melakukan INSERT. Dan kemudian Anda dapat melihat - 694. Anda dapat melihat ID transaksi yang melakukan penyisipan ini. Dan begitulah cara kerjanya.
Dan kalau saya lihat ID backend saya sekarang, sekarang 695.
Dan saya dapat melihat 695 muncul di meja saya.
Dan jika saya update di sini seperti ini, maka saya mendapatkan kasus yang berbeda. Dalam hal ini, 695 adalah kunci eksklusif, dan pembaruan memiliki perilaku yang sama, namun tidak ada konflik di antara keduanya, yang merupakan hal yang sangat tidak biasa.
Dan Anda dapat melihat bahwa di bagian atas adalah ShareLock, dan di bagian bawah adalah ExclusiveLock. Dan kedua transaksi berhasil.
Dan Anda perlu mendengarkan ceramah saya di MVCC untuk memahami bagaimana hal ini terjadi. Namun ini ilustrasi bahwa Anda dapat melakukannya secara bersamaan, yaitu melakukan SELECT dan UPDATE secara bersamaan.
Mari kita atur ulang dan lakukan satu operasi lagi.
Jika Anda mencoba menjalankan dua pembaruan secara bersamaan pada baris yang sama, pembaruan tersebut akan diblokir. Dan ingat, saya katakan bahwa pembaca tidak memblokir penulis, dan penulis tidak memblokir pembaca, tetapi penulis yang satu memblokir penulis yang lain. Artinya, kita tidak bisa membiarkan dua orang memperbarui baris yang sama secara bersamaan. Anda harus menunggu sampai salah satunya selesai.
Dan untuk mengilustrasikannya, saya akan melihat tabel Lockdemo. Dan kita akan melihat satu baris. Per transaksi 698.
Kami telah memperbarui ini menjadi 2. 699 adalah pembaruan pertama. Dan berhasil atau sedang dalam transaksi pending dan menunggu kami konfirmasi atau pembatalan.
Tapi lihat hal lain - 2/51 adalah transaksi pertama kami, sesi pertama kami. 3/112 adalah permintaan kedua yang datang dari atas yang mengubah nilai itu menjadi 3. Dan jika Anda perhatikan, yang teratas mengunci dirinya sendiri, yaitu 699. Namun 3/112 tidak memberikan kunci tersebut. Kolom Lock_mode menyatakan apa yang ditunggu. Diperkirakan 699. Dan jika Anda melihat di mana 699 berada, itu lebih tinggi. Dan apa yang dilakukan sesi pertama? Dia membuat kunci eksklusif pada ID transaksinya sendiri. Beginilah cara Postgres melakukannya. Ini memblokir ID transaksinya sendiri. Dan jika Anda ingin menunggu seseorang mengkonfirmasi atau membatalkan, maka Anda perlu menunggu selama ada transaksi yang tertunda. Dan itulah mengapa kita bisa melihat garis yang aneh.
Mari kita lihat lagi. Di sebelah kiri kami melihat ID pemrosesan kami. Di kolom kedua kita melihat ID transaksi virtual kita, dan di kolom ketiga kita melihat lock_type. Apa artinya ini? Pada dasarnya apa yang dikatakannya adalah memblokir ID transaksi. Namun perhatikan bahwa semua baris di bawah menyatakan relasi. Jadi Anda memiliki dua jenis kunci di atas meja. Ada kunci relasi. Dan kemudian ada pemblokiran transaksiid, di mana Anda memblokir sendiri, itulah yang terjadi di baris pertama atau paling bawah, di mana transaksiid berada, di mana kita menunggu 699 menyelesaikan operasinya.
Saya akan melihat apa yang terjadi di sini. Dan di sini dua hal terjadi secara bersamaan. Anda sedang melihat kunci ID transaksi di baris pertama yang mengunci sendiri. Dan dia menghalangi dirinya sendiri untuk membuat orang menunggu.
Jika Anda melihat baris ke-6, itu adalah entri yang sama dengan baris pertama. Dan oleh karena itu transaksi 699 diblokir. 700 juga mengunci sendiri. Dan kemudian di baris bawah Anda akan melihat bahwa kami sedang menunggu 699 menyelesaikan operasinya.
Dan di lock_type, tuple Anda melihat angka.
Anda dapat melihatnya 0/10. Dan ini adalah nomor halaman, dan juga offset dari baris ini.
Dan Anda melihatnya menjadi 0/11 saat kami memperbarui.
Namun kenyataannya 0/10, karena operasi ini harus menunggu. Kami memiliki kesempatan untuk melihat bahwa ini adalah seri yang saya tunggu untuk dikonfirmasi.
Setelah kami mengonfirmasinya dan menekan komit, dan ketika pembaruan selesai, inilah yang kami dapatkan lagi. Transaksi 700 adalah satu-satunya kunci, tidak menunggu orang lain karena sudah dilakukan. Itu hanya menunggu transaksi selesai. Begitu 699 habis, kita tidak perlu menunggu apa pun lagi. Dan sekarang transaksi 700 mengatakan semuanya baik-baik saja, ia memiliki semua kunci yang diperlukan pada semua tabel yang diizinkan.
Dan untuk membuat semuanya menjadi lebih rumit, kita membuat tampilan lain, yang kali ini akan memberi kita hierarki. Saya tidak berharap Anda memahami permintaan ini. Tapi ini akan memberi kita pandangan yang lebih jelas tentang apa yang sedang terjadi.
Ini adalah tampilan rekursif yang juga memiliki bagian lain. Dan kemudian itu menyatukan semuanya kembali. Ayo gunakan ini.
Bagaimana jika kita melakukan tiga pembaruan secara bersamaan dan mengatakan bahwa barisnya sekarang menjadi tiga. Dan kami akan mengubah 3 menjadi 4.
Dan disini kita lihat 4. Dan ID transaksi 702.
Lalu saya ubah 4 menjadi 5. Dan 5 menjadi 6, dan 6 menjadi 7. Dan saya akan mengurutkan beberapa orang yang akan menunggu transaksi yang satu ini selesai.
Dan semuanya menjadi jelas. Apa baris pertama? Ini 702. Ini adalah ID transaksi yang awalnya menetapkan nilai ini. Apa yang tertulis di kolom Diberikan saya? Saya punya tanda f. Demikian update saya yang (5, 6, 7) belum bisa disetujui karena menunggu ID transaksi 702 berakhir. Di sana kami memiliki pemblokiran ID transaksi. Dan ini menghasilkan 5 kunci ID transaksional.
Dan jika Anda melihat 704, di 705, belum ada yang tertulis di sana, karena mereka belum tahu apa yang sedang terjadi. Mereka hanya menulis bahwa mereka tidak tahu apa yang sedang terjadi. Dan mereka hanya akan tidur karena menunggu seseorang selesai dan dibangunkan ketika ada kesempatan untuk berganti barisan.
Seperti inilah tampilannya. Jelas mereka semua menunggu baris ke-12.
Inilah yang kami lihat di sini. Ini 0/12.
Jadi, setelah transaksi pertama disetujui, di sini Anda dapat melihat cara kerja hierarkinya. Dan sekarang semuanya menjadi jelas. Semuanya menjadi bersih. Dan mereka sebenarnya masih menunggu.
Inilah yang terjadi. 702 berkomitmen. Dan sekarang 703 mendapatkan kunci baris ini, dan kemudian 704 mulai menunggu 703 untuk melakukan. Dan 705 juga menunggu hal ini. Dan ketika semua ini selesai, mereka membersihkan diri. Dan saya ingin menunjukkan bahwa semua orang mengantri. Dan ini sangat mirip dengan situasi kemacetan lalu lintas ketika semua orang sedang menunggu mobil pertama. Mobil pertama berhenti dan semua orang berbaris dalam antrean panjang. Kemudian bergerak, lalu mobil berikutnya dapat melaju ke depan dan mendapatkan bloknya, dan seterusnya.
Dan jika hal ini tampaknya tidak cukup rumit bagi Anda, sekarang kami akan membahas tentang kebuntuan. Saya tidak tahu siapa di antara Anda yang pernah menemuinya. Ini adalah masalah yang cukup umum dalam sistem database. Namun kebuntuan terjadi ketika satu sesi menunggu sesi lain untuk melakukan sesuatu. Dan saat ini sesi lain sedang menunggu sesi pertama untuk melakukan sesuatu.
Dan, misalnya, 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 kepadamu jika kamu tidak memberikannya kepadaku.” Dan kita berakhir dalam situasi kebuntuan. Saya yakin Ivan tidak akan melakukan ini, tetapi Anda memahami arti bahwa kita memiliki dua orang yang ingin mendapatkan sesuatu dan mereka belum siap untuk memberikannya sampai orang lain memberikan apa yang mereka inginkan. Dan tidak ada solusi.
Dan pada dasarnya, database Anda perlu mendeteksi hal ini. Dan kemudian Anda perlu menghapus atau menutup salah satu sesi, karena jika tidak, sesi tersebut akan tetap ada selamanya. Dan kami melihatnya di database, kami melihatnya di sistem operasi. Dan di semua tempat di mana kita memiliki proses paralel, hal ini bisa terjadi.
Dan sekarang kita akan memasang dua kebuntuan. Kita masukkan 50 dan 80. Di baris pertama, saya perbarui dari 50 menjadi 50. Saya akan mendapatkan nomor transaksi 710.
Lalu saya akan mengubah 80 menjadi 81, dan 50 menjadi 51.
Dan seperti inilah tampilannya. Jadi 710 memiliki satu baris yang diblokir, dan 711 menunggu konfirmasi. Kami melihat ini ketika kami memperbarui. 710 adalah pemilik seri kami. Dan 711 menunggu 710 menyelesaikan transaksi.
Dan bahkan disebutkan di baris mana kebuntuan terjadi. Dan di sinilah hal itu mulai menjadi aneh.
Sekarang kami memperbarui 80 menjadi 80.
Dan disinilah kebuntuan dimulai. 710 menunggu jawaban dari 711, dan 711 menunggu 710. Dan ini tidak akan berakhir dengan baik. Dan tidak ada jalan keluar dari hal ini. Dan mereka akan mengharapkan tanggapan dari satu sama lain.
Dan itu akan mulai menunda segalanya. Dan kami tidak menginginkan itu.
Dan Postgres memiliki cara untuk memperhatikan ketika hal ini terjadi. Dan ketika ini terjadi, Anda mendapatkan kesalahan ini. Dan dari sini jelas bahwa proses ini dan itu sedang menunggu SHARE LOCK dari proses lain, yaitu diblokir oleh proses 711. Dan proses itu menunggu SHARE LOCK diberikan pada ID transaksi ini dan itu dan diblokir oleh proses ini dan itu. Oleh karena itu, ada situasi kebuntuan di sini.
Apakah ada kebuntuan tiga arah? Apa itu mungkin? Ya.
Kami memasukkan angka-angka ini ke dalam tabel. Kita ubah 40 menjadi 40, kita lakukan pemblokiran.
Kami mengubah 60 menjadi 61, 80 menjadi 81.
Lalu kita ubah 80 dan kemudian booming!
Dan 714 sekarang menunggu 715. Yang ke 716 sedang menunggu yang ke 715. Dan tidak ada yang bisa dilakukan mengenai hal itu.
Tidak ada lagi dua orang di sini, sudah ada tiga orang di sini. Aku menginginkan sesuatu darimu, yang ini menginginkan sesuatu dari orang ketiga, dan orang ketiga menginginkan sesuatu dariku. Dan kita berakhir dalam penantian tiga arah karena kita semua menunggu orang lain menyelesaikan apa yang perlu mereka lakukan.
Dan Postgres tahu di baris mana hal ini terjadi. Maka itu akan memberi Anda pesan berikut, yang menunjukkan bahwa Anda mempunyai masalah ketika tiga input saling memblokir. Dan tidak ada batasan di sini. Ini mungkin terjadi ketika 20 entri saling memblokir.
Masalah selanjutnya adalah serializable.
Jika kunci serializable khusus.
Dan kita kembali ke 719. Outputnya cukup normal.
Dan Anda dapat mengklik untuk melakukan transaksi dari serializable.
Dan Anda menyadari bahwa Anda sekarang memiliki jenis kunci SA yang berbeda - artinya dapat diserialkan.
Jadi kami memiliki jenis kunci baru yang disebut SARieadLock, yang merupakan kunci serial dan memungkinkan Anda memasukkan serial.
Dan Anda juga dapat memasukkan indeks unik.
Dalam tabel ini kami memiliki indeks unik.
Jadi kalau saya masukkan angka 2 di sini, maka saya punya angka 2. Tapi di bagian paling atas, saya masukkan angka 2 lagi. Dan Anda dapat melihat bahwa 721 memiliki kunci eksklusif. Namun sekarang 722 menunggu 721 menyelesaikan operasinya karena ia tidak dapat memasukkan 2 sampai ia mengetahui apa yang akan terjadi pada 721.
Dan jika kita melakukan subtransaksi.
Di sini kita memiliki 723.
Dan jika kita menyimpan point tersebut lalu mengupdatenya, maka kita mendapatkan ID transaksi baru. Ini adalah pola perilaku lain yang perlu Anda waspadai. Jika kami mengembalikan ini, maka ID transaksinya akan hilang. 724 daun. Tapi sekarang kita punya 725.
Jadi apa yang saya coba lakukan di sini? Saya mencoba menunjukkan contoh kunci tidak biasa yang mungkin Anda temukan: apakah itu kunci serial atau SAVEPOINT, ini adalah jenis kunci berbeda yang akan muncul di tabel kunci.
Ini adalah pembuatan kunci eksplisit (eksplisit), yang memiliki pg_advisory_lock.
Dan Anda melihat bahwa jenis pemblokiran terdaftar sebagai penasehat. Dan di sini tertulis “penasihat” dengan warna merah. Dan Anda dapat memblokir secara bersamaan seperti ini dengan pg_advisory_unlock.
Dan sebagai penutup, saya ingin menunjukkan kepada Anda satu hal lagi yang menakjubkan. Saya akan membuat tampilan lain. Tapi saya akan menggabungkan tabel pg_locks dengan tabel pg_stat_activity. Dan mengapa saya ingin melakukan ini? Karena ini akan memungkinkan saya untuk melihat dan melihat semua sesi saat ini dan melihat dengan tepat jenis kunci apa yang mereka tunggu. Dan ini cukup menarik ketika kita menyatukan tabel kunci dan tabel query.
Dan di sini kita membuat pg_stat_view.
Dan kami memperbarui baris demi satu. Dan di sini kita melihat 724. Lalu kita perbarui baris kita menjadi tiga. Dan apa yang kamu lihat di sini sekarang? Ini adalah permintaan, yaitu Anda melihat seluruh daftar permintaan yang tercantum di kolom kiri. Lalu di sisi kanan Anda dapat melihat penyumbatan dan apa yang ditimbulkannya. Dan ini bisa menjadi lebih jelas bagi Anda sehingga Anda tidak perlu kembali ke setiap sesi setiap saat dan melihat apakah Anda perlu bergabung atau tidak. Mereka melakukannya untuk kita.
Fitur lain yang sangat berguna adalah pg_blocking_pids. Anda mungkin belum pernah mendengar tentang dia. Apa yang dia lakukan? Hal ini memungkinkan kita untuk mengetahui bahwa untuk sesi ini 11740 ID proses spesifik apa yang ditunggu. Dan terlihat 11740 menunggu 724. Dan 724 berada di paling atas. Dan 11306 adalah ID proses Anda. Pada dasarnya, fungsi ini melewati tabel kunci Anda. Dan saya tahu ini sedikit rumit, tetapi Anda berhasil memahaminya. Pada dasarnya fungsi ini melewati tabel kunci ini dan mencoba menemukan di mana ID proses ini diberi kunci yang sedang ditunggu. Dan ia juga mencoba mencari tahu ID proses mana yang dimiliki oleh proses yang menunggu untuk dikunci. Jadi Anda dapat menjalankan fungsi ini pg_blocking_pids.
Dan ini bisa sangat berguna. Kami baru menambahkan ini di versi 9.6, jadi fitur ini baru berumur 5 tahun, namun sangat-sangat berguna. Dan hal yang sama berlaku untuk permintaan kedua. Ini menunjukkan dengan tepat apa yang perlu kita lihat.
Inilah yang ingin saya bicarakan dengan Anda. Dan seperti yang saya harapkan, kami menghabiskan seluruh waktu kami karena ada begitu banyak slide. Dan slide tersedia untuk diunduh. Saya ingin mengucapkan terima kasih karena telah hadir di sini. Saya yakin Anda akan menikmati sisa konferensi ini, terima kasih banyak!
Pertanyaan:
Misalnya, jika saya mencoba memperbarui baris, dan sesi kedua mencoba menghapus seluruh tabel. Sejauh yang saya mengerti, seharusnya ada sesuatu seperti kunci niat. Apakah ada hal seperti itu di Postgres?
Mari kita kembali ke awal. Anda mungkin ingat bahwa ketika Anda melakukan sesuatu, misalnya ketika Anda melakukan SELECT, kami mengeluarkan AccessShareLock. Dan ini mencegah meja terjatuh. Jadi jika Anda, misalnya, ingin memperbarui satu baris dalam tabel atau menghapus satu baris, maka seseorang tidak dapat menghapus seluruh tabel secara bersamaan karena Anda memegang AccessShareLock ini di seluruh tabel dan di atas baris tersebut. Dan setelah Anda selesai, mereka dapat menghapusnya. Tapi sampai Anda langsung mengubah sesuatu di sana, mereka tidak akan bisa melakukannya.
Ayo lakukan lagi. Mari beralih ke contoh penghapusan. Dan Anda lihat bagaimana ada kunci eksklusif pada baris di atas seluruh tabel.
Ini akan terlihat seperti kunci eksklusif, bukan?
Ya, sepertinya begitu. Saya mengerti apa yang Anda bicarakan. Anda mengatakan bahwa jika saya melakukan SELECT lalu saya memiliki ShareExclusive dan kemudian menjadikannya Row Exclusive, apakah itu menjadi masalah? Namun anehnya hal ini tidak menimbulkan masalah. Ini sepertinya meningkatkan derajat kunci, tetapi pada dasarnya saya memiliki kunci yang mencegah penghapusan. Dan sekarang, saat saya membuat kunci ini lebih kuat, kunci ini tetap mencegah penghapusan. Jadi bukan berarti aku akan naik. Maksudnya, mencegah hal itu terjadi ketika berada di level yang lebih rendah juga, jadi ketika saya menaikkan levelnya, tetap mencegah tabel tersebut terhapus.
Saya mengerti apa yang Anda bicarakan. Tidak ada kasus eskalasi kunci di sini, di mana Anda mencoba melepaskan satu kunci untuk memasukkan kunci yang lebih kuat. Di sini hanya meningkatkan pencegahan secara menyeluruh, sehingga tidak menimbulkan konflik apa pun. Tapi itu pertanyaan yang bagus. Terima kasih banyak telah menanyakan hal ini!
Apa yang perlu kita lakukan untuk menghindari situasi kebuntuan ketika kita memiliki banyak sesi, jumlah pengguna banyak?
Postgres secara otomatis mengetahui situasi kebuntuan. Dan secara otomatis akan menghapus salah satu sesi. Satu-satunya cara untuk menghindari pemblokiran mati adalah dengan memblokir orang dalam urutan yang sama. Jadi ketika Anda melihat aplikasi Anda, sering kali terjadi kebuntuan... Bayangkan saya ingin memblokir dua hal yang berbeda. Satu aplikasi mengunci tabel 1, dan aplikasi lain mengunci 2, lalu tabel 1. Dan cara termudah untuk menghindari kebuntuan adalah dengan melihat aplikasi Anda dan mencoba memastikan bahwa penguncian terjadi dalam urutan yang sama di semua aplikasi. Dan ini biasanya menghilangkan 80% masalah, karena semua jenis orang menulis aplikasi ini. Dan jika Anda memblokirnya dalam urutan yang sama, Anda tidak akan menemui situasi kebuntuan.
Terima kasih banyak atas penampilan Anda! Anda berbicara tentang vakum penuh dan, jika saya memahaminya dengan benar, vakum penuh mendistorsi urutan catatan dalam penyimpanan terpisah, sehingga catatan saat ini tidak berubah. Mengapa vakum penuh mengambil akses kunci eksklusif dan mengapa bertentangan dengan operasi tulis?
Itu pertanyaan yang bagus. Alasannya adalah vakum penuh mengambil alih meja. Dan kami pada dasarnya membuat tabel versi baru. Dan mejanya akan baru. Ternyata ini akan menjadi versi tabel yang benar-benar baru. Dan masalahnya adalah ketika kita melakukan ini, kita tidak ingin orang-orang membacanya karena kita ingin mereka melihat tabel baru. Dan ini berhubungan dengan pertanyaan sebelumnya. Jika kita bisa membaca sekaligus, kita tidak akan bisa memindahkannya dan mengarahkan orang ke meja baru. Kita harus menunggu hingga semua orang selesai membaca tabel ini, sehingga pada dasarnya ini adalah situasi eksklusif yang terkunci.
Kami hanya mengatakan bahwa kami mengunci dari awal karena kami tahu bahwa pada akhirnya kami memerlukan kunci eksklusif untuk memindahkan semua orang ke salinan baru. Jadi kita berpotensi dapat menyelesaikan masalah ini. Dan kami melakukannya dengan cara ini dengan pengindeksan secara simultan. Namun hal ini jauh lebih sulit dilakukan. Dan ini sangat berkaitan dengan pertanyaan Anda sebelumnya tentang lock eksklusif.
Apakah mungkin untuk menambahkan batas waktu penguncian ke Postgres? Di Oracle, saya dapat, misalnya, menulis "pilih untuk memperbarui" dan menunggu 50 detik sebelum memperbarui. Itu bagus untuk aplikasinya. Namun di Postgres, saya harus segera melakukannya dan tidak menunggu sama sekali, atau menunggu sampai suatu saat.
Ya, Anda dapat memilih batas waktu pada kunci Anda, pada kunci Anda. Anda juga dapat mengeluarkan perintah larangan, yang akan... jika Anda tidak dapat segera mendapatkan kuncinya. Oleh karena itu, batas waktu penguncian atau hal lain yang memungkinkan Anda melakukan ini. Hal ini tidak dilakukan pada tingkat sintaksis. Ini dilakukan sebagai variabel di server. Terkadang ini tidak dapat digunakan.
Bisakah Anda membuka slide 75?
Ya.
Dan pertanyaan saya adalah sebagai berikut. Mengapa kedua proses pembaruan mengharapkan 703?
Dan ini adalah pertanyaan yang bagus. Ngomong-ngomong, saya tidak mengerti mengapa Postgres melakukan ini. Namun ketika 703 dibuat, ia mengharapkan 702. Dan ketika 704 dan 705 muncul, sepertinya mereka tidak tahu apa yang mereka harapkan karena belum ada apa pun di sana. Dan Postgres melakukannya dengan cara ini: ketika Anda tidak bisa mendapatkan kunci, ia menulis “Apa gunanya memproses Anda?”, karena Anda sudah menunggu seseorang. Jadi kita biarkan saja, tidak akan update sama sekali. Tapi apa yang terjadi di sini? Segera setelah 702 menyelesaikan proses dan 703 menerima kuncinya, sistem kembali lagi. Dan dia bilang sekarang ada dua orang yang menunggu. Lalu mari kita perbarui bersama-sama. Dan mari kita tunjukkan bahwa keduanya mengharapkan.
Saya tidak tahu mengapa Postgres melakukan ini. Tapi ada masalah yang disebut f…. Menurut saya ini bukan istilah dalam bahasa Rusia. Ini adalah saat semua orang menunggu satu kastil, meskipun ada 20 otoritas yang menunggu kastil tersebut. Dan tiba-tiba mereka semua terbangun di waktu yang bersamaan. Dan semua orang mulai mencoba bereaksi. Tapi sistemnya membuat semua orang menunggu 703. Karena mereka semua menunggu, dan kami akan segera mengantre semuanya. Dan jika muncul permintaan baru lainnya yang dihasilkan setelah ini, misalnya 707, maka akan ada kekosongan lagi.
Dan menurut saya hal ini dilakukan agar kita dapat mengatakan bahwa pada tahap ini 702 sedang menunggu 703, dan semua yang datang setelah itu tidak akan memiliki entri apa pun di bidang ini. Tetapi begitu pelayan pertama pergi, semua orang yang menunggu saat itu sebelum pembaruan menerima token yang sama. Jadi menurut saya ini dilakukan agar kita bisa memprosesnya secara berurutan agar pesanannya benar.
Saya selalu memandang ini sebagai fenomena yang agak aneh. Karena di sini misalnya kami tidak mencantumkannya sama sekali. Tapi menurut saya setiap kali kita memberikan kunci baru, kita melihat semua orang yang sedang dalam proses menunggu. Lalu kita menyusun semuanya. Dan kemudian setiap orang baru yang masuk hanya masuk ke antrian ketika orang berikutnya telah selesai diproses. Pertanyaan yang sangat bagus. Terima kasih banyak atas pertanyaan Anda!
Menurut saya, jauh lebih logis jika 705 mengharapkan 704.
Namun masalahnya di sini adalah sebagai berikut. Secara teknis, Anda bisa membangunkan salah satunya. Jadi kita akan membangunkan satu atau yang lain. Tapi apa yang terjadi di sistem? Anda dapat melihat bagaimana 703 di bagian paling atas telah memblokir ID transaksinya sendiri. Beginilah cara kerja Postgres. Dan 703 diblokir oleh ID transaksinya sendiri, jadi jika ada yang mau menunggu maka menunggu 703. Dan intinya 703 selesai. Dan hanya setelah selesai salah satu proses terbangun. Dan kita tidak tahu persis seperti apa proses ini nantinya. Kemudian kami memproses semuanya secara bertahap. Namun tidak jelas proses mana yang dibangkitkan terlebih dahulu, karena bisa saja salah satu dari proses tersebut. Pada dasarnya, kami memiliki penjadwal yang mengatakan bahwa kami sekarang dapat mengaktifkan salah satu proses ini. Kami hanya memilih satu secara acak. Jadi keduanya perlu diperhatikan karena kita bisa membangkitkan salah satunya.
Dan masalahnya adalah kita memiliki CP-infinity. Oleh karena itu, kemungkinan besar kita bisa bangun nanti. Dan kalau misal kita Awaken nanti, kita tunggu yang baru dapat Block, jadi kita tidak menentukan siapa sebenarnya yang akan Awaken dulu. Kami cukup menciptakan situasi seperti itu, dan sistem akan membangunkan mereka dalam urutan acak.
Ada . Lihat, mereka juga menarik dan bermanfaat. Tentu saja topiknya sangat rumit. Terima kasih banyak, Bruce!
Sumber: www.habr.com