Penyatuan Koneksi PostgreSQL:Bagian 1 – Pro &Kontra

Dulu, di galaksi yang sangat jauh, 'utas' adalah hal baru dalam pemrograman yang jarang digunakan dan jarang dipercaya. Dalam lingkungan itu, pengembang PostgreSQL pertama memutuskan untuk melakukan proses forking untuk setiap koneksi ke database adalah pilihan yang paling aman. Sayang sekali jika database Anda mogok.

Sejak itu, banyak air mengalir di bawah jembatan itu, tetapi komunitas PostgreSQL tetap pada keputusan awal mereka. Sulit untuk menyalahkan argumen mereka – karena memang benar bahwa:

• Setiap klien yang memiliki prosesnya sendiri mencegah klien yang berperilaku buruk agar tidak merusak seluruh database.
• Pada sistem Linux modern, perbedaan overhead antara forking proses dan pembuatan thread jauh lebih sedikit daripada sebelumnya.
• Pindah ke arsitektur multithread akan membutuhkan penulisan ulang yang ekstensif.

Namun, dalam aplikasi web modern, klien cenderung membuka banyak koneksi. Pengembang sering sangat tidak dianjurkan untuk mengadakan koneksi database saat operasi lain berlangsung. “Buka koneksi selambat mungkin, tutup koneksi secepat mungkin”. Tapi itu menyebabkan masalah dengan arsitektur PostgreSQL – proses forking menjadi mahal ketika transaksi sangat singkat, seperti yang ditentukan oleh kebijaksanaan umum.

Arsitektur Kumpulan Koneksi

Menggunakan pustaka bahasa modern sedikit mengurangi masalah – penggabungan koneksi adalah fitur penting dari sebagian besar pustaka akses basis data populer. Ini memastikan koneksi 'tertutup' tidak benar-benar tertutup, tetapi dikembalikan ke kumpulan, dan 'membuka' koneksi baru mengembalikan 'koneksi fisik' yang sama kembali, mengurangi forking sebenarnya di sisi PostgreSQL.

Namun, aplikasi web modern jarang monolitik, dan sering menggunakan banyak bahasa dan teknologi. Menggunakan kumpulan koneksi di setiap modul hampir tidak efisien:

• Bahkan dengan jumlah modul yang relatif kecil, dan ukuran kumpulan kecil di masing-masing, Anda berakhir dengan banyak proses server. Pergantian konteks di antara mereka membutuhkan biaya.
• Dukungan penggabungan sangat bervariasi antara perpustakaan dan bahasa – satu kumpulan yang berperilaku buruk dapat menghabiskan semua sumber daya dan membuat database tidak dapat diakses oleh modul lain.
• Tidak ada kontrol terpusat – Anda tidak dapat menggunakan tindakan seperti batas akses khusus klien.

Akibatnya, middleware populer telah dikembangkan untuk PostgreSQL. Ini berada di antara database dan klien, terkadang di server terpisah (fisik atau virtual) dan terkadang di kotak yang sama, dan membuat kumpulan tempat klien dapat terhubung. Middleware ini adalah:

• Dioptimalkan untuk PostgreSQL dan arsitekturnya yang agak unik di antara DBMS modern.
• Berikan kontrol akses terpusat untuk beragam klien.
• Memungkinkan Anda untuk menuai imbalan yang sama seperti kumpulan sisi klien, dan kemudian beberapa lagi (kita akan membahas ini lebih detail di posting berikutnya)!

Kontra Pooler Koneksi PostgreSQL

Pengumpul koneksi adalah bagian yang hampir tak terpisahkan dari penyiapan PostgreSQL yang siap produksi. Meskipun ada banyak manfaat yang terdokumentasi dengan baik menggunakan penyambung koneksi, ada beberapa argumen yang harus dibuat untuk tidak menggunakannya:

• Memperkenalkan middleware dalam komunikasi pasti akan menimbulkan beberapa latensi. Namun, ketika berada di host yang sama, dan memperhitungkan overhead dari forking koneksi, dalam praktiknya hal ini dapat diabaikan seperti yang akan kita lihat di bagian selanjutnya.
• Middleware menjadi satu-satunya titik kegagalan. Menggunakan cluster pada level ini dapat menyelesaikan masalah ini, tetapi hal itu menambah kompleksitas arsitektur.

  

• Middleware menyiratkan biaya tambahan. Anda memerlukan server tambahan (atau 3), atau server database Anda harus memiliki sumber daya yang cukup untuk mendukung kumpulan koneksi, selain PostgreSQL.
• Berbagi koneksi antara modul yang berbeda dapat menjadi kerentanan keamanan. Sangat penting bagi kita untuk mengonfigurasi pgPool atau PgBouncer untuk membersihkan koneksi sebelum dikembalikan ke pool.
• Otentikasi bergeser dari DBMS ke pooler koneksi. Ini mungkin tidak selalu dapat diterima.

  

• Ini meningkatkan area permukaan untuk serangan, kecuali akses ke database yang mendasarinya dikunci untuk mengizinkan akses hanya melalui kumpulan koneksi.
• Ini membuat komponen lain yang harus dipelihara, disesuaikan dengan beban kerja Anda, keamanan sering ditambal, dan ditingkatkan sesuai kebutuhan.

Haruskah Anda Menggunakan Pengumpul Koneksi PostgreSQL?

Namun, semua masalah ini dibahas dengan baik di komunitas PostgreSQL, dan strategi mitigasi memastikan pro dari pooler koneksi jauh melebihi kontra mereka. Pengujian kami menunjukkan bahwa bahkan sejumlah kecil klien dapat memperoleh manfaat yang signifikan dari penggunaan connection pooler. Mereka layak untuk konfigurasi tambahan dan upaya pemeliharaan.

Dalam posting berikutnya, kita akan membahas salah satu kumpulan koneksi paling populer di dunia PostgreSQL – PgBouncer, diikuti oleh Pgpool-II, dan terakhir perbandingan uji kinerja dari keduanya Pengumpul koneksi PostgreSQL di postingan terakhir seri ini.