Hogyan gyorsítsuk fel egy nagy tábla lassú aggregáló lekérdezéseit?

Question

IT Interview Practice · Accepted Answer

Lassú aggregáció optimalizálásakor először tisztázd, **mit jelent az eredmény, és melyik művelet viszi el az időt**. Az aggregáció sorokból készít összesítést, például kereskedőnkénti bevételt. Költségét az olvasott és összevont adatok mennyisége adja.

Vegyünk egy előző havi bevételt mutató irányítópultot. Ezen dönthetünk a lekérdezés javításáról, előkészített összesítésről vagy a riportolás áthelyezéséről.

## 1. Gyorsítás előtt ellenőrizd az eredményt

Tisztázd, fizetett vagy létrehozott rendelés számít-e bevételnek, hogyan kezelitek a visszatérítést, és mely pénznemek szerepelnek. Kérdezd meg, mennyire friss adat kell. Ezek a döntések a lekérdezést és az optimalizálási lehetőségeket is módosítják.

Gyakori hiba a fizetést több rendelési tételhez kapcsolni, majd összeadni a fizetési összeget:

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

A számok szemléltetők. A lekérdezés megsokszorozta a fizetést: gyorsabban csak hibás eredményt adna. A megfelelő üzleti szinten aggregálj, vagy javítsd az összekapcsolást a teljesítmény mérése előtt.

## 2. Keresd meg a végrehajtás drága részét

A végrehajtási terv megmutatja az eredményhez használt műveleteket. A drága lépéseket és bemeneti méretüket vizsgáld, ne feltételezd, hogy csak új index kell.

| Megfigyelés | Vizsgálandó kérdés |
| --- | --- |
| Sok felesleges sor beolvasása | Szűrés vagy partíciókihagyás kizárhatja őket? |
| A tényleges sorszám nagyon eltér a becsléstől | Reprezentatívak a statisztikák? |
| Az összekapcsolás sokszor ismétel munkát | Túl nagy a bemenet vagy rossz a hozzáférési út? |
| Csoportosítás vagy rendezés lemezre ír | Memóriaemelés előtt csökkenthető a bemenet? |

PostgreSQL-ben az EXPLAIN (ANALYZE, BUFFERS) végre is hajtja a lekérdezést, és futási adatokat ad. Drága vizsgálatot kontrollált környezetben vagy tudatosan kijelölt éles erőforráskerettel végezz. [PostgreSQL EXPLAIN](https://www.postgresql.org/docs/current/using-explain.html).

## 3. Csökkentsd a munkát a meglévő adatbázisban

Az irányítópulthoz csak a szükséges hónapot és oszlopokat válaszd. Ellenőrizd, valóban kimaradnak-e a többi partíciók, és a joinok nem hoznak-e be szükségtelen adatokat.

Index akkor hasznos, ha elég olvasást takarít meg. Ha a riport a sorok többségét igényli, a szekvenciális olvasás megfelelő lehet. A tervet és mért költséget értékeld, ne az index puszta megjelenését.

Ha a rendezés lemezre kerül, a bemenet csökkentése megoldhatja. Minden lekérdezés memóriaemelése viszont kimerítheti a RAM-ot párhuzamos riportoknál. Reprezentatív egyidejű terheléssel tesztelj.

## 4. Döntsd el, előkészíthető-e az eredmény

Ha sokan ugyanazokat az összegeket kérik, és késés elfogadható, a nyers rendelések állandó újraolvasása pazarlás. Összesítő tábla tárolhat napi, kereskedőnkénti és pénznemenkénti értékeket; az irányítópult kisebb eredményeket egyesít.

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

Az előny a közös számítás egyszeri elvégzéséből származik, nem minden kérésenkéntiből. A materializált nézet másik tárolási lehetőség, saját frissítési működéssel.

A megtakarítás felelősséggel jár:

- Határozd meg a frissítési gyakoriságot, és jelezd az adatfrissességet a felhasználónak.
- Kezeld a visszatérítéseket, késői rendeléseket és javításokat dupla számolás nélkül.
- Legyen biztonságos az ismételt feldolgozás és lehetséges az összesítések újraépítése.
- Átlagok összevonásához összeget és darabszámot tárolj; átlagok átlaga hibás lehet.

Ehhez az irányítópulthoz csak akkor jó az előkészítés, ha frissessége és javítási szabályai teljesítik az első lépés igényét.

## 5. Méréssel indokolt esetben különítsd el a riportolást

Ha a nagy analitikus olvasások drágák maradnak és zavarják a vásárlást, értékelj megfelelő analitikus tárolót. Számolj szinkronizációs késéssel, helyreállítással és egy új rendszer üzemeltetésével.

Olvasási replika elkülönítheti a riportterhelést, de ugyanaz a lekérdezés ott is drága lehet. Az elkülönítés a költség helyét változtatja, nem feltétlenül szünteti meg.

Minden változást megbízható eredményhez és azonos tesztterheléshez mérj. Vizsgáld a válaszidőt, erőforrásokat, frissességet és az írásokra gyakorolt hatást.

**Emlékezz:** helyes eredmény → mért szűk keresztmetszet → kevesebb felesleges munka → megfelelő előösszesítés → szükség esetén külön analitika.

Megfigyelés	Vizsgálandó kérdés
Sok felesleges sor beolvasása	Szűrés vagy partíciókihagyás kizárhatja őket?
A tényleges sorszám nagyon eltér a becsléstől	Reprezentatívak a statisztikák?
Az összekapcsolás sokszor ismétel munkát	Túl nagy a bemenet vagy rossz a hozzáférési út?
Csoportosítás vagy rendezés lemezre ír	Memóriaemelés előtt csökkenthető a bemenet?

1. Gyorsítás előtt ellenőrizd az eredményt

2. Keresd meg a végrehajtás drága részét

3. Csökkentsd a munkát a meglévő adatbázisban

4. Döntsd el, előkészíthető-e az eredmény

5. Méréssel indokolt esetben különítsd el a riportolást

Kapcsolódó kérdések