Wie partitionierst du eine einzelne Tabelle mit Milliarden Rows?

Question

IT Interview Practice · Accepted Answer

**Splitte die riesige Tabelle in kleinere physische Child-Tabellen nach einem Partition Key, sodass jede Query nur die benötigten Partitionen berührt (Partition Pruning) statt Milliarden Rows zu scannen.** Eine Tabelle mit 5 Mrd. Order-Rows verhält sich weiterhin wie eine logische Tabelle, aber die Engine überspringt 99% davon, wenn dein `WHERE` auf den Partition Key filtert.

## Die Form einer partitionierten Tabelle

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

## Wahl einer Partitionsstrategie

- **Range** - nach Datums-/ID-Bereichen. Am besten für Zeitreihen (Orders, Logs, Events); aktuelle Daten bleiben heiß und alte Ranges sind leicht zu droppen.
- **Hash** - gleichmäßige Verteilung über N Partitionen per `hash(key) % N`. Nutze es, wenn es keinen natürlichen Range gibt und du ausgeglichene Last willst (z. B. `user_id`).
- **List** - explizite Buckets (`region IN ('EU','US')`). Gut für Tenant- oder 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, Indizes, Wartung

- **Partition Pruning** funktioniert nur, wenn die Query auf den **Partition Key** filtert. Filtere auf etwas anderes und du scannst jede Partition - der Fehler Nummer 1.
- **Local Index** = ein Index pro Child (Default in Postgres); günstig mit der Partition zu bauen und zu droppen. **Global Index** (Oracle) spannt über alle Partitionen - hilft eindeutigen Lookups über Partitionen, muss aber neu gebaut werden, wenn du eine droppst.
- **Wartung** wird O(Partition): archiviere alte Daten mit `DROP TABLE orders_2019` (sofort, kein riesiges `DELETE`), und `ATTACH`/`DETACH` für rollende Fenster.

## Interview-Perspektive

Der Interviewer sondiert, ob du verstehst, dass **Partitionierung kein Indexieren ist** - sie reduziert die gescannten Daten, ein Index reduziert die untersuchten Rows innerhalb eines Scans; oft brauchst du beides. Eine gute Antwort benennt Range/Hash/List; eine hervorragende Antwort betont, dass **der Partition Key deinem dominanten Query-Filter entsprechen muss**, warnt, dass ein falscher Key das Pruning tötet, und erwähnt günstige Archivierung per `DROP`.

**Trade-off:** Cross-Partition-Queries (kein Key-Filter, oder Unique-Constraints über Partitionen) werden langsamer und Unique-Enforcement wird schwerer. Partitioniere keine 10M-Row-Tabelle - du fügst betriebliche Komplexität ohne Gewinn hinzu. Partitioniere, wenn die Tabelle riesig ist **und** Queries natürlich durch den Key eingegrenzt sind.

Die Form einer partitionierten Tabelle

Wahl einer Partitionsstrategie

Pruning, Indizes, Wartung

Interview-Perspektive

Ähnliche Fragen