Temukan permintaan mahal sebelum mengubah basis data
Mulai dari tindakan pengguna: memuat kategori, mencari artikel, menambah ke keranjang, atau mengirim pesanan. Tangkap rutenya, jumlah kueri, durasi basis data, baris yang dikembalikan, dan durasi permintaan. Halaman yang lambat juga bisa menunggu kode aplikasi atau dependensi lain, jadi jangan mendiagnosis hanya dari waktu muat halaman.
Rencana kueri (query plan) adalah jalur basis data melalui tabel, indeks, join, sort, dan agregat. Di PostgreSQL, EXPLAIN menunjukkan jalur itu. EXPLAIN ANALYZE menjalankan pernyataan dan melaporkan baris dan waktu aktual, jadi gunakan kueri representatif yang aman. Selisih besar antara estimasi dan aktual baris adalah alasan untuk menyelidiki statistik atau kondisi, bukan permintaan indeks otomatis.
Hubungkan kueri kandidat ke rute dan hasil, sehingga laporan pada dashboard tidak menyalip checkout yang lambat.
Catat pengukuran sebelum perubahan dan lalu lintas yang sebanding tanpa mencatat pengenal pelanggan, token, atau nilai terkait kartu.
Rancang indeks untuk jalur akses yang sebenarnya Anda gunakan
Indeks adalah struktur yang dipelihara yang dapat membantu menemukan baris atau mengembalikannya dalam urutan; itu bukan saklar kecepatan universal. Mulailah dari filter, kunci join, dan urutan (sort) kueri penting, lalu konfirmasi indeks yang diusulkan di dalam plan. PostgreSQL mendokumentasikan bahwa indeks B-tree yang cocok dapat memenuhi ORDER BY tanpa sort terpisah, terutama dengan LIMIT kecil.
Indeks menambah penyimpanan dan kerja tulis karena insert, update, dan delete harus memeliharanya. Untuk kueri yang membutuhkan fraksi besar dari tabel, sequential scan dan sort eksplisit bisa lebih cepat. Uji pada data yang mirip produksi dan pertahankan indeks hanya bila manfaatnya menjustifikasi biayanya.
Gunakan filter kueri dan ORDER BY yang sebenarnya, termasuk tie-breaker deterministik saat antarmuka membutuhkan urutan stabil.
Tinjau apakah indeks digunakan dan apa biayanya saat menulis; periksa ulang saat data dan lalu lintas berubah.
Buat paginasi stabil dan terjangkau
Paginasi berbasis nomor halaman biasanya menggunakan LIMIT plus OFFSET. Selalu tetapkan urutan yang dapat diprediksi. PostgreSQL memperingatkan bahwa tanpa ORDER BY, LIMIT bisa mengembalikan subset yang tak terduga; nilai LIMIT atau OFFSET yang berbeda dapat menghasilkan subset yang tidak konsisten karena optimizer mungkin memilih rencana yang berbeda.
OFFSET besar perlu ditelaah karena baris yang dilewati tetap harus dihitung. Untuk penjelajahan katalog, riwayat pesanan, atau arsip yang dalam, pertimbangkan paginasi cursor atau keyset (keyset pagination): minta baris setelah nilai urut stabil terakhir yang terlihat dan tie-breaker unik. Tentukan bagaimana rekaman baru atau dihapus muncul sebelum mengubah antarmuka.
Kembalikan ukuran halaman terkecil yang berguna daripada hasil yang tidak dibatasi.
Putuskan apakah antarmuka benar-benar membutuhkan total yang tepat pada setiap permintaan.
Cache pekerjaan baca tanpa mengirimkan respons yang salah
Caching menggunakan kembali hasil sebelumnya alih-alih membangunnya ulang dari basis data. Mulailah di lapisan HTTP untuk halaman publik yang repeatable dan aset yang diberi versi, karena hit cache dapat menghindari kerja aplikasi dan basis data. web.dev merekomendasikan caching jangka panjang untuk URL yang diberi versi; mengubah URL adalah mekanisme invalidasi yang praktis.
Kebijakan cache adalah keputusan kebenaran (correctness). Cache bersama dapat menggunakan satu respons ke banyak pengguna, jadi jangan bagikan keluaran yang spesifik akun, keranjang, harga, atau otorisasi kecuali dirancang dan diuji untuk cakupan itu. Cache-Control private membatasi penggunaan ulang ke cache browser, sementara no-store mengarahkan cache untuk tidak menyimpannya.
Pisahkan keluaran katalog publik atau artikel dari keluaran yang spesifik sesi, lokasi, dan sensitif terhadap izin.
Tentukan siapa yang boleh melihat nilai usang, berapa lama, dan jalur invalidasi atau revalidasinya.
Lindungi kapasitas koneksi daripada sekadar menaikkan batas
Koneksi adalah sesi klien langsung ke basis data. Worker, cron job, preview, atau retry dapat menghabiskan slot meskipun kueri individu tampak dapat diterima. max_connections di PostgreSQL mengontrol koneksi konkuren, diset saat server start, dan nilai lebih tinggi mengalokasikan lebih banyak sumber daya termasuk shared memory. Menaikkannya tanpa model beban dapat memindahkan titik kegagalan.
Tetapkan satu anggaran di seluruh web worker, pekerjaan latar, administrasi, dan replika. Gunakan pooling terbatas di tempat yang sesuai, pertahankan headroom untuk pemulihan, dan terapkan timeout agar pekerjaan yang tersangkut tidak menunggu selamanya. Angka aman bergantung pada engine, memori, campuran kueri, dan batas penyedia; konfirmasikan dengan operator.
Sertakan proses web, antrian, tugas terjadwal, migrasi, alat pelaporan, dan tugas deployment.
Batasi concurrency dan gunakan backoff sehingga sebuah kesalahan tidak menggandakan permintaan koneksi.
Amati biaya kueri dengan konteks dan kontrol privasi
Peringkat pekerjaan basis data berdasarkan dampak total, bukan satu sampel lambat. Kueri yang cukup lambat yang dipanggil ribuan kali bisa lebih penting daripada laporan yang jarang. pg_stat_statements di PostgreSQL mengagregasi data perencanaan dan eksekusi termasuk panggilan, total dan rata-rata waktu eksekusi, baris, dan aktivitas buffer. Ia membutuhkan konfigurasi server dan restart untuk ditambahkan atau dihapus; pelacakan perencanaan dapat menambah overhead.
Hubungkan grup kueri ke rute, versi rilis, dan jendela waktu. OpenTelemetry menyarankan mengumpulkan teks kueri secara default hanya setelah sanitasi mengganti literal, dan menggunakan ringkasan kueri ber-kardinalitas rendah untuk pengelompokan. Ini membantu pemilik melihat tren tanpa mengekspor data pelanggan atau membuat label untuk setiap nilai.
Tinjau durasi, total waktu, panggilan, error, koneksi, dan baris; masing-masing mengekspos mode kegagalan yang berbeda.
Gunakan kueri terparameterisasi dan verifikasi literal dihapus sebelum trace atau log meninggalkan aplikasi.
Kirim perubahan basis data sebagai pekerjaan keandalan yang dapat dibalik
Perlakukan indeks, penulisan ulang, kebijakan cache, pengaturan pool, atau perubahan skema sebagai perubahan produksi dengan pemilik, ukuran keberhasilan, dan keputusan rollback. Validasi di lingkungan representatif, rilis ke irisan terbatas, dan pantau perjalanan yang terkena. Lebih cepat bukan berarti sukses jika perubahan mengembalikan data yang salah, hilang, duplikat, atau usang.
Perubahan skema perlu kehati-hatian karena versi aplikasi dapat saling bertumpuk. Panduan Google Cloud menjelaskan urutan kompatibilitas: rilis aplikasi yang menangani skema lama dan baru, ubah skema, lalu rilis fitur yang menggunakannya. Ini mempertahankan jalur rollback aplikasi. Perilaku penguncian dan perubahan online berbeda menurut engine dan layanan terkelola; minta tinjauan yang memenuhi syarat untuk sistem ber-volume tinggi atau terkait pembayaran.
Nama rute, sinyal kinerja dan kebenaran, serta ambang batas yang menghentikan rollout.
Verifikasi kinerja dan kebenaran pada irisan yang terkendali sebelum memperluas; latih jalur kembali di luar insiden.