Unawezaje kuboresha aggregate queries polepole kwenye jedwali kubwa?

Question

IT Interview Practice · Accepted Answer

Ili kuboresha aggregate ya polepole, tambua kwanza **matokeo yanamaanisha nini na ni operation gani inatumia muda**. Aggregate huunganisha mistari kuwa muhtasari, kama mapato kwa mfanyabiashara. Gharama yake hutegemea kiasi cha data kinachosomwa na kuunganishwa.

Fikiria dashboard inayoonyesha mapato ya mwezi uliopita. Tumia mfano huu kuamua kuboresha query, kuhifadhi muhtasari uliotayarishwa au kuhamishia ripoti kwingine.

## 1. Hakikisha jibu kabla ya kuliharakisha

Fafanua ikiwa mapato ni oda zilizolipwa au zilizoundwa, jinsi refunds zinavyohesabiwa na sarafu zinazojumuishwa. Uliza pia dashboard inapaswa kuwa na data mpya kiasi gani. Maamuzi haya hubadilisha query na mbinu zinazowezekana za kuboresha.

Kosa la kawaida ni kuunganisha malipo na bidhaa kadhaa za oda halafu kujumlisha kiasi cha malipo:

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

Namba hizi ni za mfano. Query imezidisha malipo, kwa hiyo kuiharakisha kungerudisha jumla isiyo sahihi haraka zaidi. Fanya aggregate katika kiwango sahihi cha biashara au badilisha join kabla ya kupima utendaji.

## 2. Tafuta sehemu ghali ya utekelezaji

Execution plan inaonyesha operations zinazotumika kupata matokeo. Angalia hatua ghali na ukubwa wa data zinazoingia badala ya kudhani jedwali linahitaji index nyingine tu.

| Kinachoonekana | Swali la kuchunguza |
| --- | --- |
| Mistari mingi isiyohusika inasomwa | Je, filters au partition pruning zinaweza kuiondoa? |
| Idadi halisi ya mistari inatofautiana sana na makadirio | Je, takwimu zinawakilisha data hii? |
| Join inarudia kazi mara nyingi | Je, data inayoingia ni nyingi au njia ya kuifikia haifai? |
| Grouping au sorting inaandika data ya muda kwenye diski | Je, data inayoingia inaweza kupunguzwa kabla ya kubadili mipaka ya kumbukumbu? |

Katika PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) huendesha query na kutoa taarifa za utekelezaji. Fanya uchunguzi ghali katika mazingira yanayodhibitiwa au kwa bajeti ya rasilimali iliyokusudiwa production. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Punguza kazi katika database ya sasa

Kwa dashboard, chagua mwezi na columns zinazohitajika. Hakiki ikiwa plan kweli inaruka partitions zisizohusika na ikiwa joins zinaingiza data ambayo muhtasari hauhitaji.

Index inafaa inapozuia usomaji wa kutosha. Ikiwa ripoti inahitaji mistari mingi, sequential scan inaweza kufaa. Tathmini plan inayotokea na gharama iliyopimwa, si uwepo wa index pekee.

Ikiwa sorting inamwagika kwenye diski, kupunguza data inayoingia kunaweza kutatua tatizo. Kuongeza kumbukumbu kwa kila query kunaweza badala yake kumaliza RAM ripoti nyingi zikiendeshwa pamoja. Jaribu kwa mzigo wakilishi wa wakati mmoja.

## 4. Amua kama matokeo yatayarishwe mapema

Ikiwa watumiaji wengi wanaomba jumla zilezile na kuchelewa kunakubalika, kusoma oda ghafi mara kwa mara kunapoteza kazi. Jedwali la muhtasari linaweza kuhifadhi jumla kwa siku, mfanyabiashara na sarafu; dashboard huunganisha matokeo haya madogo.

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

Faida hutokana na kufanya hesabu zinazoshirikishwa mara moja badala ya kila request. Materialized view ni njia nyingine ya kuhifadhi matokeo ya query, ikiwa na utaratibu wake wa refresh.

Akiba hiyo inaleta majukumu:

- Bainisha matokeo yanaburudishwa mara ngapi na mwonyeshe mtumiaji kiwango husika cha upya wake.
- Tumia refunds, oda zilizochelewa na marekebisho bila kuhesabu mara mbili.
- Fanya uchakataji wa kurudiwa kuwa salama na uhifadhi njia ya kujenga muhtasari upya.
- Hifadhi jumla na idadi wakati wa kuunganisha wastani; kuchukua wastani wa wastani kunaweza kuwa kosa.

Kwa dashboard hii, muhtasari uliotayarishwa unafaa tu ikiwa upya wake na kanuni za marekebisho vinatimiza mahitaji ya hatua ya kwanza.

## 5. Tenganisha ripoti vipimo vinapohalalisha

Ikiwa scans pana za uchanganuzi bado ni ghali na zinaingilia manunuzi, tathmini hifadhi ya uchanganuzi inayofaa mzigo huo. Jumuisha ucheleweshaji wa kusawazisha, urejeshaji na gharama ya kuendesha mfumo mwingine.

Read replica inaweza kutenga mzigo wa ripoti, lakini query ileile bado inaweza kuwa ghali huko. Kutenganisha hubadilisha mahali gharama inapolipwa; si lazima kuiondoe.

Linganisha kila badiliko na matokeo yanayoaminika na mzigo uleule wa majaribio. Angalia muda wa majibu, rasilimali, upya na athari kwa uandishi.

**Kumbuka:** matokeo sahihi → kikwazo kilichopimwa → kazi isiyo ya lazima ipungue → muhtasari ulioandaliwa ukifaa → uchanganuzi tofauti ikiwa bado unahitajika.

Kinachoonekana	Swali la kuchunguza
Mistari mingi isiyohusika inasomwa	Je, filters au partition pruning zinaweza kuiondoa?
Idadi halisi ya mistari inatofautiana sana na makadirio	Je, takwimu zinawakilisha data hii?
Join inarudia kazi mara nyingi	Je, data inayoingia ni nyingi au njia ya kuifikia haifai?
Grouping au sorting inaandika data ya muda kwenye diski	Je, data inayoingia inaweza kupunguzwa kabla ya kubadili mipaka ya kumbukumbu?

1. Hakikisha jibu kabla ya kuliharakisha

2. Tafuta sehemu ghali ya utekelezaji

3. Punguza kazi katika database ya sasa

4. Amua kama matokeo yatayarishwe mapema

5. Tenganisha ripoti vipimo vinapohalalisha

Maswali yanayohusiana