Comment partitionner une seule table avec des milliards de lignes ?

Question

IT Interview Practice · Accepted Answer

**Découpez la table géante en tables enfants physiques plus petites par une partition key, pour que chaque requête ne touche que les partitions dont elle a besoin (partition pruning) au lieu de scanner des milliards de lignes.** Une table de 5 milliards de lignes de commandes se comporte toujours comme une seule table logique, mais le moteur en saute 99% quand votre `WHERE` filtre sur la partition key.

## La forme d'une table partitionnée

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

## Choisir une stratégie de partitionnement

- **Range** — par plages de date/id. Idéal pour les séries temporelles (commandes, logs, événements) ; les données récentes restent hot et les anciennes plages sont faciles à supprimer.
- **Hash** — répartition uniforme sur N partitions par `hash(key) % N`. À utiliser quand il n'y a pas de range naturel et que vous voulez une charge équilibrée (par ex. `user_id`).
- **List** — buckets explicites (`region IN ('EU','US')`). Bon pour l'isolation par tenant ou région.

```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, maintenance

- **Le partition pruning** ne fonctionne que si la requête filtre sur la **partition key**. Filtrez sur autre chose et vous scannez chaque partition — l'erreur n°1.
- **Local index** = un index par enfant (par défaut dans Postgres) ; bon marché à construire et supprimer avec la partition. **Global index** (Oracle) s'étend sur toutes les partitions — aide les lookups uniques entre partitions mais doit être reconstruit quand vous en supprimez une.
- **La maintenance** devient O(partition) : archivez les anciennes données avec `DROP TABLE orders_2019` (instantané, pas de gigantesque `DELETE`), et `ATTACH`/`DETACH` pour les fenêtres glissantes.

## Perspective d'entretien

L'examinateur sonde si vous comprenez que le **partitionnement n'est pas de l'indexation** — il réduit les données scannées, un index réduit les lignes examinées au sein d'un scan ; vous avez souvent besoin des deux. Une bonne réponse nomme range/hash/list ; une excellente insiste que **la partition key doit correspondre à votre filtre de requête dominant**, prévient qu'une mauvaise clé tue le pruning, et mentionne l'archivage bon marché via `DROP`.

**Compromis :** les requêtes cross-partition (sans filtre de clé, ou les contraintes uniques entre partitions) deviennent plus lentes et l'application de l'unicité est plus difficile. Ne partitionnez pas une table de 10M de lignes — vous ajoutez de la complexité opérationnelle sans gain. Partitionnez quand la table est énorme **et** que les requêtes sont naturellement scoped par la clé.

La forme d'une table partitionnée

Choisir une stratégie de partitionnement

Pruning, index, maintenance

Perspective d'entretien

Questions connexes