Arsitektur PostgreSQL

Ketika psql berhasil terhubung, di sisi lain ada bukan satu program melainkan satu keluarga proses: pengawas, para pekerja, dan penjaga-penjaga latar yang bekerja diam-diam. Susunan inilah yang disebut arsitektur PostgreSQL, dan memahaminya membuka banyak pintu sekaligus — mengapa koneksi mahal, kenapa ada proses bernama autovacuum, dan ke mana data pergi sebelum benar-benar menempel di disk. Chapter ini membedah susunan itu lalu membuktikan keberadaannya lewat query ke statistik server yang sedang kita jalankan.

Postmaster: Penjaga Pintu Server #

Saat server PostgreSQL dinyalakan (lewat pg_ctl atau service sistem operasi), proses pertama yang berjalan adalah postmaster. Postmaster membuka socket koneksi pada alamat dan port yang dikonfigurasi, lalu menunggu. Begitu sebuah client — psql, aplikasi web, script backup — datang mengetuk, postmaster memeriksa kredensialnya menurut aturan di file pg_hba.conf, dan bila lolos, postmaster melakukan fork: menciptakan satu backend process khusus untuk koneksi itu, lalu menyerahkan percakapannya.

Model “satu proses per koneksi” punya dua konsekuensi penting. Pertama, isolasi: backend bekerja di proses sistem operasi sendiri, jadi kekacauan di satu koneksi tidak merusak mesin-mesin koneksi lain — dan bila satu backend mati secara tak wajar, postmaster menghentikan semua backend lain serta menjalankan recovery demi menjaga konsistensi data. Kedua, biaya: setiap proses memakan memori sendiri, sehingga jumlah koneksi dibatasi parameter max_connections — di lingkungan materi ini, 100.

Satu Keluarga Proses dalam Satu Diagram #

Hubungan para proses dan memori bersama bisa dipetakan sebagai berikut:

Cara membacanya: client hanya berbicara dengan backend miliknya (parse, plan, execute — persis pipeline chapter sebelumnya). Para backend tidak menyimpan data di memorinya masing-masing; mereka membaca dan menulis lewat shared memory yang dibagi bersama — dua bagian terpentingnya shared buffers (cache halaman-halaman tabel dan index) dan WAL buffers (antrian catatan WAL). Proses-proses latar belakang di baris bawah diagram menjaga dua gudang memori itu agar tetap sehat; tugas masing-masing kita bedah sebentar lagi.

Shared Memory dan Ukurannya #

Kapasitas memori bersama diatur parameter di postgresql.conf, dan isinya bisa kita baca dari view pg_settings — tidak perlu membuka file konfigurasi. Query berikut menampilkan empat parameter yang paling sering disinggung:

SELECT name, setting, unit
FROM pg_settings
WHERE name IN ('shared_buffers', 'max_connections', 'work_mem', 'maintenance_work_mem')
ORDER BY name;

Output yang Dihasilkan:

         name         | setting | unit 
----------------------+---------+------
 maintenance_work_mem | 65536   | kB
 max_connections      | 100     | 
 shared_buffers       | 16384   | 8kB
 work_mem             | 4096    | kB
(4 rows)

Mari kita artikan tiap barisnya:

1. shared_buffers 16384 x 8kB: ukuran cache halaman utama — 16.384 halaman berukuran 8kB, total 128MB (nilai bawaan). Semua baca-tulis tabel dan index lewat cache ini.
2. max_connections 100: jumlah koneksi (backend process) maksimum yang diizinkan serentak — angka yang selaras dengan model satu proses per koneksi di atas.
3. work_mem 4096 kB: memori internal per operasi sortir dan agregasi, dipakai backend sebelum tumpah ke disk. Nilai bawaannya 4MB.
4. maintenance_work_mem 65536 kB: sepupu work_mem untuk pekerjaan maintenance seperti VACUUM dan pembuatan index — lebih besar karena pekerjaannya lebih lapar.

Proses Latar Belakang #

Proses latar bekerja tanpa diminta dan tanpa koneksi client mana pun. Kelima proses berikut adalah penghuni tetap setiap server PostgreSQL:

Daftar di atas bukan teori kosong — seluruh proses itu hidup di server yang sedang kita pakai dan tercatat di view pg_stat_activity:

SELECT backend_type
FROM pg_stat_activity
WHERE backend_type IN ('background writer', 'checkpointer', 'walwriter',
                       'autovacuum launcher', 'logical replication launcher')
ORDER BY backend_type;

Output yang Dihasilkan:

         backend_type         
------------------------------
 autovacuum launcher
 background writer
 checkpointer
 logical replication launcher
 walwriter
(5 rows)

Lima baris hasil = lima proses latar, muncul berurutan abjad karena ORDER BY backend_type. Filter IN (...) sengaja memotong daftar ke lima jenis itu; tanpa filter, pg_stat_activity juga menampilkan para client backend — termasuk koneksi kita sendiri.

Melihat Proses Kita Sendiri #

Setiap backend punya nomor proses sistem operasi yang bisa ditanyakan dengan function pg_backend_pid(). Query berikut menyaring pg_stat_activity agar hanya menampilkan baris milik koneksi kita:

SELECT pid, application_name, state, backend_type
FROM pg_stat_activity
WHERE pid = pg_backend_pid();

Output yang Dihasilkan:

 pid  | application_name | state  |  backend_type  
------+------------------+--------+----------------
 4282 | psql             | active | client backend
(1 row)

Empat kolom itu menceritakan identitas lengkap sebuah sesi. pid adalah nomor proses sistem operasi backend kita — angka yang akan berbeda setiap kali koneksi dibuat, termasuk di mesin Anda. application_name berisi nama yang dikirim client (psql pada contoh ini; aplikasi produktif sebaiknya mengisinya agar mudah dilacak). state bernilai active karena saat query berjalan, koneksi kita memang sedang mengeksekusi query. Terakhir, backend_type mengonfirmasi wujud kita di keluarga proses: satu client backend di antara para proses latar.

Ke Mana Data Fisik Pergi #

Seluruh isi database akhirnya menetap sebagai file di data directory (PGDATA). Dua penghuninya paling penting: direktori base/ yang menyimpan file-file tabel dan index per database, dan direktori pg_wal/ yang menyimpan segmen-segmen WAL — catatan perubahan yang menjamin transaksi selamat dari mati listrik. Di akar data directory juga bersemayam postgresql.conf (konfigurasi, termasuk empat parameter yang kita baca tadi) dan pg_hba.conf (aturan siapa yang boleh terhubung).

Tiga chapter terakhir membangun pemahaman tentang apa PostgreSQL dan bagaimana ia bekerja di balik layar. Pertanyaan terakhir sebelum praktik dimulai: di medan mana database ini benar-benar dipakai orang? Chapter Use Case PostgreSQL memetakan jawabannya dari aplikasi web sampai data geospasial.

Referensi #

• Arsitektur PostgreSQL dalam Tutorial
• Statistik Aktivitas Database
• Konfigurasi Runtime

SELECT pid, application_name, state, backend_type
FROM pg_stat_activity
WHERE pid = pg_backend_pid();

SELECT name, setting, unit
FROM pg_settings
WHERE name IN ('shared_buffers', 'max_connections', 'work_mem', 'maintenance_work_mem')
ORDER BY name;

SELECT backend_type
FROM pg_stat_activity
WHERE backend_type IN ('background writer', 'checkpointer', 'walwriter',
                       'autovacuum launcher', 'logical replication launcher')
ORDER BY backend_type;