Masalah penskalaan besar dengan fitur LISTEN/NOTIFY PostgreSQL telah memicu diskusi luas di komunitas developer setelah Recall.ai membagikan pengalaman mereka dengan masalah performa database. Perusahaan tersebut menemukan bahwa fitur yang tampaknya tidak berbahaya ini dapat meruntuhkan seluruh sistem database di bawah beban tulis bersamaan yang tinggi.
Masalah Kunci Global yang Tersembunyi
Fitur LISTEN/NOTIFY PostgreSQL, yang umum digunakan untuk notifikasi real-time dan pola pub-sub, mengandung keterbatasan arsitektur yang mengejutkan. Ketika perintah NOTIFY berjalan dalam sebuah transaksi, ia memperoleh kunci global pada seluruh database selama fase commit. Ini secara efektif mengubah semua commit database menjadi antrian satu file, sepenuhnya menghancurkan kemampuan untuk menangani beberapa penulis secara bersamaan.
Masalah ini menjadi sangat parah di bawah skenario konkurensi tinggi. Recall.ai mengalami ini secara langsung ketika memproses jutaan jam rekaman rapat dengan puluhan ribu penulis simultan. Beban database mereka melonjak drastis, tetapi penggunaan CPU dan disk justru turun drastis - tanda yang jelas bahwa sistem terjebak menunggu kunci daripada melakukan pekerjaan yang sebenarnya.
Catatan: Kunci global berarti hanya satu operasi yang dapat berjalan pada satu waktu di seluruh database, memblokir semua transaksi lain dari penyelesaian.
Masalah Skalabilitas PostgreSQL LISTEN/NOTIFY:
- Masalah: Kunci database global selama fase commit NOTIFY
- Dampak: Membuat serial semua commit database di bawah penulisan bersamaan
- Gejala: Beban database tinggi, penggunaan CPU/disk rendah, penurunan throughput query yang masif
- Ambang batas skala: Menjadi bermasalah dengan puluhan ribu penulis bersamaan
- Jenis kunci: AccessExclusiveLock pada objek 0 dari kelas 1262 dari database 0
 |
|---|
| Metrik performa sistem yang menyoroti dampak global locking terhadap operasi database |
Reaksi Komunitas dan Solusi Alternatif
Komunitas developer telah merespons dengan campuran kami sudah bilang dan kekhawatiran yang tulus tentang keterbatasan yang kurang terdokumentasi ini. Banyak developer berpengalaman menunjukkan bahwa PostgreSQL unggul dalam operasi data relasional tetapi kesulitan dengan beban kerja pub-sub konkurensi tinggi.
Beberapa pendekatan alternatif muncul dari diskusi tersebut. Beberapa developer merekomendasikan menggunakan antrian pesan khusus seperti NATS atau Redis untuk operasi pub-sub, sementara yang lain menyarankan solusi berbasis polling menggunakan fitur FOR UPDATE SKIP LOCKED PostgreSQL. Pendekatan pemantauan WAL (Write-Ahead Log) juga mendapat perhatian sebagai cara untuk mendeteksi perubahan database tanpa masalah penguncian.
Catatan: Pemantauan WAL melibatkan pengawasan log transaksi PostgreSQL untuk perubahan, menyediakan cara untuk bereaksi terhadap pembaruan database tanpa menggunakan LISTEN/NOTIFY.
Solusi Alternatif yang Dibahas:
- Pendekatan polling: Menggunakan
FOR UPDATE SKIP LOCKEDdengan exponential backoff - Message queues: NATS , Redis , atau Kafka untuk operasi pub-sub
- Pemantauan WAL: Mendengarkan PostgreSQL Write-Ahead Log untuk perubahan
- Pelacakan lapisan aplikasi: Memindahkan logika notifikasi keluar dari database
- Pola transactional outbox: Pemrosesan notifikasi terpisah setelah commit
Pelajaran untuk Arsitektur Database
Insiden ini menyoroti masalah yang lebih luas dalam pengembangan perangkat lunak modern: godaan untuk menggunakan PostgreSQL sebagai pisau Swiss Army untuk semua kebutuhan data. Meskipun PostgreSQL sangat serbaguna, mendorongnya melampaui kasus penggunaan optimalnya dapat menyebabkan kemacetan yang tidak terduga.
Diskusi komunitas mengungkapkan bahwa banyak developer telah mengalami masalah serupa dengan fitur PostgreSQL lainnya seperti trigger dan keamanan tingkat baris di bawah beban tinggi. Konsensusnya tampaknya adalah bahwa meskipun fitur-fitur ini bekerja dengan baik untuk beban sedang, mereka tidak menskalakan secara linear dengan peningkatan konkurensi.
Database adalah untuk data. Data masuk dan data keluar, tetapi data tidak boleh memutuskan apa yang terjadi selanjutnya berdasarkan dirinya sendiri. Itulah gunanya kode aplikasi.
Poin penting yang dapat diambil adalah pentingnya pengujian beban dan memahami implikasi arsitektur dari fitur database sebelum menerapkannya dalam produksi. Apa yang bekerja sempurna untuk ribuan operasi mungkin sepenuhnya gagal pada ratusan ribu.
Bergerak Maju
Untuk developer yang saat ini menggunakan LISTEN/NOTIFY, ini tidak berarti panik segera. Fitur ini bekerja dengan baik untuk sebagian besar aplikasi dengan beban sedang. Namun, ada baiknya mempertimbangkan alternatif jika Anda merencanakan pertumbuhan yang signifikan atau sudah mengalami masalah performa.
Insiden ini juga menunjukkan nilai pemantauan dan logging yang tepat. Recall.ai mampu mengidentifikasi jenis kunci spesifik yang menyebabkan masalah mereka hanya setelah mengaktifkan logging kunci yang detail, yang membantu mereka melacak masalah kembali ke fitur LISTEN/NOTIFY.
Kasus ini berfungsi sebagai pengingat bahwa bahkan sistem database yang matang dan dihormati seperti PostgreSQL memiliki keterbatasan penskalaan di tempat yang tidak terduga. Pertahanan terbaik adalah pengujian menyeluruh, pemantauan yang tepat, dan memiliki rencana migrasi yang siap ketika Anda mencapai batas tersebut.
Referensi: Postgres LISTEN/NOTIFY does not scale