Partitioning (Database)

Database Partitioning est la division d'une table en partitions plus petites (chunks) pour améliorer performance des queries, faciliter maintenance, et permettre archivage différencié. Différent de sharding (qui distribue sur multiple instances) — partitioning typiquement single-instance.

Types de partitioning :
(1) **Range partitioning** — partitions définies par ranges de values d'une colonne (e.g. par date : 2023, 2024, 2025 ; par geographic region ; par status). Le plus courant pour time-series.
(2) **List partitioning** — par enum values explicites (status='active' → partition A, status='archived' → partition B).
(3) **Hash partitioning** — hash de colonne → partition, distribution équitable, no logical meaning.
(4) **Composite partitioning** — combinaison (range-hash, range-list).

Avantages : (1) **Partition pruning** — query planner skip partitions non pertinentes (`WHERE date > '2024-01-01'` n'examine que partitions 2024-2025) ; (2) **Faster maintenance** — VACUUM, REINDEX, ANALYZE per partition vs entire table ; (3) **Bulk operations** — DROP partition (atomic, fast) au lieu de DELETE WHERE (slow, logs WAL) ; (4) **Tiered storage** — old partitions sur slower/cheaper disk ; (5) **Parallel scans** ; (6) **Faster vacuum** sur Postgres.

SGBD support :
- **PostgreSQL** : déclaration native depuis 10/11 (`PARTITION BY RANGE`, `LIST`, `HASH`) — pg_partman tool helps maintain.
- **MySQL/MariaDB** : partitioning native (RANGE, LIST, HASH, KEY).
- **Oracle** : leader historique partitioning, très avancé.
- **SQL Server** : partitioned tables.
- **TimescaleDB** : extension Postgres avec auto-partitioning par time (hypertables).
- **ClickHouse** : optimized for time-series via partitioning natif.

Use cases idéaux : (1) tables très grandes (>100M rows) ; (2) time-series data (logs, events, metrics, IoT) ; (3) lifecycle data (older = archived ou deleted) ; (4) multi-tenant SaaS (partition par tenant_id) ; (5) reporting analytics ON large tables.

Pièges : (1) bad partition key = pas d'amélioration ; (2) trop de partitions (e.g. par day pour 10 ans = 3650 partitions) impacts planning time ; (3) modification schema cross-partitions complex. Compétences DP-300, DEA-C01.