Miten partitioit yksittäisen taulun, jossa on miljardeja rivejä?

Question

IT Interview Practice · Accepted Answer

**Jaa jättitaulu pienempiin fyysisiin lapsitauluihin partitioavaimen mukaan, jotta jokainen kysely koskettaa vain tarvitsemiaan partitioita (partition pruning) miljardien rivien skannaamisen sijaan.** Taulu, jossa on 5 miljardia tilausriviä, käyttäytyy edelleen yhtenä loogisena tauluna, mutta moottori ohittaa 99 % siitä, kun `WHERE`-lauseesi suodattaa partitioavaimella.

## Partitioidun taulun muoto

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

## Partitiostrategian valinta

- **Range** — päivä-/id-rangejen mukaan. Paras aikasarjoille (tilaukset, lokit, tapahtumat); tuore data pysyy kuumana ja vanhat rangeet on helppo pudottaa.
- **Hash** — tasainen levitys N partition yli `hash(key) % N`:llä. Käytä kun luonnollista rangea ei ole ja haluat tasapainotetun kuorman (esim. `user_id`).
- **List** — eksplisiittiset bucketit (`region IN ('EU','US')`). Hyvä tenant- tai alue-eristykseen.

```sql
-- Postgres: range-partitiointi kuukauden mukaan, karsi created_at:lla
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');

-- Tämä skannaa VAIN orders_2025_01:n, ei koko taulua
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indeksit, ylläpito

- **Partition pruning** toimii vain, jos kysely suodattaa **partitioavaimella**. Suodata jollakin muulla ja skannaat jokaisen partition — virhe #1.
- **Local index** = yksi indeksi per lapsi (oletus Postgresissa); halpa rakentaa ja pudottaa partition mukana. **Global index** (Oracle) kattaa kaikki partitiot — auttaa uniikkeja hakuja partitioiden yli mutta on rakennettava uudelleen, kun pudotat yhden.
- **Ylläpidosta** tulee O(partitio): arkistoi vanha data `DROP TABLE orders_2019`:lla (välitön, ei jättimäistä `DELETE`:ä), ja `ATTACH`/`DETACH` liukuville ikkunoille.

## Haastattelunäkökulma

Haastattelija tutkii, ymmärrätkö että **partitiointi ei ole indeksointia** — se vähentää skannattavaa dataa, indeksi vähentää skannauksen sisällä tutkittavia rivejä; tarvitset usein molemmat. Hyvä vastaus nimeää range/hash/list; loistava vastaus korostaa, että **partitioavaimen on vastattava hallitsevaa kyselysuodatinta**, varoittaa että väärä avain tappaa pruningin, ja mainitsee halvan arkistoinnin `DROP`:lla.

**Kompromissi:** cross-partition-kyselyt (ei avainsuodatinta, tai uniikkius-constraintit partitioiden yli) hidastuvat ja uniikkiuden valvonta on vaikeampaa. Älä partitioi 10M rivin taulua — lisäät operatiivista monimutkaisuutta ilman hyötyä. Partitioi kun taulu on valtava **ja** kyselyt ovat luonnollisesti avaimen rajaamia.

Partitioidun taulun muoto

Partitiostrategian valinta

Pruning, indeksit, ylläpito

Haastattelunäkökulma

Aiheeseen liittyvät kysymykset