Hvordan partitionerer du en enkelt tabel med milliarder af rows?

Question

IT Interview Practice · Accepted Answer

**Split den gigantiske tabel i mindre fysiske child-tabeller efter en partition key, så hver forespørgsel kun rører de partitioner den har brug for (partition pruning) i stedet for at scanne milliarder af rows.** En tabel med 5B ordre-rows opfører sig stadig som én logisk tabel, men engine'en springer 99% af den over, når din `WHERE` filtrerer på partition key.

## Formen af en partitioneret tabel

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

## Valg af partitionsstrategi

- **Range** — efter dato/id-ranges. Bedst til time-series (ordrer, logs, events); nylige data forbliver hot og gamle ranges er lette at droppe.
- **Hash** — jævn spredning over N partitioner efter `hash(key) % N`. Brug når der ikke er noget naturligt range og du vil have balanceret belastning (fx `user_id`).
- **List** — eksplicitte buckets (`region IN ('EU','US')`). God til tenant- eller region-isolation.

```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, indexes, vedligeholdelse

- **Partition pruning** virker kun, hvis forespørgslen filtrerer på **partition key**. Filtrér på noget andet og du scanner hver partition — fejl nr. 1.
- **Local index** = ét index pr. child (default i Postgres); billigt at bygge og droppe med partitionen. **Global index** (Oracle) spænder alle partitioner — hjælper unikke opslag på tværs af partitioner men skal genopbygges når du dropper en.
- **Vedligeholdelse** bliver O(partition): arkivér gamle data med `DROP TABLE orders_2019` (øjeblikkelig, intet gigantisk `DELETE`), og `ATTACH`/`DETACH` til rullende vinduer.

## Interview-perspektiv

Intervieweren undersøger, om du forstår, at **partitionering ikke er indeksering** — det reducerer de scannede data, et index reducerer de undersøgte rows inden for en scan; du har ofte brug for begge. Godt svar navngiver range/hash/list; fremragende svar understreger, at **partition key skal matche dit dominerende query-filter**, advarer om, at en forkert nøgle dræber pruning, og nævner billig arkivering via `DROP`.

**Trade-off:** cross-partition-forespørgsler (intet key-filter, eller unique constraints på tværs af partitioner) bliver langsommere og unique-håndhævelse er sværere. Partitionér ikke en 10M-row-tabel — du tilføjer driftskompleksitet uden gevinst. Partitionér når tabellen er enorm **og** forespørgsler naturligt er scopet af nøglen.

Formen af en partitioneret tabel

Valg af partitionsstrategi

Pruning, indexes, vedligeholdelse

Interview-perspektiv

Relaterede spørgsmål