Cum optimizezi agregările lente pe un tabel mare?

Question

IT Interview Practice · Accepted Answer

Pentru a optimiza o agregare lentă, identifică mai întâi **ce înseamnă rezultatul și ce operație consumă timpul**. O agregare combină rânduri într-un rezumat, precum venitul fiecărui comerciant. Costul depinde de volumul datelor citite și combinate.

Să luăm un tablou de bord care afișează venitul lunii trecute. Folosește acest exemplu pentru a decide dacă îmbunătățești interogarea, păstrezi un rezumat pregătit sau muți raportarea în alt sistem.

## 1. Confirmă răspunsul înainte de a-l accelera

Clarifică dacă venitul se referă la comenzi plătite sau create, cum sunt tratate rambursările și ce monede sunt incluse. Stabilește și cât de recente trebuie să fie datele afișate. Aceste alegeri schimbă atât interogarea, cât și optimizările disponibile.

O greșeală frecventă este asocierea unei plăți cu mai multe articole ale comenzii, urmată de însumarea plății:

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

Numerele sunt ilustrative. Interogarea a multiplicat plata, deci accelerarea ei ar returna mai repede un total incorect. Agregă la nivelul operațional dorit sau modifică asocierea înainte de a evalua performanța.

## 2. Găsește partea costisitoare a execuției

Un plan de execuție arată operațiile folosite pentru obținerea rezultatului. Examinează pașii costisitori și volumul intrărilor lor, fără să presupui că tabelul are nevoie doar de încă un index.

| Observație | Întrebare de investigat |
| --- | --- |
| Sunt citite multe rânduri irelevante | Le pot exclude filtrele sau eliminarea partițiilor inutile din plan? |
| Numărul real de rânduri diferă mult de estimări | Statisticile sunt reprezentative pentru aceste date? |
| O asociere repetă aceeași muncă de multe ori | Intrarea este prea mare sau calea de acces este nepotrivită? |
| Gruparea sau sortarea scrie date temporare pe disc | Poate fi redusă intrarea înainte de modificarea limitelor de memorie? |

În PostgreSQL, EXPLAIN (ANALYZE, BUFFERS) execută interogarea și raportează informații de execuție. Rulează o investigație costisitoare într-un mediu controlat sau cu un buget de resurse stabilit explicit pentru producție. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Redu munca în baza de date actuală

Pentru tabloul de bord, selectează luna și coloanele necesare. Verifică dacă planul omite efectiv partițiile fără legătură și dacă asocierile aduc date inutile pentru rezumat.

Un index este util când evită suficiente citiri. Dacă raportul necesită majoritatea rândurilor, o scanare secvențială poate fi potrivită. Evaluează planul rezultat și costul măsurat, nu doar apariția unui index.

Dacă sortarea ajunge să folosească discul, reducerea intrării poate rezolva problema. Creșterea memoriei pentru fiecare interogare poate, dimpotrivă, epuiza RAM când rulează multe rapoarte simultan. Testează cu o sarcină concurentă reprezentativă.

## 4. Decide dacă pregătești rezultatul în avans

Dacă mulți utilizatori cer aceleași totaluri și acceptă o întârziere, scanarea repetată a comenzilor brute irosește muncă. Un tabel de rezumate poate păstra totaluri pe zi, comerciant și monedă; tabloul de bord combină aceste rezultate mai mici.

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

Beneficiul provine din efectuarea o singură dată a calculelor comune, în locul repetării lor la fiecare cerere. O vedere materializată este alt mod de a păstra rezultatul unei interogări, cu propriul comportament de reîmprospătare.

Această economie introduce responsabilități:

- Definește frecvența actualizării și arată utilizatorului cât de recente sunt datele relevante.
- Aplică rambursările, comenzile întârziate și corecțiile fără numărare dublă.
- Fă reprocesarea sigură și păstrează posibilitatea reconstruirii rezumatelor.
- Păstrează suma și numărul când combini medii; media mediilor poate fi greșită.

Pentru acest tablou de bord, rezumatele pregătite sunt o opțiune numai dacă actualitatea și regulile de corectare respectă cerința din primul pas.

## 5. Separă raportarea când măsurătorile o justifică

Dacă scanările analitice ample rămân costisitoare și afectează cumpărăturile, evaluează un depozit analitic potrivit sarcinii. Include întârzierea sincronizării, recuperarea și costul operării încă unui sistem.

O replică pentru citire poate izola sarcina raportării, însă aceeași interogare poate rămâne costisitoare și acolo. Separarea schimbă locul în care se plătește costul; nu îl elimină neapărat.

Compară fiecare modificare cu un rezultat de încredere și cu aceeași sarcină de test. Verifică timpul de răspuns, resursele, actualitatea datelor și efectul asupra scrierilor.

**De reținut:** rezultat corect → limitare măsurată → mai puțină muncă inutilă → rezumate pregătite dacă se potrivesc → analiză separată dacă mai este necesară.

Observație	Întrebare de investigat
Sunt citite multe rânduri irelevante	Le pot exclude filtrele sau eliminarea partițiilor inutile din plan?
Numărul real de rânduri diferă mult de estimări	Statisticile sunt reprezentative pentru aceste date?
O asociere repetă aceeași muncă de multe ori	Intrarea este prea mare sau calea de acces este nepotrivită?
Gruparea sau sortarea scrie date temporare pe disc	Poate fi redusă intrarea înainte de modificarea limitelor de memorie?

1. Confirmă răspunsul înainte de a-l accelera

2. Găsește partea costisitoare a execuției

3. Redu munca în baza de date actuală

4. Decide dacă pregătești rezultatul în avans

5. Separă raportarea când măsurătorile o justifică

Întrebări conexe