Isu penskalaan utama dengan ciri LISTEN/NOTIFY PostgreSQL telah mencetuskan perbincangan meluas dalam komuniti pembangun selepas Recall.ai berkongsi pengalaman mereka dengan masalah prestasi pangkalan data. Syarikat tersebut mendapati bahawa ciri yang kelihatan tidak berbahaya ini boleh menjatuhkan keseluruhan sistem pangkalan data di bawah beban penulisan serentak yang berat.
Masalah Kunci Global Tersembunyi
Ciri LISTEN/NOTIFY PostgreSQL, yang biasa digunakan untuk pemberitahuan masa nyata dan corak pub-sub, mengandungi had seni bina yang mengejutkan. Apabila arahan NOTIFY berjalan dalam transaksi, ia memperoleh kunci global pada keseluruhan pangkalan data semasa fasa komit. Ini secara berkesan mengubah semua komit pangkalan data menjadi barisan satu fail, memusnahkan sepenuhnya keupayaan untuk mengendalikan berbilang penulis secara serentak.
Isu ini menjadi sangat teruk di bawah senario konkurensi tinggi. Recall.ai mengalami ini secara langsung apabila memproses berjuta-juta jam rakaman mesyuarat dengan puluhan ribu penulis serentak. Beban pangkalan data mereka meningkat secara mendadak, tetapi penggunaan CPU dan cakera sebenarnya menurun - tanda jelas bahawa sistem tersekat menunggu kunci daripada melakukan kerja sebenar.
Nota: Kunci global bermaksud hanya satu operasi boleh diteruskan pada satu masa merentasi keseluruhan pangkalan data, menghalang semua transaksi lain daripada selesai.
Isu Penskalaan PostgreSQL LISTEN/NOTIFY:
- Masalah: Kunci pangkalan data global semasa fasa commit NOTIFY
- Impak: Mensirikan semua commit pangkalan data di bawah penulisan serentak
- Simptom: Beban pangkalan data tinggi, penggunaan CPU/cakera rendah, penurunan besar-besaran dalam pemprosesan pertanyaan
- Ambang skala: Menjadi bermasalah dengan puluhan ribu penulis serentak
- Jenis kunci: AccessExclusiveLock pada objek 0 kelas 1262 pangkalan data 0
 |
|---|
| Metrik prestasi sistem yang menyerlahkan kesan penguncian global terhadap operasi pangkalan data |
Reaksi Komuniti dan Penyelesaian Alternatif
Komuniti pembangun telah bertindak balas dengan campuran kami sudah memberitahu anda dan kebimbangan tulen tentang had yang kurang didokumentasikan ini. Ramai pembangun berpengalaman menyatakan bahawa PostgreSQL cemerlang dalam operasi data hubungan tetapi bergelut dengan beban kerja pub-sub konkurensi tinggi.
Beberapa pendekatan alternatif muncul daripada perbincangan. Sesetengah pembangun mengesyorkan menggunakan baris gilir mesej khusus seperti NATS atau Redis untuk operasi pub-sub, manakala yang lain mencadangkan penyelesaian berasaskan undian menggunakan ciri FOR UPDATE SKIP LOCKED PostgreSQL. Pendekatan pemantauan WAL (Write-Ahead Log) juga mendapat perhatian sebagai cara untuk mengesan perubahan pangkalan data tanpa isu penguncian.
Nota: Pemantauan WAL melibatkan menonton log transaksi PostgreSQL untuk perubahan, menyediakan cara untuk bertindak balas kepada kemaskini pangkalan data tanpa menggunakan LISTEN/NOTIFY.
Penyelesaian Alternatif yang Dibincangkan:
- Pendekatan polling: Menggunakan
FOR UPDATE SKIP LOCKEDdengan exponential backoff - Message queues: NATS , Redis , atau Kafka untuk operasi pub-sub
- Pemantauan WAL: Mendengar PostgreSQL Write-Ahead Log untuk perubahan
- Penjejakan lapisan aplikasi: Memindahkan logik pemberitahuan keluar dari pangkalan data
- Corak transactional outbox: Pemprosesan pemberitahuan berasingan selepas commit
Pelajaran untuk Seni Bina Pangkalan Data
Insiden ini menyerlahkan isu yang lebih luas dalam pembangunan perisian moden: godaan untuk menggunakan PostgreSQL sebagai pisau Swiss Army untuk semua keperluan data. Walaupun PostgreSQL sangat serba boleh, menolaknya melampaui kes penggunaan optimumnya boleh membawa kepada kesesakan yang tidak dijangka.
Perbincangan komuniti mendedahkan bahawa ramai pembangun telah menghadapi isu serupa dengan ciri PostgreSQL lain seperti pencetus dan keselamatan peringkat baris di bawah beban tinggi. Konsensus nampaknya ialah walaupun ciri-ciri ini berfungsi dengan baik untuk beban sederhana, ia tidak berskala secara linear dengan peningkatan konkurensi.
Pangkalan data adalah untuk data. Data masuk dan data keluar, tetapi data tidak boleh memutuskan apa yang berlaku seterusnya berdasarkan dirinya sendiri. Itulah fungsi kod aplikasi.
Pengajaran utama ialah kepentingan ujian beban dan memahami implikasi seni bina ciri pangkalan data sebelum menggunakannya dalam pengeluaran. Apa yang berfungsi dengan sempurna untuk ribuan operasi mungkin gagal sepenuhnya pada ratusan ribu.
Bergerak Ke Hadapan
Untuk pembangun yang kini menggunakan LISTEN/NOTIFY, ini tidak bermakna panik segera. Ciri ini berfungsi dengan baik untuk kebanyakan aplikasi dengan beban sederhana. Walau bagaimanapun, adalah wajar untuk mempertimbangkan alternatif jika anda merancang untuk pertumbuhan yang ketara atau sudah mengalami masalah prestasi.
Insiden ini juga menunjukkan nilai pemantauan dan pengelogan yang betul. Recall.ai dapat mengenal pasti jenis kunci khusus yang menyebabkan masalah mereka hanya selepas membolehkan pengelogan kunci terperinci, yang membantu mereka mengesan masalah kembali kepada ciri LISTEN/NOTIFY.
Kes ini berfungsi sebagai peringatan bahawa walaupun sistem pangkalan data yang matang dan dihormati seperti PostgreSQL mempunyai had penskalaan di tempat yang tidak dijangka. Pertahanan terbaik ialah ujian menyeluruh, pemantauan yang betul, dan mempunyai rancangan migrasi yang sedia apabila anda mencapai had tersebut.