Hur partitionerar du en enda tabell med miljarder rader?

Question

IT Interview Practice · Accepted Answer

**Dela den gigantiska tabellen i mindre fysiska barntabeller på en partitionsnyckel, så att varje fråga rör bara de partitioner den behöver (partition pruning) istället för att scanna miljarder rader.** En tabell med 5B order-rader beter sig fortfarande som en logisk tabell, men motorn hoppar över 99% av den när din `WHERE` filtrerar på partitionsnyckeln.

## Formen på en partitionerad tabell

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

## Att välja en partitionsstrategi

- **Range** — på datum/id-intervall. Bäst för tidsserier (ordrar, loggar, händelser); färsk data förblir het och gamla intervall är lätta att droppa.
- **Hash** — jämn spridning över N partitioner via `hash(key) % N`. Använd när det inte finns något naturligt intervall och du vill ha balanserad last (t.ex. `user_id`).
- **List** — explicita buckets (`region IN ('EU','US')`). Bra för tenant- eller regionsisolering.

```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, index, underhåll

- **Partition pruning** fungerar bara om frågan filtrerar på **partitionsnyckeln**. Filtrera på något annat och du scannar varje partition — misstag nummer 1.
- **Local index** = ett index per barn (standard i Postgres); billigt att bygga och droppa med partitionen. **Global index** (Oracle) spänner över alla partitioner — hjälper unika uppslagningar över partitioner men måste byggas om när du droppar en.
- **Underhåll** blir O(partition): arkivera gammal data med `DROP TABLE orders_2019` (omedelbart, ingen gigantisk `DELETE`), och `ATTACH`/`DETACH` för rullande fönster.

## Intervjuperspektiv

Intervjuaren undersöker om du förstår att **partitionering inte är indexering** — det minskar den data som scannas, ett index minskar de rader som undersöks inom en scan; du behöver ofta båda. Bra svar namnger range/hash/list; utmärkt svar betonar att **partitionsnyckeln måste matcha ditt dominerande frågefilter**, varnar att en felaktig nyckel dödar pruning, och nämner billig arkivering via `DROP`.

**Avvägning:** cross-partition-frågor (inget nyckelfilter, eller unika constraints över partitioner) blir långsammare och unik-upprätthållande är svårare. Partitionera inte en 10M-raders tabell — du lägger till driftkomplexitet utan vinst. Partitionera när tabellen är enorm **och** frågor naturligt scopar på nyckeln.

Formen på en partitionerad tabell

Att välja en partitionsstrategi

Pruning, index, underhåll

Intervjuperspektiv

Relaterade frågor