Bagaimana mengoptimalkan agregasi lambat pada tabel besar?

Question

IT Interview Practice · Accepted Answer

Untuk mempercepat agregasi lambat, pahami dahulu **arti hasil dan operasi yang menghabiskan waktu**. Agregasi menggabungkan baris menjadi ringkasan, misalnya pendapatan per merchant. Biayanya bergantung pada banyaknya data yang dibaca dan digabungkan.

Ambil dashboard pendapatan bulan lalu. Gunakan contoh ini untuk memilih antara memperbaiki query, menyimpan ringkasan siap pakai, atau memindahkan pelaporan.

## 1. Pastikan jawabannya benar sebelum dipercepat

Jelaskan apakah pendapatan berdasarkan pesanan dibayar atau dibuat, cara menghitung refund, dan mata uang yang disertakan. Tanyakan juga kebutuhan kesegaran dashboard. Pilihan ini mengubah query dan optimasi yang tersedia.

Kesalahan umum adalah menggabungkan pembayaran dengan beberapa item pesanan, kemudian menjumlahkan nilai pembayaran:

```text
[Payment: 100] -> [Join with 3 items] -> [100, 100, 100]
                                               |
                                          [SUM = 300]
```

Angka tersebut ilustratif. Query menggandakan pembayaran, sehingga mempercepatnya hanya mengembalikan total salah lebih cepat. Agregasikan pada tingkat bisnis yang tepat atau ubah join sebelum mengevaluasi performa.

## 2. Temukan bagian eksekusi yang mahal

Execution plan menunjukkan operasi untuk memperoleh hasil. Periksa langkah mahal beserta ukuran masukannya, bukan menganggap tabel hanya membutuhkan indeks baru.

| Pengamatan | Pertanyaan pemeriksaan |
| --- | --- |
| Banyak baris tidak relevan dibaca | Bisakah filter atau partition pruning menyingkirkannya? |
| Jumlah baris aktual jauh dari perkiraan | Apakah statistik mewakili data ini? |
| Join mengulang pekerjaan berkali-kali | Apakah input terlalu besar atau jalur akses tidak sesuai? |
| Pengelompokan atau pengurutan menulis data sementara ke disk | Bisakah input dikurangi sebelum menaikkan batas memori? |

Di PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) menjalankan query dan melaporkan informasi runtime. Lakukan investigasi mahal di lingkungan terkontrol atau dengan anggaran produksi yang ditetapkan secara sengaja. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Kurangi pekerjaan pada database saat ini

Untuk dashboard, pilih bulan dan kolom yang diperlukan. Periksa apakah plan benar-benar melewati partisi lain dan apakah join membawa data yang tidak dibutuhkan ringkasan.

Indeks berguna ketika menghindari cukup banyak pembacaan. Jika laporan membutuhkan sebagian besar baris, sequential scan mungkin tepat. Nilai plan dan biaya terukur, bukan sekadar keberadaan indeks.

Jika sorting meluber ke disk, mengurangi input mungkin menyelesaikannya. Menaikkan memori setiap query justru bisa menghabiskan RAM ketika banyak laporan berjalan bersama. Uji dengan beban bersamaan yang representatif.

## 4. Putuskan apakah hasil perlu disiapkan sebelumnya

Jika banyak pengguna meminta total sama dan sedikit keterlambatan dapat diterima, membaca ulang pesanan mentah membuang pekerjaan. Tabel ringkasan dapat menyimpan total per hari, merchant, dan mata uang; dashboard menggabungkan hasil kecil itu.

```text
[Orders] -> [Scheduled / incremental calculation]
                              |
                       [Daily summaries] -> [Dashboard]
```

Manfaatnya berasal dari perhitungan bersama sekali saja, bukan setiap request. Materialized view adalah cara lain menyimpan hasil query, dengan perilaku refresh tersendiri.

Penghematan ini membawa tanggung jawab:

- Tentukan frekuensi refresh dan tampilkan kesegaran yang relevan kepada pengguna.
- Terapkan refund, pesanan terlambat, dan koreksi tanpa menghitung dua kali.
- Buat pemrosesan ulang aman dan pertahankan cara membangun ulang ringkasan.
- Simpan sum dan count untuk menggabungkan rata-rata; rata-rata dari rata-rata bisa salah.

Untuk dashboard ini, ringkasan siap pakai hanya cocok jika aturan kesegaran dan koreksinya memenuhi kebutuhan langkah pertama.

## 5. Pisahkan pelaporan bila pengukuran membenarkannya

Jika pemindaian analitik luas tetap mahal dan mengganggu pembelian, evaluasi penyimpanan analitik yang sesuai. Sertakan keterlambatan sinkronisasi, pemulihan, dan biaya mengoperasikan sistem lain.

Read replica dapat mengisolasi beban pelaporan, tetapi query yang sama mungkin tetap mahal di sana. Pemisahan mengubah tempat biaya dibayar, bukan otomatis menghilangkannya.

Bandingkan setiap perubahan dengan hasil tepercaya dan beban uji yang sama. Periksa waktu respons, sumber daya, kesegaran, dan dampak terhadap penulisan.

**Ingat:** hasil benar → hambatan terukur → kurangi pekerjaan sia-sia → ringkasan jika sesuai → analitik terpisah jika masih perlu.

Pengamatan	Pertanyaan pemeriksaan
Banyak baris tidak relevan dibaca	Bisakah filter atau partition pruning menyingkirkannya?
Jumlah baris aktual jauh dari perkiraan	Apakah statistik mewakili data ini?
Join mengulang pekerjaan berkali-kali	Apakah input terlalu besar atau jalur akses tidak sesuai?
Pengelompokan atau pengurutan menulis data sementara ke disk	Bisakah input dikurangi sebelum menaikkan batas memori?

1. Pastikan jawabannya benar sebelum dipercepat

2. Temukan bagian eksekusi yang mahal

3. Kurangi pekerjaan pada database saat ini

4. Putuskan apakah hasil perlu disiapkan sebelumnya

5. Pisahkan pelaporan bila pengukuran membenarkannya

Pertanyaan terkait