Scaling PostgreSQL TRIGGER (s)

Bagaimana Postgres memicu skala mekanisme?

Kami memiliki instalasi PostgreSQL yang besar dan kami mencoba menerapkan sistem berbasis acara menggunakan tabel log dan TRIGGER.

Pada dasarnya kami ingin membuat TRIGGER untuk setiap tabel yang ingin kami beri tahu untuk operasi UPDATE / INSERT / DELETE. Setelah pemicu ini diaktifkan, ia akan menjalankan fungsi yang hanya akan menambahkan baris baru (penyandian acara) ke tabel log yang kemudian akan kami polling dari layanan eksternal.

Sebelum membahas semua dengan Postgres TRIGGER, kami ingin mengetahui bagaimana skala mereka: berapa banyak pemicu yang dapat kita buat pada satu instalasi Postgres? Apakah mereka memengaruhi kinerja kueri? Adakah yang pernah mencoba ini sebelumnya?

Pada dasarnya kami ingin membuat TRIGGER untuk setiap tabel yang ingin kami beri tahu untuk operasi UPDATE / INSERT / DELETE. Setelah pemicu ini diaktifkan, ia akan menjalankan fungsi yang hanya akan menambahkan baris baru (penyandian acara) ke tabel log yang kemudian akan kami polling dari layanan eksternal.

Itu penggunaan standar yang cukup untuk pemicu.

Sebelum membahas semua dengan Postgres TRIGGER, kami ingin mengetahui bagaimana skala mereka: berapa banyak pemicu yang dapat kita buat pada satu instalasi Postgres?

Jika Anda terus membuatnya, akhirnya Anda akan kehabisan ruang disk.

Tidak ada batasan spesifik untuk pemicu.

Batas postgreSQL didokumentasikan pada halaman tentang .

Apakah mereka memengaruhi kinerja kueri?

Itu tergantung pada jenis pemicu, bahasa pemicu, dan apa yang dilakukan pemicu.

BEFORE ... FOR EACH STATEMENTPemicu PL / PgSQL sederhana yang tidak melakukan apa pun memiliki overhead hampir nol.

FOR EACH ROWpemicu memiliki overhead yang lebih tinggi daripada FOR EACH STATEMENTpemicu. Penskalaan, tentu saja, dengan jumlah baris yang terpengaruh.

AFTERpemicu lebih mahal daripada BEFOREpemicu karena mereka harus antri sampai pernyataan selesai melakukan tugasnya, kemudian dieksekusi. Mereka tidak tumpah ke disk jika antrian menjadi besar (setidaknya di 9,4 dan di bawah, dapat berubah di masa depan) sehingga AFTERantrian pemicu yang besar dapat menyebabkan memori yang tersedia untuk diserbu, yang mengakibatkan pernyataan dibatalkan.

Pemicu yang mengubah NEWbaris sebelum memasukkan / memperbarui lebih murah daripada pemicu yang melakukan DML.

Kasus penggunaan spesifik yang Anda inginkan akan berkinerja lebih baik dengan perangkat tambahan dalam proses yang mungkin membuatnya menjadi PostgreSQL 9.5 (jika kami beruntung), di mana FOR EACH STATEMENTpemicu dapat melihat virtual OLDdan NEWtabel. Ini tidak mungkin dalam versi PostgreSQL saat ini, jadi Anda harus menggunakan FOR EACH ROWpemicu.

Adakah yang pernah mencoba ini sebelumnya?

Tentu saja. Ini penggunaan standar yang cukup untuk pemicu, bersama dengan audit, pemeriksaan kewarasan, dll.

Anda akan ingin melihat ke dalam LISTENdan NOTIFYcara yang baik untuk membangunkan pekerja Anda ketika perubahan pada tabel tugas terjadi.

Anda sudah melakukan hal yang paling penting dengan menghindari berbicara dengan sistem eksternal langsung dari pemicu. Itu cenderung bermasalah untuk kinerja dan keandalan. Orang sering mencoba melakukan hal-hal seperti mengirim surat langsung dari pemicu, dan itu berita buruk.

Ini jawaban yang sedikit terlambat, tetapi mungkin berguna untuk pembaca di masa depan

Sekarang hari (dalam versi 10,11,12) kita tidak perlu menyimpan data yang sama dua kali (dalam WAL oleh PG dan secara manual). Kita dapat menggunakan mekanika Decoding Logikal Postgre (sama dengan replikasi logis) untuk melacak semua atau beberapa perubahan pada data kita (atau mengirim peristiwa itu ke beberapa antrian seperti kafka untuk dianalisis nanti)