Partitionnement
Statut
Document de cadrage data — version initiale.
Objectif
Le partitionnement doit améliorer la scalabilité des tables volumineuses sans complexifier trop tôt l'architecture.
Il doit être utilisé pour des volumes réels ou des besoins prévisibles, pas par principe.
État actuel visible
Une migration Supabase 20260415_stats_events.sql crée une table stats_events partitionnée mensuellement par created_at.
Cela confirme une stratégie déjà appliquée aux événements statistiques.
La partition mensuelle des contenus ou publications est une cible envisagée pour la scalabilité, mais elle n'est pas confirmée comme livrée dans les migrations Laravel inspectées.
Candidats au partitionnement
| Table ou domaine | Justification |
|---|---|
stats_events | Gros volume naturel, requêtes temporelles. |
| Publications | Volume potentiellement élevé, requêtes par date et commune. |
| Logs IA | Volume et rétention spécifiques. |
| Notifications | Historique volumineux, purge par période. |
| Audit logs | Conservation contrôlée par période. |
Principes
- Partitionner d'abord les données événementielles.
- Garder les tables métier principales simples tant que le volume le permet.
- Prévoir les partitions futures avant saturation.
- Documenter les index par partition.
- Tester les requêtes applicatives avant migration.
Risques
- Complexité opérationnelle.
- Oubli de création de partitions futures.
- Requêtes mal écrites qui scannent trop de partitions.
- Migration difficile si la table est déjà volumineuse.
Vision cible
La cible est un partitionnement progressif :
- statistiques et événements ;
- logs IA et notifications si nécessaire ;
- publications ou contenus à fort volume ;
- archivage ou stockage froid pour données anciennes.
Points à clarifier
- Maintien automatique des partitions.
- Convention de nommage.
- Politique d'archivage.
- Impact sur Laravel migrations.
- Source canonique des partitions entre Laravel et Supabase.