Le passage à l’échelle est la capacité d’accompagner un accroissement de toute nature(volume, nombre de clients, charge des clients, vitesse de réseaux) de telle manière que le temps de ré-ponse soit plus ou moins constant.
Le facteur de passage à l’échelle (Scale-Up) mesure la conservation du temps de réponse d’une requête pour une augmentation proportionnelle de la taille de la base de données et le nombre des nœuds de traitement de la machine parallèle. Le scale-up est idéal s’il reste toujours égal à 1 et il est dit linéaire.
Figure 2.39 – Exemple des Scale-Up
Par exemple, soient deux problèmes P1 et P2 avec P2 n fois plus gros que P 1 et T (P i, p)
le temps d’exécution du problème Pi sur un système avec p processeurs. Ainsi, Le scale-up est défini par la formule suivante:
scale up = T (P1, p)
T (P2, p × N ) (2.2)
2.4 Bilan et discussion
Après une analyse fine de la littérature sur les travaux de le déploiement des bases de données parallèles en général et les entrepôts de données parallèles en particulier, nous re-marquons que les problèmes liés au déploiement d’une base de données parallèle, à savoir, la fragmentation, l’allocation, la réplication et l’équilibrage de charge sont traités d’une manière indépendante (isolée). Le concepteur partitionne son entrepôt en utilisant une technique par-ticulière de manière que le schéma de fragmentation généré optimise une charge de requêtes,
ensuite il alloue les fragments sur des sites (nœuds de la machine parallèle) en utilisant un algorithme particulier tel que le schéma d’allocation généré doit optimiser l’exécution de re-quêtes sur les différents nœuds. Puis, le concepteur duplique les fragments générés sur les nœuds de traitement en utilisant un algorithme dédié à la réplication de données afin d’assurer la haute disponibilité des données ainsi que la haute performance du système. Une fois les données partitionnées et allouées (d’une manière redondante), une stratégie d’équilibrage de charge est définie pour optimiser la charge de requêtes et atteindre la haute performance du système. Cette indépendance a fait naître quatre communautés, chacune travaillant sur l’un des principaux problèmes liés au problème de conception d’un entrepôt de données. Chaque communauté ne se soucie ni de la génération de ses entrées, ni d’une architectures de déploie-ment spécifique. En effet, les problèmes liés au déploiedéploie-ment des entrepôts de données ont été étudiés sur diverses architectures matérielles. Toutefois, les grands éditeurs de moteur de bases de données déploient les entrepôts de données parallèles en utilisant des approches de place-ment (circulaire, par intervalle et par hachage) et des stratégies de réplication conventuelles (chained declustering, mirrored Declustering, interleaved declustering). Malheureusement, ces approches n’utilisent aucun modèle de coût pour mesurer la performance des schémas obtenus avant son exploitation. Sachons que l’ensemble des rapports d’analyse sont élaborés durant la phase d’analyse des besoins. En outre, les autres approches proposées pour le déploiement d’un EDP utilisent au plus trois modèles de coût : un pour sélectionner l’ensemble de fragments optimisant l’ensemble de requêtes, un pour assurer une distribution efficace des fragments sur nœuds de la machine parallèle et un autre pour sélectionner le meilleur placement des répliques. Nous appelons cette démarche de déploiement par le déploiement itératif (ou séquentiel); ces étapes sont illustrées dans la figure ci-dessous.
Figure 2.40 – Les étapes de l’approche de conception itérative
L’inconvénient majeur de ce cycle de déploiement est son ignorance de l’interdépendance entre la fragmentation, l’allocation, la réplication et l’équilibrage de charge. Comme nous avons
2.4. Bilan et discussion
déjà mentionné, les problèmes liés à la conception parallèle sont mutuellement dépendants. De plus, chaque phase considère une métrique pour identifier la qualité de solution proposée. Cela génère une multitude de métriques hétérogènes qui peuvent pénaliser la solution finale. D’autre part, à l’exception des algorithmes conventionnels, l’approche de déploiement utilisée n’est pas générique. Chaque algorithme se déploie sur une architecture matérielle précise. En conséquence, les modèles de coût utilisés par ces algorithmes pour la sélection des schémas finaux ne prédisent pas correctement le coût; ils négligent l’effet de plusieurs paramètres. Les optimiseurs du SGBD sont sophistiqués et ils sont capables de prendre en considération des statistiques de base de données pour produire des estimations précises, mais le temps significatif consommé par les invocations de l’optimiseur pose des limitations sérieuses pour sélectionner la meilleure configuration de la conception physique, ce qui provoque de longues durées de fonctionnement, en particulier pour la conception physique de grandes bases de données ou d’entrepôts de données.
Ainsi, l’inexactitude dans la prédication de coût de la requête est nuisible pour la qualité des algorithmes, car ils augmentent les chances de sélectionner des solutions sous optimales. Par ailleurs, les approches proposées visent à atteindre la haute performance et elles ne considèrent la stratégie d’équilibrage de charge qu’au moment du traitement parallèle des requêtes. Donc, l’équilibrage de charge doit être pris en considération durant la phase de sélection du schéma de placement de données (qui englobe le schéma de fragmentation, d’allocation et de réplication). En conclusion, il apparaît donc qu’il existe un besoin fort d’une nouvelle approche générique de déploiement d’un entrepôt de données parallèle qui remédie à cet inconvénient.
Conclusion
Tout au long de ce chapitre, nous avons évoqué des éléments fondamentaux pour la com-préhension des entrepôts de données parallèles auxquels nous allons faire référence dans les chapitres suivants. Nous pouvons conclure que principalement l"’ déploiement d’un entrepôt de données parallèle consiste d’abord à partitionner son schéma ensuite à allouer les fragments générés sur les nœuds d’une machine parallèle. En conséquence, il est nécessaire de résoudre les problèmes suivants:
– quelle est l’architecture matérielle la plus adéquate pour un entrepôt de données ? – comment l’entrepôt de données doit-il être fragmenté ?
– combien de copies de fragments doivent être répliquées ?
– comment les fragments vont-ils être alloués sur les nœuds de la machine parallèle ? – quelle est l’information nécessaire pour le processus de fragmentation et d’allocation ? – est-ce que la charge de travail est uniformément distribuée sur les nœuds ?
– quel est le processus le plus approprié au traitement parallèle d’une requête OLAP ? Peu de travaux traitent d’une manière séquentielle (itérative) les problèmes liés au déploie-ment d’un entrepôt de données parallèle. En effet, les chercheurs utilisent plusieurs variantes des architectures sans partage pour mettre en place les EDP. Ainsi, plusieurs modèles de coût sont utilisés.
Plusieurs problèmes restent non résolus, dont principalement les algorithmes de placement où le critère utilisé change au point de dégrader l’équilibrage de la charge.
Nous devons donc faire recours à une nouvelle approche de déploiement générique sur les architecture distribuées sans partage. Notre approche prendra en considération l’interdépen-dance entre les sous-problèmes de la conception d’un entrepôt de données parallèle. Mais avant d’aborder cela, il nous faut définir un modèle unifié de coût représentant le paradigme de traitement parallèle et prenant en considération tous les paramètres des sous-problèmes de la conception d’un EDP: la fragmentation, l’allocation, la réplication et l’équilibrage de charge.
C’est pourquoi le chapitre suivant est consacré à la présentation de notre propre modèle de coût qui sera une métrique d’évaluation de la qualité de la conception d’un entrepôt de données parallèle.