Qu'est-ce que le partitionnement de table ?

Question

Accepted Answer

**Le partitionnement** divise une grande table en plus petites pièces physiques (**partitions**) basées sur la valeur d'une colonne — tout en apparaissant comme une seule table logique aux requêtes. Il améliore les performances et la maintenabilité pour les très grandes tables en permettant à la base de données d'analyser ou de maintenir uniquement les partitions pertinentes.

## Comment fonctionne le partitionnement

```sql
-- a huge `orders` table partitioned BY RANGE on the order date
CREATE TABLE orders (id INT, order_date DATE, amount DECIMAL)
PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- orders is ONE logical table, but stored as separate per-year partitions
```

La table est une entité logique unique, mais stockée physiquement en partitions. Les requêtes et les insertions vont automatiquement vers la bonne partition.

## L'avantage clé : l'élagage de partitions

```sql
-- a query filtered by the partition key only scans RELEVANT partitions
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → the database skips orders_2023 entirely, scanning only orders_2024 ("partition pruning")
```

**L'élagage de partitions** est le principal gain de performance : une requête filtrée sur la clé de partitionnement ne touche que les partitions pertinentes, en ignorant le reste — transformant un balayage de milliards de lignes en un balayage du seul sous-ensemble pertinent.

## Stratégies de partitionnement

```text
RANGE → by a value range (dates, numeric ranges) — common for time-series data
LIST  → by a list of discrete values (region, category)
HASH  → by a hash of the key (even distribution across partitions)
```

## Autres avantages

```text
✓ Maintenance — drop/archive old data by dropping a whole partition (instant vs DELETE)
  e.g. DROP TABLE orders_2020 — far faster than DELETE WHERE year = 2020
✓ Smaller indexes per partition; parallel operations across partitions
✓ Manage huge tables in manageable pieces
```

## Quand utiliser le partitionnement

```text
✓ VERY LARGE tables (hundreds of millions / billions of rows) where queries filter
  on a natural partition key (often time/date for logs, events, orders)
✓ Time-series data where you regularly archive/drop old data
✗ Small/medium tables — partitioning adds complexity with little benefit
  (proper indexing usually suffices)
→ Partitioning complements indexing for VERY large tables; it's not a substitute.
```

## Pourquoi c'est important

Le partitionnement de table est une technique importante pour gérer et interroger les **très grandes tables**, et sa compréhension est une connaissance précieuse de niveau senior pour travailler avec les bases de données à grande échelle.

Lorsque les tables atteignent des centaines de millions ou des milliards de lignes, même les requêtes indexées et les opérations de maintenance peuvent devenir lentes, et le partitionnement résout ce problème en divisant la table en plus petites pièces physiques.

Le principal avantage en termes de performance est l'**élagage de partitions** — les requêtes filtrées sur la clé de partitionnement ne balayent que les partitions pertinentes (en ignorant le reste), ce qui réduit considérablement les données analysées pour les très grandes tables (particulièrement courant pour les données de série chronologique filtrées par date).

Au-delà de la performance des requêtes, le partitionnement offre d'importants **avantages de maintenance** : l'archivage ou la suppression de données anciennes devient instantané (suppression d'une partition entière par rapport à une opération `DELETE` lente et coûteuse de millions de lignes — un avantage opérationnel significatif pour les données de journaux/événements avec des politiques de rétention), ainsi que des indexes par partition plus petits et des opérations parallèles.

Comprendre les **stratégies** (RANGE pour les plages de dates/numériques — courant pour les séries chronologiques ; LIST pour les valeurs discrètes ; HASH pour une distribution uniforme) et surtout **quand utiliser le partitionnement** (très grandes tables avec une clé de partitionnement naturelle, en particulier les séries chronologiques avec archivage régulier — *pas* les petites/moyennes tables où l'indexation suffit et le partitionnement ajoute simplement de la complexité) reflète un jugement mature.

Comme la gestion de très grandes tables est un véritable défi dans les systèmes à grande échelle, et comme le partitionnement (avec l'élagage de partitions et la maintenance efficace) est l'outil standard pour cela — complétant plutôt que remplaçant l'indexation — la compréhension du partitionnement de table est une connaissance précieuse de niveau senior pour la scalabilité des bases de données, particulièrement pertinente pour les systèmes de données à grande échelle, de séries chronologiques ou à haut volume, et un sujet qui démontre une compréhension de la gestion des bases de données à grande échelle.