Hoe partitioneer je één tabel met miljarden rows?

Question

IT Interview Practice · Accepted Answer

**Splits de gigantische tabel in kleinere fysieke child-tabellen op een partition key, zodat elke query alleen de partities raakt die hij nodig heeft (partition pruning) in plaats van miljarden rows te scannen.** Een tabel met 5 miljard order-rows gedraagt zich nog steeds als één logische tabel, maar de engine slaat 99% ervan over wanneer je `WHERE` filtert op de partition key.

## De vorm van een gepartitioneerde tabel

```text
                 orders (logische parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child-tabel)    (child-tabel)    (child-tabel)    (child, actief)
       │                                                  │
   lokale index                                       lokale index
   (per child)                                        (per child)
```

## Een partitiestrategie kiezen

- **Range** — op datum/id-bereiken. Beste voor time-series (orders, logs, events); recente data blijft hot en oude bereiken zijn makkelijk te droppen.
- **Hash** — gelijkmatige spreiding over N partities op `hash(key) % N`. Gebruik wanneer er geen natuurlijk bereik is en je gebalanceerde belasting wilt (bijv. `user_id`).
- **List** — expliciete buckets (`region IN ('EU','US')`). Goed voor tenant- of regio-isolatie.

```sql
-- Postgres: range-partitie op maand, prune op 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');

-- Dit scant ALLEEN orders_2025_01, niet de hele tabel
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indexen, onderhoud

- **Partition pruning** werkt alleen als de query filtert op de **partition key**. Filter op iets anders en je scant elke partitie — de #1 fout.
- **Lokale index** = één index per child (default in Postgres); goedkoop te bouwen en te droppen met de partitie. **Globale index** (Oracle) omspant alle partities — helpt unieke lookups over partities maar moet herbouwd worden wanneer je er een dropt.
- **Onderhoud** wordt O(partitie): archiveer oude data met `DROP TABLE orders_2019` (direct, geen gigantische `DELETE`), en `ATTACH`/`DETACH` voor voortschrijdende vensters.

## Interviewperspectief

De interviewer peilt of je begrijpt dat **partitionering geen indexering is** — het vermindert de gescande data, een index vermindert de onderzochte rows binnen een scan; je hebt vaak beide nodig. Een goed antwoord benoemt range/hash/list; een uitstekend antwoord benadrukt dat **de partition key moet matchen met je dominante query-filter**, waarschuwt dat een verkeerde sleutel pruning doodt, en noemt goedkope archivering via `DROP`.

**Afweging:** cross-partition queries (geen key-filter, of unique constraints over partities) worden trager en unique-afdwinging is moeilijker. Partitioneer geen tabel van 10M rows — je voegt operationele complexiteit toe zonder winst. Partitioneer wanneer de tabel enorm is **én** queries natuurlijk gescoped zijn op de sleutel.

De vorm van een gepartitioneerde tabel

Een partitiestrategie kiezen

Pruning, indexen, onderhoud

Interviewperspectief

Gerelateerde vragen