Hogyan partícionálsz egy egyetlen táblát több milliárd sorral?

Question

IT Interview Practice · Accepted Answer

**Oszd fel az óriási táblát kisebb fizikai gyermek-táblákra egy partíciós kulcs szerint, így minden lekérdezés csak a szükséges partíciókat érinti (partition pruning) ahelyett, hogy milliárdnyi sort szkennelne.** Egy 5 milliárd rendelés-soros tábla még mindig egy logikai táblaként viselkedik, de a motor átugorja 99%-át, amikor a `WHERE` a partíciós kulcsra szűr.

## Egy partícionált tábla alakja

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## Partíciós stratégia választása

- **Range** — dátum/id tartományok szerint. Legjobb idősorokhoz (rendelések, logok, események); a friss adat forró marad és a régi tartományok könnyen eldobhatók.
- **Hash** — egyenletes terítés N partíción `hash(key) % N`-nel. Használd, ha nincs természetes tartomány és kiegyensúlyozott terhelést akarsz (pl. `user_id`).
- **List** — explicit vödrök (`region IN ('EU','US')`). Jó tenant vagy régió izolációhoz.

```sql
-- Postgres: range partition by month, prune on created_at
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- This scans ONLY orders_2025_01, not the whole table
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indexek, karbantartás

- **A partition pruning** csak akkor működik, ha a lekérdezés a **partíciós kulcsra** szűr. Szűrj valami másra és minden partíciót szkennelsz — az első számú hiba.
- **Local index** = egy index gyermekenként (default a Postgresben); olcsó építeni és eldobni a partícióval. **Global index** (Oracle) minden partíciót átfog — segít az egyedi kereséseknél partíciók között de újra kell építeni, amikor eldobsz egyet.
- **A karbantartás** O(partíció) lesz: archiválj régi adatot `DROP TABLE orders_2019`-cel (azonnali, nincs óriási `DELETE`), és `ATTACH`/`DETACH` gördülő ablakokhoz.

## Interjú szemszög

Az interjúztató azt vizsgálja, érted-e, hogy a **partícionálás nem indexelés** — csökkenti a szkennelt adatot, egy index csökkenti a vizsgált sorokat egy szkenen belül; gyakran mindkettőre szükséged van. A jó válasz megnevezi a range/hash/list-et; a kiváló válasz hangsúlyozza, hogy **a partíciós kulcsnak illeszkednie kell a domináns lekérdezési szűrődhöz**, figyelmeztet, hogy egy rossz kulcs megöli a pruningot, és említi az olcsó archiválást `DROP`-pal.

**Kompromisszum:** a cross-partition lekérdezések (nincs kulcs-szűrő, vagy egyedi megszorítások partíciók között) lassabbak lesznek és az egyediség kikényszerítése nehezebb. Ne partícionálj egy 10M-soros táblát — üzemeltetési komplexitást adsz hozzá haszon nélkül. Partícionálj, amikor a tábla hatalmas **és** a lekérdezéseket természetesen a kulcs szűkíti.

Egy partícionált tábla alakja

Partíciós stratégia választása

Pruning, indexek, karbantartás

Interjú szemszög

Kapcsolódó kérdések