Notre Modèle de Coût
Algorithm 2 Algorithme de répartition de charges( Algo_Migration_Dynam)
1: Entrées: NSUR, NSOUS, MP, M
2: Sorties: MPSQ : Matrice de Placement des Sous-Requêtes
3: Fonctions: isSysLoaded() : fonction booléenne, retourne vrai si le système est équilibré.
4: Rechercher le nœud Nj ∈ NSUR ayant la plus grande priorité ;
5: Rechercher le nœud Nk ∈ NSOUS qui minimise le coût de redistribution CT entre Nk et Nj
6: Transférer le(s) fragment(s) F alloué(s) sur Nj à Nk en mettant à jour la matrice MPSQ;
7: Calculer la priorité p de Nj;
8: if (p=0) then
9: Supprimer Nj de NSUR et Nk de NSOUS ; aller à 13
10: else
11: Supprimer Nk de NSOUS et aller à 5
12: end if 13: if (isSysLoaded()) then 14: Aller à Fin 15: else 16: Aller à 1 17: end if 18: Fin
3.1.3.7 La collecte et la fusion des résultats
Une fois qu’un nœud de traitement achève la charge qui lui a été affectée, il transmet son résultat final au nœud de soumission. sachant que la communication entre les nœuds dépend
3.2. La définition de notre modèle de coût
de la topologie du réseau d’interconnexion (en bus, en étoile, en anneau, réseau maillé). Après la collecte de tous les résultats partiels, le coordinateur s’occupe de leur fusion en appliquant exactement la requête initiale, pour regrouper les résultats partiels.
3.2 La définition de notre modèle de coût
Pour définir notre modèle de coût, nous présentons cinq hypothèses :
– les tables de dimensions sont répliquées sur les nœuds de la machine parallèle et résident dans leurs mémoires centrales.
– les conditions de sélection sont toujours descendues sur l’arbre syntaxique comme dans [92].
– la distribution biaisée suit le modèle de distribution Zipf [33] comme dans [135]. – la démarche de fragmentation horizontale est basée sur les prédicats comme dans [32]. – la communication entre les nœuds de la plateforme est symétrique.
Maintenant nous avons tous les ingrédients pour estimer le coût de traitement parallèle (CT P ) d’une requête OLAP. Ce dernier comprend deux coûts : coût de traitement (CT ) et coût de communication (CC). Les deux coûts sont exprimés en termes de pages.
CT P = CT + CC (3.9)
3.2.1 Coût de traitement
Le coût de traitement dans un environnent parallèle est égal au temps d’exécution maxi-male d’un nœud. Le temps de traitement local au niveau de chaque nœud est calculé après l’élaboration du plan d’exécution optimal qui nécessite la définition d’ordre d’exécution des jointures.
Pour choisir le meilleur ordre d’exécution de jointure entre le fragment fait et les fragments de dimension, nous adoptons la stratégie "Minimum share" qui consiste à définir un seuil nommé share(F, Al, D). Share(F, Ak, D) calcule le nombre d’instances du fragment de la table
des faits Fi pour chaque instance utilisée du fragment Dkj de la table de dimension Dkà travers l’attribut Al , clé étrangère dans le fragment Fi de la table des faits F . Le share(F, D) est la moyenne des share (F, Al, D).
kFin Djk = share(Fi, Al) × kDjk . (3.10) Nous nous intéressons à la taille des résultats intermédiaire, pour éviter leur stockage sur le disque, ce qui peut augmenter le coût d’E/S.
Une fois que le plan d’exécution est identifié, les fragments sont chargés en mémoire pour le traitement. Chaque nœud soumet les résultats partiels des requêtes au nœud de soumission
qui s’occupe de la fusion des requêtes.
De plus, le temps de traitement d’une exécution parallèle est égal au temps de réponse du processeur le plus chargé. En conséquence, le coût de traitement est
K X l=1 fl× max 1≤m≤M NF X i=0
MU[l][i] × MPSQ[i][m] × T aille(Fi)
Pm
, (3.11)
3.2.2 Le coût de communication
Le coût de communication représente le coût nécessaire pour transmettre des données (ré-sultats intermédiaires ou fragments) d’un nœud Ni vers un nœud Nj. Comme pour les disques, l’unité de mesure du coût de communication est la page. Ainsi, le coût de communication d’une donnée D est calculé en multipliant le nombre de pages à envoyer par le coût unitaire de com-munication. Notons que la taille de la table doit être divisée par la taille de la page afin de calculer le nombre de pages envoyées.
K X l=1 fl× Gl X g=1 M X i=1 M X j=1
CC[i][j] × (M P SQ[g][i] × (1 − MP F[k][j])) × T aille(Fk)
P S (3.12)
où Gl représente le nombre de sous-requêtes de Ql
En résumé, le coût d’exécution d’une charge de requête sur un cluster de machine est donné par la formule suivante
K X l=1 fl× ( max 1≤m≤M NF X i=0
MU[l][i] × MM P SQ[i][m] × T aille(Fi)
Pm + Gl X g=1 M X i=1 M X j=1
CC[i][j] × (M P SQ[g][i] × (1 − MP F[k][j])) × T aille(Fk)
P S ) (3.13)
Conclusion
Dans ce chapitre, nous avons d’abord montré l’intérêt et le rôle des modèles de coût dans l’optimisation, la sélection des structures d’optimisation et la phase de déploiement des bases/entrepôts de données. Nous avons également présenté une démarche modulaire pour dé-finir l’ensemble des paramètres d’entrées de notre modèle de coût, où le sac des paramètres est partitionné en groupes dont chacun est associé à une étape particulière de la phase de déploiement. Cette démarche permet de rendre le modèle de coût plus flexible et extensible (en
ajoutant d’autres couches comme les paramètres liès auc entrées-sorties). Pour les paramètres
calculés, nous avons donné l’ensemble des formules permettant de les calculer en considérant un grappe de base de données hétérogène.
Une politique d’exécution d’une requête sur cette grappe est détaillée. Elle comprend la phase de réécriture de requêtes, l’identification des fragments des faits (sachant que les tables
3.2. La définition de notre modèle de coût
de dimension sont stockées en mémoire centrale de chaque nœud), l’ordonnancement des sous requêtes issues d’une requête globale et l’identification des nœuds pertinents pour exécuter les sous requêtes. L’idée sous-jacente à cette phase est d’allouer les requêtes sur les nœuds de la grappes. Cette phase est formalisée comme un problème d’optimisation. Nous avons montré que ce problème soit dual du problème de remplissage (Dual Bin Packing Problem). Finalement, nous avons donné l’ensemble de formules de notre modèle de coût. L’intérêt de notre modèle est sa possibilité de quantifier n’importe quelle solution de déploiement.
Notre modèle de coût sera exploité par l’ensemble des algorithmes (fragmentation, alloca-tion, réplication) qui seront développés dans les chapitres suivants.