Hur optimerar du långsamma aggregeringar på en stor tabell?

Question

IT Interview Practice · Accepted Answer

För att optimera en långsam aggregering behöver du först identifiera **vad resultatet betyder och vilken operation som tar tiden**. En aggregering sammanför rader till en sammanställning, till exempel omsättning per handlare. Kostnaden beror på hur mycket data som måste läsas och kombineras.

Tänk på en dashboard som visar förra månadens omsättning. Använd exemplet för att avgöra om frågan ska förbättras, en färdig sammanställning lagras eller rapporteringen flyttas.

## 1. Säkerställ rätt svar innan du gör det snabbare

Klargör om omsättning avser betalda eller skapade order, hur återbetalningar hanteras och vilka valutor som ingår. Fråga också hur aktuella siffrorna måste vara. Valen påverkar både frågan och möjliga optimeringar.

Ett vanligt misstag är att koppla en betalning till flera orderrader och sedan summera betalningsbeloppet:

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

Siffrorna är exempel. Frågan har multiplicerat betalningen, så en snabbare fråga skulle bara leverera fel totalsumma snabbare. Aggregera på rätt verksamhetsnivå eller ändra kopplingen innan prestandan utvärderas.

## 2. Hitta den dyra delen av körningen

En exekveringsplan visar vilka operationer som används för att få resultatet. Granska dyra steg och storleken på deras indata i stället för att anta att tabellen bara behöver ett till index.

| Observation | Fråga att undersöka |
| --- | --- |
| Många irrelevanta rader läses | Kan filter eller partitionseliminering utesluta dem? |
| Faktiska radantal skiljer sig kraftigt från uppskattningarna | Representerar statistiken dessa data? |
| En join upprepar arbete många gånger | Är indata för stora eller åtkomstvägen olämplig? |
| Gruppering eller sortering skriver temporära data till disk | Kan indata minskas innan minnesgränserna ändras? |

I PostgreSQL kör EXPLAIN (ANALYZE, BUFFERS) frågan och redovisar körinformation. Gör en dyr undersökning i en kontrollerad miljö eller med en medveten resursbudget i produktion. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Minska arbetet i den befintliga databasen

Välj den månad och de kolumner dashboarden behöver. Kontrollera om planen faktiskt hoppar över ovidkommande partitioner och om joins hämtar data som sammanställningen inte behöver.

Ett index är användbart när det sparar tillräckligt mycket läsning. Om rapporten behöver de flesta raderna kan en sekventiell skanning vara lämplig. Bedöm den faktiska planen och uppmätta kostnaden, inte bara om ett index används.

Om sortering spiller över till disk kan mindre indata lösa problemet. Mer minne till varje fråga kan i stället tömma RAM när många rapporter körs samtidigt. Testa med representativ samtidig belastning.

## 4. Avgör om resultatet ska förberedas

Om många användare begär samma totalsummor och en fördröjning är acceptabel slösar upprepade skanningar av råa order arbete. En sammanställningstabell kan lagra totalsummor per dag, handlare och valuta; dashboarden kombinerar dessa mindre resultat.

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

Vinsten kommer från att gemensamma beräkningar görs en gång i stället för vid varje begäran. En materialiserad vy är ett annat sätt att lagra ett frågeresultat, med ett eget beteende för uppdatering.

Besparingen medför ansvar:

- Definiera hur ofta resultaten uppdateras och visa användaren deras relevanta aktualitet.
- Tillämpa återbetalningar, sena order och rättelser utan dubbelräkning.
- Gör upprepad bearbetning säker och behåll ett sätt att återskapa sammanställningarna.
- Lagra summa och antal när medelvärden kombineras; medelvärdet av medelvärden kan bli fel.

För denna dashboard är förberedda sammanställningar ett alternativ endast om deras aktualitet och rättningsregler uppfyller kraven från steg ett.

## 5. Separera rapportering när mätningar motiverar det

Om breda analytiska skanningar fortfarande är dyra och stör köp, utvärdera ett analyslager som passar belastningen. Ta med synkroniseringsfördröjning, återställning och kostnaden för att driva ytterligare ett system.

En läsreplik kan isolera rapporteringsbelastningen, men samma fråga kan fortfarande vara dyr där. Separation ändrar var kostnaden betalas; den tar inte nödvändigtvis bort den.

Jämför varje ändring mot ett tillförlitligt resultat och samma testbelastning. Kontrollera svarstid, resurser, aktualitet och påverkan på skrivningar.

**Kom ihåg:** korrekt resultat → uppmätt flaskhals → mindre onödigt arbete → förberedda sammanställningar om lämpligt → separat analys om det fortfarande behövs.

Observation	Fråga att undersöka
Många irrelevanta rader läses	Kan filter eller partitionseliminering utesluta dem?
Faktiska radantal skiljer sig kraftigt från uppskattningarna	Representerar statistiken dessa data?
En join upprepar arbete många gånger	Är indata för stora eller åtkomstvägen olämplig?
Gruppering eller sortering skriver temporära data till disk	Kan indata minskas innan minnesgränserna ändras?

1. Säkerställ rätt svar innan du gör det snabbare

2. Hitta den dyra delen av körningen

3. Minska arbetet i den befintliga databasen

4. Avgör om resultatet ska förberedas

5. Separera rapportering när mätningar motiverar det

Relaterade frågor