Décision : quelle stratégie de partitionnement ?
Le partitionnement découpe une grande table en plusieurs morceaux physiques sous un même nom logique, ce qui facilite la suppression des anciennes données et permet aux requêtes de ne consulter que les morceaux pertinents (partition pruning). Sur de petites tables, en revanche, il ne fait qu'ajouter de la complexité. Cet arbre vérifie d'abord si le partitionnement est vraiment nécessaire, puis vous oriente entre Range, List, Hash et Composite selon les schémas d'accès et de répartition.
La table est-elle vraiment assez grande pour nécessiter un partitionnement ?
Le partitionnement n'est pas une solution miracle de performance ; c'est un outil d'échelle et de maintenance (cycle de vie). Si la table n'est pas assez grande ou si les requêtes sont déjà performantes avec des index, le partitionnement n'apporte que complexité des plans et surcharge de gestion. Votre table atteint-elle des dizaines de millions de lignes ou plus/des centaines de Go, ou est-elle encore petite/moyenne ?
- Oui, elle est très grande et/ou les anciennes données doivent être supprimées/archivées en masse
- Non, table petite/moyenne, ou je ne suis pas sûr
Comment accédez-vous aux données et comment les découper ?
La clé de partition doit être la colonne sur laquelle filtrent la plupart des requêtes ; c'est seulement alors que le pruning s'applique. Quel est le schéma d'accès dominant ? Par date/plages séquentielles (30 derniers jours), par valeurs de catégorie/région précises, ou n'y a-t-il pas de filtre clair et vous voulez répartir la charge uniformément ?
- Plages séquentielles comme date/numéro de séquence (X derniers jours, par mois)
- Ensembles de valeurs discrètes comme catégorie/région/tenant
- Pas de plage/catégorie claire ; l'objectif est de répartir la charge uniformément
- Date et fort volume à la fois ; découpage sur deux dimensions nécessaire
Recommandation : ne partitionnez pas (pas encore)
Le partitionnement n'apporte aucun bénéfice sur les tables petites/moyennes ; des index bien choisis et une maintenance normale suffisent. Un partitionnement prématuré complique les plans de requête, manque le pruning avec une mauvaise clé et ajoute une surcharge opérationnelle.
Recommandation : partitionnement Range
Le partitionnement Range découpe les lignes selon des plages séquentielles d'une colonne (par ex. plages de dates : une partition par mois/trimestre). C'est la stratégie la plus courante et la plus puissante pour les séries temporelles et les tables en croissance continue.
Recommandation : partitionnement List
Le partitionnement List regroupe les lignes selon des valeurs discrètes et connues d'une colonne (par ex. region = 'TR','EU','US' ou ID de tenant). Lorsqu'il existe des catégories naturelles et finies, il rend l'accès et la gestion clairs.
Recommandation : partitionnement Hash (répartition uniforme)
Le partitionnement Hash répartit les lignes de façon relativement uniforme sur un nombre prédéfini de partitions selon le hachage de la colonne clé. Il sert à éviter les points chauds et à équilibrer la charge en l'absence de plage/catégorie naturelle.
Recommandation : partitionnement Composite (multi-niveaux)
Le partitionnement composite combine deux stratégies : il découpe d'abord au niveau supérieur, puis divise chaque partition en sous-partitions (par ex. Range-by-Hash ou Range-by-List). Il est utilisé lorsque le cycle de vie temporel et la répartition uniforme/séparation par catégorie sont nécessaires en même temps.