Editions ENI Livres | Vidéos | e-Formations
Optimiser le modèle
Identifier les optimisations
Dans un système d’information décisionnel, les optimisations techniques peuvent être de plusieurs natures :
-
Optimiser le temps de chargement des processus de nuit, c’est-à-dire le chargement de l’ODS, du datawarehouse et des datamarts.
-
Optimiser l’espace disque occupé par l’ensemble des bases du SID.
-
Optimiser le temps de réponse des restitutions.
S’il y a parfois des optimisations techniques à effectuer pour progresser sur un point ou sur un autre, il ne faut pas non plus s’attendre à une recette miracle : un volume de données important et des opérations complexes nécessiteront toujours un temps et un espace disque non négligeables.
Un système décisionnel, c’est une part d’opérations de précalcul et une part d’opérations sur demande : il y a donc un curseur à placer entre un système rapide à charger et peu volumineux, et de l’autre côté de l’échelle, des restitutions très réactives à l’utilisation. Difficile de privilégier l’un sans pénaliser l’autre. Ainsi, au-delà des optimisations techniques, il y aura bien un équilibre à trouver dans la modélisation.
Un modèle exhaustif est un modèle comportant de nombreux datamarts...
Optimisation de la base de données relationnelle
1. Utilisation des index
Sans entrer dans les détails, les index des bases de données permettent d’identifier plus rapidement une ligne dans une base de données, en créant une sorte de sommaire de la base de données permettant de chercher une ligne en ne se focalisant que sur son index plutôt que sur tout son contenu.
L’utilisation d’index est donc recommandée, mais encore faut-il bien indexer. En effet, indexer le maximum de colonnes est bien évidemment inutile et contre-productif. La mise à jour des index est chronophage : il faut donc que le gain à l’utilisation des index dépasse le coût de création et de mise à jour, d’où leur utilisation réfléchie et parcimonieuse.
Dans le cas où l’on a identifié les opérations coûteuses (une requête particulièrement longue), les moteurs de bases de données permettent eux-mêmes d’analyser la requête et de faire une proposition d’index à créer, évaluant au passage le gain de temps potentiel.
Cette technique est à la fois la plus simple, et la plus efficace : les index nécessaires sont créés, et plus d’indexation inutile.
Exemple
L’exemple ci-dessous montre la manipulation à effectuer dans SQL Server Management Studio, l’interface de requêtage du SGBD Microsoft SQL Server, afin de déterminer et générer les index adéquats.
Après avoir saisi une requête dans la fenêtre de lancement classique, afficher le plan d’exécution (indiqué par 1 sur le schéma) :
La requête est découpée étape par étape. Si la création d’un index est utile, l’information est affichée (2). Dans ce cas, il y a possibilité de générer la requête permettant de créer l’index adéquat (3) :
La requête est générée mais non exécutée (4) :
Dans le cas où l’on ne peut pas identifier les requêtes coûteuses, que l’outil ne permet pas la suggestion d’index, ou tout simplement, par anticipation, voici les règles à suivre :
-
Pour les tables de dimensions...
Optimisation de l’utilisation du serveur ETL
Dans le cas où le processus d’intégration effectué par un ETL est long, il ne faut pas hésiter à utiliser les fonctionnalités spécifiques de chaque ETL (parallélisation, méthode de distribution des données dans les nœuds…).
Cependant, de manière générale, il est conseillé de distribuer la charge entre le serveur de base de données et le serveur ETL. Lorsqu’une base de données est source d’un traitement ETL, plutôt que d’utiliser une simple sélection sur la table, préférerez l’utilisation d’une requête SQL de sélection avancée afin de recentrer le périmètre et effectuer les opérations mieux gérées par le moteur SQL que le moteur ETL :
-
Sélectionner uniquement les colonnes nécessaires plutôt qu’un SELECT *.
-
Sélectionner uniquement les lignes nécessaires avec un WHERE.
-
Effectuer les opérations de tri avec une clause ORDER.
-
Effectuer les agrégations avec une clause GROUP BY.
De plus, au-delà du fait d’utiliser les fonctions par le moteur adéquat, cela permet d’utiliser la puissance de calcul des deux serveurs plutôt que du seul serveur ETL.
