Hvordan partisjonerer du en enkelt tabell med milliarder av rader?

Question

IT Interview Practice · Accepted Answer

**Del den gigantiske tabellen i mindre fysiske barnetabeller på en partisjonsnøkkel, slik at hver spørring berører kun partisjonene den trenger (partition pruning) i stedet for å skanne milliarder av rader.** En tabell med 5B ordre-rader oppfører seg fortsatt som én logisk tabell, men motoren hopper over 99% av den når `WHERE` filtrerer på partisjonsnøkkelen.

## Formen på en partisjonert tabell

```text
                 orders (logisk parent)
                        │  partisjonsnøkkel = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (barnetabell)    (barnetabell)    (barnetabell)    (barn, aktiv)
       │                                                  │
   lokal indeks                                       lokal indeks
   (per barn)                                         (per barn)
```

## Å velge en partisjonsstrategi

- **Range** — på dato/id-intervaller. Best for time-series (orders, logs, events); nylig data forblir hot og gamle ranges er lette å droppe.
- **Hash** — jevn spredning over N partisjoner på `hash(key) % N`. Bruk når det ikke finnes noe naturlig range og du vil ha balansert belastning (f.eks. `user_id`).
- **List** — eksplisitte bøtter (`region IN ('EU','US')`). Bra for tenant- eller region-isolering.

```sql
-- Postgres: range-partisjon på måned, beskjær på 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');

-- Dette skanner KUN orders_2025_01, ikke hele tabellen
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indekser, vedlikehold

- **Partition pruning** fungerer kun hvis spørringen filtrerer på **partisjonsnøkkelen**. Filtrer på noe annet og du skanner hver partisjon — feil nummer 1.
- **Lokal indeks** = én indeks per barn (standard i Postgres); billig å bygge og droppe med partisjonen. **Global indeks** (Oracle) spenner over alle partisjoner — hjelper unike oppslag over partisjoner men må gjenoppbygges når du dropper en.
- **Vedlikehold** blir O(partisjon): arkiver gammel data med `DROP TABLE orders_2019` (umiddelbar, ingen gigantisk `DELETE`), og `ATTACH`/`DETACH` for rullende vinduer.

## Intervjuperspektiv

Intervjueren undersøker om du forstår at **partisjonering ikke er indeksering** — den reduserer data skannet, en indeks reduserer rader undersøkt innenfor en scan; du trenger ofte begge. Godt svar navngir range/hash/list; utmerket svar understreker at **partisjonsnøkkelen må matche ditt dominerende query-filter**, advarer om at en feil nøkkel dreper pruning, og nevner billig arkivering via `DROP`.

**Avveining:** cross-partition-spørringer (ingen key-filter, eller unike constraints over partisjoner) blir tregere og unik-håndhevelse er vanskeligere. Ikke partisjoner en 10M-rads tabell — du legger til operasjonell kompleksitet uten gevinst. Partisjoner når tabellen er enorm **og** spørringer er naturlig scopet av nøkkelen.

Formen på en partisjonert tabell

Å velge en partisjonsstrategi

Pruning, indekser, vedlikehold

Intervjuperspektiv

Relaterte spørsmål