Hvordan optimerer man langsomme aggregeringer på en stor tabel?

Question

IT Interview Practice · Accepted Answer

For at optimere en langsom aggregering skal du først finde **resultatets betydning og den operation, der bruger tiden**. Aggregering samler rækker til et resumé, eksempelvis omsætning pr. sælger. Prisen afhænger af mængden, der læses og kombineres.

Overvej et dashboard med sidste måneds omsætning. Brug eksemplet til at vælge mellem en bedre forespørgsel, et gemt resumé eller rapportering et andet sted.

## 1. Bekræft svaret, før det gøres hurtigere

Afklar, om omsætning betyder betalte eller oprettede ordrer, hvordan refunderinger behandles, og hvilke valutaer der indgår. Fastlæg også kravet til friske data. Det ændrer både forespørgslen og optimeringsmulighederne.

En almindelig fejl er at forbinde en betaling med flere ordrelinjer og derefter summere betalingsbeløbet:

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

Tallene er illustrative. Forespørgslen har mangedoblet betalingen, så en optimering giver blot et forkert resultat hurtigere. Aggregér på det tilsigtede forretningsniveau, eller ret joinet før ydelsesmålingen.

## 2. Find den dyre del af kørslen

En eksekveringsplan viser operationerne bag resultatet. Undersøg dyre trin og deres inputstørrelser frem for at antage, at tabellen blot mangler et indeks.

| Observation | Spørgsmål til undersøgelse |
| --- | --- |
| Mange irrelevante rækker læses | Kan filtre eller udeladelse af partitioner fjerne dem? |
| Faktiske antal afviger meget fra estimater | Repræsenterer statistikken disse data? |
| Et join gentager arbejde mange gange | Er input for stort eller adgangsvejen uegnet? |
| Gruppering eller sortering skriver midlertidigt til disk | Kan input reduceres før ændring af hukommelsesgrænser? |

I PostgreSQL udfører EXPLAIN (ANALYZE, BUFFERS) forespørgslen og viser kørselsinformation. Undersøg dyre forespørgsler i et kontrolleret miljø eller med et bevidst produktionsbudget. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Reducér arbejdet i den nuværende database

Vælg den nødvendige måned og de nødvendige kolonner til dashboardet. Kontrollér, om planen faktisk springer irrelevante partitioner over, og om joins henter data, resuméet ikke behøver.

Et indeks er nyttigt, når det sparer tilstrækkelig læsning. Hvis rapporten behøver de fleste rækker, kan en sekventiel scanning være passende. Bedøm planen og den målte pris, ikke blot tilstedeværelsen af et indeks.

Hvis sortering flyder ud på disk, kan mindre input løse problemet. Mere hukommelse til hver forespørgsel kan derimod opbruge RAM ved mange samtidige rapporter. Test med repræsentativ samtidighed.

## 4. Afgør, om resultatet skal forberedes

Hvis mange efterspørger de samme totaler, og forsinkelse accepteres, spilder gentagne scanninger af rå ordrer arbejde. En resumétabel kan gemme totaler pr. dag, sælger og valuta, som dashboardet kombinerer.

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

Fordelen kommer af at udføre fælles beregninger én gang frem for ved hver anmodning. Et materialiseret view er en anden måde at gemme resultatet på med sin egen opdateringsadfærd.

Besparelsen giver nye forpligtelser:

- Fastlæg opdateringsfrekvens, og vis brugeren relevant information om friskhed.
- Indarbejd refunderinger, sene ordrer og rettelser uden dobbeltoptælling.
- Gør gentagen behandling sikker, og behold en mulighed for at genopbygge resuméer.
- Gem sum og antal ved kombination af gennemsnit; gennemsnittet af gennemsnit kan være forkert.

For dashboardet er forberedte resuméer kun relevante, hvis deres friskhed og rettelsesregler opfylder første trins krav.

## 5. Adskil rapportering, når målinger begrunder det

Hvis brede analytiske scanninger stadig er dyre og forstyrrer køb, så vurder et analytisk lager til arbejdsbyrden. Medregn synkroniseringsforsinkelse, gendannelse og driften af endnu et system.

En læsereplika kan isolere rapportbelastningen, men den samme forespørgsel kan stadig være dyr dér. Adskillelse flytter omkostningen; den fjerner den ikke nødvendigvis.

Sammenlign hver ændring med et pålideligt resultat under samme testbelastning. Kontrollér svartid, ressourcer, friskhed og påvirkning af skrivninger.

**Husk:** korrekt resultat → målt flaskehals → mindre unødigt arbejde → egnede resuméer → separat analyse, hvis det stadig kræves.

Observation	Spørgsmål til undersøgelse
Mange irrelevante rækker læses	Kan filtre eller udeladelse af partitioner fjerne dem?
Faktiske antal afviger meget fra estimater	Repræsenterer statistikken disse data?
Et join gentager arbejde mange gange	Er input for stort eller adgangsvejen uegnet?
Gruppering eller sortering skriver midlertidigt til disk	Kan input reduceres før ændring af hukommelsesgrænser?

1. Bekræft svaret, før det gøres hurtigere

2. Find den dyre del af kørslen

3. Reducér arbejdet i den nuværende database

4. Afgør, om resultatet skal forberedes

5. Adskil rapportering, når målinger begrunder det

Relaterede spørgsmål