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 – Set Processing vs Row Processing. Cet article fait partie d’une série sur les principes fondamentaux des datawarehouse, mais s’applique à tous les traitements de type batch.

Durant 6 ans à faire des Proof Of Concept et des Benchmarks sur des datawarehouse pour les clients, il y a un domaine qui s’est toujours montré problématique: les traitements par lots (batch). La plupart du temps, ces batchs prennent la forme de procédures et packages PL/SQL, qui font du chargement de donnée, de la transformation, du traitement, ou quelque chose de similaire.
La raison pour laquelle c’est souvent problématique, c’est que les développeurs y ont codé en dur la lenteur du traitement. Je suis certain que les développeurs ne savaient pas qu’ils faisaient cela, lorsqu’ils ont codé leur PL/SQL, mais en tout cas, c’est ce qui est arrivé.

Alors comment ont-ils codé ‘en dur’ cette lenteur en PL/SQL ?

En général, c’est parce que au lieu d’avoir lu les spécifications métiers en étudiant l’état ‘avant’ et ‘après’ des données, puis d’en avoir déterminé la manière la plus efficace de faire ces modifications de données, les développeurs PL/SQL ont fait une traduction littérale de chaque règle/exigence lues dans les specs, une par une. On devine cela lorsqu’on voit du code qui parcours un curseur ligne par ligne, mais aussi dans du PL/SQL qui ne fait qu’exécuter une série de requêtes SQL souvent mal concues.

Etude de cas de la lenteur codée ‘en dur’

La suite est basée sur une histoire vécue. Seuls les noms ont été modifiés pour protéger les innocents.

Voici un extrait de pseudo-code que j’ai rencontré dans un POC:

{truncate de toutes les tables intermédiaires}
insert into temp1 select * from t1 where create_date = hier;
insert into temp1 select * from t2 where create_date = hier;
insert into temp1 select * from t3 where create_date = hier;
insert into temp2 select * from temp1 where {conditions};
insert into target_table select * from temp2;
pour chacune des  20 colonnes
loop
  update target_table t
    set t.column_name =
      (select column_name
       from t4
       where t.id=t4.id )
    where i.column_name is null
end loop
update target_table t set {liste de 50 columns} = select {50 colonnes} from t5 where t.id=t5.id;

Je m’arrête ici car la suite risquerait de vous faire pleurer.
J’hésite un peu à poser la question, mais n’est-ce pas évident ce qu’il y a de pas correct dans ce traitement ?
Voici les principales raisons que je vois à cette inefficacité:

• Pourquoi insérer toutes les données dans temp1, et ne les filtrer que lorsqu’on remplit temp2 ? Si vous n’avez jamais entendu le conseil ‘filtrez les données au plus tôt’ alors vous avez des devoirs à faire.
• Pourquoi publier dans la table cible, puis faire 20 update d’une seule colonne chacun, suivi d’un update de 50 colonnes ? Meilleure question: pourquoi faire des update de masse ? Les update (et delete) de masse sont à proscrire, il faut les éviter à tout prix.

Et alors, comme beaucoup de client qui font un POC (preuve de concept) sur une machine Exadata, ils n’ont pas du tout envie de modifier leur code, ils veulent juste voir quelle performance la plateforme Exadata peur leur délivrer. Et pour leur plus grand bonheur, ils ont réduit la durée du traitement de 2.5 jours (batch de week-end qui commence le vendredi après midi et n’est toujours pas terminé le lundi matin) à 10 heures, gagnant ainsi plus de 2 jours. Maintenant, le batch peut planter et ils auront le temps de le relancer avant l’ouverture aux utilisateurs du lundi matin. Eh, je suppose que je serais aussi très exité si je gagnait 24 heures sur un traitement de 38 heures. Mais ce n’est pas le cas lorsque je suis un ingénieur de performance de base de données qui sait qu’il y a encore plus de performance à gagner.

Comme je n’était pas satisfait par cela, j’ai pris sur moi de prouver que de re-designer le code peut avoir un retour très intéressant sur la plateforme Exadata, et j’ai codé complètement un flux de donnée qui travaille de manière ensembliste, avec juste une poignée de requêtes SQL (et pas de PL/SQL). Le résultat: le traitement d’une semaine complète de données (plusieurs centaines de millions de lignes) prend maintenant 12 minutes. C’est exact: 7 jours de données nettoyées, transformées, enrichies et publiées en 12 minutes seulement.

Lorsque j’ai annoncé la nouvelle au client, qu’il était possible de charger une semaine de données en seulement 12 minutes, ils étaient très excités, c’est le moins que l’on puisse dire. En fait, il y en a un qui a même dit, un peu hors du contexte, que maintenant une seule journée de données pourrait être chargées en 2 minutes, et que cela donnerait un autre niveau de fraîcheur aux données, ce qui permettrait au métier de prendre des décision meilleures et plus rapides, grâce aux données actualisées plus souvent. Ma réponse: CQFD ! Le client voit maintenant ce qu’il est possible de faire avec Exadata, et qui était impossible avant.

C’est pas obligatoire, mais c’est souhaitable

Je ne vais pas changer ma casquette d’ingénieur base de données en vendeur de produit, pas maintenant, et probablement jamais, mais c’est le réalité telle qu’elle existe. Les boites informatiques ont démarré avec des faibles volumes de données, et une logique de programmation sur des petits volumes, et cela a fonctionné un certain temps. Pourquoi ? Parce que le traitement peu efficace d’un faible volume de données est seulement un peu inefficace Mais la même logique de développement sur un gros volume de données devient alors très inefficace.
C’est pourquoi j’ai déjà dit: pour exploiter à fond la plateforme Exadata (ou n’importe quelle plateforme actuelle), il faut changer le code. Ne me faites pas dire ce que je n’ai pas dit: je ne dis pas qu’il est nécessaire revoir le code de l’application pour Exadata. Je dis que vous pouvez choisir de revoir le code pour Exadata parce que l’application n’est tout simplement pas conçue pour profiter du traitement massivement parallèle que Exadata permet. Il est temps que les décisions de design de l’application soient basées sur les technologies d’aujourd’hui, et non sur celles sur lesquelles l’application a été faite. Avance rapide vers aujourd’hui.

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.