Entreposage de données - Optimisation
Un entrepôt de données ne cesse d'évoluer et il est imprévisible quelle requête l'utilisateur va publier à l'avenir. Par conséquent, il devient plus difficile de régler un système d'entrepôt de données. Dans ce chapitre, nous verrons comment régler les différents aspects d'un entrepôt de données tels que les performances, la charge de données, les requêtes, etc.
Difficultés de réglage de l'entrepôt de données
Le réglage d'un entrepôt de données est une procédure difficile pour les raisons suivantes -
L'entrepôt de données est dynamique; il ne reste jamais constant.
Il est très difficile de prédire quelle requête l'utilisateur va publier à l'avenir.
Les exigences commerciales changent avec le temps.
Les utilisateurs et leurs profils changent constamment.
L'utilisateur peut passer d'un groupe à un autre.
La charge de données sur l'entrepôt change également avec le temps.
Note - Il est très important d'avoir une connaissance complète de l'entrepôt de données.
Évaluation de la performance
Voici une liste de mesures objectives de la performance -
- Temps de réponse moyen aux requêtes
- Taux de numérisation
- Temps utilisé par requête de jour
- Utilisation de la mémoire par processus
- Taux de débit d'E / S
Voici les points à retenir.
Il est nécessaire de spécifier les mesures dans l'accord de niveau de service (SLA).
Il ne sert à rien d'essayer de régler les temps de réponse, s'ils sont déjà meilleurs que ceux requis.
Il est essentiel d'avoir des attentes réalistes lors de l'évaluation des performances.
Il est également essentiel que les utilisateurs aient des attentes réalistes.
Pour masquer la complexité du système à l'utilisateur, des agrégations et des vues doivent être utilisées.
Il est également possible que l'utilisateur puisse écrire une requête que vous n'aviez pas réglée.
Réglage de la charge des données
La charge des données est un élément essentiel du traitement de nuit. Rien d'autre ne peut s'exécuter tant que le chargement des données n'est pas terminé. C'est le point d'entrée dans le système.
Note- S'il y a un retard dans le transfert des données, ou dans l'arrivée des données, tout le système est gravement affecté. Par conséquent, il est très important de régler d'abord le chargement des données.
Il existe différentes approches de réglage de la charge de données qui sont décrites ci-dessous -
L'approche très courante consiste à insérer des données à l'aide du SQL Layer. Dans cette approche, des vérifications et des contraintes normales doivent être effectuées. Lorsque les données sont insérées dans la table, le code s'exécute pour rechercher suffisamment d'espace pour insérer les données. Si l'espace disponible n'est pas suffisant, il faudra peut-être allouer plus d'espace à ces tables. Ces vérifications prennent du temps et sont coûteuses pour le processeur.
La seconde approche consiste à contourner tous ces contrôles et contraintes et à placer les données directement dans les blocs préformatés. Ces blocs sont ensuite écrits dans la base de données. C'est plus rapide que la première approche, mais cela ne peut fonctionner qu'avec des blocs entiers de données. Cela peut entraîner un gaspillage d'espace.
La troisième approche est que lors du chargement des données dans la table qui contient déjà la table, nous pouvons maintenir des index.
La quatrième approche dit que pour charger les données dans des tables qui contiennent déjà des données, drop the indexes & recreate themlorsque le chargement des données est terminé. Le choix entre la troisième et la quatrième approche dépend de la quantité de données déjà chargées et du nombre d'index à reconstruire.
Vérifications d'intégrité
La vérification de l'intégrité affecte fortement les performances de la charge. Voici les points à retenir -
Les contrôles d'intégrité doivent être limités car ils nécessitent une puissance de traitement élevée.
Des contrôles d'intégrité doivent être appliqués sur le système source pour éviter une dégradation des performances de la charge de données.
Requêtes de réglage
Nous avons deux types de requêtes dans l'entrepôt de données -
- Requêtes fixes
- Requêtes ad hoc
Requêtes fixes
Les requêtes fixes sont bien définies. Voici les exemples de requêtes fixes -
- rapports réguliers
- Requêtes prédéfinies
- Agrégations courantes
Le réglage des requêtes fixes dans un entrepôt de données est le même que dans un système de base de données relationnelle. La seule différence est que la quantité de données à interroger peut être différente. Il est bon de stocker le plan d'exécution le plus réussi lors du test des requêtes fixes. Le stockage de ces plans d'exécution nous permettra de repérer le changement de taille des données et le biais des données, car cela entraînera une modification du plan d'exécution.
Note - Nous ne pouvons pas faire plus sur la table de faits, mais tout en traitant les tables de dimension ou les agrégations, la collection habituelle d'ajustement SQL, de mécanisme de stockage et de méthodes d'accès peut être utilisée pour régler ces requêtes.
Requêtes ad hoc
Pour comprendre les requêtes ad hoc, il est important de connaître les utilisateurs ad hoc de l'entrepôt de données. Pour chaque utilisateur ou groupe d'utilisateurs, vous devez connaître les éléments suivants:
- Le nombre d'utilisateurs dans le groupe
- S'ils utilisent des requêtes ad hoc à intervalles réguliers
- S'ils utilisent fréquemment des requêtes ad hoc
- S'ils utilisent occasionnellement des requêtes ad hoc à des intervalles inconnus.
- La taille maximale de la requête qu'ils ont tendance à exécuter
- La taille moyenne de la requête qu'ils ont tendance à exécuter
- Si elles nécessitent un accès détaillé aux données de base
- Le temps de connexion écoulé par jour
- L'heure de pointe de l'utilisation quotidienne
- Le nombre de requêtes exécutées par heure de pointe
Points to Note
Il est important de suivre les profils de l'utilisateur et d'identifier les requêtes qui sont régulièrement exécutées.
Il est également important que le réglage effectué n'affecte pas les performances.
Identifiez les requêtes similaires et ad hoc qui sont fréquemment exécutées.
Si ces requêtes sont identifiées, la base de données changera et de nouveaux index pourront être ajoutés pour ces requêtes.
Si ces requêtes sont identifiées, de nouvelles agrégations peuvent être créées spécifiquement pour les requêtes qui entraîneraient leur exécution efficace.