Kako particionirate eno tabelo z milijardami vrstic?

Question

IT Interview Practice · Accepted Answer

**Razdelite orjaško tabelo v manjše fizične podrejene (child) tabele po particijskem ključu, tako da vsaka poizvedba dotakne le particije, ki jih potrebuje (partition pruning), namesto skeniranja milijard vrstic.** Tabela s 5 milijardami vrstic naročil se še vedno vede kot ena logična tabela, a pogon preskoči 99% nje, ko vaš `WHERE` filtrira po particijskem ključu.

## Oblika particionirane tabele

```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)
```

## Izbira strategije particioniranja

- **Range** — po obsegih datuma/id. Najboljše za časovne vrste (naročila, logi, dogodki); nedavni podatki ostanejo vroči, stari obsegi pa se enostavno odvržejo.
- **Hash** — enakomerna razpršitev čez N particij po `hash(key) % N`. Uporabite, ko ni naravnega obsega in želite uravnoteženo obremenitev (npr. `user_id`).
- **List** — eksplicitni segmenti (`region IN ('EU','US')`). Dobro za izolacijo najemnika (tenant) ali regije.

```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';
```

## Obrezovanje, indeksi, vzdrževanje

- **Obrezovanje particij (partition pruning)** deluje le, če poizvedba filtrira po **particijskem ključu**. Filtrirajte po nečem drugem in skenirate vsako particijo — napaka št. 1.
- **Lokalni indeks** = en indeks na podrejeno tabelo (privzeto v Postgresu); poceni za gradnjo in odstranitev skupaj s particijo. **Globalni indeks** (Oracle) obsega vse particije — pomaga pri unikatnih pregledih čez particije, a ga je treba ponovno zgraditi, ko eno odvržete.
- **Vzdrževanje** postane O(particija): arhivirajte stare podatke z `DROP TABLE orders_2019` (takojšen, brez orjaškega `DELETE`) in `ATTACH`/`DETACH` za drseča okna.

## Pogled s stališča razgovora

Izpraševalec preverja, ali razumete, da **particioniranje ni indeksiranje** — zmanjša skenirane podatke, indeks zmanjša pregledane vrstice znotraj skeniranja; pogosto potrebujete oba. Dober odgovor poimenuje range/hash/list; odličen poudari, da se **particijski ključ mora ujemati z vašim prevladujočim filtrom poizvedbe**, opozori, da napačen ključ ubije obrezovanje, in omeni poceni arhiviranje prek `DROP`.

**Kompromis:** medparticijske poizvedbe (brez filtra ključa ali unikatne omejitve čez particije) postanejo počasnejše in uveljavljanje unikatnosti je težje. Ne particionirajte 10M-vrstične tabele — dodate operativno kompleksnost brez koristi. Particionirajte, ko je tabela orjaška **in** so poizvedbe naravno obsežene po ključu.

Oblika particionirane tabele

Izbira strategije particioniranja

Obrezovanje, indeksi, vzdrževanje

Pogled s stališča razgovora

Povezana vprašanja