Cet article est la traduction d’un article de Greg Rahn publié sur son blog. L’article original en anglais est:The Core Performance Fundamentals Of Oracle Data Warehousing – Partitioning. Cet article fait partie d’une série sur les principes fondamentaux des datawarehouse.

Le partitionnement est une fonctionnalité majeure pour les performance d’un datawarehouse sous Oracle, car l’élagage des partition (partition pruning) va la plupart du temps faire en sorte qu’il y ait moins de données à lire sur une table. Le résultat, c’est qu’il y a besoin de moins de ressources système, et que les requêtes sont plus performantes.
Quelqu’un m’a dit un jour « les I/O les plus rapides sont ceux que l’on ne fait jamais » C’est précisément la raison pour laquelle le partitionnement est ce qu’il y a de mieux pour un datawarehouse: il permet de réduire les I/O.
Je parle souvent de l’élagage des partitions (partition pruning) comme d’un anti-index. Un index est utilisé pour trouver la faible quantité de données qui est nécessaire, alors que le partitionnement est utilisé pour éliminer une grande quantité de données qui n’est pas nécessaire.

Principales utilisations du partitionnement

Je vois quatre raisons pour l’utilisation du partitionnement dans un datawarehouse Oracle:

• Élimination de données
• Jointures partition par partition (Partition-Wise Joins)
• Maintenabilité (chargements par échange de partitions, indexes locaux, etc.)
• Cycle de vie des données (Information Lifecycle Management – ILM)

Les bases du partitionnement

Le partitionnement par RANGE (ou INTERVAL) des tables de faits sur une colonne date/heure et le pattern le plus courant dans un datawarehouse Oracle. Alors le partition pruning (élagage) va éliminer les données qui ne sont pas dans la fenêtre de temps désirée, telle que définie dans la requête.

Par exemple: J’ai une table de faits qui contient les informations des points de vente, chaque ligne a un timestamp qui correspond à l’heure où l’article est passé à la caisse. Disons que cette valeur est stockée dans la colonne EVENT_TS, qui du type DATE ou TIMESTAMP. Dans la plupart des cas, il serait logique de partitionner par range sur EVENT_TS, en ayant une partition par jour Cela signifie que toutes les requêtes qui utilisent un prédicat de filtre sur EVENT_TS (donc probablement dans la plupart des cas) vont pouvoir éliminer des quantités importantes de données, celles qui ne sont pas satisfaites par le prédicat de la requête. Si vous voulez regarder les chiffres des ventes d’hier, il n’est pas nécessaire de ramener les enregistrements de la semaine dernière ou du mois dernier !

Options de sous-partitionnement

En fonction du votre modèle de données de votre datawarehouse, vous pouvez également choisir de sous-partitionner une table. Cela permet d’aller plus loin dans le partitionnement d’une table et de permettre l’élimination d’un plus grand volume de données. Et cela peut permettre aussi les jointure partition par partition (partition-wise join) qui permettent de réduire les ressources CPU et mémoire utilisées, en réduisant la quantité de données échangées entre les processus parallèle.

Pour cette raison, il est très avantageux d’utiliser le partitionnement ou le sous-partitionnement par HASH sur des modèles en troisième forme normale (3NF) pour permette les jointures partitions par partitions (partition-wise joins).

Les mod̬les dimensionnels ( mod̬les en ̩toile Рstar schema ) peuvent ̩galement b̩n̩ficier du sous-partitionnement par HASH et des jointures partition-wise.
En général il est préférable de sous-partitionner par HASH sur une colonne qui est une clé étrangère (foreign key) vers une grosse table de dimension, comme une table CLIENTS par exemple, alors la partition-wise join pourra être utilisée pour une jointure entre la table de faits et cette grosse table.

Maintenabilité

Pour différentes raisons, la gestions des des objets volumineux peut être difficile, et c’est là que le partitionnement d’Oracle permet de faire de nombreuses opérations soit au niveau global, soit au niveau des partitions ou sous-partitions. Cela rend plus facile les opérations sur des grosses tables ou indexes.

De plus le partitionnement est transparent pour les applications, ce qui signifie que les requêtes SQL faites sur un objet partitionné se comportent de la même manière que sur un objet non-partitionné. Les principales fonctionnalités comprennent:

• Chargement par échange de partition (partition exchange): Les données peuvent être chargées «hors ligne» puis échangées avec une partition de la table (ALTER TABLE ... EXCHANGE PARTITION ...).
• Des index locaux – La construction des index locaux est plus rapide qu’avec des indexes globaux.
• Compression – Peut être appliqué au niveau du segment donc il est possible d’avoir un mélange partitions compressées et non compressées.
• Move, Rebuild, Truncate et Drop – Chaque partition (ou sous-partition) est un segment et peut faire l’objet d’une opération de maintenance de manière isolée et indépendante des autres partitions de la table.
• Cycle de vie des données (ILM) – Le partitionnement permet d’implémenter une stratégie de gestion du cycle de vie des données (archivage, purge, …)

Résumé

Pour les raisons décrites ci-dessus, aussi bien de performance que de maintenabilité, je dirais que le partitionnement est une fonctionnalité indispensable pour un datawarehouse sous Oracle. Le partitionnement devrait permettre de réduire le temps de réponse des requêtes, ainsi que l’utilisation des ressources, pour faire des accès aux données plus intelligents (en n’allant voir que les données dont la requête a besoin). Il existe d’autres cas d’utilisation du partitionnement, et ils sont expliqués dans la documentation Oracle, avec des exemples.