Hvordan optimaliserer du trege aggregeringer på en stor tabell?

Question

IT Interview Practice · Accepted Answer

For å forbedre en treg aggregering må du først finne **hva resultatet betyr, og hvilken operasjon som bruker tiden**. En aggregering samler rader til et sammendrag, som omsetning per forhandler. Kostnaden avhenger av hvor mye data som må leses og kombineres.

Tenk på et dashbord med forrige måneds omsetning. Bruk eksemplet til å velge mellom å forbedre spørringen, lagre et ferdig sammendrag eller flytte rapporteringen.

## 1. Bekreft svaret før du gjør det raskere

Avklar om omsetning betyr betalte eller opprettede ordrer, hvordan refusjoner håndteres, og hvilke valutaer som inngår. Spør også hvor oppdatert dashbordet må være. Dette påvirker både spørringen og mulige forbedringer.

En vanlig feil er å koble en betaling til flere ordrelinjer og deretter summere betalingsbeløpet:

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

Tallene er eksempler. Spørringen har multiplisert betalingen, så høyere hastighet gir bare feil total raskere. Aggreger på riktig forretningsnivå eller endre koblingen før ytelsen vurderes.

## 2. Finn den kostbare delen av utføringen

En kjøreplan viser operasjonene som brukes for å finne resultatet. Undersøk dyre trinn og datamengden inn i dem fremfor å anta at tabellen bare trenger en indeks til.

| Observasjon | Spørsmål å undersøke |
| --- | --- |
| Mange irrelevante rader leses | Kan filtre eller partisjonsbeskjæring utelukke dem? |
| Faktisk radantall avviker mye fra anslaget | Er statistikken representativ for dataene? |
| En kobling gjentar mye arbeid | Er inndataene for store eller tilgangsmetoden uegnet? |
| Gruppering eller sortering skriver midlertidige data til disk | Kan inndata reduseres før minnegrensene endres? |

I PostgreSQL utfører EXPLAIN (ANALYZE, BUFFERS) spørringen og rapporterer informasjon om kjøringen. Gjør kostbare undersøkelser i et kontrollert miljø eller med et bevisst ressursbudsjett i produksjon. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Reduser arbeid i dagens database

Velg nødvendig måned og kolonner for dashbordet. Kontroller om planen faktisk hopper over uvedkommende partisjoner, og om koblinger henter data sammendraget ikke trenger.

En indeks er nyttig når den unngår nok lesing. Hvis rapporten trenger de fleste radene, kan en sekvensiell skanning være riktig. Vurder planen og målt kostnad, ikke bare om en indeks brukes.

Hvis sorteringen må bruke disk, kan mindre inndata løse problemet. Mer minne per spørring kan derimot tømme RAM når mange rapporter kjører samtidig. Test med representativ samtidig belastning.

## 4. Vurder å forberede resultatet på forhånd

Hvis mange brukere spør etter samme totaler og noe forsinkelse er akseptabelt, sløser gjentatt skanning av råordrer med arbeid. En sammendragstabell kan lagre totaler per dag, forhandler og valuta; dashbordet kombinerer disse mindre resultatene.

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

Gevinsten kommer av å gjøre felles beregninger én gang i stedet for ved hver forespørsel. En materialisert visning lagrer også et spørringsresultat, med sin egen oppdateringsmekanisme.

Denne besparelsen gir nye ansvar:

- Definer oppdateringsfrekvens og vis brukeren hvor ferske resultatene er.
- Håndter refusjoner, sene ordrer og korrigeringer uten dobbelttelling.
- Gjør gjentatt behandling trygg og behold en måte å bygge sammendragene på nytt.
- Lagre sum og antall når gjennomsnitt kombineres; gjennomsnitt av gjennomsnitt kan bli feil.

For dette dashbordet er ferdige sammendrag aktuelle bare dersom ferskhet og korrigeringsregler oppfyller kravet fra første trinn.

## 5. Skill ut rapportering når målinger begrunner det

Hvis brede analyseskanninger fortsatt er kostbare og forstyrrer kjøp, vurder et analyselager tilpasset belastningen. Ta med synkroniseringsforsinkelse, gjenoppretting og driftskostnaden ved et ekstra system.

En lesereplika kan isolere rapportbelastningen, men den samme spørringen kan fortsatt være dyr der. Separasjon flytter kostnaden; den fjerner den ikke nødvendigvis.

Sammenlign hver endring med et pålitelig resultat og samme testbelastning. Kontroller svartid, ressurser, ferskhet og påvirkning på skriving.

**Husk:** riktig resultat → målt flaskehals → mindre unødvendig arbeid → ferdige sammendrag hvis egnet → separat analyse hvis fortsatt nødvendig.

Observasjon	Spørsmål å undersøke
Mange irrelevante rader leses	Kan filtre eller partisjonsbeskjæring utelukke dem?
Faktisk radantall avviker mye fra anslaget	Er statistikken representativ for dataene?
En kobling gjentar mye arbeid	Er inndataene for store eller tilgangsmetoden uegnet?
Gruppering eller sortering skriver midlertidige data til disk	Kan inndata reduseres før minnegrensene endres?

1. Bekreft svaret før du gjør det raskere

2. Finn den kostbare delen av utføringen

3. Reduser arbeid i dagens database

4. Vurder å forberede resultatet på forhånd

5. Skill ut rapportering når målinger begrunner det

Relaterte spørsmål