Kepiye ngoptimalake query agregat sing alon ing tabel gedhe?

Question

IT Interview Practice · Accepted Answer

Kanggo ngoptimalake agregasi alon, dhisik temtokake **apa tegese asil lan operasi endi sing ngentekake wektu**. Agregasi nggabungake baris dadi ringkesan, kayata pendapatan saben pedagang. Biayane gumantung marang akeh data sing kudu diwaca lan digabung.

Bayangna dashboard sing nuduhake pendapatan sasi kepungkur. Gunakake tuladha iki kanggo mutusake apa kudu ndandani query, nyimpen ringkesan sing wis diitung, utawa mindhah laporan menyang sistem liya.

## 1. Pasthekake asil bener sadurunge digawe luwih cepet

Jlentrehake apa pendapatan saka pesenan sing dibayar utawa sing digawe, carane nangani refund, lan mata uang apa sing kalebu. Takokake uga sepira anyar data dashboard kudu ana. Pilihan iki ngowahi query lan optimasi sing bisa dipilih.

Kesalahan umum yaiku nggabungake siji pembayaran karo sawetara item pesenan banjur njumlahake pembayaran:

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

Angka iki mung tuladha. Query wis nggandakake pembayaran, mula nyepetake mung ngasilake total salah luwih cepet. Agregasikake ing tingkat bisnis sing dikarepake utawa owahi join sadurunge nguji kinerja.

## 2. Temokake bagean eksekusi sing larang

Execution plan nuduhake operasi kanggo entuk asil. Priksa langkah sing larang lan ukuran inpute, aja langsung nganggep tabel mung butuh indeks anyar.

| Pengamatan | Bab sing kudu ditliti |
| --- | --- |
| Akeh baris ora relevan diwaca | Apa filter utawa partition pruning bisa nyingkirake? |
| Cacah baris nyata adoh saka perkiraan | Apa statistik nggambarake data iki? |
| Join mbaleni gaweyan kaping pirang-pirang | Apa input kegedhen utawa cara akses ora cocog? |
| Grouping utawa sorting nulis data sementara menyang disk | Apa input bisa dikurangi sadurunge ngganti wates memori? |

Ing PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) tenan nglakokake query lan menehi informasi wektu eksekusi. Tindakake investigasi larang ing lingkungan sing dikontrol utawa nganggo anggaran beban produksi sing disengaja. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Kurangi gaweyan ing database saiki

Kanggo dashboard, pilih sasi lan kolom sing dibutuhake. Priksa apa plan tenan ngliwati partisi sing ora ana gandhengane lan apa join nggawa data sing ora perlu kanggo ringkesan.

Indeks migunani yen bisa nyingkiri cukup akeh maca. Yen laporan butuh meh kabeh baris, sequential scan bisa luwih trep. Nilai plan lan biaya sing diukur, ora mung apa indeks katon digunakake.

Yen sorting tumpah menyang disk, ngurangi input bisa ngrampungake masalah. Nambah memori saben query malah bisa ngentekake RAM nalika akeh laporan mlaku bebarengan. Uji nganggo beban bebarengan sing makili panggunaan nyata.

## 4. Temtokake apa asil perlu disiapake luwih dhisik

Yen akeh pangguna njaluk total sing padha lan keterlambatan bisa ditampa, maca pesenan mentah bola-bali mbuwang gaweyan. Tabel ringkesan bisa nyimpen total saben dina, pedagang, lan mata uang; dashboard nggabungake asil sing luwih cilik iki.

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

Manfaate saka nindakake pitungan bebarengan sapisan, ora saben request. Materialized view uga bisa nyimpen asil query, kanthi aturan refresh dhewe.

Pangiritan iki nggawa tanggung jawab:

- Temtokake sepira kerep asil dianyari lan tuduhake kesegaran data sing relevan marang pangguna.
- Terapake refund, pesenan telat, lan koreksi tanpa ngitung kaping pindho.
- Gawe pangolahan bola-bali aman lan tetep ana cara mbangun ulang ringkesan.
- Simpen jumlah lan cacah nalika nggabungake rata-rata; rata-rata saka rata-rata bisa salah.

Kanggo dashboard iki, ringkesan sing wis disiapake mung dadi pilihan yen aturan kesegaran lan koreksine nyukupi syarat ing langkah kapisan.

## 5. Pisahake laporan yen pangukuran mbuktekake perlu

Yen scan analitik amba tetep larang lan ngganggu tuku, evaluasi panyimpenan analitik sing cocog. Itung uga keterlambatan sinkronisasi, pamulihan, lan biaya ngoperasikake sistem liyane.

Read replica bisa misahake beban laporan, nanging query sing padha isih bisa larang ing kana. Misahake mung ngganti panggonan biaya ditanggung; durung mesthi ngilangi biaya.

Bandhingake saben owah-owahan karo asil sing dipercaya lan beban uji sing padha. Priksa wektu respons, sumber daya, kesegaran, lan pengaruh marang panulisan.

**Elinga:** asil bener → hambatan sing diukur → kurang gaweyan ora perlu → ringkesan siap yen cocog → analitik kapisah yen isih dibutuhake.

Pengamatan	Bab sing kudu ditliti
Akeh baris ora relevan diwaca	Apa filter utawa partition pruning bisa nyingkirake?
Cacah baris nyata adoh saka perkiraan	Apa statistik nggambarake data iki?
Join mbaleni gaweyan kaping pirang-pirang	Apa input kegedhen utawa cara akses ora cocog?
Grouping utawa sorting nulis data sementara menyang disk	Apa input bisa dikurangi sadurunge ngganti wates memori?

1. Pasthekake asil bener sadurunge digawe luwih cepet

2. Temokake bagean eksekusi sing larang

3. Kurangi gaweyan ing database saiki

4. Temtokake apa asil perlu disiapake luwih dhisik

5. Pisahake laporan yen pangukuran mbuktekake perlu

Pitakon sing gegandhengan