MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE Ecole nationale Supérieure d'informatique ESI (ex-ini), Oued-Smar, Alger

Dimension: px
Commencer à balayer dès la page:

Download "MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE Ecole nationale Supérieure d'informatique ESI (ex-ini), Oued-Smar, Alger"

Transcription

1 MINISTERE DE L ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE Ecole nationale Supérieure d'informatique ESI (ex-ini), Oued-Smar, Alger MEMOIRE Pour l obtention du diplôme de : MAGISTERE EN INFORMATIQUE Option : Informatique Repartie et Mobile Présenté par : Hamiche Mahmoud Encadré par : Dr Walid-Khaled HIDOUCI Titre de la thèse : Etude comparative entre les techniques de parallélisation dans un environnement de bases de données répliquées Soutenu publiquement le 03/03/2012 devant le jury composé de : Mme. BENATCHBA Karima Prof (ESI) Président Mme ABED Hafida Prof (Université de Blida) Examinatrice Mr. AIT AOUDIA Samy Prof (ESI) Examinateur Mr. KERMI Adel M.C.B (ESI) Examinateur Dr Walid-Khaled HIDOUCI Docteur (ESI) Directeur de mémoire ANNEE UNIVERSITAIRE 2010/2011

2 Dédicaces Je dédie ce travail A ma mère chérie ainsi qu à mon père, ayant toujours tout fait pour que je ne manque de rien. A mes collègues, qui m ont aidé et soutenu pendant tout mon cursus de postgraduation. A toute ma famille pour avoir toujours cru en moi. A mes amis ayant partagé avec moi les bons et les mauvais moments.

3 Remerciements A Mr Hidouci qui m a suivis et encadrer tout au long de l année en me prodiguant de précieux conseils et en s impliquant dans les moindres détails du projet, A ma collègue Fadila qui a eu la gentillesse de corriger la présente thèse A mes collègues qui m ont aidé à réaliser cette thèse, par leurs conseils et leurs encouragements A mes enseignants qui ont contribué à ma formation et m ont aidé durant tout mon cursus à l école, A toute personne ayant contribué de près ou de loin à l aboutissement de ce travail, A ma famille et mes amis pour leur soutien indéfectible dans les moments difficiles. Mahmoud

4 Résumé : Le besoin en haute performance ne cesse de croître, particulièrement dans le domaine de gestion de données, cela est dû à la multiplication des volumes de données et la complexité des traitements. Le présent travail vise à explorer les perspectives de haute performance dans le contexte des bases de données répliquées. En effet, on adresse plus exactement le problème de l exécution parallèle des requêtes de lecture sur un cluster de stations, avec la réplication comme stratégie de partitionnement de données. Traditionnellement, la réplication était, par excellence, une solution de haute disponibilité. Toutefois, ses caractéristiques la rendent un champ fertile pour les différentes techniques de parallélisation. La plupart des solutions existantes tendent pour le parallélisme interrequêtes via le routage des requêtes, qui améliore le débit de système sans agir sur les requêtes individuelles. A travers ce travail, on se focalise sur le parallélisme intra-requête, à l aide de la technique de partitionnement virtuel avec ces deux variantes SVP (simple virtual partitioning) et AVP (adaptatif virtual partitioning), où on met l accent sur les points forts et les points faibles de chacune des deux techniques, et les conditions optimales pour leur utilisation. La validation expérimentale est appuyée par l implémentation de notre solution de parallélisation appelée «FastDBC», qui constitue un middleware exécutant au-dessus d un cluster de bases de données répliquées. Mot clés : base de données distribuée, SGBD parallèle, cluster de base de données, réplication, routage des requêtes, partitionnement virtuel, middleware. Abstract: Need of high-performance keep on progress constantly, particularly in data management field, which can be explained by the huge data volumes and the high processing complexity. This work aims to explore the perspectives of high-performance in the context of replicated databases. In fact, we consider the problem of parallel execution of read-intensive ad-hoc queries on database cluster, with replication as data partitioning strategy. Traditionally, replication was employed for high-availability. However, its characteristics make it a good area for several parallelization techniques. Most of current solutions provide inter-queries parallelism via queries routing, that improve system output without operate on individual queries. Cross this work, on focus on intra-query parallelism by the aim of virtual partitioning technique with its two versions: SVP (simple virtual partitioning) and AVP (adaptive virtual partitioning). We show the weakness and the forces of each version, besides the optimal conditions for their use. For the purpose of validation, we implemented our custom solution called FastDBC. It is a middleware that provide intra-query parallelism by executing queries on the top of database cluster. Keywords: distributed database, parallel DBMS, database cluster, replication, queries routing, virtual partitioning, and middleware.

5 Sommaire Introduction générale: Base de données et SGBD parallèle et distribuée: Introduction : Définitions : Motivations : Objectifs: Haute performance : Disponibilité des données : Haute scalabilité : Architecture matérielle: Architecture à mémoire partagée (shared memory): Avantages : Inconvénients : Architecture à disque partagé (shared disque) : Avantages : Inconvénient : Architecture sans partage (shared nothing) : Avantages : Inconvénient : Architecture hybride NUMA : Avantages : Inconvénients : Partitionnement des données : Schémas de partitionnement : Le partitionnement horizontal : Le partitionnement vertical : Le partitionnement hybride : Techniques de partitionnement : Partitionnement circulaire (round-robin): Partitionnement par intervalles : Partitionnement par hachage : Formes de parallélisme : Parallélisme inter-requêtes : II

6 Parallélisme intra-requêtes : Parallélisme inter-opérateurs : Parallélisme pipeline : Parallélisme indépendant : Parallélisme intra-opérateur : Mesure de performances: Le speed-up : Le scale-up : Problèmes liés au parallélisme : L interférence : La communication : Le coût d initialisation : Le déséquilibrage de la charge de travail (Skew) : Conclusion : Mise en parallèle des opérateurs de base : Introduction : La recherche parallèle : Le tri parallèle : Aperçu sur les algorithmes de tri séquentiel : Tri bulle : Tri par insertion : Tri fusion : Tri rapide (Quick sort) : Tri fusion parallèle (Parallel Merge-All Sort): Tri fusion binaire parallèle (Parallel Binary-Merge Sort) : Tri parallèle par partitionnement (Parallel Partitioned Sort): Les agrégations parallèles : Approche par fusion : Approche à deux phases : Approche par redistribution : La jointure parallèle : Jointure par boucle imbriquée : Jointure par boucle imbriquée simple: Jointure par produit cartésien par bloc: III

7 Jointure par produit cartésien par bloc avec indexe: Version parallèle de l algorithme de boucle imbriquée : Jointure par tri fusion : Algorithme Tri fusion simple : Algorithme tri fusion avec filtre : Version parallèle de l algorithme de tri fusion : Jointure par hachage : Jointure par hachage classique : Jointure par hachage grâce : Jointure par hachage hybride : Jointure par hachage non bloquant (pipeline hash join) : La version parallèle de l algorithme de hachage : Conclusion : Parallélisation des requêtes dans les bases de données répliquées : Introduction : Définition de réplication : Avantages de réplication : La disponibilité : La fiabilité : Les performances : Vues de donnés selon utilisation : Une autonomie accrue: Le soutien des applications évoluées : Type de réplication : Réplication synchrone : Réplication asynchrone : Approches de parallélisation : Introduction : Architecture logicielle : Le routage des requêtes et le parallélisme inter-requêtes: Aperçu sur le routage de requêtes : Objectifs de routage : La classification des stratégies de routage : Stratégies de routage : IV

8 Partitionnement virtuel et le parallélisme intra-opérateur: Pourquoi le parallélisme intra-opérateur? Définition de partitionnement virtuel : Récriture des requêtes : Partitionnement virtuel simple SVP (Simple Virtual Partitioning): Partitionnement virtuel adaptatif AVP (Adaptive Virtual Partitioning): Composition de résultat final : De la haute performance avec le partitionnement virtuel : Combiner le parallélisme inter-requêtes et le parallélisme intra-requête : Partitionnement VS réplication : Parallélisation avec la Réplication partielle : Prototype de SGBD parallèles à base de réplication : PARGRES : POWERDB : APUAMA : Conclusion : Conception et mise en œuvre d une solution de parallélisation à base de réplication : Introduction: Présentation de la solution FastDBC: Systèmes cibles: Architecture générale: Architecture détaillée: Dictionnaire de données (DataCatalogue) : Interpréteur SQL (SQLParser) : Partitionneur virtuel (VirtualPartitioner): Collecteur de résultat (ResultCollector): Exécuteur de requête (QueryExecutor): Exécuteur de requête d écriture (DataWriter): Gestionnaire de l exécution distribué (DistributionExecutionManager) : Calculateur des statistiques (StatCalculator) : Interface utilisateur (FastAdmin) : Évaluation des requêtes avec FastDBC : Caractéristique de FastDBC : Solution multiplateforme : V

9 Solution non intrusive : Tolérance aux pannes : La haute disponibilité: Equilibre de la charge de travail : Support de l hétérogénéité des sites : Parallélisme inter-utilisateurs : Scalabilité : Détails de mise en œuvre: Système d exploitation : SGBD : Langage de programmation : Bibliothèque de programmation : Conclusion : Etude expérimentale : Introduction : Benchmark de test : Récriture des requêtes avec le partitionnement virtuel: Environnement de test : Performances SVP : Performances AVP : Performances avec le Data Skew : AVP vs SVP : Conclusion : Conclusion et perspective : Annexe A : PostgreSQL : Annexe B : Requêtes TCPH benchmark : Annexe C : Configuration de Slony-I avec pgadmin[apg 11]: Bibliographie : VI

10 Liste des figures : Figure 1: Architecture à mémoire partagée... 7 Figure 2:Architecture à disque partagé (shared disque)... 9 Figure 3:architecture sans partage (shared nothing) Figure 4:Architecture hybride NUMA Figure 5:partitionnement horizontal [NEK 10] Figure 6:partitionnement vertical [NEK 10] Figure 7:partitionnement hybride [NEK 10] Figure 8:partitionnement circulaire Figure 9:partitionnement par intervalle Figure 10:partitionnement par hachage Figure 11:parallélisme inter-requêtes [TAN 08] Figure 12:exécution parallèle d'une requête Figure 13: parallélisme intra-requêtes [TAN 08] Figure 14:parallélisme pipeline [NEK 10] Figure 15: parallélisme indépendant Figure 16:parallélisme intra-opérateur [NEK 10] Figure 17:déséquilibrage de la charge de travail [TAN 08] Figure 18:tri fusion parallèle [TAN 08] Figure 19:Tri fusion binaire parallèle [TAN 08] Figure 20: Tri parallèle par partitionnement [TAN 08] Figure 21:agrégation parallèle par fusion Figure 22:agrégation parallèle à deux phases Figure 23:agrégation parallèle par redistribution Figure 24:jointure par boucle imbriqué simple Figure 25:Jointure par produit cartésien par bloc Figure 26:jointure par hachage classique Figure 27: jointure par hachage simple (version détaillée) Figure 28:architecture logicielle de système de parallélisation Figure 29:architecture de middleware Figure 30:algorithme BQNR [ROH 01] Figure 31:parallélisme intra-requête dans les bases de données répliquées Figure 32: partitionnement virtuel adaptative Figure 33:Algorithme AVP [CAM 05] Figure 34:architecture logicielle de ParGres [MAT 05] Figure 35:architecture de PowerDB [FUA 02] Figure 36:architecture APUAMA [MIR 06] Figure 37: Architecture générale de FastDBC Figure 38: Architecture interne de FastDBC Figure 39: Structure de catalogue Figure 40: Format de plan d execution logique Figure 41: Grammaire implémenté par ParserSQL de FastDBC Figure 42: Diagramme fonctionnel de partitionneur Figure 43:SGBD classique VS SGBD embarqué [KRE 10] Figure 44: fonctionnement de collecteur VII

11 Figure 45: fonctionnement de QueryExecutor Figure 46: implémentation d AVP Figure 47: Fenêtre principale de FastAdmin Figure 48: visualiser les propriétés d'un objet du catalogue Figure 49: visualiser la structure du catalogue Figure 50: Ajouter un site d'exécution Figure 51: liste des sites d'exécution Figure 52: paramétrage de la stratégie AVP Figure 53: interface de saisi de la requête Figure 54: Fenêtre de résultat Figure 55: Fenêtre des statistiques Figure 56: Schéma de TCP-H benchmark [TCP 2011] Figure 57: Graphes de temps d'exécution SVP Figure 58: graphes de temps d'exécution AVP Figure 59: Graphes temps d'execution SVP/AVP en présence de Data Skew Figure 60: Temps d'exécution SVP vs AVP Liste des tableaux : Tableau 1:transformation des fonctions d'agrégation en cas de parallélisme Tableau 2:paramètre AVP [LIM 09] Tableau 3:phase de fusion avec les fonctions d'agéragtions Tableau 4: solutions de réplication avec PostgreSQL Tableau 5: Modules parallèles et module séquentiels Tableau 6: Transformations effectués par le partitionner en cas de fonctions d'agrégation Tableau 7: règle d'écriture de requête de récupération en cas de fonction d'agrégation Tableau 8: Formules de calcul des cardinalités des tables Tableau 9:Cardinalités des tables pour les tests Tableau 10:temps d'exécution SVP sans Data Skew Tableau 11:Valeurs de test pour les paramètres AVP Tableau 12:Temps d'exécution AVP sans Data Skew Tableau 13: Temps d'exécution SVP/AVP avec le data skew VIII

12 Introduction générale: La gestion des données est l un des soucis majeurs depuis le début de l informatique. L absence de standard a conduit au fait que chaque application a mis en place ses propres structures et ses propres règles de gestion de données. La normalisation de la présentation des données à l aide du modèle relationnel a permis de développer des logiciels spécifiques à la gestion de données, appelés communément les systèmes de gestion de bases de données (SGBD). Les premiers SGBDs étaient des systèmes centralisés, tournant sur des machines séquentielles, gérant des volumes de données pouvant atteindre quelques giga octets. A l époque, les SGBDs centralisés répondent parfaitement aux besoins. Cependant, les deux dernières décennies ont connu une évolution spectaculaire des volumes de données manipulés, conjuguée à une forte complexité des traitements. La vulgarisation d Internet a élargi la portée des applicatifs. Actuellement, de nombreuses applications sont déployées sur internet, avec des millions d utilisateurs et un volume de données quotidien très important. Les SGBDs disponibles s avéraient incapables de faire face aux nouveaux besoins. Les éditeurs des SGBDs et les chercheurs ont relevé le défi, plusieurs solutions ont été proposées, en vue d améliorer les performances. Les premiers travaux se sont focalisés sur l architecture matérielle. En effet, la technologie des circuits intégrés, l augmentation de la taille des mémoires caches, l optimisation de temps d accès, la rapidité des bus, la multiplication de la taille des disques, mais surtout la diminution de coût des solutions matérielles dédiées ont incité les chercheurs à s investir dans le matérielle. Les premières alternatives de la haute performance dans le domaine des bases de données étaient les SGBDs parallèles. C est des composants logiciels qui tournent sur des supercalculateurs, constitués de plusieurs processeurs et éventuellement plusieurs disques. Les efforts se sont concrétisés par le développement de plusieurs prototypes de SGBD parallèle (GAMMA [DeW90], TERADATA, BUBBA, ). Toutefois, les SGBDs parallèles souffrent de plusieurs inconvénients, les principaux sont : leur coût élevé et leur manque de scalabilité. L évolution rapide de la technologie des réseaux de communication a ouvert de nouvelles perspectives devant les concepteurs des systèmes distribués. Les chercheurs dans le domaine des bases de données parallèles ne sont pas restés indifférents, une nouvelle variante de SGBDs parallèles a vu le jour, appelé «Cluster de bases de données». C'est un genre de SGBDs distribués tournant sur un réseau local très rapide. Un SGBD distribué adopte une approche complètement décentralisée, aucune infrastructure dédiée n est requise. L architecture matérielle est composée d un ensemble de sites (un site est souvent un simple PC de bureau) liés par un réseau d interconnexion à haut débit. Les données sont soit partitionnées, soit dupliquées sur les différentes sites, selon la stratégie mise en œuvre. Ainsi, les utilisateurs accèdent non seulement aux données présentes sur leur propre site, mais également à celles disponibles sur des sites distants. Ce type d architecture à moindre coût offre un grand potentiel de parallélisme, avec une scalabilité accrue et une bonne tolérance aux pannes. Le partitionnement des données constitue un facteur crucial pour les SGBDs parallèles, car il détermine le type et la stratégie de parallélisation. L approche traditionnelle préconise de distribuer les données à travers les sites. Le même schéma conceptuel est respecté par tous les sites, cependant les données d une table sont réparties en plusieurs fragments distincts, suivant l une des 1

13 techniques de partitionnement (round robin, par intervalle, par hachage). Une approche potentiellement simplificatrice à la distribution de données est fournie par les techniques de réplication. La réplication est définie comme étant le processus de duplication et d entretien d objets de base de données. Plusieurs copies de la même base de données sont hébergées sur des sites distincts, tout en garantissant la consistance et la cohérence des copies. Ceci dans le but d augmenter la fiabilité du système, d améliorer la tolérance aux pannes et d assurer une haute disponibilité des données, qui permet par conséquent d améliorer l accessibilité et les performances. Coté logiciel, il y avait plusieurs questions à répondre. Comment introduire le parallélisme? Quels sont les types de parallélisme possibles? Et comment les combiner efficacement? Le parallélisme intra-requête était la première source potentielle de parallélisme. Certes les mêmes opérations basiques sont effectuées par les SGBDs séquentiels et les SGBDs distribués (sélection, jointure, tri, agrégation). Toutefois, le degré de complexité et les considérations architecturales sont nettement supérieurs dans un environnement distribué. Les implémentations séquentielles ne sont plus valables en cas de parallélisme. L implémentation du parallélisme intra-requête est passée par la conception de nouveaux algorithmes spécifiques à chaque type d architecture, et à chaque approche de placement de données. Le parallélisme inter-requêtes représente une alternative intéressante, surtout pour les systèmes de réplication, dans la mesure où il permet d évaluer les requêtes en parallèle sur des sites distincts en parfaite isolation. Notons, que ce type de parallélisme est mis en place à l aide d un middleware, qui permet d équilibrer la charge de travail. La présente thèse se focalise sur les stratégies de parallélisation dans les bases de données répliquées, et plus particulièrement le partitionnement virtuel. Notre objectif est de démontrer, dans un environnement réel, qu en plus de la haute disponibilité, les bases de données répliquées peuvent être exploitées pour offrir de la haute performance, avec le partitionnement virtuel comme une stratégie de parallélisation. En outre, les deux variantes du partitionnement virtuel SVP (Simple Virtual Partitioning) et AVP (Adaptive Virtual Partitioning) sont profondément étudiées et une comparaison exhaustive entre eux est dressée, en vue d identifier les points forts et les points faibles de chaque variante. L étude théorique est consolidée par l implémentation d un prototype baptisé «FastDBC», qui met en pratique les différents concepts abordés, et permet de valider les résultats théoriques. A travers cette thèse, on a essayé de faire le tour des différentes notions et techniques relatives aux bases de données parallèles. La thèse est composée de cinq chapitres. Le premier clarifie tous les concepts liés aux SGBDs et bases de données parallèles et distribuées : la définition, les motivations, les architectures matérielles, les techniques de partitionnement, les formes de parallélisme, la mesure de performances et les problèmes confrontés lors de la parallélisation. Le chapitre deux est consacré aux implémentations des opérateurs relationnels (la recherche, le tri, la jointure, les agrégations) et leur adaptation au parallélisme sur les architectures «sharednothing». On étale les principaux algorithmes parallèles, qui ont été employés sur les différents SGBDs parallèles, que ce soit des prototypes universitaires, où des produits commerciaux, notamment ceux spécifiques à l opérateur de jointure, vu son coût, sa complexité et sa nature, qui rendent son optimisation plus importante. Le chapitre trois met l accent sur les opportunités de parallélismes dans les bases de données répliquées. On commencera par définir la technique de réplication, ses types, ses avantages et ses 2

14 inconvénients. Par la suite, on se focalisera sur les approches de parallélisation dans les bases de données répliquées : le routage des requêtes avec ses variantes, qui emploie le parallélisme interrequête, et le partitionnement virtuel avec ses deux version (SVP et AVP), qui propose une implémentation du parallélisme intra-requête. On poursuit avec la réplication partielle, et on termine par évoquer quelques prototypes de SGBD à base de réplication. Dans le quatrième chapitre, on va procéder à la description de l outil que nous avons développé dans le cadre de ce travail, qu on a nommé «FastDBC». C est un middleware, qui permet d évaluer les requêtes SQL sur un cluster de base de données avec la technique de partitionnement virtuel. La partie majeure du chapitre est consacrée à l architecture logicielle, ou chaque composant est décrit en détails (le fonctionnement et la structure). La suite du chapitre met la lumière sur l interface utilisateur de l outil et ses caractéristiques logicielles. Le cinquième et dernier chapitre est dédié à la validation expérimentale, ou une série de tests est effectuée sur le benchmark TCP-H. l étude expérimentale vise à prouver l efficacité de la technique du partitionnement virtuel dans un environnement réel, et à établir une comparaison entre ses deux variantes SVP et AVP. 3

15 Chapitre1 : Base de données et SGBD parallèle et distribuée Chapitre 1 : Base de donne es et SGBD paralle le et distribue e 4

16 Chapitre1 : Base de données et SGBD parallèle et distribuée 1. Base de données et SGBD parallèle et distribuée: 1.1. Introduction : Dans ce chapitre, on va définir les concepts de base relatifs à la gestion des bases de données parallèles, avec la définition des SGBDs parallèles et distribués, les architectures matérielles, les formes de parallélisme, les techniques de partitionnement, et la mesure des performances Définitions : Une base de données distribuée [Con05] peut être vue comme une collection de plusieurs bases de données physiquement distribuées sur un ensemble de sites, sémantiquement reliées, car elles partagent le même schéma conceptuel. Les données peuvent être fragmentées, ainsi chaque site héberge uniquement une partie des données. L autre option consiste à répliquer les données, cela implique la duplication de la base de données sur chaque site (une copie par site). Un système de base de données distribué (SGBDD) est constitué d un ensemble de sites faiblement couplés, dotés chacun d un SGBD centralisé. Idéalement, ses sites sont complètement indépendants, le moyen d interconnexion est un réseau à haut débit, avec aucun support physique partagé. En outre, le système de base de données tournant sur chaque site peut être différent d un site à l autre, donnant la possibilité d intégrer plusieurs SGBD centralisés (Oracle, SQLSERVER, PostgreSQL ) dans un seul SGBD distribué. Côté fonctionnel, chaque site peut être impliqué dans l exécution des requêtes (transactions ou requêtes de consultation). Cela est défini selon la stratégie d exécution, la disponibilité des sites, et le placement des données. Un système de base de données parallèle [Dew92], décrit un SGBD usuel, qui tend à améliorer les performances à travers une implémentation parallèle des opérations basiques exécutés massivement par un SGBD, comme : la lecture des données, la construction d indexe, et l évaluation des requêtes. Un SGBD parallèle est destiné à tourner sur une machine parallèle (typiquement une machine multiprocesseur), cela est fortement demandé, puisqu il était conçu en vue de tirer profit de la puissance offerte par le matériel. Par analogie, une base de données crée sur un SGBD parallèle est dite : base de données parallèle Motivations : Le traitement parallèle des données, implémenté à l aide des SGBD parallèles et distribués n est plus qu une curiosité scientifique, mais un besoin réel et rationnel. Actuellement, on assiste à l émergence de plusieurs applications qui manipulent une quantité énorme de données (de l ordre de téraoctets) laissant les SGBD centralisés complètement dépassés. Le passage des SGBDs centralisés vers des SGBD parallèles est motivé par les facteurs suivants : L utilisation massive des ordinateurs, et l évolution exponentielle d internet ont donné issue à des applications qui sont utilisées à l échelle mondial, avec éventuellement des millions d abonnés. Les données collectées sur leur identité, habitudes, préférences et passions ont produit des grandes bases de données. Les organisations et les entreprises exploitent généralement ses bases de données pour des besoins d analyse (les produits les plus vendus, les liens les plus visités, les services les plus demandés ). Les requêtes employées pour ce type de besoins sont complexes et relativement lourdes à exécuter. Ainsi, les SGBD centralisés ne sont pas capables de répondre efficacement à ce genre de requête. 5

17 Chapitre1 : Base de données et SGBD parallèle et distribuée Les données relationnelles sont naturellement adaptées au traitement parallèle. Que ce soit le stockage des données, ou le traitement des requêtes peuvent être mises en parallèle avec un léger effort. La technologie des supercalculateurs et des mainframes a atteint ses limites. Aujourd hui, on est arrivé à la barrière technologique, sur plusieurs fonds. La fréquence d horloge est entrain de stagné, on a du mal à augmenter la quantité de mémoire vive, la vitesse de bus et des disques croit lentement, en plus du coût qui est considéré très élevé par rapport au cluster de PC. L évolution des technologies des réseaux a aboutie à des réseaux de communication plus fiables et des bandes passantes plus larges. Ainsi, les délais de transmission sont considérablement réduits 1.4. Objectifs: Le partage des bases de données sur plusieurs machines a fait, depuis de nombreuses années, l objet de recherches intenses dans le but d augmenter la puissance du calcul, qui constitue un facteur important de l efficacité d une application Haute performance : Tout d abord, l un des principaux objectifs du parallélisme consiste à offrir un rapport coût/performance plus satisfaisant que celui des gros systèmes [Dew92]. Deux métriques sont généralement utilisées afin de mesurer les performances d un système: le débit (en transactions par seconde) et le temps de réponse. Le parallélisme permet d augmenter le débit global si plusieurs requêtes sont exécutées simultanément (parallélisme inter-requêtes) et de décroître le temps de réponse si plusieurs processeurs coopèrent à l exécution de la même requête (parallélisme intra-requête). Toutefois, diminuer le temps de réponse d une requête peut induire un surcoût de communication et engendrer par voie de conséquences une dégradation du débit global Disponibilité des données : Un système parallèle de base de données utilise la réplication des données afin d accroître leur disponibilité. En effet, étant constitué de composants identiques, le SGBD maintient au moins deux copies stockées sur chacun des disques le constituant. Par la suite, la panne d un des disques n induit aucun coût, du moment que les données qu il contenait sont disponibles au niveau d un autre disque. Il va de soi que le support des copies multiples nécessite l implémentation d un software qui maintient la cohérence de ces copies Haute scalabilité : Un système parallèle idéal doit avoir deux caractéristiques clés: une capacité d accroissement linéaire (scale-up) et une accélération correspondante au gain de performances, obtenu en augmentant le nombre de processeurs, et en laissant la base de données telle quelle. La capacité d accroissement est mesurée en augmentant proportionnellement la taille de la base de données et le nombre de processeurs. L idéal est que l accélération augmente proportionnellement au nombre de processeurs et que la capacité d accroissement reste constante. 6

18 Chapitre1 : Base de données et SGBD parallèle et distribuée 1.5. Architecture matérielle: Certes La haute performance est la raison principale derrière l émergence des bases de données parallèles et distribués, mais il est évident que tous les concepts théoriques proposés n auraient pas été concrétisés, si on ne possédait pas le matériel adéquat. La mise en œuvre du parallélisme sousentend l utilisation de support matériel parallèle, typiquement des supercalculateurs dotés de plusieurs processeurs, mémoires, disques et éventuellement divers périphériques. L architecture matérielle d un système parallèle est étroitement liée à son domaine d utilisation. En effet, le choix d une architecture destinée à supporter un SGBD parallèle est guidé par le souci d atteindre tous les objectifs cités précédemment, avec le meilleur rapport prix/performances, de plus, le bon partage d information entre processeurs conditionne l efficacité et l extensibilité d un système parallèle. Plusieurs supports matériels ont été exploités pour la mise en œuvre des SGBDs parallèles, passant par des machines SMP, les machines UMA, les clusters MPP, jusqu à les clusters de PC, etc. cependant, toutes ces machines sont reparties en quatre catégories : les architectures à mémoire partagée, à disques partagés, sans partage et les architectures hybrides Architecture à mémoire partagée (shared memory): Cette architecture est caractérisée par une mémoire centrale et disque dur partagé. Ils sont accessibles à tous les processeurs du système, avec un coût d accès uniforme pour toutes les parties de la mémoire. Les différents composants du système (processeurs, mémoire, disques, autres périphériques) sont reliés par un périphérique d interconnexion (bus), qui permet l accès direct à la mémoire. Mémoire partagée M M M Disque partagé D D D Réseau d interconnexion P P P P Processeurs Figure 1: Architecture à mémoire partagée L implémentation d un SGBD parallèle au-dessus de telles architectures est relativement évidente, d une part les données sont rassemblées sur le même emplacement, ce qui ressemble à un SGBD 7

19 Chapitre1 : Base de données et SGBD parallèle et distribuée centralisé. Et d autre part la charge de communication est largement réduite grâce au partage de la mémoire. Plusieurs SGBD parallèles ont adopté cette architecture : XPRS[Sto88] de l université de Berkeley, Volcano [Gra94], Oracle [Dav92], Sequent, Encore, Escala et DBS3 [Rim04] Avantages : Plusieurs facteurs ont contribué au succès de cette architecture : Cette architecture a abrité Plusieurs SGBDs parallèles avec succès Accès rapide aux données Facilité d implémentation L équilibrage de charge est facile à réaliser Tolérance aux pannes, car la défaillance d un processeur ne provoque pas l arrêt du système Inconvénients : Cependant, cette architecture présente quelques faiblesses qui réduisent considérablement son efficacité : Le principal inconvénient est l interférence entre processeurs. En effet, l ajout d un nouveau processeur peut affecter les performances des processeurs existants. Ainsi, cette architecture supporte un nombre limité de processeurs (entre 2 et 8), au-delà de ça, l accès à la mémoire peut devenir un véritable goulot d étranglement (à cause des accès conflictuels et la congestion sur le bus d interconnexion), qui diminue significativement le gain occasionné par l ajout d un nouveau processeur. L architecture à mémoire partagée est peu scalable. Un nombre restreint de processeurs peut être incorporé. En outre, l ajout de processeurs peut nécessiter la mise à jour de la partie hardware, mais aussi la partie software. Ainsi, cette architecture est plus adéquate aux applications de taille moyenne, ou on n a pas besoin d exploiter le parallélisme massif. Le coût de ce type d architecture est relativement élevé. Telles machines demeurent inaccessibles pour plusieurs entreprises et organisations qui nécessitent des solutions hautes performances mais ne dispose pas de budget suffisant Architecture à disque partagé (shared disque) : Dans une architecture à disques partagés, tous les processeurs accèdent à l ensemble des disques mis à disposition du système, via un réseau d interconnexion. Chaque processeur est muni d une mémoire local, qui lui est exclusivement réservée (aucun autre processeur ne peut lui accéder). Cette architecture a permet d améliorer la scalabilité des architectures à mémoire partagé, en éliminant les conflits d accès et en allégeant la congestion sur le réseau d interconnexion. En contrepartie, le problème de cohérence des mémoires locales est surgit. En effet, la lecture de la même page disque par plusieurs processeurs pose le problème de cohérence entre les copiés, et cela d autant plus que le nombre de mises à jour est important. Ceci suggère l utilisation d un mécanisme de cohérence de cache, qui peut être coûteux (en coût et en performance) à mettre en œuvre. Parmi les SGBDs ayant adoptés cette architecture on cite : l IMS/VS data sharing product d IBM [Suw 82], VAX DBMS de DEC [KLS 86], et Oracle Parallèle Server [Dav92]. 8

20 Chapitre1 : Base de données et SGBD parallèle et distribuée Processeurs/mémoires P P P P M M M M Réseau d interconnexion D D D Disque partagé Figure 2:Architecture à disque partagé (shared disque) Avantages : Cette architecture est similaire à l architecture à mémoire partagée, seul le niveau de partage qui diffère. Donc, elle présente tous ces avantages, en plus de : L élimination des conflits d accès à la mémoire centrale Offrir plus de tolérance au panne, car le seul support partagé est le disque. Donc, tant que le disque est fonctionnel et au moins un processeur est actif, le système restera fonctionnel Faciliter la répartition de la charge de travail Inconvénient : Un surcoût lié au mécanisme de cohérence de cache. Cette architecture doit être inévitablement équipée d une partie software ou hardware, qui doit garantir la cohérence entre des différentes copies d une même page disque chargées sur les mémoires locales et la copie original située au niveau de disque. Notons que le mécanisme de cohérence peut affecter significativement les performances globales du système L accès disque peut se transformer en véritable goulot d étranglement, si les mémoires locales ne sont pas suffisamment grandes. Les processeurs sont amenés à faire beaucoup d accès disque, en aboutissant à une congestion sur le réseau d interconnexion. 9

21 Chapitre1 : Base de données et SGBD parallèle et distribuée Architecture sans partage (shared nothing) : Dans une architecture à mémoires distribuées, aucune ressource n est partagée. Ainsi, chaque processeur possède son propre disque dur, et sa propre mémoire locale. Typiquement, cette architecture est constituée d une collection de PC, ou stations de travail connectés par le bais d un réseau d interconnexion à haut débit. Cette architecture est caractérisée par l absence de tous types de partage, Les données sont fragmentées ou dupliquées sur les différents postes, la communication est réalisée uniquement par échange de messages via le réseau. Actuellement, la tendance est vers les systèmes distribués, l architecture à mémoire distribuées est un et par excellence. Ainsi, la plupart des travaux récents sur les SGBDs parallèles y optent, en introduisant un nouveau type de SGBDS appelés : les SGBD répartis. Ce type d architecture est beaucoup moins coûteux que les autres, vu qu aucun matériel dédié n est requis, un réseau de quelques PC de bureau sera largement suffisant pour l implémenter. En outre, elle est facilement extensible, de nouveaux postes peuvent être aisément incorporés au système, au même titre que les postes défaillants, qui seront soit remplacés, soit éliminés. En plus, elle garantit la haute disponibilité à travers la duplication des données. Cependant, ses systèmes ne sont pas complètement maitrisés, leur développement et administration représentent un véritable défi. Autrement, leurs performances sont étroitement liées à la stratégie d équilibrage de la charge de travail, un mauvais équilibrage réduit considérablement le gain occasionné par l utilisation du parallélisme. Le coût de communication peut être élevé (l exécution des requêtes peut nécessiter la redistribution des données). La vulnérabilité aux pannes est un problème qui s accentue avec l augmentation de nombre de postes sur le réseau. De nombreux SGBDs parallèles ont été implémenté au-dessus de cette architecture, nous citons : Teradata de ATT, NonStopSQL de Tandem, Gamma de l université de Wisconsin [DeW90], Bubba de MCC [Rim04], EDBS et PRISMA/DB Avantages : Extensibilité élevé Haute disponibilité des données Moindre Coût Inconvénient : Difficulté de réaliser l équilibrage de charge Difficulté d implémentation et d administration Vulnérabilité aux pannes 10

22 Chapitre1 : Base de données et SGBD parallèle et distribuée Processeurs/mémoires/disques D D D D P P P P M M M M Réseau d interconnexion Figure 3:architecture sans partage (shared nothing) Architecture hybride NUMA : L architecture hybride connue sous le nom NUMA (Non Uniform Memory Access), est proposée comme un compromis entre le manque d extensibilité de l architecture à mémoire partagée, et la difficulté de réaliser l équilibrage de charge dans l architecture à mémoire distribuée. Un système NUMA est une structure hiérarchique, il est constitué d un ensemble de nœuds connectés par un réseau d interconnexion usuel, comme une architecture à mémoire partagée. Néanmoins, les nœuds ne sont pas des simples PC mais des supercalculateurs calculateurs à mémoire partagée. Cette architecture hérite des avantages des deux architectures à mémoire partagée et à mémoire distribué. L extensibilité n est pas pénalisée, car on peut toujours ajouter des supercalculateurs à mémoire partagée. Par ailleurs, l équilibrage de charge est relativement facile à implémenter, puisque, un seul nœud est généralement suffisant pour exécuter, en parallèle, une requête, et rares sont les cas, ou on étale l exécution sur plusieurs nœuds. Tandis que le coût reste son inconvénient principal. Le prix d une telle machine est extrêmement élevé. De nombreux prototypes de machine NUMA ont vu le jour. Des exemples récents de machines commerciales à architecture NUMA sont la NUMA-Q de Sequent et la Convex SPP1200 qui peuvent 11

23 Chapitre1 : Base de données et SGBD parallèle et distribuée supporter quelques centaines de processeurs. Coté SGBD, Informix et DB2 d IBM sont des exemples qui supportent cette architecture Avantages : Elle permet d offrir l extensibilité des architectures à mémoire partagée La réalisation d équilibrage de charge est relativement simple Elle présente les meilleures performances, par rapport aux autres architectures Inconvénients : Un coût élevé Architecture matérielle complexe Réseau d interconnexion Figure 4:Architecture hybride NUMA 12

24 Chapitre1 : Base de données et SGBD parallèle et distribuée 1.6. Partitionnement des données : Le partitionnement et le placement des données dans les SGBDs parallèles est l un des facteurs critiques, qui font d un SGBD parallèle un système performant ou non. En effet, le placement de données détermine la qualité de l équilibrage de charge assurée par le système, de même il peut apporter de considérable gain en temps, particulièrement dans un système multidisques, car une bonne distribution de données permet, en effet, de répartir les accès sur les différents disques, et d optimiser ainsi le temps d accès et le débit global Schémas de partitionnement : Trois approches ont vu le jour quant à le partitionnement des données [BEL 04]. La première approche est le partitionnement horizontale, il porte uniquement sur les données, le schéma conceptuel reste intacte. La deuxième approche est le partitionnement vertical, cette dernière nécessite la modification de schéma. La troisième approche, appelée le partitionnement hybride, est la combinaison des deux premières Le partitionnement horizontal : Le partitionnement horizontal consiste à diviser une relation R en sous-ensembles de tuples appelés fragments horizontaux, chacun étant défini par une opération de restriction appliquée à la relation. Les tuples de chaque fragment horizontal satisfait une clause de prédicats. Le schéma de fragmentation de la relation R est donné par : H1 = Cl1 (R), H2 =Cl2(R), Hq = Clq (R), où Cli est une clause de prédicats. La reconstruction de la relation R à partir de ces fragments horizontaux est obtenue par l'opération d'union de ces fragments. Le partitionnement horizontal se décline en deux versions : Le partitionnement horizontal primaire et Le partitionnement horizontal dérivé. Le partitionnement primaire d'une relation est effectué grâce à des prédicats de sélection définis sur la relation elle-même. Tandis que, Le partitionnement horizontal dérivé se réalise avec des prédicats de sélection définis sur une autre relation. Figure 5:partitionnement horizontal [NEK 10] Le partitionnement vertical : La fragmentation verticale n agit pas sur les données mais sur le schéma. En effet, une relation est divisée en sous relations appelées fragments verticaux, obtenus en appliquant des projections sur la relation à fragmenter. Chaque processeur héberge la totalité des tuples d une relation, mais avec un sous-ensemble d attributs. La jointure de tous les fragments verticaux permet de reconstruire la relation d origine. 13

25 Chapitre1 : Base de données et SGBD parallèle et distribuée Les requêtes de projection peuvent tirer du profit du schéma de partitionnement. Seuls les processeurs qui détiennent les attributs requis sont impliqués dans son exécution, le reste des processeurs seront éventuellement confiés à l exécution d une autre requête. L inconvénient de ce schéma est, qu'il requiert des jointures supplémentaires lorsqu'une requête accède à plusieurs fragments. Figure 6:partitionnement vertical [NEK 10] Le partitionnement hybride : Afin de combiner les avantages des deux schémas de partitionnement horizontal et vertical, le partitionnement hybride (appelé aussi mixte) est proposé comme un compromis. Une relation R est d abord fragmentée horizontalement, puis chaque fragment horizontal est divisé verticalement en plusieurs fragments verticaux. Notons, qu on peut commencer par un partitionnement vertical suivi, d un partitionnement horizontal. Figure 7:partitionnement hybride [NEK 10] 14

26 Chapitre1 : Base de données et SGBD parallèle et distribuée Techniques de partitionnement : La répartition horizontale des grands volumes de données sur plusieurs disques, permet d accélérer les opérations d entrées/sorties, en lisant en parallèle sur tous les disques. Diverses stratégies de partitionnement ont été employées, on note : Le partitionnement circulaire Le partitionnement par intervalle Le partitionnement par hachage Partitionnement circulaire (round-robin): Cette stratégie de partitionnement est la plus simple. Les tuples sont placés sur les sites selon leur numéro d ordre. Ainsi, le premier tuple sera mis sur le premier nœud, le deuxième tuple sur le deuxième nœud, on continue de cette manière jusqu au dernier nœud, puis on poursuit de manière circulaire comme précédemment. En général, le IIème tuple sera mis sur le nœud (I MOD N) tel que N est le nombre de nœuds disponibles. Cette technique de répartition de données, également connue sous le nom Round-Robin, garantie un bon équilibre de la charge de travail entre les différents nœuds, pour les requêtes nécessitant des parcours séquentiels. Par contre, elle représente un inconvénient pour les applications désirant avoir des tuples ayants des valeurs particulières. Figure 8:partitionnement circulaire Partitionnement par intervalles : Cette technique permet de réunir dans le même disque tous les tuples dont la valeur de l attribut de répartition appartient à un intervalle précis. Si on dispose de N disques, alors, on devise l intervalle de l attribut de partitionnement en N sous-intervalles consécutifs et disjoints, et on associe un intervalle à chaque disque. Cette technique s avère très utile pour les demandes de parcours séquentiels où associatifs (trouver tous les tuples ayant la même valeur pour un attribut), ainsi que la recherche d échelle de valeurs (par exemple trouver les ouvriers dont le salaire est inférieur à 12ooo DA). Par contre cette stratégie ne garantit pas l équilibre de charge entre les processeurs, de même avec cette stratégie, on risque 15

27 Chapitre1 : Base de données et SGBD parallèle et distribuée une distribution non uniforme des données. Les SGBDs parallèles Bubba, Gamma, Oracle et Tandem offrent cette méthode de partitionnement. La dénomination anglophone de cette méthode est «Range partitioning». Figure 9:partitionnement par intervalle Partitionnement par hachage : Ce type de partitionnement connu sous le nom de «hash partitioning», répartit les données en fragments dont les tuples sont sémantiquement liés. Il consiste à appliquer une fonction de hachage sur un sous-ensemble d attributs, la valeur retournée par la fonction de hachage détermine le site sur lequel le tuple sera placé. Ainsi les tuples, au sein d un même fragment, ont tous la même valeur de hachage. Figure 10:partitionnement par hachage 16

28 Chapitre1 : Base de données et SGBD parallèle et distribuée Cette technique s avère performante pour les applications désirant faire des recherches exactes basées sur l attribut(s) de partitionnement, où le site hébergeant les tuples cherchés sera adressé directement, évitant d exécuter la requête sur l ensemble des sites. Cela permet de réduire le coût d exécution de la requête, en plus les sites n ayant pas participé à l exécution peuvent être exploités pour traiter d autres requêtes. Néanmoins, le partitionnement par hachage présente de faibles performances vis-à-vis des requêtes par intervalle. Tous les sites doivent contribuer à l exécution de la requête, ce qui dégrade les performances. Sur un autre stade, cette technique est très sensible à la distribution des valeurs de l attribut de hachage, en effet, si certaines valeurs sont plus fréquentes que les autres, les fragments résultants peuvent être potentiellement déséquilibrés, ce qui baisse considérablement l apport de parallélisme. Les SGBDs parallèles : Bubba, Arbre, Gamma et Teradata offrent cette méthode de partitionnement. 17

29 Chapitre1 : Base de données et SGBD parallèle et distribuée 1.7. Formes de parallélisme : Parallélisme inter-requêtes : Le parallélisme inter-requêtes tend à exécuter en parallèle les différentes requêtes et transactions soumises par les usagers. En effet, cette forme de parallélisme ne permet pas d accélérer l exécution des requêtes individuelles. Cependant, elle améliore significativement le débit en transactions, ainsi le parallélisme inter-requête est plus intéressant dans un contexte multi-utilisateurs, ou un nombre important de requêtes (relativement simple) sont soumises en parallèle. Le parallélisme inter-requêtes est la forme la plus simple du parallélisme à implémenter dans un système de base de données, et plus particulièrement sur les architectures à mémoire partagée. Les SGBDs conçus pour les machines séquentielles peuvent tourner, moyennant de quelques changements, sur un supercalculateur à mémoire partagée, car même les SGBDs séquentiels supportent l exécution concurrente des transactions. Ainsi, les transactions exécutées en pseudoparallélisme sur une machine séquentielle, profiteront d un parallélisme réel sur un supercalculateur. Tandis que le support de parallélisme inter-requêtes sur une architecture à mémoire distribuée, est plus difficile à mettre en œuvre, puisque il nécessite l installation des mécanismes supplémentaires pour garantir la cohérence des données. Figure 11:parallélisme inter-requêtes [TAN 08] 18

30 Chapitre1 : Base de données et SGBD parallèle et distribuée Parallélisme intra-requêtes : Le parallélisme intra-requêtes se réfère à l'exécution d'une requête unique en parallèle sur plusieurs processeurs et disques. Du moment où le parallélisme inter-requêtes ne permet pas d accélérer l exécution d une requête (exécution séquentielle des requêtes), le parallélisme intra-requêtes est tant important, vu qu il permet d accélérer l exécution des requêtes de longue durée. Une requête relationnelle est constituée de plusieurs opérations de base : des jointures, des sélections, des tris et des agrégations. Donc, une exécution parallèle d une requête implique l exécution parallèle de ces opérations de base. Pour illustrer le principe, prenons l exemple d une requête effectuant la jointure entre quatre relations appelées respectivement R1, R2, R3, R4, les jointures sont notées J1, J2, J3. Une stratégie de parallélisation simple préconise de calculer simultanément les deux jointures J1 et J3, puis J2. Figure 12:exécution parallèle d'une requête Une autre approche consiste à exécuter la même requête, mais sur un ensemble disjoint de données. La requête est lancée sur un ensemble de processeurs, ou chacun abrite une partie de données. Les résultats intermédiaires, retournés par l ensemble des processeurs, sont regroupés pour constituer le résultat final. 19

31 Chapitre1 : Base de données et SGBD parallèle et distribuée Figure 13: parallélisme intra-requêtes [TAN 08] Parallélisme inter-opérateurs : Le parallélisme de type inter-opérateur consiste à exécuter en parallèle plusieurs opérateurs du graphe de la requête, afin de réduire le temps nécessaire à la résolution de cette dernière. On peut citer deux formes de parallélisme inter-opérateurs : le parallélisme inter-operateurs Indépendant et le parallélisme inter-operateurs pipeline. Dans la première forme, les opérateurs ne sont pas liés, or dans la deuxième forme, le début de certaines opérations nécessite les résultats d une autre opération (producteur-consommateur) Parallélisme pipeline : Le pipelining est une technique primordiale pour accélérer l exécution des requêtes. Il consiste à exécuter deux opérations A et B en parallèle, de tel façon que les tuples produits par A sont immédiatement consommés par B, sans attendre la matérialisation de la totalité des tuples produits par A. l avantage de cette technique, pour les SGBDs séquentiels, est qu elle permet d éviter la sauvegarde des résultats intermédiaire. Cela reste valable pour les SGBDs parallèles, mais en plus on peut faire tourner les deux opérations A et B sur deux processeurs distincts, ainsi l opération B consomme concurremment ce que l opération A produit. Le pipelining convient bien aux architectures à nombre restreint de processeurs. En effet, la chaine pipeline (ensemble d opérateurs exécutés en pipeline) ne doit pas dépasser une certaine longueur. En plus une partie des opérateurs algébriques ne supporte pas le pipelining, leurs entrées doivent être complètement matérialisées avant le début de l exécution, on prend comme exemple l opérateur de tri. 20

32 Chapitre1 : Base de données et SGBD parallèle et distribuée Figure 14:parallélisme pipeline [NEK 10] Parallélisme indépendant : Ce type de parallélisme intervient quand les opérateurs d une même requête sont mutuellement indépendants. Sur la figure ci-dessous, les deux opérateurs OP1 et OP2 peuvent profiter de parallélisme indépendant, en les lançant sur deux processeurs distincts, sur probablement des fragments de deux données disjoints. Cette technique n offre pas un haut degré de parallélisme, du fait que les possibilités d opérateurs indépendants sont généralement limitées au sein d une requête. Figure 15: parallélisme indépendant 21

33 Chapitre1 : Base de données et SGBD parallèle et distribuée Parallélisme intra-opérateur : Un opérateur de base opère généralement sur des tables de très grande taille. On peut pousser la granularité de parallélisme jusqu à l opérateur. Un tel parallélisme est réalisé, on exécutant l opérateur simultanément sur des fragments séparés de données. Ce type de parallélisme est appelé «parallélisme intra-opérateur». Le défi principal dans le parallélisme intra-opérateur est de savoir comment réorganiser les données de telle façon à offrir plus de parallélisme. De plus, il n est pas possible de réaliser ce type de parallélisme avec la version séquentielle des opérateurs de base, ainsi leur reformulation s avère inévitable, afin de fournir une version plus sophistiquée, qui tire profit de parallélisme. Il faut noter que ce parallélisme nécessite la définition du nombre de nœuds alloués à un même opérateur, de même la stratégie d exécution la mieux adaptée à son contexte (par exemple pour avoir le résultat final d une sélection, on fusionne les différents résultats de chaque instance de l opérateur). Figure 16:parallélisme intra-opérateur [NEK 10] 1.8. Mesure de performances: L objectif principal de parallélisme est d améliorer les performances. Cependant, concevoir des métriques robustes, qui permettent de quantifier le gain occasionné par l utilisation de parallélisme reste problématique. Actuellement, les métriques existantes s appuient sur deux mesures : le débit en transactions, qui désigne le nombre de transaction validés par unité de temps, et le temps de réponse, qui représente le temps écoulé entre la soumission de la requête et le retour de résultat. Dans un système qui traite un grand nombre de requêtes simples, on s intéresse à augmenter le débit en transaction, par exécuter autant que possible de requêtes en parallèle. Tandis que, sur un système, qui reçoit de lourdes requêtes, on préfère améliorer le temps de réponse, en décomposant chaque requête complexe en sous-requêtes pouvant être lancées en parallèle. Dans le domaine des SGBDs parallèles, deux métriques sont adoptées pour mesurer les performances : le premier est le «scale-up», il reflète le débit en transaction. Le deuxième est «speed-up», il indique l accélération sur le temps de réponse Le speed-up : Ce paramètre permet de mesurer l accélération obtenu par l ajout de nouvelles ressources matérielles (processeurs, mémoires et disques). Il est exprimé par le rapport entre le temps de réponse séquentielle (sur une machine monoprocesseur) et le temps de réponse parallèle (sur une 22

34 Chapitre1 : Base de données et SGBD parallèle et distribuée architecture parallèle). Soit TS le temps de traitement d une opération exécutée de manière séquentielle, et TP le temps d exécution de la même opération en parallèle sur P processeurs, le speed-up obtenu par l exécution parallèle est donné par la formule suivante : ( )= Un système parallèle idéal est celui qui permet d obtenir un speed-up linéaire (Speed-up(P) = P). Un speed-up idéal indique qu une opération peut être exécutée n fois plus vite, si on dispose de n fois plus de ressources matérielles. Notons que le speed-up caractérise l algorithme utilisé sur une architecture matérielle donnée, et non les performances d une machine. Par exemple certains algorithmes présentent des speed-up super linéaires (Speed-up(P) > P), cela signifie que lorsque la taille du système augmente, leur rapport temps/taille est décroissant. Ceci se produit généralement dans les solutions matérielles/logicielles dédiées (le logiciel et le matériel sont conçu pour marcher ensemble) On peut déduire l efficacité EP d un algorithme parallèle, à partir de speed-up, en divisant le speedup par le nombre de processeurs, autrement dit, le rapport entre le speed-up effectif et le speed-up idéal : = Il est important de connaitre qu il est plus facile d obtenir de bon speed-up avec des algorithmes de jointures peu efficaces (ex : boucles imbriquées). En effet, la part des surcoûts d exécution est d autant plus grande que le temps de réponse est petit. La mesure de speed-up ne peut donc être prise pour comparer deux systèmes ou deux stratégies d exécution. Il est important dans ce cas de mesurer aussi les performances relatives aux deux systèmes ou stratégies [BOU 96] Le scale-up : Ce paramètre exprime le fait de pouvoir traiter des tâches de plus en plus lourdes, dans un temps constant en augmentant le degré de parallélisme. En d autres termes, le scale-up montre la capacité d un système parallèle n fois plus gros à résoudre un problème n fois plus grand. Pour illustrer le principe. Prenant deux problèmes à traiter appelés respectivement P1 et P2, tel que P2 est n fois plus grand (la taille de problème est mesurée selon le contexte de traitement) que P1. T(P1,m) le temps nécessaire pour résoudre P1 sur m processeurs et T(P2,m*n) le temps nécessaire pour résoudre P2 sur m*n processeurs. Alors le scale-up est donné par la formule suivante : = ( 1, ) ( 2, ) Un système parallèle idéal est celui qui permet d obtenir un scale-up égale à 1. Un scale-up linéaire signifie de garder le même niveau de performances quand la charge de travail et le nombre de ressources sont augmentées ensemble. Dans le contexte des bases de données, un problème n fois plus grand est obtenu par augmenter n fois le volume de données à traiter. Par exemple, supposons qu on désire mesurer le scale-up d un opérateur de sélection. Pour obtenir une sélection n fois plus grande, il suffit simplement de multiplier le volume des données à sélectionner par n. Ceci n est pas toujours vrai. En effet, la notion de complexité est délicate à manipuler, et ne peut s appliquer qu aux 23

35 Chapitre1 : Base de données et SGBD parallèle et distribuée problèmes relativement simples, par exemple pour le cas d une opération de jointure, la complexité n est pas linéairement proportionnelle à la taille de ses opérandes. C est pour cette raison que la mesure de speed-up, est plus facile à mettre en œuvre, est souvent préférée à celle du scale-up Problèmes liés au parallélisme : Bien que l intégration du parallélisme dans les SGBDs s avère séduisant, son apport peut être considérablement diminué à cause de plusieurs obstacles. En effet, une implémentation efficace d un SGBD parallèle est énormément complexe. Le gain réel apporté par le parallélisme est largement audessous du gain théorique. Cela est dû à plusieurs facteurs, on cite : L interférence : Dans un système parallèle, l accès aux ressources partagées (matérielles ou logicielles) est souvent synchronisé, des règles de cohérence doivent être vérifiées à chaque accès (ex : un seul processus accède à une section critique). Cela implique la mise en attente de certaines tâches, ce qui limite le gain de parallélisme. Notons qu une ressource mal gérée, où trop sollicitée peut se transformer en goulot d étranglement, en provoquant une dégradation intense des performances La communication : La coordination et l ordonnancement des tâches est une caractéristique des systèmes parallèles. Leur implémentation nécessite la mise en place des mécanismes de communication. La communication inter-processeur est effectuée à l aide des routines système souvent lourdes. L émetteur et le récepteur doivent passer par une phase de synchronisation qui risque d être conséquente. De plus dans une architecture à mémoire partagée, la communication implique le transfert des messages réseau. L impact de communication est d autant plus important que le degré de parallélisme est élevé. En effet, une grande quantité de messages de contrôle et de données sont échangées entre les différentes entités concurrentes pour assurer l exécution parallèle. La communication constitue un obstacle majeur à l obtention d un haut speed-up. C est pour cette raison que beaucoup de travaux se sont focalisés sur la minimisation de nombre de messages échangés Le coût d initialisation : Une phase d initialisation est effectuée avant de passer à l exécution effective d une requête. Après l analyse syntaxique et sémantique de la requête, elle est décomposée en sous-requêtes, ou chacune sera lancée sur un processeur. Le lancement de chaque sous-requête implique la création d une ou plusieurs entités concurrentes (threads ou processus) qui seront chargées de l exécution effective de la requête. En fin d exécution. Les sous-résultats, produits par chaque sous-requête, seront consolidés pour former le résultat final. Toutes ses opérations sont réalisées par le site hôte, donc elles sont exécutées séquentiellement. Le temps d exécution de la phase d initialisation est directement proportionnel au degré de parallélisme. Ainsi, dans une architecture composée de plusieurs centaines de sites, le temps d initialisation sera particulièrement conséquent, à un point de dominer le temps global d exécution, en aboutissant à un speed-up relativement faible. Donc, il est très utile de choisir judicieusement le degré de parallélisme, afin de réduire le temps d initialisation, toutes en exploitant au mieux l architecture parallèle. 24

36 Chapitre1 : Base de données et SGBD parallèle et distribuée Le déséquilibrage de la charge de travail (Skew) : Réduire le temps de réponse en distribuant la charge d une requête sur plusieurs processeurs est l objectif d une exécution parallèle. Le principal obstacle à cet objectif est la mauvaise distribution de la charge. Lorsque des processeurs sont surchargés alors que d autres sont inactifs. Les performances d une exécution parallèle peuvent alors se dégrader considérablement. Typiquement, le temps de réponse correspond à celui du processeur le plus chargé. En effet, ce problème est certainement celui qui affecte le plus la mesure de speed-up d une exécution parallèle. La figure ci-dessous illustre le problème pour une exécution sur quatre processeurs. Figure 17:déséquilibrage de la charge de travail [TAN 08] Comme nous avons deux types de parallélisme d une requête: le parallélisme intra-opérateurs (horizontalement), en distribuant chaque opérateur sur un ensemble de processeurs, et le parallélisme inter-opérateurs indépendant ou pipeline (verticalement), en distribuant tous les opérateurs de la requête sur différents processeurs. Les solutions proposées pour la répartition de charge sont généralement spécifiques à un type de parallélisation et à une architecture spécifique. Plusieurs techniques de répartition de la charge de travail ont vu le jour ([KIT 90], [SCH 89], [SHA 93], [BRU 95]). La plupart des travaux se sont portés sur le traitement de dataskew en cas de jointure, car le déséquilibrage est plus néfaste Conclusion : A travers ce chapitre, on a mis en évidence les notions rudimentaires des bases de données parallèles, notamment : les objectifs et les motivations, les architectures matérielles, les formes de parallélisme, la technique de partitionnement et ses variantes, le traitement parallèle des requêtes, les métriques permettant de mesurer le gain d une exécution parallèle.et enfin, on a évoqué quelques problèmes liés à l exécution parallèle. 25

37 Chapitre 2: Mise en parallèle des opérateurs de base Chapitre2 : Mise en paralle le des ope rateurs de base 26

38 Chapitre 2: Mise en parallèle des opérateurs de base 2. Mise en parallèle des opérateurs de base : 2.1. Introduction : Le parallélisme intra-opérateur est généralement la source du parallélisme la plus importante. Idéalement, il est obtenu par le partitionnement des données, en gardant l implémentation séquentielle des opérateurs relationnels. Cependant, cela n est pas toujours vrai, des opérateurs relationnels comme la jointure nécessite un traitement sophistiqué pour sa mise en parallèle, d autres doivent être adaptés afin de tirer profit du parallélisme. Ainsi, une large panoplie d algorithmes a proposé des implémentations parallèles pour la quasitotalité des opérations de bases au sein d un SGBD. L opérateur de jointure a pris la part du lion, vu son coût, sa complexité et sa nature, qui imposent un véritable défi. Dans ce chapitre, on étalera les principaux algorithmes parallèles, qui ont été employés sur les différents SGBDs parallèles, que ce soit des prototypes universitaires, où des produits commerciaux. Dans ce qui suit, on présentera une collection d algorithmes parallèles employés pour la parallélisation des opérateurs relationnels. Cependant, on mettra l accent d avantage sur les variantes destinées principalement aux architectures «shared nothing» La recherche parallèle : L opération de recherche dans le contexte des bases de données est représentée par L opération de sélection. C est l une des opérations les plus communes de l algèbre relationnel. La sélection est un opérateur unaire, autrement dit, elle prend comme paramètre une seul table. Elle permet de sélectionner un ensemble de tuples, à partir de la table cible, qui répondent à un critère donné. Sous SQL, l opération de sélection est exprimée par la clause «WHERE», qui définit le critère de recherche, appelé également prédicat de recherche. La version parallèle de l opération de sélection est particulièrement intuitive, il s agit de lancer l opération de rechercher sur tous les sites hébergeant un fragment de la table cible, puis rassembler les tuples produits par chaque site, afin de constituer le résultat final. Néanmoins, quelques optimisations peuvent être introduites, selon le prédicat de sélection et le type de partitionnement. Dans le cas d une recherche exacte (le prédicat de recherche porte sur un seul attribut, avec un test d égalité à une valeur) avec un partitionnement par hachage ou intervalle. Si l attribut de recherche est celui du partitionnement, l opérateur de recherche est instancié uniquement sur le site susceptible de contenir les tuples recherchés. La recherche par intervalle peut bénéficier d un traitement privilégié, dans le cas d un partitionnement par intervalle sur l attribut de recherche. Seuls les sites, dont l intervalle du partitionnement chevauche avec l intervalle de recherche, seront impliqués dans l exécution de l opération de sélection Le tri parallèle : Aperçu sur les algorithmes de tri séquentiel : Tri bulle : c est le tri le plus ancien et le plus simple qui est encore utilisé, malgré qu il soit le plus lent. Le tri bulle compare chaque élément dans la liste avec l élément suivant, et les permuter si 27

39 Chapitre 2: Mise en parallèle des opérateurs de base nécessaire, l algorithme répète ce processus jusqu à faire une passe sur la liste sans permuter aucun élément. Cet algorithme est facile à implémenter, sa complexité est O(n2) Tri par insertion : comme son nom le suggère, cet algorithme insère chaque élément dans sa propre place dans la liste finale, l implémentation la plus intuitive nécessite deux listes, la liste source, et la liste dans laquelle les éléments seront insérés. Cependant les implémentations les plus courantes exploitent une seule liste afin d optimiser l utilisation de la mémoire. Sa complexité est O(n2), mais il est plus efficace que le tri bulle Tri fusion : il divise la liste à trier en deux sous listes de même taille, chaque sous liste est triée récursivement, puis fusionnée avec l autre sous liste pour former la liste finale, comme la plus part des tris récursive, le tri fusion a une complexité de O(n log n) Tri rapide (Quick sort) : c est un algorithme massivement récursif, il adopte la stratégie «diviser pour résoudre». il est le plus rapide parmi les algorithmes de complexité O(n log n), théoriquement c est le plus simple, mais sa difficulté réside dans son implémentation, il se compose de 4 phases : Si la liste à trier est vide, ou elle contient un seul élément, alors retour. Prend un élément de la liste comme pivot. Diviser la liste en deux sous-listes, l une contient les éléments inférieurs au pivot, l autre contient les éléments restants. Répéter récursivement l algorithme pour les deux sous listes Tri fusion parallèle (Parallel Merge-All Sort): Le tri fusion parallèle est historiquement le premier algorithme étant employé pour réaliser le tri parallèle. Ainsi, il a été implémenté par de nombreux prototypes universitaires (Gamma [DEW 90]) et SGBDs commerciaux. Typiquement, cet algorithme est composé de deux phases : une phase de tri local, et une phase de fusion globale. La phase de tri local est effectuée indépendamment sur chaque site, en utilisant un algorithme de tri séquentiel. La phase de fusion finale est entamée juste après la fin de l étape de tri local. Les fragments triés, au niveau de chaque site, sont transférés au site hôte, qui se charge de les fusionner pour former le résultat final. 28

40 Chapitre 2: Mise en parallèle des opérateurs de base Figure 18:tri fusion parallèle [TAN 08] Bien que le tri fusion parallèle soit relativement simple, il expose une faiblesse flagrante. La phase de fusion est purement séquentielle, un seul site est attribué à l étape de fusion, cela est d autant plus critique que le nombre de site effectuant le tri est élevé. Le problème de congestion du réseau est potentiellement posé. Une grande quantité de données sera transférée sur le réseau à la fin de tri local, ce qui génère un trafic énorme. Ces deux anomalies peuvent réduire considérablement l efficacité de cet algorithme Tri fusion binaire parallèle (Parallel Binary-Merge Sort) : Le tri fusion binaire parallèle est similaire au tri fusion parallèle. La phase de tri local est la même, tandis que la phase de fusion est distribuée sur plusieurs sites en adoptant la technique de pipeline. Les sites contribuant au tri sont structurés de manière hiérarchique. Chaque deux sites situés au niveau des feuilles, effectuent le tri puis envoient le résultat, en pipeline, au site de niveau supérieur, qui accomplit la fusion. Cela se poursuit jusqu à atteindre la racine qui est rien d autre que le site hôte. Cet algorithme est qualifié de «binaire», car les sites sont groupés en triangles, deux sites réalisent le tri et le troisième effectue la fusion. La version générale appelée «Parallel K-Merge Sort» permet de concentrer K sites effectuant le tri local auteur d un seul site, qui effectue la fusion. 29

41 Chapitre 2: Mise en parallèle des opérateurs de base Figure 19:Tri fusion binaire parallèle [TAN 08] Il est évident que cette variante permet d atténuer le problème de fusion séquentielle, en partageant son exécution sur plusieurs sites. En outre, le pipeline évite de matérialiser le résultat intermédiaire. Cependant, le problème de fusion séquentielle n est pas complètement contourné. La fusion finale, considérée la plus lourde, est effectuée sur le site hôte, où les deux séquences les plus grandes sont fusionnées séquentiellement. 30

42 Chapitre 2: Mise en parallèle des opérateurs de base Tri parallèle par partitionnement (Parallel Partitioned Sort): Cet algorithme de tri est inspiré des algorithmes de jointure parallèle, où le travail est décomposé en une phase de redistribution suivi d une phase de traitement local. Dans le tri local par partitionnement, les données sont d abord redistribuées par intervalle. Chaque site scanne ses propres données, puis il les répartie sur l ensemble des sites, selon les intervalles calculés en amont. A la fin de la phase de distribution, chaque site disposera d une séquence de tuples non triés appartenant à son intervalle correspondant. Ensuite, chaque site entamera une phase de tri local. Les fragments triés sont transférés au site hôte, qui se charge de les consolider dans l ordre adéquat afin de former le résultat final. Figure 20: Tri parallèle par partitionnement [TAN 08] Cet algorithme est intéressant dans la mesure, où il permet d éviter la fusion séquentielle, et offrir un haut degré de parallélisme, vu que l ensemble des sites participent aux deux phases de traitement. Malgré ces avantages, le problème de déséquilibrage de la charge de travail peut dégrader significativement les performances de cet algorithme. En effet, si la redistribution des données génère des fragments déséquilibrés, la phase de tri local devient considérablement lourde, car la fin d exécution de cette étape n est atteinte qu après la fin des exécutions des tris locaux Les agrégations parallèles : Les requêtes d agrégations permettent de grouper les tuples selon un ensemble d attribut, afin d extraire des informations synthétiques. Des fonctions d agrégations (somme, moyenne, taille de groupe) sont appliquées par la suite sur les groupes résultants. Ce type de requêtes est plus fréquent dans les systèmes décisionnels. Ces derniers traitent des volumes de données gigantesques, par conséquent le besoin en haute performance est plus insistant. Trois approches ont été proposées pour agréger en parallèle les données. 31

43 Chapitre 2: Mise en parallèle des opérateurs de base Approche par fusion Approche à deux phases Approche par redistribution Approche par fusion : Cet algorithme était la première issue pour le calcul parallèle des agrégations, qui était implémenté au départ par le prototype Gamma. L approche par fusion est réalisée en deux phases, un calcul des agrégations locales, suivi d une étape d agrégation globale. Pendant la phase d agrégation locale. Chaque site groupe ses tuples, selon les attributs d agrégations désignés, et applique les fonctions d agrégations indépendamment des autres sites. Après la fin des calculs d agrégations locales, les résultats intermédiaires sont envoyés au site hôte. Ce dernier se charge d effectuer l agrégation globale. Son calcul est similaire à l agrégation locale, cependant les fonctions d agrégation sont appliquées sur les différents résultats reçus, après consolidation. Figure 21:agrégation parallèle par fusion Il est évident que cette approche peut être extrêmement performante, si le nombre de sites est restreint, et les tailles des résultats intermédiaires sont petites. Autrement, l agrégation globale peut consommer la portion majeure du temps d exécution, et puisque cette phase est séquentielle, le gain de parallélisme devient moins important. Pour remédier à cet inconvénient, une autre variante de cet algorithme agit sur la phase d agrégation globale, au lieu de l exécuter séquentiellement, les sites sont structurés en hiérarchie binaire. Ainsi, chaque deux site accomplissent une l agrégation local, puis envoient le résultat au site de niveau supérieur, ce dernier à son tour, agrège les tuples reçus, et les envoie au site supérieur, jusqu à arriver au site hôte. 32

44 Chapitre 2: Mise en parallèle des opérateurs de base Approche à deux phases : Comme son nom l indique, cette approche agit en deux phases : une phase d agrégation locale, suivie d une phase d agrégation globale. L étape d agrégation locale est similaire à celle de l approche par fusion. Chaque site agrège ces propres tuples selon l attribut d agrégation, comme il s agit d une agrégation séquentielle usuelle. Les résultats intermédiaires, obtenus suite à l exécution de l agrégation locale, sont ensuite distribués sur l ensemble des sites participant à l exécution, selon l attribut d agrégation. Le schéma de distribution choisi doit répartir les tuples sémantiquement. Les techniques de partitionnement par intervalle ou hachage sont souvent employées, le round-robin est à écarter. La fin de distribution est suivie par une phase d agrégation globale. Ainsi, chaque site regroupe les tuples issus de distribution suivant l attribut d agrégation. Les tuples ayants des valeurs identiques pour l attribut d agrégations sont fusionnés, et les fonctions d agrégation sont appliquées. Les résultats temporaires de l agrégation globale sont ensuite renvoyés au site hôte, qui se charge de les consolider pour constituer le résultat final. Figure 22:agrégation parallèle à deux phases L avantage de cette approche est qu elle permet de calculer en parallèle l agrégation globale, et d éviter le goulot d étranglement créé par l exécution séquentielle. Néanmoins, l introduction de la redistribution sous-entend le problème de déséquilibre de la charge de travail, qui reste le premier inconvénient pour n importe quel algorithme qui adopte la redistribution Approche par redistribution : Cette approche est inspirée principalement des algorithmes de calcul de jointure (voir ci-dessous). Typiquement, le calcul est décomposé en deux étapes. Une étape de redistribution sanctionnée par une phase de traitement locale. Ainsi, l approche par redistribution se poursuit en deux phases, une phase de distribution et une phase de calcul d agrégation. 33

45 Chapitre 2: Mise en parallèle des opérateurs de base D abord, les tuples sont redistribué suivant l attribut d agrégation, en appliquant une technique de partitionnement sémantique (intervalle, ou hachage). Cette phase va produire des fragments de données disjoints (sur l attribut d agrégation). Une valeur de l attribut d agrégation n est présente que sur un seul fragment. Ainsi, les sites peuvent calculer les agrégations locales indépendamment les uns des autres. Sur chaque site, les tuples résultants de la distribution, sont agrégés et les fonctions d agrégations sont appliquées, afin de calculer les mesures d agrégat. Les résultats d agrégations sont ensuite renvoyés au site hôte, qui les consolide pour constituer le résultat final. Figure 23:agrégation parallèle par redistribution Cette approche a la particularité de ne pas recourir à l agrégation locale. Tous le calcule se résume en une distribution suivie d une agrégation usuelle, aucun traitement spécifique n est requis. Visiblement, cette technique est plus performante que les deux précédentes. Toutefois, ces performances sont étroitement liées à la qualité de distribution, et la vitesse du réseau d interconnexion, car il est évident que la quantité de données échangée est nettement supérieure La jointure parallèle : L'opération de jointure, de deux relations R et S, est en général coûteuse, en raison de la taille des résultats qui peut atteindre R * S ( R, et S désignent les tailles des relations R et S). De ce fait, une opération de jointure sur plusieurs relations peut potentiellement produire un résultat, dont la taille est proche du produit des tailles des relations référencées. Durant les dernières décennies des efforts significatifs ont été focalisés sur la conception des algorithmes de jointure efficaces. Initialement, la jointure par produit cartésien, par boucle imbriquée (nested loops), ou par tri fusion (sorte merge) étaient des algorithmes de choix. Cependant des travaux menés par [KIT 83] et [DEW 84] ont démontré le potentiel des méthodes basées sur le hachage. Cette variante d algorithmes de jointure a attiré beaucoup d attention au sein de la communauté scientifique et industrielle, vu qu elle a affiché des performances plus élevées, et une haute adaptabilité vis-à-vis les architectures parallèles. 34

46 Chapitre 2: Mise en parallèle des opérateurs de base Jointure par boucle imbriquée : Jointure par boucle imbriquée simple: L algorithme le plus simple, et dans certain sens le plus intuitif, pour implémenter la jointure de deux relations R et S, est le produit cartésien, appelé aussi la boucle imbriquée. Il consiste à comparer chaque tuple de la relation R (appelé la relation interne) avec tous les tuples de la relation S (appelé relation externe), comme il est indiqué dans la figure24. L avantage principal de cet algorithme est sa simplicité, un autre avantage, c est qu il peut calculer le produit cartésien et tous les types de jointure, c'est-à-dire avec n importe quel prédicat de comparaison (=, <>,>, <). Cependant, les optimisateurs des requêtes évitent le produit cartésien, à cause de sa tendance à garder, en mémoire, beaucoup de tuples, qui éventuellement ne satisferont pas le prédicat de jointure lors de l évaluation. A l exception des cas ou la relation interne est très petite, les performances de la jointure par boucle imbriquée sont catastrophiques, car elle implique un grand nombre de comparaisons. De plus, pour des relations internes de grande taille, qui ne peuvent pas tenir complètement en mémoire vive, il est nécessaire d'effectuer un grand nombre d'entrées/sorties. Figure 24:jointure par boucle imbriqué simple Donc cette technique présente deux inconvénients majeurs. Le premier réside dans sa structure qui implique R * S comparaisons. Le second provient de sa gestion de la mémoire. En effet, si l'une ou l'autre des relations ne tient pas en mémoire, un grand nombre d'entrées/sorties vont avoir lieu. Notons que les entrées/sorties se font en général par page de données et non par tuple Jointure par produit cartésien par bloc: Pour garantir une gestion meilleure de la mémoire d une part, et pallier aux insuffisances observées chez l algorithme de jointure par boucle imbriquée simple d autre part, une technique appelée jointure par produit cartésien par bloc a été proposée. Elle permet de minimiser le nombre des entrées/sorties dans le cas de relations ne tenant pas en mémoire. 35

47 Chapitre 2: Mise en parallèle des opérateurs de base Cette variante consiste à maximiser le nombre de pages de R chargées en mémoire, en se contentant de charger une seule page de S à la fois. Ensuite les pages de la relation interne R (chargée en mémoire) sont parcourues, page par page, et leur contenu est alors comparé aux tuples formants la page (chargée en mémoire) de la relation externe S. Supposons qu on dispose de α pages en mémoire centrale, donc on va allouer α -2 pages à la relation R. Une des deux pages restantes est utilisée afin de charger au tour de rôle les pages de la relation S. La seconde sert à stocker les tuples résultats (elle est écrite sur disque lorsqu'elle est pleine). Ainsi, les tuples des pages de R en mémoire sont comparés à ceux de chaque page de S. Lorsque toutes les pages de S ont été chargées, afin que les tuples de R leurs soient comparées, on charge α -2 nouvelles pages de R, et on leur présente les pages de S, et ainsi de suite jusqu'au traitement complet de R, la figure25 met en évidence la technique. Figure 25:Jointure par produit cartésien par bloc Jointure par produit cartésien par bloc avec indexe: Une autre amélioration peut être apportée à la jointure par produit cartésien, en introduisant un indexe sur l attribut de jointure de la relation externe S. En effet, dans l algorithme présenté précédemment, chaque tuple de R est comparé à l ensemble des tuples de S. L index, sur les tuples de S, permet pour chaque tuple de R, de récupérer un pointeur sur les pages de S contenant des tuples correspondants au tuple de R. De cette manière, il suffit ensuite de charger les pages contenants les tuples de S, afin d'en extraire ceux-ci et de les joindre au tuple de R en cours de traitement, ce qui réduit considérablement le nombre de comparaisons Version parallèle de l algorithme de boucle imbriquée : Une version parallèle de cet algorithme consiste à partitionner la relation externe S sur les différents processeurs constituant la machine parallèle. Ensuite, on diffuse la relation interne R sur ces processeurs. Mais dans le cas où la relation interne R est volumineuse (cas fréquent), il est évident que cette approche implique un surcoût de communication très important ce qui va faire chuter les performances. Une amélioration certaine consiste à distribuer les deux relations à l'aide d'une fonction (commune) de hachage (ou par intervalle) portant sur l'attribut de jointure. Les variantes faisant intervenir un 36

48 Chapitre 2: Mise en parallèle des opérateurs de base index supposent que S ait été indexé à l'avance. A nouveau, cet algorithme sera plus intéressant si S est répartie suivant l'attribut de jointure et à l'aide d'une fonction de hachage ou par intervalles, car R peut alors être répartie de la même façon, plutôt que dupliquée sur chaque processeur Jointure par tri fusion : Algorithme Tri fusion simple : Le second algorithme, souvent utilisé pour la jointure, est le tri fusion (sort merge). Il faudrait que les deux relations soient triées sur l attribut de jointure, ensuite une étape de fusion des deux relations triées sera faite. Le principe consiste à partir du premier tuple de R et du premier tuple de S. Notons R.a l'attribut de jointure de R et S.b l'attribut de jointure de S. Si R.a est inférieur à S.b, on passe au tuple suivant de R. Si R.a est supérieur à S.b, on passe au tuple suivant de S, est enfin si R.a et S.b sont égaux, on produit un tuple résultat. On passe ensuite au tuple suivant d'une des deux relations Algorithme tri fusion avec filtre : Il s agit d une combinaison entre la boucle imbriquée et le tri fusion, d abord la relation interne (plus petite) est triée sur l attribut de jointure, puis sauvegardée dans un fichier temporaire. Ensuite toute la mémoire disponible sera exploitée pour créer des séquences triées à partir de la relation externe (plus grande) en utilisant le remplacement et la sélection [GOE 93]. Ces séquences ne seront pas écrites sur disque, mais elles seront immédiatement jointes à la relation interne en utilisant le tri fusion. Cet algorithme réduit le nombre de parcours de la relation interne à la moitié par rapport à l algorithme de boucle imbriqué, et il évite l écriture et la lecture de fichier temporaire contenant la relation externe triée Version parallèle de l algorithme de tri fusion : La version parallèle de l algorithme de tri fusion est une adaptation fidèle de l algorithme traditionnel destiné aux machines monoprocesseur. La relation la plus petite des deux relations, impliquées dans la jointure (soit R), est d abord redistribuée à travers la table de division (split table), qui contient une entrée par processeur (avec son disque correspondant). Une fonction de hachage est appliquée sur l attribut de jointure pour chaque tuple, afin de déterminer le site (processeur plus disque) approprie. Au moment où les tuples arrivent à un site, ils seront stockés dans un fichier temporaire. Quand la totalité de la relation R est redistribuée, chaque fichier local est alors trié en parallèle. À noter que chaque fragment de R sur chaque disque passe à travers la table de division (split table) pour la redistribution. La relation S sera traitée de la même manière. Du moment que la même fonction de hachage est exploitée pour redistribuer les deux relations, seules les tuples contenues dans des fragments se trouvant sur le même site, sont susceptible d être joints. Pendant la phase suivante, une étape de fusion locale est effectuée en parallèle sur tous les sites participants à la jointure. Ensuite, les résultats locaux seront rassemblés pour produire le résultat final. 37

49 Chapitre 2: Mise en parallèle des opérateurs de base Jointure par hachage : Jointure par hachage classique : La version la plus simple de cet algorithme consiste à appliquer une fonction de hachage sur l attribut de jointure de la plus petite relation (soit R), afin de construire une table de hachage (cette opération est appelée phase de build). Ensuite, on applique la même fonction de hachage, pour chaque tuple de la plus grande relation (soit S), et on le compare avec les tuples de la première relation ayant la même valeur de hachage (phase de probe). En cas d égalité, les deux tuples seront concaténés et ajoutés au résultat. Un exemple de la jointure par hachage simple est illustré dans la figure cidessous. Figure 26:jointure par hachage classique Chaque tuple de R est inséré dans la table de hachage, selon la valeur obtenue en appliquant la fonction de hachage, sur l attribut de jointure (Dept dans cet exemple). S il y a plus d un seul tuple ayant la même valeur de hachage, ils seront chaînés dans la même entrée (R1 et R3 dans l entrée 2). A la fin de cette étape, la table de hachage sera bâtie. Pour chaque tuple de S, la même fonction de hachage sera appliquée sur l attribut de jointure. Si la valeur de hachage indique une entrée vide, ce tuple sera écarté, sinon le tuple sera comparé avec tous les tuples liés à l entrée correspondante. S il y a une égalité la paire est écrite dans la relation résultante. 38

50 Chapitre 2: Mise en parallèle des opérateurs de base La raison pour laquelle, on choisit la plus petite relation pour bâtir la table de hachage, est d essayer d éviter de construire une table volumineuse, qui éventuellement ne tient pas complètement en mémoire, ce qui baisse les performances, à cause des entrées/sorties. Mais même la plus petite relation peut produire une table, dont la taille dépasse la mémoire disponible. Afin de remédier au problème de débordement de la table de hachage, une technique permet de répartir la relation interne R en paquets, de sorte que chaque paquet sert à former une portion de la table qui tient en mémoire. Initialement, on commence à construire la table de hachage sur la relation interne R, en cas ou la table ne tient pas en mémoire, on choisit une fonction de hachage f(x), qui partitionne la relation R en N paquets, tel que chaque paquet généré puisse tenir en mémoire (si b pages de mémoire sont disponibles, un paquet doit en occuper au plus b-2). Si plusieurs paquets peuvent tenir en mémoire, ils peuvent y coexister. Les autres sont écrits sur disque et chargés au besoin. Soit f la fonction de hachage servant à construire les paquets, et retournant des valeurs comprises entre 1 et n. On procède en examinant d'abord les tuples de la relation interne R. Seuls les tuples vérifiant f(a)=1 sont conservés, les autres sont stockés dans un fichier temporaire matérialisant la relation R. Les tuples vérifiant f(a)=1 sont insérés dans la table de hachage a l'aide d'une seconde fonction g différente de f. Les tuples de la relation externe S sont ensuite examinés. A nouveau, ceux ne vérifiant pas f(b)=1 sont stockés dans un fichier temporaire matérialisant la relation S et ceux vérifiant f(b)=1 sont comparés aux tuples de la table de hachage (suivant la fonction g). On recommence ensuite avec R' et S' et f(x)=2, et ainsi de suite jusqu'a f(x)=n. La figure27, illustre cette technique. Figure 27: jointure par hachage simple (version détaillée) L inconvénient de cet algorithme est le nombre élevé des entrées/sorties, quand la mémoire n est pas grande. Dans ce cas, beaucoup de paquets sont générés, et chaque tuple peut être lu et écrit plusieurs fois. Sous des conditions extrêmes, beaucoup d entrées/sorties sont produites, ce qui affecte considérablement les performances. Cependant, si la mémoire est suffisamment grande pour contenir la table de hachage, cet algorithme présente souvent des bonnes performances. 39

51 Chapitre 2: Mise en parallèle des opérateurs de base Jointure par hachage grâce : L algorithme de hachage grâce se compose de trois phases. Dans la première phase l algorithme partitionne R en N paquets, en appliquant une fonction de hachage sur l attribut de jointure pour chaque tuple de R. dans la deuxième phase la relation S est partitionnée en N paquets, en exploitant la même fonction de hachage. Dans la phase finale, l algorithme effectue la jointure entre chaque paquet de R et le paquet correspondant de S (les deux paquets ayants la même valeur de hachage). Le nombre de paquets N est choisi de façon à être très grand. Cela réduit la chance qu un paquet ne tienne pas en mémoire lors de l exécution de jointure entre deux paquets. Dans le cas où les paquets sont très petits par rapport à la mémoire principale, certains seront combinés durant la troisième phase pour former des paquets de taille optimale Jointure par hachage hybride : L algorithme de hachage hybride se compose aussi de trois phases. Dans la première phase, l algorithme utilise une fonction de hachage pour partitionner la relation interne R en N paquets. Les tuples de premier paquet sont utilisés pour construire la table de hachage, les N-1 paquets restants sont stockés dans un fichier temporaire. Une bonne fonction de hachage produit juste assez de paquets suffisamment petits pour tenir en mémoire. Durant la deuxième phase la relation externe S est partitionnée à l aide de la fonction de hachage de la phase une. Encore une fois, les N-1 paquets restants sont sauvegardés dans un fichier temporaire, et les tuples du premier paquet sont utilisés immédiatement pour sonder la table de hachage bâtie lors de la phase une. Pendant la troisième phase, l algorithme effectue la jointure de N-1 paquets de R avec les N-1 paquets respectifs de S. ainsi la jointure est subdivisée en série de petites jointures, qui s exécutent sans provoquer un débordement. Notons que la taille de la relation interne détermine le nombre de paquets, indépendamment de la taille de la relation externe. Le hachage hybride combine la phase de construction des paquets avec la phase de jointure. Ainsi dans la première phase, les relations sont partitionnées, et une portion de l opération de jointure est effectuée, contrairement au hachage grâce Jointure par hachage non bloquant (pipeline hash join) : Cet algorithme a été développé pour enlever l aspect bloquant caractérisant les algorithmes de jointure précédents, et améliorer le temps de réponse des requêtes multi jointures, qui utilise massivement le pipeline. Son principe est simple, il consiste à considérer les deux relations de façon symétrique comme relation interne et externe. Lorsqu'un tuple d'une des deux relations arrive, il est tout d'abord haché, comparé à la table de build de l'autre relation, puis placé dans la table de build de sa propre relation, quel que soit le résultat de comparaison. De cette façon, il n'est pas nécessaire d'attendre la fin de construction de la table de build, pour commencer à effectuer des comparaisons, et donc à potentiellement produire des tuples résultats. Un tel algorithme prend son intérêt dans les jointures entre tables intermédiaires, mais également lorsque les tuples de la relation de probe sont disponibles avant la fin de la relation de build. Le principal inconvénient de cette méthode réside dans son surcoût en stockage, car il implique la création de deux tables de build. Un handicap pouvant toutefois être partiellement compensé par quelques astuces de programmation (on peut, par exemple, cesser l'insertion des tuples dans les tables de build dès que l'une des deux tables est complètement bâtie). 40

52 Chapitre 2: Mise en parallèle des opérateurs de base La version parallèle de l algorithme de hachage : Pour paralléliser cet algorithme, on doit redistribuer la relation interne R sur l ensemble des sites effectuant la jointure, à l aide de la table de division (split table). Certes le débordement de la table de hachage peut se produire sur n importe quel site participant à la jointure, mais chaque site possède son propre fragment de la relation R, ainsi que sa propre fonction de hachage f, donc on peut mettre en œuvre la version centralisée sur chaque site. Ainsi, la version parallèle de l algorithme de hachage se déroule en deux phases, une phase de redistribution parallèle, ou chaque site scanne son propre fragment et redistribue les tuples, en appliquant une fonction de hachage sur l attribut de jointure. Le résultat de la fonction de hachage détermine le site cible. A la fin de cette phase, la version séquentielle de l algorithme de hachage sera lancée sur chaque site. Les résultats partiels seront transférés au site hôte, qui les consolide et renvoie le résultat final. Notons que n importe qu elle variante de l algorithme de hachage puisse être mise en œuvre pendant la jointure séquentielle: hachage simple, hachage grâce ou hachage hybride Conclusion : Dans ce chapitre, on a fait le tour sur les différentes implémentations parallèles des opérateurs de base. On a décrit l approche courante pour la recherche parallèle et les éventuelles optimisations. Les différentes variantes d algorithmes de tri parallèle ont été étalées. Le calcul d agrégation parallèle a été abordé de façon synthétique, en donnant les trois possibilités de sa parallélisation. En fin, on s est approfondi dans les nombreux algorithmes proposés pour le calcul parallèle de la jointure. Certes la possibilité de calcul parallèle au sein d un SGBD sont énorme. Néanmoins, le gain théorique de parallélisme reste largement loin de gain obtenu dans la pratique. De nombreux problèmes sont à résoudre, notamment le déséquilibrage de la charge de travail, qui réduit considérablement l efficacité de la majorité des algorithmes parallèles existants. 41

53 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Chapitre 3 : Paralle lisation des reque tes dans les bases de donne es re plique es 42

54 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées 3. Parallélisation des requêtes dans les bases de données répliquées : 3.1. Introduction : L une des techniques les plus employées, dans les systèmes volumineux, est la réplication. L objectif initial de la réplication est la haute disponibilité et la tolérance aux pannes. Cependant, l architecture des systèmes de réplication dissimule un grand potentiel de parallélisme. Ce chapitre met l accent sur quelques approches d introduction du parallélisme dans les bases de données répliquées Définition de réplication : La réplication [SIL 01] est une techniques implémentée par plusieurs systèmes de gestion de bases de données, afin d augmenter la disponibilité des données et d améliorer la fiabilité du système. Typiquement, la technique de réplication implique l utilisation d un SGBD distribué composé de plusieurs sites connectés par le bais d un réseau d interconnexion. Chaque site héberge une copie complète ou partielle de la collection de données globale. En outre, la réplication met en œuvre les mécanismes nécessaires pour garantir la cohérence des copies. Ainsi, Les modifications apportées à un site sont capturées et stockées localement, avant d être transmises et appliquées à chacun des sites participants à la réplication. La réplication est un mécanisme de choix pour offrir de la haute performance. Avec la vulgarisation d internet, de nombreuses applications sont utilisées à l échelle mondiale, avec éventuellement des millions d utilisateurs. Une telle application peut réduire le temps de réponse, en permettant un accès concurrentiel de ces utilisateurs. La réplication est une technologie spécifique des bases de données distribuées, dont l objectif est de partager les données parmi des sites multiples. Dans le même cadre, on identifie aussi la technique de fragmentation (appelé aussi partitionnement). Néanmoins, les bases de données répliquées et les bases de données fragmentées représentent deux notions distinctes. En fait, Dans une base de données fragmentée, les données sont disponibles dans plusieurs emplacements, mais une relation, voire un tuple, particulier est hébergé à un emplacement bien précis. Tandis que la réplication signifie que les mêmes données sont disponibles dans plusieurs sites Avantages de réplication : La réplication est largement exploitée en vue d améliorer les performances des applications complexes. Plusieurs avantages [CON 05] plaident pour son adoption : La disponibilité : En effet, la duplication des données augmente la disponibilité. Les utilisateurs et les applications ont une multitude de chemins d accès à une même donnée. Ainsi, si un site devient inaccessible pour une raison ou pour une autre. Le système peut continuer à répondre aux requêtes des usagers, en les redirigeant vers un autre site encore accessible, qui va prendre le relais. Notons que la redirection est transparente à l usager La fiabilité : Il est évident que copier une même donnée sur plusieurs emplacements distant, réduit considérablement la chance qu elle soit définitivement perdue. La défaillance d un site n implique pas l arrêt du système. Les utilisateurs connectés au site défaillant sont immédiatement servis par un 43

55 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées autre en marche, et les données stockées dessus sont facilement récupérables à partir d un autre emplacement du moment que les données sont dupliquées sur chaque site Les performances : Dans un système centralisé caractérisé par une forte charge de travail. La réplication constitue une alternative incontestable en vue d accélérer l exécution des requêtes utilisateurs. La réplication offre, en effet, un accès local, rapide à des données partagées, parce qu elle équilibre la répartition des activités sur plusieurs sites. Certains utilisateurs peuvent dès lors accéder à plus d un serveur, tandis que d autres utilisateurs accèdent à des serveurs différents, ce qui restitue des niveaux de performances acceptables sur tous les serveurs Vues de donnés selon utilisation : Il est devenu commun que une organisation déploie plusieurs applicatifs qui manipulent la même collection de données (souvent la même base de données). En plus de la haute disponibilité, la réplication permet de créer plusieurs copiés hébergées sur des sites distincts, ou chaque site sera complément dédié à répondre aux requêtes d un type d applicatif bien précis Une autonomie accrue: Dans une infrastructure de réplication réelle, les sites ne sont pas forcément liés par un réseau local. Rien n empêche d utiliser un réseau plus étendu comme intranet, VPN, ou même internet. Dans tel contexte, les ruptures de connexion sont plus que probables, et un système de réplication basique devient dramatiquement inefficace. Les techniques de réplication notamment celles asynchrones y remédient, en exploitant le concept de snapshot (copie instantané), implémenté par plusieurs SGBDs. Un instantané (snapshot) [RAM 99] est une copie complète ou partielle (c est-à-dire une réplique) d une relation cible, prise à un moment précis et unique. Les instantanés permettent à des utilisateurs de travailler sur des sous-ensembles d une base de données d entreprise, alors qu ils sont déconnectés du serveur de base de données central. Par la suite, dès que la connexion est rétablie, les utilisateurs synchronisent (rafraîchissent) leurs instantanés avec le contenu de la base de données centrale, si nécessaire. Ceci peut signifier que les instantanés reçoivent les mises à jour issues de la base de données centrale, mais aussi la base de données centrale reçoive des mises à jour en provenance des instantanés. Quelle que soit l action menée, les données de l instantané et de la base de données d entreprise retrouvent périodiquement leur cohérence Le soutien des applications évoluées : La vulgarisation de certains type d applications (décisionnel, Mobile, cloud computing) ouvrent de larges perspectives pour la réplication. L intégration des applications innovantes de l informatique mobile s est rendue plus aisé grâce à la réplication. Des périphériques nomades comme : le téléphone portable, pocket PC ou d autre peuvent travailler en mode déconnecté des jours et des jours, puis synchroniser avec la base de données centrale dès qu une connexion est disponible. Les besoins des entreprise sont en perpétuelle évolution, les bases de données de production installées pour le soutien des applications métiers, exploitées traditionnellement par des systèmes OLTP (online transaction processing), sont de plus en plus exposées aux systèmes d analyse décisionnelle OLAP (online analytical processing). En effet, l analyse OLAP génère une charge de traitement conséquente, qui pénalise éventuellement le système de gestion de base de données. Ainsi, on peut envisager l ajout de nouveaux serveurs dédiés à l analyse OLAP, qui maintiennent une réplique de la base de données initiale. 44

56 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Bien entendu un système de base de données répliquée, qui offre les avantages cités ci-dessus présente aussi une complexité majeure par rapport à une base de données centralisée. Ainsi, les performances de l ensemble risquent d être grevées par les transactions de mise à jour, car la moindre modification logique doit être appliquée à toutes les copies de la base de données, pour que celles-ci demeurent cohérentes. Les techniques de contrôle de concurrence et de récupération sont plus complexes et donc plus coûteuses par rapport aux mêmes opérations dans un système sans réplication Type de réplication : Garantir La cohérence des copies est un aspect inhérent à la technique de réplication. Idéalement, les modifications opérées sur chaque site sont instantanément propagées vers le reste des sites. Cependant, cela peut s avérer pénalisant. Selon la vitesse de rafraichissement des données, on identifie deux types de réplication : la réplication synchrone et la réplication asynchrone Réplication synchrone : Dans ce type de réplication [KEM 00], la mise à jour d une copie implique la propagation immédiate des modifications sur les copies distantes. Ce mécanisme est implémenté à l aide des transactions distribuées. En effet, Une transaction coordonne les mises à jour locales, et elle n est validée qu après la réception de la validation de chaque site. Avec ce type de réplication, la consistance des données, l isolation des transactions et la tolérance aux fautes sont naturellement garanties, sans aucun contrôle supplémentaire. Deux approches sont proposées en vue d assurer la réplication synchrone. La première approche appelé réplication par sélection «voting». Elle stipule qu une transaction doit mettre à jour la majorité des copies, et en lit suffisamment afin de s assurer que l une des copies et la plus récentes. Par exemple, si on a 8 copies, et 5 copies sont mises à jour par une transaction, alors 4 copies au minimum seront lues. Chaque copie est marquée par un numéro de version. La version la plus récente sera retenue. Cette approche est peu efficace, du moment qu une lecture exigent la lecture de plusieurs copies, cela est autant pénalisant, si on considère que l accès en consultation est souvent plus fréquent que l accès en mise à jour. La deuxième approche est «lire un, écrit tous» ( read any write all ). Pour lire une donnée, une transaction peut lire sur n'importe quelle copie, mais pour mettre à jour une donnée, elle doit mettre à jour toutes les copies. Ainsi, les lectures sont rapides, spécialement s il y a une copie locale. Cependant les mises à jour sont lourdes. Cette approche est habituellement adoptée pour réaliser la réplication synchrone, particulièrement dans les applications à forte caractère consultatif. La réplication synchrone n est implémentée que rarement dans les systèmes commerciaux. Les réticences des éditeurs des SGBDs s expliquent par plusieurs inconvénients. Les performances sont médiocres à causes des mises jour lourdes. La scalabilité est limité, car un nombre important de site alourdit d avantage les mises à jour. La tolérance aux pannes est réduite, une transaction risque de ne pas s achever complètement si un ou plusieurs sites, qui détiennent des répliques, sont inaccessibles. En outre, le réseau peut se transformer en goulot d étranglement, si le trafic généré pour coordonner la synchronisation, est dense. 45

57 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Réplication asynchrone : Afin d alléger les opérations de mise à jour de la réplication synchrone, de nombreux travaux ont été entamés, donnant issue à une nouvelle technique baptisée la réplication asynchrone [KEM 00]. Au lieu de propager les modifications immédiatement vers tous les sites, au sein de la même transaction, la réplication asynchrone permet de sauvegarder les modifications localement, puis de les diffuser vers le reste des sites suivant une politique définie. Avec cette technique, la vitesse de rafraichissement des données varie d un système à l autre. Le délai de rétablissement de la cohérence peut évoluer de quelques secondes à plusieurs heures, voire des jours. Quoi qu il en soit, les données se synchronisent en définitive à la même valeur dans tous les sites dupliqués. La réplication asynchrone est réalisée suivant deux approches : la première approche consiste à transférer les mises à jour vers un site maitre. Ainsi, un site esclave n exécute jamais les mises à jour, mais il les envoie au site maitre, qui met à jour les données, et diffuse un ordre de mise à jour asynchrone vers tous les sites esclaves. Cette approche garantit la serialisablilité des transactions, toutefois l architecture maitre/esclave réduit considérablement les performances et la tolérance aux pannes du système. La deuxième approche offre plus de souplesse lors des mises à jour. Chaque site effectue ces propres mises à jour et propage les modifications. Cette approche est plus attractive, cependant il est plus complexe à mettre en place. Bien que la réplication asynchrone transgresse le principe de la cohérence des données, elle constitue un compromis pragmatique entre l intégrité des données et leur disponibilité, parfois plus adapté aux besoins des organisations, puisqu elles peuvent travailler sur des répliques qui n ont pas nécessairement besoin d être toujours parfaitement synchronisées et actualisées. 46

58 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées 3.5. Approches de parallélisation : Introduction : Bien que l objectif principal de la réplication soit la haute disponibilité, la haute performance peut être réalisée en exploitant l architecture distribuée du système. Les requêtes des utilisateurs peuvent potentiellement s exécuter en parallèle, du fait que les données sont dupliquées sur plusieurs sites. Les travaux menés dans ce sens ont essayé de transposer les techniques de parallélisme, employées dans les bases de données fragmentées vers les bases de données répliquées. Le parallélisme interrequêtes est la première issue explorée. En effet, la réplication favorise naturellement ce type du parallélisme. Les requêtes des usagers sont lancées simultanément sur des sites distincts, aucune forme de communication n est requise, du moment où la totalité de la base de données est répliquée sur chaque site. Certes, le parallélisme inter-requête améliore le débit du système en servant plus de clients par unité de temps, mais le temps d exécution des requêtes individuelles reste intact, les systèmes recevant des requêtes complexes ne peuvent pas tirer profit de ce genre du parallélisme. Pour remédier à ça, le parallélisme intra-requête est introduit. Typiquement, le parallélisme interrequête est implémenté à l aide d une couche logicielle sous forme d un middleware, qui constitue le seul point d accès au système de réplication. Le middleware intercepte les requêtes soumises, et les transformes en un ensemble de sous-requêtes, qui seront exécutées parallèlement sur les différents sites, les résultats locaux seront consolidés pour former le résultat final Architecture logicielle : La Plupart des solutions de parallélisation combinées au système de réplication, sont conçus sous forme de composant logiciel externe (middleware) [PAE 08]. Ce dernier définit la politique de parallélisation (parallélisme inter-requêtes ou intra-requêtes), le degré de parallélisme (l identité et le nombre des nœuds impliqués), et contrôle l exécution parallèle (message de contrôle, gestion des erreurs, consolidation des résultats intermédiaires, ). Le middleware est la seule interface accessible aux utilisateurs. Il se charge de capturer, analyser, puis faire exécuter les requêtes soumises, sur l ensemble des sites. Notons que chaque site est doté d un SGBD séquentiel, qui peut être similaire ou différent d un site à l autre. 47

59 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Client Client Client Client Middleware Site(SGBD) Site(SGBD) Site(SGBD) Site(SGBD) Site(SGBD) BD répliquée BD répliquée BD répliquée BD répliquée BD répliquée Figure 28:architecture logicielle de système de parallélisation L architecture du middleware illustrée par la figure ci-dessus est constituée des entités suivantes : Le translateur SQL : il est le point d entrée du middleware, son rôle est l analyse syntaxique et sémantique des requêtes soumises. L analyse est sanctionnée par un plan d exécution contenant : les tables référencées, les attributs impliqués (les attributs résultants, les attributs de jointure, les attributs de sélection, les attributs d agrégation, ) et les types d opération (sélection, projection, jointure agrégation). Ce plan est déposé dans la file des requêtes prêtes. La file de requêtes : elle sert à stocker les requêtes prêtes à s exécuter. Le catalogue de données : en plus du schéma de base de données classique, il comprend une panoplie d informations, qui vont servir à déterminer la stratégie et les paramètres de parallélisation, entre outre : la cardinalité de chaque relation, les valeurs max et min pour chaque attribut, l historique d exécution, le nombre de requêtes en cours sur chaque site, etc. Le coordinateur : c est le cœur du middleware. Son rôle est de définir la stratégie de parallélisation et veiller sur le bon déroulement de l exécution. Le coordinateur sonde la file d attente des requêtes afin de récupérer la requête à lancer. Notons que les requêtes ne sont pas lancées selon leur ordre d arrivée (premier arrivée, premier servi). Le coordinateur choisit, selon l état actuel du système (les ressources allouées, le nombre de requêtes en cours, le nombre de sites surchargés, ) la requête adéquate. Le coordinateur consulte le catalogue de données et le plan d exécution associé à la requête. Une étape d analyse est effectuée en vue de déterminer le type de parallélisme. En cas de parallélisme inter-requêtes, il sollicite «le routeur de requêtes», qui va sélectionner le site exécuteur. Tandis que dans le cas de parallélisme intra-requêtes, il décompose la requête en sous-requêtes, ou chacune est traitée sur un site distinct, en agissant sur un fragment de données. Pendant l exécution, il continue 48

60 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées d intercepter les erreurs et éventuellement les solutionner. En fin d exécution, les sites lui renvoient les résultats intermédiaires, qui sont rassemblés et retournés au client. Le routeur de requêtes : ce composant n est pas présent sur tous les prototypes développés, certains l intègrent au coordinateur, toutefois sa complexité incite à le dégager comme un module indépendant. Son rôle est de choisir le site qui va traiter la requête, dans le contexte de parallélisme inter-requêtes. Pour ce faire, il collecte en permanence les indicateurs liés à la charge des sites : le nombre de requêtes en cours, l utilisation des processeurs, la consommation de la mémoire, etc. Translateur SQL Routeur de requêtes File de requêtes Catalogue de données Coordinateur Figure 29:architecture de middleware Le routage des requêtes et le parallélisme inter-requêtes: Aperçu sur le routage de requêtes : L implémentation de parallélisme inter-requêtes est réalisable sous l hypothèse que chaque nœud peut évaluer n importe qu elle requête indépendamment des autres nœuds, ceci contraint le système à adopter la technique de réplication, afin d assurer que chaque site dispose d une copie complète de la base de données. Décider sur quel nœud, la requête courante sera évaluée, est appelé le routage des requêtes. L objectif principal de routage est de réduire le temps de réponse et élever le débit en requêtes, à travers l équilibrage de la charge de travail entre l ensemble des sites. Le choix du site exécuteur est basé sur l état global du système, exprimé par un ensemble d indicateurs : la charge de chaque site, les pannes éventuelles, la configuration matérielle de chaque site, etc. Mais aussi par la requête à traiter et l historique des requêtes exécutées Objectifs de routage : Comme décrit dans [RAH 92], un schéma de routage doit répondre autant que possible à certaines exigences, qui déterminent sa qualité : 49

61 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Les performances : bien évidemment une stratégie de routage doit améliorer les performances globales du système, dans ces deux aspects : le temps d exécutions des requêtes et le débit transactionnel du système. Les ressources du système (les CPU, la mémoire, le disque de chaque nœud), doivent être consommées équitablement et efficacement pendant l exécution. La moyenne des transactions validées par unité de temps, et le temps de réponse maximal ([RAH 92]) sont les deux mesures les plus utilisées pour exprimer les performances d un schéma de routage. L efficacité : l efficacité d un schéma de routage se mesure par : le rapport entre le temps nécessaire pour la prise de décision de routage et le temps d exécution globale d une requête. Plus ce rapport est petit, plus le schéma est efficace. Autrement dit, le coût de routage doit être négligeable vis-à-vis au gain potentiel en performances. En effet, un compromis est fait entre l efficacité et les performances. Une stratégie de routage sophistiquée consomme plus de temps, avec un lourd impact sur les performances, tandis qu un schéma de routage simpliste est rapide, mais le gain escompté est relativement faible. Ainsi, selon les spécificités du système à traiter, on pourra privilégier un aspect par rapport à un autre. L adaptabilité : une bonne stratégie de routage est adaptative ou dynamique. Le rôle de l administrateur est réduit au maximum. Le mécanisme de routage capte en permanence les changements de configuration et les conditions d exécution (un nœud tombé en panne, ajout de nouveaux nœuds, la charge de chaque nœud, ), il les analyse, puis il réagit sous forme d actions correctionnelle, en cas de besoin. La stabilité : cette propriété caractérise la fiabilité du schéma de routage sous les conditions d exécution extrêmes (une montée en charge pointue et inhabituelle, panne de plusieurs nœuds, ), ou l aspect d adaptabilité ne sera guère suffisant pour rétablir la situation, et l intervention de l administrateur est incontournable. Sous ces hypothèses, le mécanisme de routage doit rendre au moins le niveau de performances minimal. En plus, ces situations doivent être détectées et signalées à l administrateur La classification des stratégies de routage : Les stratégies de routage sont classées suivant deux axes : La dépendance aux requêtes : ce critère distingue les stratégies de routage, selon si la décision de routage est dépendante/indépendante des requêtes traitées. De nombreuses approches de routage sont «requêtes-indépendantes». Autrement dit, la requête à évaluer ne peut pas affecter le routage. Dans ce cas, l état du système est le seul facteur, qui guide la stratégie de routage. La qualité d une telle stratégie est étroitement liée au degré de rafraichissement des informations caractérisant l état du système (la consommation CPU, IO et mémoire de chaque site, nombre de requêtes en cours, les pannes, ). Généralement, un mécanisme supplémentaire se charge de capturer ces informations et les rendre disponibles à l ensemble des nœuds. Pour ce faire, deux politiques sont adoptées [RAH 92]: une politique proactive, ou ces informations sont collectées périodiquement, son efficacité est liée à la période de rafraichissement, qui doit être judicieusement calculé afin de garantir des informations fraiches avec un coût raisonnable. La politique réactive s appuie sur les événements produits au niveau de chaque sites (lancement/fin d une requête, changement significative de la consommation CPU, IO ou mémoire, ). Suite à un événement, les changements sont notifiés, et l état du système est mise à jour. 50

62 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Cependant, les travaux menés par [ROM 02] et [SYU 86] ont prouvé que l analyse des requêtes génère des informations utiles (les tables référencées, les indexes impliqués, l exploitation du cache, mode d accès, ), qui peuvent potentiellement améliorer le routage. Ces travaux ont proposé des stratégies «requêtes-dépendantes» plus sophistiquées, s appuyant sur la requête en cours de traitement, pour déterminer le site approprié. Les prérequis : cette classification regroupe les stratégies de routage suivant leur flexibilité, c'est-àdire, est ce que la décision de routage est prise dynamiquement, ou basée sur des informations pré calculées. Certaines approches nécessitent des informations calculées préalablement, typiquement l historique d exécution des requêtes. Ces informations sont exploitées pour calculer la corrélation entre les requêtes, éventuellement celles affichant un coefficient de corrélation élevé seront routées vers la même destination. Le routage basé sur l affinité (affinity-based routing) [ROH 01] est un excellent exemple d algorithme à base de prérequis. En contrepartie, autres approches ne considèrent que les informations disponibles actuellement, avec probablement d avantage d informations issues de l analyse et de l estimation, sans avoir besoin des prérequis. Le routage basé sur le cache (cache approximation routing) fait partie de cette catégorie Stratégies de routage : La stratégie BQNR (Balancing-Query-Number Routing) [CAR 85]: c est un algorithme requêteindépendante. Son principe est d essayer d avoir le même nombre de requêtes actives par site. Le système recueille en permanence le nombre de requêtes en cours par site, et les stockent dans une table triée. La requête nouvellement arrivée est assignée au site ayant le minimum de requêtes actives (la première entrée de la table). Figure 30:algorithme BQNR [ROH 01] La stratégie BNQRD (Balance the Number of Queries by Resource Demands) [CAR 65] : c est une variante requête-dépendante. Les requêtes sont classées selon leur consommation du CPU et d entrées/sorties. Le nœud ayant le plus petit nombre de requête de même classe sera choisi. L idée derrière la classification est que malgré que plusieurs sites aient visiblement la même charge de travail. L accumulation de nombreuses requêtes à forte consommation I/O au niveau d un même site, transforme le disque en un goulot d étranglement. Ainsi une requête passe un temps considérable en l attente d une opération I/O, en aboutissant à une mauvaise utilisation CPU et visvers-sa, des requêtes à forte consommation CPU provoquent une surexploitation du CPU, par conséquent une sous-exploitation du disque. Les études effectuées par [CAR 88] affirment, que NBQRD offre une accélération de plus de 10% par rapport à BQNR. La stratégie LERT (Least Estimated Response Time): c est une variante requête-dépendante. Les demandes CPU et d entrées/sorties sont employées pour estimer le temps de réponse sur chaque 51

63 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées nœud. Le nœud ayant le plus petit temps estimé sera choisi. La qualité de routage repose sur la précision de la fonction d estimation. Cependant dans le cas général, ses performances sont similaires à celles de BNQRD. La stratégie ABR (Affinity-Based Routing) [ROH 01] : l idée derrière cette approche est d assigner les requêtes qui accèdent les mêmes données aux mêmes nœuds. Evidemment, c est une stratégie requête-dépendante. Les requêtes soumises sont réparties en plusieurs groupes d affinité, ces derniers sont calculés en analysant le schéma de base de données, et une trace d exécution de référence. Le schéma de routage assigne chaque groupe à une destination fixe. Les travaux de simulation ont montré que l apport de cette stratégie réside dans la diminution des entrées/sorties grâce à l exploitation du cache d entrée/sortie. La stratégie ABR s appuie sur les données accédées pour calculer l affinité entre deux requêtes. Néanmoins, le type d accès n est pas pris en considération (séquentiel ou aléatoire). Cela risque de fausser la valeur d affinité, car deux requêtes qui accèdent à des portions différentes de la même relation, seront placées dans le même groupe d affinité, malgré qu elles manipulent des données différentes. Un autre inconvénient est que les groupes d affinité sont pré-calculés, ce qui rend la stratégie non adaptative. La stratégie CAQR (Cache Approximation Query Routing) [ROM 02] : un simple constat peut confirmer que la plupart du temps d exécution d une requête est consommé par les opérations d entrée/sortie, cela est d autant vrai que le volume de données manipulé est conséquent. Les algorithmes de routage précédents ignorent l apport occasionné par le cache. En revanche, la CAQR estime l impact de l état du cache sur l évaluation de la requête, et l utilise pour le routage. L idée est que le temps d exécution d une requête est minimal, dans le nœud dont le cache contient la majeure partie de données accédée par la requête. En vue de prédire le contenu des caches associés aux nœuds, le système sauvegarde la trace des requêtes exécutées sur chaque nœud, ainsi que les relations référencées. Cela est réalisé par l analyse de la clause «FROM». L état du cache est estimé en se basant sur les n dernières requêtes évaluées sur le nœud. Le gain apporté par le cache d un nœud à l exécution de la requête actuelle, est mesuré par l intersection entre le contenu du cache et les relations accédés Partitionnement virtuel et le parallélisme intra-opérateur: Pourquoi le parallélisme intra-opérateur? Certes Le parallélisme inter-requêtes améliore le rendement global du système, par augmenter le débit en transactions et hausser la qualité de service (plus de disponibilité, plus de tolérance aux pannes). Néanmoins, dans un système caractérisé par une grande complexité de traitement, les requêtes soumises peuvent être très lourdes à exécuter. Le parallélisme inter-requêtes ne peut en aucun cas apporter un gain en performances, vu que la requête est confiée à un seul site, qui va l évaluer évidemment en séquentiel. Le parallélisme intra-requête, et plus particulièrement intra-opérateur était la seule alternative susceptible de répondre à ce besoin. Comme on a détaillé précédemment, le parallélisme intraopérateur s appuie sur le partitionnement des données. Dans le contexte des bases de données répliquées, cela contredit le principe de réplication basé sur la duplication. Cette contrainte est contournée par la technique de partitionnement virtuel. Communément, le partitionnement virtuel 52

64 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées passe par la réécriture de la requête à traiter en plusieurs sous-requêtes, ou chacune porte sur un fragment distinct de données. Une sous-requête est obtenue par l ajout d un prédicat d intervalle sur l attribut de partitionnement à la clause «WHERE». L élément clé de cette technique est le calcul des intervalles. En effet, ils doivent être choisis de façon à produire des fragments de même taille. Sous l hypothèse de l uniformité des données, le calcul est intuitif, l exemple suivant exhibe une requête de jointure entre deux tables «client» et «facture» de tailles respectives 150,000 et 1, 000,000. Une exécution parallèle sur deux nœuds va donner suite à deux sous-requêtes illustrées par la figure ci-dessous. Cependant, la distribution uniforme des données n est garantie que rarement. Le partitionnement simple va aboutir inéluctablement à des fragments fortement déséquilibrés (problème de Data Skew). Afin de réduire l impact de la non uniformité des données, des techniques de partitionnement plus sophistiquées ont vu le jour, dont certaines sont détaillées dans ce qui suit. SELECT CodeClient, NomClient, CodeFacture, DateFacture, MontantFacture FROM Client, Facture WHERE Client.CodeClient = Facture.CodeClient SELECT CodeClient, NomClient, CodeFacture, MontantFacture FROM Client, Facture WHERE Client.CodeClient = Facture CodeClient AND (Client.CodeClient BETWEEN 1 AND 75000) AND (Facture.CodeClient BETWEEN 1 AND 75000) SELECT CodeClient, NomClient, CodeFacture, MontantFacture FROM Client, Facture WHERE Client.CodeClient = Facture CodeClient AND (Client.CodeClient BETWEEN AND ) AND (Facture.CodeClient BETWEEN AND ) Figure 31:parallélisme intra-requête dans les bases de données répliquées Définition de partitionnement virtuel : Supposons une opération de sélection algébrique σ avec un prédicat P appliqué sur la table R. on définit une partition virtuelle α sur R par RPV= σp(r), avec P est un prédicat de la forme : A appartient à [a1,a2), ou A est un attribut de R, et a1,a2 deux valeurs de domaine de A, sous la contrainte a1<a2 [CAM 05]. Pour mettre en place le parallélisme intra-requête avec le partitionnement virtuel, on peut procéder de la manière suivante : communément une requête Q fait appel à plusieurs tables, la technique préconise d appliquer le partitionnement virtuel sur la table la plus volumineuse (soit R), le reste des tables (soit S) ne sera pas concerné. Avec un cluster composé de n sites, on doit construire n prédicats (P1, P2, P3,, Pn) afin de produire les n partitions virtuelles associées (RVP1, RVP2, RVP3,, RVPn). La requête de base Q(R,S) est transformée en n sous-requêtes { Q1(RVP1,S), Q2(RVP2,S),, Qn(RVPn,S)} 53

65 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées de la forme Qi(RVPi,S), ou chacune est lancée sur un site distinct, en agissant sur une seule partition virtuelle. L ensemble des sous-requêtes est équivalent à la requête d origine sous les conditions suivantes [OZS 99] : Les partitions virtuelles doivent être deux à deux disjoint, ceci se traduit mathématiquement par: i, j (i j, 1 i, j n), RVPi RVPj = ). L union des toutes les partitions doit produire la relation de base R. la formulation mathématique donne : r R, RVPi, 1 i n, ou r RVPi, sachant que r est un tuple quelconque de R. Exécuter en parallèle la requête Q ne se résume pas à lancer les sous-requêtes sur les différents sites. En effet, la génération du résultat final RES(Q) requiert une phase supplémentaire, ou les n résultats intermédiaires {RES(Q1), RES(Q2),, RES(Qn) } sont composés à l aide d une opération spécifique Ω, autrement dit, RES(Q)=Ω(RES(Qi)), i=1,,n. l opération Ω n est déterminée que par la requête à traiter Q, et elle peut varier d une simple d opération d union ( ), jusqu à un traitement extrêmement complexe(par exemple une requête avec agrégations nécessite éventuellement d agréger les résultats intermédiaires). A l encontre du partitionnement physique qui s appuie sur la distribution physique des données, le partitionnement virtuel opère sur la requête en cours, au moyennant d une suite de transformations algébriques. Le partitionnement virtuel offre un degré de flexibilité plus élevé, du moment où, une ou plusieurs relations sont partitionnées selon différentes schémas, sans aucun incidence sur le placement physique des données, chose qui est loin d être réalisable avec le partitionnement physique, ou le moindre changement mène potentiellement à une réorganisation des données sur l ensemble des sites. Bien que, le partitionnement virtuel est employé souvent pour faire de la fragmentation horizontale, d ailleurs ce que laisse entendre la définition. Cependant, conceptuellement rien n empêche de construire des fragments verticaux, ou même hybride avec le partitionnement virtuel [LIM 09]. Il suffit de remplacer l opération de sélection par l opération appropriée, soit une projection en cas de fragmentation vertical, ou une sélection suivie d une projection en cas d un schéma hybride. Notons que dans le cadre de ce travail, seule la fragmentation horizontale est prise en charge Récriture des requêtes : Le partitionnement virtuel s articule sur la transformation des requêtes, ou autrement dit la réécriture des requêtes. Le challenge est de produire des sous-requêtes, dont le temps d exécution est approximativement égal. Superficiellement, l opération s avère triviale, si on se reporte à au langage SQL, il suffit d ajouter des prédicats d intervalles (de la forme A BETWEEN V1 AND V2) à la clause WHERE de la requête, pour construire les sous-requêtes. Toutefois, une analyse plus profonde soulève plusieurs problèmes, qui conditionnent les performances de la technique. Le premier est le calcul des intervalles. Ceci est d autant plus difficile dans les cas suivants : Les valeurs de l attribut de partitionnement ne sont pas distribuées uniformément sur l intervalle principal [MIN, MAX]. La requête de base comporte des prédicats, qui portent sur l attribut de partitionnement A (de la forme : A> val, A< val, ). Ceci rend le partitionnement plus délicat, et même, met en question l utilisation du parallélisme intra-requête. En effet, de tels prédicats sont restrictifs, 54

66 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées et peuvent réduire considérablement la quantité de données manipulée, de ce fait, le temps d exécution sera relativement court, et l application du parallélisme pourra devenir néfaste dans ce cas. Même en cas de distribution uniforme, le calcul d intervalles reste difficile. La présence de prédicats supplémentaires complique l obtention de fragments virtuels équilibrés [LIM 05]. Considérant la requête suivante : SELECT Client.Nom, SUM(Facture.Montant) FROM Client,Facture, Pays WHERE Client.IdClient=Facture. IdClient AND Client.IdPays=Pays.IdPays AND Pays.Nom= ALGERIE GROUP BY Client.IdClient Typiquement, le partitionnement virtuel s appliquera sur la table Facture, avec comme attribut de partitionnement IdFacture. En supposant une forte corrélation entre le Pays.IdPays et Facture.IdFacture (ex : les ID des factures provenant d Algérie appartiennent à un intervalle particulier), le partitionnement sera de mauvaise qualité. Pour certaines requête, le processus de réécriture peut aller au-delà d associer des prédicats d intervalles. En vue de conserver la sémantique de la requête d origine, quelques opérations sont remplacées par leurs équivalents dans le contexte, notamment les fonctions d agrégations. Le tableau ci-dessous récapitule les équivalences : Fonction dans la requête d origine Fonction dans les sous-requêtes MAX(a) MAX(a) MIN(a) MIN(a) SUM(a) SUM(a) COUNT(a) COUNT(a) AVG(a) SUM(a), COUNT(a) VAR(a) SUM(a2), SUM(a), COUNT(a) Tableau 1:transformation des fonctions d'agrégation en cas de parallélisme Partitionnement virtuel simple SVP (Simple Virtual Partitioning): La technique SVP est reconnue comme la plus simple et la plus intuitive. Le calcul des intervalles repose simplement sur le nombre de nœuds et les valeurs minimale et maximale de l attribut de partitionnement. L intervalle du iième nœud est donné par la formule suivante : ()=[ +, ( + 1) + ] L avantage principal du SVP est sa simplicité. Toutefois, son efficacité dépend de plusieurs facteurs, le premier et la distribution uniforme des données, car en l absence de cette caractéristique, les tailles des partitions seront significativement différentes. Outre, SVP est de nature statique, les intervalles sont calculés en amont de l exécution. Une telle propriété empêche le système d effectuer l équilibrage de la charge dynamiquement, en agissant sur les intervalles pendant l exécution. En plus, SVP requiert l existence d un indexe cluster sur l attribut de partitionnement. Ajouter de condition d intervalle ne garantit pas, que le site lit uniquement la portion de la table, qui 55

67 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées correspondants à son fragment virtuel, à partir du disque. Souvent, l entièreté de la table est scannée, en aboutissant à une détérioration des performances à causes du coût excessif des I/O. un indexe cluster permet d éviter un scan de la table, en effectuant un accès aléatoire à base d indexe. Cependant, l existence d un indexe est une condition nécessaire mais pas suffisante pour éviter de scanner la table. L optimisateur du SGBD peut choisir de ne pas s en servir, s il estime que le nombre de tuples accédés dépasse un certain seuil, ce qui efface l apport de SVP Partitionnement virtuel adaptatif AVP (Adaptive Virtual Partitioning): Avec la technique SVP, on se limite d assigner une seule sous-requête par nœud. Sous cette contrainte, le rééquilibrage de la charge pendant l exécution est impossible. Le partitionnement virtuel adaptatif propose de générer plus de sous-requêtes que le nombre de nœud. Ainsi, un nœud peut potentiellement évaluer plus d une seule sous-requête. Site1 Q11 Q12 Q13 SGBD BD répliquée Siten Qn1 Qn2 Qn3 SGBD BD répliquée Q Solution Middleware La version standard de cet algorithme agit en deux phases. Au départ, la requête est divisée en sousrequêtes en employant le partitionnement virtuel simple (SVP). Quand un nœud reçoit la sousrequête qui lui a été assignée, il ne la soumet pas directement au SGBD, mais il la subdivise en mini sous-requêtes, qui seront exécutées localement, ou transférées aux sites moins chargés. Figure 32: partitionnement virtuel adaptative Avec les variantes les plus simples du AVP [LIM 04], chaque site génère plusieurs sous-requêtes, qui manipulent des partitions virtuelles de même taille. Tous les intervalles ont une taille fixe, qui constitue un paramètre de la technique. Cette variante s est avérée performante, à condition que la taille des intervalles soit bien ajustée. La taille optimale diffère d une requête à l autre, et son calcul passe inévitablement par une étude empirique, basée sur un ensemble de tests effectués manuellement. Utiliser des petites tailles semble un bon compromis, mais il peut mener à l exécution 56

68 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées d un nombre élevé de sous-requêtes. Une telle situation est caractérisée par des faibles performances, à cause de la phase d initialisation, et la lecture répétitive des tables, non concernées par le partitionnement. Cependant, la technique AVP tend à adapter la taille des partitions virtuelles dynamiquement et automatiquement, quel que soit la requête à traiter, et en prenant en compte la charge courante du site exécuteur. Dans ce contexte, chaque site détermine localement la taille optimale, en fonction de la requête en cours et de la charge actuelle. Le processus du calcul n est pas déterministe, il commence par une petite taille, et la fait évoluer, jusqu à converger vers la taille optimale. Ceci sousentend que les tailles diffèrent d un site à l autre, et d une requête à une autre. L algorithme comme décrit par [LIM 05], entame l exécution avec un intervalle de petite taille. Cela permet de s assurer que le SGBD accède la table de partitionnement en exploitant l index cluster, et du coup, éviter un scan précoce. La première sous-requête est soumise au SGBD, et son temps d exécution est sauvegardé. Pendant les prochaines itérations, l algorithme augmente la taille de la partition par un facteur (Facteur_aug_part), qui constitue un paramètre d entrée, et capture le temps d exécution correspondant. Si l augmentation en temps d exécution est proportionnellement inférieure à l augmentation en taille de partition, faire une nouvelle itération, sinon la stabilité est atteinte, et la taille optimale est trouvée. Notons que la taille ne doit en aucun cas dépasser le seuil, à partir duquel le SGBD ignore l index, et effectue un scan de la table. Après la stabilité, l algorithme AVP continue de collecter les temps d exécution et les analyser, en vue de s adapter aux événements produits en cours de route. Si plusieurs exécutions de mauvaise qualité se succèdent (dont les temps d exécutions sont relativement plus longs), l algorithme détecte une détérioration des performances. Dans ce cas, il diminue la taille de partition, et relance de nouveau la procédure de calcul de la taille optimale, en employant un facteur «Facteur_aug_part» moins élevé, afin d affiner la recherche, et explorer des tailles différentes de celles des précédents calculs. Plusieurs causes sont derrière ce comportement : les défauts du cache (le SGBD garde les données les plus requêtées en cache. Lors d une lecture, si les données sont mises en cache, la demande est satisfaite sans aucune I/O, sinon un défaut du cache est signalé, le SGBD lit les données à partir du disque, et met à jour le cache), le data skew (une distribution non-uniforme des données, fait que des intervalles de même taille produisent des partitions virtuelles sensiblement différentes), une augmentation inhabituelle de la charge de site. 57

69 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées AVP( Intervalle_AVP : in ) Intervalle_AVP /*intervalle assigné au site*/ Variables locales: partsize, newsize /* intervalle utilisé pour l exécution de la prochaine sous-requête */ sizeincrfactor /* facteur d augmentation de la taille de partition */ detexeccounter /*nombre d exécution de mauvaise qualité*/ deter /* une variable booléenne pour signalé une détérioration des performances */ begin partsize initial partition size; sizeincrfactor initial size increase factor; while(vpinterval not processed) { execute subquery with partsize keeping execution time; newsize partsize * (1.0 + sizeincrfactor); execute subquery with newsize keeping execution time; if (increase on exec time <= tolerated increase) then { partsize newsize; /*continuer d augmenter la taille*/ } else /*la taille optimale est trouvée*/ { deter FALSE; detexeccounter 0; while((vpinterval not processed) and (not deter)) { execute subquery with partsize keeping exec time; if( increase on exec time > tolerated ) then { detexeccount detexeccounter + 1; if(detexeccount > limit for bad execs ) then { deter TRUE; /*confirmer la détérioration*/ decrease partsize; sizeincrfactor factor for new size searching; } } Else { detexeccounter 0; } } } } end; Figure 33:Algorithme AVP [CAM 05] L algorithme AVP, tel qu il est décrit ci-dessus, fait intervenir plusieurs paramètres (taille de la partition initiale, facteur d augmentation, nombre de mauvaise exécution, ), et il est évident que son efficacité dépend fortement des valeurs initiales qui y sont assignées. Obtenir des meilleures performances signifie de trouver la combinaison optimale des valeurs initiales pour l ensemble des paramètres. Une telle combinaison est déterminée automatiquement grâce à un mécanisme de feedback, ou récoltée suite à des études expérimentales, comme celle effectuée par [LIM 09]. 58

70 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Paramètre valeur Taille de partition initiale 2024 Facteur d augmentation (sizeincrfactor) 100% Augmentation permise en temps d exécution pendant la recherche de la taille optimale 25% * sizeincrfactor Augmentation permise en temps d exécution après stabilité 10% Nombre de mauvaises exécutions consécutives 3 Facteur de réduction appliqué sur la taille de la partition, suite à une détérioration de performances 5% Facteur d augmentation après détérioration de performances 20% Tableau 2:paramètre AVP [LIM 09] A l encontre du SVP, ou chaque site se contente de soumettre la sous-requête à l instance local de SGBD et attendre le résultat, la technique AVP laisse les sites exécuter progressivement la sousrequête sur leurs partitions virtuelles. En analysant l algorithme, on s aperçoit que rien ne contraint un site à exécuter la sous-requête sur la totalité de sa partition. Cela suggère d ajuster, au fur et à mesure de l exécution, les tailles des partitions virtuelles, en vue de partager équitablement la charge de travail globale. En effet, AVP tire parti de ce constat, et permet de rééquilibrer la charge de travail dynamiquement, grâce à la redistribution des intervalles. Ainsi, un site qui termine l évaluation de la sous-requête correspondante peut se voir assigner une partie d une partition virtuelle, qui a été attribué initialement à un autre site. L AVP présente de multiples avantages. Le premier est son caractère ultra-dynamique, ou elle s adapte non seulement à la requête à traiter, mais aussi aux changements occasionnels de la charge du système. Les intervalles étroits évitent que le SGBD opte pour un scan de la table en la présence d un indexe sur l attribut de partitionnement. En plus, la manipulation des petits volumes de données offre la possibilité d utiliser certaines variantes d algorithmes caractérisées par une forte consommation de la mémoire, par exemple l opération de jointure sera exécutée à l aide de l algorithme de hachage plus efficacement, de fait que la totalité de la table de hachage tient en mémoire. Cependant la mise en œuvre effective de la technique AVP n est pas évidente. La génération d un nombre élevé de sous-requête peut dégrader au lieu d améliorer les performances. Par conséquent, le nombre de sous-requête doit être choisi judicieusement en se basant sur les caractéristiques de la base de données, le nombre de nœuds et la charge actuelle du système. En outre, la redistribution dynamique des sous-requêtes rend l architecture du système plus complexe. Chaque nœud communique périodiquement le coordinateur a fin de publier son état, se renseigner sur l état du système et éventuellement transférer des sous-requêtes à évaluer par les nœuds les moins chargés Composition de résultat final : Dans un environnement de bases de données distribuées, et particulièrement sur une architecture shared-nothing, la procédure de traitement d une requête s étend pour inclure la phase de fusion des résultats intermédiaires, issus des exécutions locales. Cette phase est spécifique au cas distribué, ou elle intervient en fin de processus et permet de composer le résultat final, qui sera restitué au client. La complexité de la phase de fusion dépend uniquement de la requête à traiter. Dans sa forme 59

71 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées la plus simple, elle se résume en la concaténation des résultats des différents sites sans aucun traitement supplémentaire. Cependant, elle peut être composée de plusieurs opérations extrêmement complexes, qui font appel à des mécanismes externes implémentés par le middleware. Le type d opérations effectuées par les requêtes détermine les actions à entreprendre pendant la fusion. Selon leur impact sur la phase de fusion, on classe les requêtes ainsi : Les requêtes avec fonctions d agrégation : la présence des fonctions d agrégation implique d abord un traitement particulier lors de la réécriture comme indique le tableau1. Ce type de requête a la spécificité de retourner un résultat composé d un seul tuple. Ainsi, l exécution d une sous-requête sur un site est sanctionnée par un tuple, qui sera renvoyé au site coordinateur. Ce dernier consolide les tuples produits au niveau d une table temporaire, sur laquelle il relance la requête d origine, en substituant les fonctions d agrégation par leurs fonctions équivalentes dans un environnement distribué. Le tableau ci-dessous établit les équivalences. Fonction dans la requête d origine Fonction équivalente lors de la fusion MAX(a) MAX ({MAX(a)PV1, MAX(a)PV1,, MAX(a)PVn}) SUM(a) SUM ({SUM(a)PV1, SUM(a)PV1,, SUM(a)PVn}) MIN(a) COUNT(a) AVG(a) VAR(a) MIN ({MIN(a)PV1, MIN(a)PV1,, MIN(a)PVn}) SUM ({COUNT(a)PV1, COUNT(a)PV1,, COUNT (a)pvn}) SUM{SUM(a)PV1, SUM(a)PV1,, SUM (a)pvn} SUM({COUNT(a)PV1, COUNT(a)PV1,, COUNT (a)pvn}) [SUM ({SUM(a2)PV1, SUM(a2)PV1,, SUM(a2)PVn})- [SUM ({COUNT(a)PV1, COUNT(a)PV1,, COUNT (a)pvn})]2] / SUM ({COUNT(a)PV1, COUNT(a)PV1,, COUNT (a)pvn}) Tableau 3:phase de fusion avec les fonctions d'agéragtions Les requêtes avec la clause «GOUP BY» : souvent, les fonctions d agrégations sont utilisées en conjonction avec la clause «GOUP BY». En effet, au lieu d appliquer une fonction sur tous les tuples retournés par une requête, «GOUP BY» sert à repartir le résultat en groupe (les groupes sont construits suivant les attributs associés à la clause), puis appeler la fonction sur chaque groupe. La procédure de composition de résultat final est similaire à la classe précédente. Toutefois, l exécution d une sous-requête produits une collection de tuples, éventuellement volumineuse. Le coordinateur doit pouvoir stocker les résultats partiaux (dans une table temporaire), en suite choisir une stratégie d exécution de l agrégation final. Si l ensemble des résultats partiaux est relativement petit, on se contente de relancer la requête d origine sur la table temporaire, sinon on peut opter pour un partitionnement par intervalles sur l attribut d agrégation, exécuter la requête de base sur chaque site, et enfin la simple concaténation des résultats locaux suffit pour construire le résultat final. Les requêtes avec «ORDER BY» : l opération de tri est généralement coûteuse, d autant plus dans un environnement distribué. Si la requête de base comporte la clause «ORDER BY», l exécution des sous-requêtes correspondantes au niveau des sites, produit des résultats partiaux triés. Le site coordinateur stocke les résultats partiaux triés, et procède à une fusion finale. 60

72 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Les autres requêtes : si la requête à traiter n appartient à aucune des classes ci-évoqués, la composition du résultat final est intuitive. Nul besoin d effectuer des traitements externes, il suffit de concaténer les résultats partiaux afin de construire le résultat final De la haute performance avec le partitionnement virtuel : Le partitionnement virtuel semble une approche attractive pour la mise en œuvre de parallélisme pour les bases de données répliquées sur un cluster de PC. Toutefois, le partitionnement virtuel ne garantit pas une amélioration significative des performances lors de l évaluation des requêtes. Quelques conditions doivent être réunies pour que le partitionnement virtuel atteigne le niveau de performance souhaité : Comme le partitionnement physique, le partitionnement virtuel essaye d exploiter toute la bande passante I/O du cluster, par la lecture simultanée sur tous les disques. Avec la réplication, et sur une architecture middleware, une gestion optimale des I/O n est pas intuitive. En effet, on doit garantir que chaque site ne lit, à partir du disque, que les tuples appartenant à sa partition virtuelle. Autrement, la totalité de la table sera scannée. Le surcoût occasionné par des I/O inutiles, mène à une dégradation saillante des performances. L ajout de prédicat d intervalle ne garantit pas une telle condition. Physiquement, les tuples formants une partition virtuelle peuvent être dispersés sur plusieurs pages, voire toutes les pages disque allouées à la table de partitionnement. Dans une telle situation, le site en question est contraint de scanner la table. Pour pallier à ce problème, la table de partitionnement doit être triée physiquement sur l attribut de partitionnement. Cela est réalisé via la construction d indexe cluster sur l attribut de partitionnement. Ce genre d indexe force l organisation physique des tuples. Ainsi, on pourra exploiter l index cluster pour pointer sur le premier tuple, et continuer de lire séquentiellement, du moment où, les tuples constituants la partition virtuelles se trouves sur des pages contiguës du disque. La présence d un indexe cluster sur l attribut de partitionnement ne garantit pas, que les instances de SGBD lancées sur chaque site, vont l exploiter pour l évaluation des sous-requêtes associées. Avant de lancer l exécution réelle d une requête, l optimiseur du SGBD calcule le plan d exécution physique. La méthode d accès (séquentielle ou aléatoire) pour une relation est déterminée, suivant la portion qui doit être trouvée lors de l évaluation de la requête. L optimiseur peut choisir un accès séquentiel, malgré l existence d un indexe, si la portion dépasse un certain seuil (qui varie d un SGBD à l autre). Ainsi, un partitionnement virtuel de qualité doit produire des partitions virtuelles, dont la taille n excède pas le seuil défini par le SGBD Combiner le parallélisme inter-requêtes et le parallélisme intra-requête : A travers ce chapitre, on a mis l accent sur deux types de parallélisme : le parallélisme inter-requêtes, et le parallélisme intra-requête. Le parallélisme inter-requêtes est plus opportun aux systèmes recevant un flux de requêtes, ayants un temps d exécution relativement court. Le débit transactionnel est grandement amélioré, grâce à l exécution simultanée de plusieurs requêtes sur des sites distincts. Certaines systèmes (exemple : analyse décisionnelle OLAP) sont souvent appelées à exécuter des traitements complexes, en manipulant des volumes de données gigantesques. Les requêtes soumises sont très lourdes, à point qu une exécution séquentielle prendra quelques heures, voire quelques jours. Le parallélisme intra-requête apporte une solution à ce problème, du moment qu il permet d accélérer l exécution des requêtes individuelles, en les lançant sur plusieurs sites. 61

73 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées Une solution de parallélisation qui implémente un des deux types de parallélisme ne peut pas être performante à tous les coups. Naturellement, un système tend à répondre à toutes les requêtes, le plus efficacement possible. Dans un système qui met en place uniquement le parallélisme interrequêtes, l exécution des requêtes lourdes aboutit à des performances médiocres. Tandis que, pour un système, qui s appuie exclusivement sur le parallélisme intra-requête en vue d offrir du parallélisme, même les requêtes courtes seront lancées sur plusieurs sites, chose qui va probablement augmenter le temps d exécution, car les temps d initialisation, de traitement et de consolidation du résultat final vont l emporter sur le temps d exécution effectif. En outre, pendant le début de vie du système, la quantité de données manipulée est généralement réduite. Ainsi, même les requêtes complexes peuvent être satisfaites séquentiellement en un temps raisonnables. Idéalement, un système doit marier les deux types de parallélisme, chacun des deux aboutit à des performances optimales sous des conditions spécifiques. Le système analyse chaque requête, estime son coût, et décide quel type de parallélisme est plus adéquat à son évaluation. Néanmoins, cela soulève de nouvelles questions : comment calculer le coût, et sur quelle base, le type de parallélisme est choisi. Une première réponse consiste à s appuyer sur l optimisateur du SGBD, qui donne dans la plupart des cas des estimations de bonnes qualités. Cependant, il ne faut, en aucun cas, négliger l état du cluster, et la charge globale du système Partitionnement VS réplication : Le partitionnement des données est la technique la plus populaire dans le cadre des bases de données parallèles. En l absence de déséquilibre de données, les partitions sont quasiment de même taille. Tous les algorithmes parallèles sont appliqués avec des performances presque idéales. En plus, le système offre une bonne scalabilité, de nouveaux sites peuvent être ajoutés sans affecter le speedup. Cependant, en cas de jointure, si l attribut de jointure est différent de celui du partitionnement, la redistribution doit avoir lieu, provocant le transfert d une grande quantité de données sur le réseau d interconnexion. La tolérance aux pannes est une des faiblesses du partitionnement. En effet, la défaillance d un site signifie la perte temporaire, voir définitive des données stockées là-dessus. Bien que la réplication fournisse de la haute disponibilité, la tolérance aux pannes est meilleure que le partitionnement, la panne d un site n a aucune incidence sur le système. L exécution des requêtes ne requiert guère la redistribution des données. La haute performance est introduite grâce notamment au parallélisme inter-requêtes. Plusieurs requêtes sont traitées en parallèle sur des sites distincts, sans aucune forme d interférence. L inconvénient majeur de la réplication est le manque de scalabilité, qui s affaiblit progressivement avec l augmentation du volume de données. Le coût des mises à jour est nettement plus élevé que le partitionnement, vu qu elles sont propagées sur tous les sites. La présence des copiés multiples soulève le problème de cohérence et consistance des données, qui est généralement lourd à gérer Parallélisation avec la Réplication partielle : Offrir de la haute performance par le biais de la réplication constitue incontestablement une solution de bonne qualité. En plus de la tolérance aux pannes et la disponibilité élevée, qui sont des caractéristiques intrinsèques de la réplication, l équilibrage de la charge de travail est réalisé d une manière simple et efficace à l aide de la redistribution des requêtes. Cependant, la réplication n est pas la solution idéale. Avec des grandes bases de données, la capacité de stockage doit être énorme 62

74 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées au niveau de chaque site. Certes, le coût des unités de stockage est en nette régression, mais leur coût sur tout le cluster pourra être très élevé. En outre, garantir la cohérence des différentes copies de la base de données devient de plus en plus complexe avec l ajout des sites et l accroissement de la taille des données, ce qui réduit considérablement la scalabilité des solutions basées sur la réplication. Combiner le partitionnement et la réplication au sein d un même schéma semble un bon compromis pour tirer profit des deux techniques. Cette idée est à la base de la technique de réplication partielle (en anglais Hybrid Design HD) [ROH 01]. La réplication partielle consiste à partitionner les tables les plus volumineuses, et répliquer les tables les plus petites. Un tel schéma ménage le support de stockage et présente presque les mêmes avantages qu un schéma de réplication usuel. En effet, avec la réplication partielle, on sacrifie une part de la disponibilité, car si un site tombe en panne, sa partition est définitivement inaccessible. L équilibrage de la charge de travail n est plus réalisable, du moment que la distribution des sous-requête n est pas possible. En plus, l évaluation de certaines requêtes peut requérir un transfert de données entre les sites. Une variante plus sophistiquée [CAM 05] préconise de dupliquer les partitions sur plusieurs sites. Cela améliore la disponibilité et permet d appliquer la technique AVP (AVP combiné avec HD a donné suite à AHP : Adaptive Hybrid Partitioning [LIM 10]) en vue de distribuer équitablement la charge de travail globale. À l encontre d AVP avec réplication, ou un site peut assigner une partie de sa charge à n importe quel site libre (en partant du principe que chaque site peut évaluer n importe quelle requête). Sous AHP, un site ne peut solliciter qu un site libre qui détient une copie de sa partition. Les performances d AHP dépendent de la stratégie de placement des réplicas des partitions. Des stratégies comme «Chained Declustering» [HSI 90] sont jugées de bonne qualité, et ont été implémentées avec succès sur quelques prototypes (PARGRES) Prototype de SGBD parallèles à base de réplication : PARGRES : ParGres [MAT 05] est un prototype universitaire développé par un groupe de chercheurs de l université de Rio de Janeiro (Brazil), en collaboration avec l INRIA. ParGres est une solution middleware, qui vise à accélérer l exécution des requêtes lourdes, particulièrement les requêtes OLAP [CHO 07], qui sont souvent extrêmement complexes, et dont les bases de données manipulées sont des entrepôts de données (Data Warehouse) [CHO 07], qui sont connues comme des bases de données d analyses de très grandes tailles. ParGres est un SGBD distribué, qui adopte l architecture shared-nothing. Le support d exécution est un réseau de PC. Sur chaque site, le SGBD PostgreSQL est installé, avec une copie complète de la base de données. Le rôle de ParGres est d évaluer en parallèle les requêtes soumises, orchestrer l exécution distribuée, et composer le résultat final, toute en garantissant l équilibrage de la charge de travail. Afin d offrir de la haute performance, ParGres met en œuvre deux types de parallélisme, en l occurrence : le parallélisme inter-requêtes et le parallélisme intra-requête. Le parallélisme interrequêtes améliore le débit transactionnel, et par conséquent, les performances globales du système, surtout pour les requêtes simples. Son implémentation est basée sur l algorithme BQNR (BalancingQuery-Number Routing), ou le site, ayant le minimum de requêtes en cours, sera choisi. Les requêtes, jugées lourdes, sont traitées avec le parallélisme intra-requête. Ce dernier est implémenté à l aide de la technique AVP. ParGres maintient un catalogue de métadonnées, ou il stocke les informations 63

75 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées nécessaires au déroulement du AVP (la cardinalité de chaque relation, les valeurs minimales et maximales par attribut, les indexes, ). Principalement, ParGres est constitué de deux composants principaux : le CQP (Cluster Query Processor) et NQP (Node Query Processor). CQP est un composant central, qui joue le rôle de coordinateur, une seule instance est lancée sur un site maitre. CQP se charge d intercepter les requêtes utilisateurs, vérifier leur consistance syntaxique et sémantique, puis générer le plan d exécution, qui spécifie : le type de parallélisme à employer, les nœuds impliqués dans les exécutions, et un plan de fusion, décrivant les opérations à effectuer lors de la composition du résultat final. Sur chaque nœud faisant partie de ParGres, une instance NQP s exécute en permanence, elle est à l écoute des messages en provenance de CQP. Lors de la réception d un message, elle inspecte son contenu, et détermine l ensemble des opérations à entreprendre. En cas de parallélisme inter-requête, elle se contente de lancer la requête, et retourner le résultat à CQP. Tandis que pour le parallélisme intra-requête, il lance l algorithme AVP, ou il progresse dans l exécution en communiquant avec les autres instances de NQP, et éventuellement leur assigner une partie de sa charge. Figure 34:architecture logicielle de ParGres [MAT 05] 64

76 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées POWERDB : PowerDB [FUA 02] est un cluster de base de données, qui s appuie sur l architecture shared-nothing. Le projet est initié par le groupe de recherche de bases de données, affilié à l institut de systèmes d information (Database Research Group Institute of Information Systems) de l université de zurich, suisse. L objectif du projet était de bâtir une solution middleware, qui s exécute au-dessus d un cluster de stations, reliés par un réseau LAN standard, en offrant de la haute performance grâce à l équilibrage de la charge de travail. La première version de PowerDB [FUA 02] s est focalisée sur l amélioration du débit transactionnel, à l aide du parallélisme inter-requête, via l implémentation de plusieurs stratégies de routage (BQNR Balancing-Query-Number Routing, BNQRD Balance the Number of Queries by Resource Demands et Cache Approximation Query Routing). PowerDB est constitué d un seul composant logiciel (baptisé «Coordinateur»), qui régit l exécution parallèle des requêtes et gère la réplication. Ce dernier s exécute sur le nœud maitre, le reste des nœuds abritent une instance du SGBD PostgreSQL, avec une copie complète de la base de données. Figure 35:architecture de PowerDB [FUA 02] Le coordinateur est la seule interface accessible aux clients, le reste de l architecture demeure transparente. Les clients interagissent seulement avec le nœud hébergeant le coordinateur. Les requêtes clients sont, d abords, rangées dans une file d attente. Le coordinateur détermine l ordre de traitement des requêtes et la destination de routage, selon la stratégie choisie. En outre, PowerDB dispose d un dictionnaire de données, ou il sauvegarde certaines informations requises à la mise en place des différentes techniques de routage. Plus récemment, le prototype PowerDB était renforcé par l intégration du parallélisme intra-requête [MIR 06]. Ce type de parallélisme devient disponible grâce à l implémentation du partitionnement virtuelle simple (SVP). Comme expliqué précédemment, SVP ne garantit pas l équilibrage de la charge 65

77 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées de travail, surtout en la présence de Data Skew. Donc, il revient aux promoteurs de ce projet d incorporer des techniques plus robuste comme l AVP APUAMA : Ce projet et le fruit de collaboration de trois université [MIR 06]: INRIA, LINA (université de nante, france) et le groupe ATLAS de l université de Rio de Janeiro, Brazil. A l instar des prototypes susévoqués, APUAMA est un middleware tournant sur un réseau de station, doté chacune d une instance locale d un SGBD (dans l implémentation proposée, c est PostgreSQL). La base de données est répliquée sur tous les nœuds. Cependant, les promoteurs d APUAMA ne sont pas partis de zéro, ils ont étendu une solution open source appelée C-JDBC [CEC 04]. C-JDBC est aussi un middleware, qui propose du parallélisme inter-requêtes, avec la gestion de réplication, ou la consistance des réplicas est assurée via un mécanisme synchrone. Figure 36:architecture APUAMA [MIR 06] APUAMA vient pour combler la faiblesse de C-JDBC sur les requêtes lourdes et complexes, en introduisant du parallélisme intra-requête, tout en exploitant le parallélisme inter-requêtes et le contrôleur de réplication, qui sont réputés fiables et performants. La stratégie retenue est le 66

78 Chapitre 3: Parallélisation des requêtes dans les bases de données répliquées partitionnement virtuel simple SVP. Les composants logiciels relatifs à APUAMA se fondent avec celles de C-JDBC, sans opérer aucune modification de son code source. Il s intercale entre le SGBD, et les composants «Connection Manger» du C-JDBC. De cette manière, C-JDBC soumet les requêtes au moteur APUAMA, qui se charge de les évaluer à l aide du parallélisme intra-requête. Semblablement à PowerDB, l utilisation du SVP représente le point faible de la solution, qui donne des performances médiocre sous certaines conditions Conclusion : Dans ce chapitre on a abordé les différents aspects liés à la réplication. On a commencé par définir la technique de réplication, par la suite on a cité ses avantages. Les types de réplication ont été présentés en détails : la réplication synchrone qui est plus forte mais lourde et la réplication asynchrone qui ne garantit pas la consistance immédiate, en revanche ses performances sont bien meilleures. Le cœur de ce chapitre est les stratégies du parallélisation dans le contexte des bases de données répliquées. On a étalé les divers types du parallélisme et leur adaptation à la réplication. Le parallélisme inter-requêtes est le plus exploité dans les bases de données répliquées, il est réalisé à l aide de plusieurs stratégies de routage des requêtes. Le parallélisme intra-requête est intégré aux bases de données répliquées à travers le partitionnement virtuel. Ce dernier se décline en deux versions : le partitionnement virtuel simple SVP, et le partitionnement virtuel adaptatif AVP. Les deux versions ont été détaillées : le principe, l algorithme, les avantages et les inconvénients. Par la suite, on a évoqué la possibilité de faire cohabiter les deux types de parallélisme inter et intra-requête, on a donné un aperçu sur la réplication partielle, et on a conclu par une revue des prototypes de SGBDs parallèles à base de réplication. 67

79 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Chapitre 4 : Conception et mise en œuvre d une solution de paralle lisation a base de re plication 68

80 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication 4. Conception et mise en œuvre d une solution de parallélisation à base de réplication : 4.1. Introduction: L évolution des bases de données en termes de volume et de traitement a imposé un véritable défi aux éditeurs des SGBDs. Les SGBDs usuels sont capables de rendre un niveau de performance acceptable jusqu à un volume de données défini, au-delà duquel on se trouve dans l obligation de mettre en place une solution de haute performance. Les SGBDs parallèles tournant sur des supercalculateurs ne sont plus la première option, actuellement beaucoup d efforts sont consentis autour des architectures shared-nothing, et plus particulièrement sur les clusters de bases de données. Typiquement, la haute performance est obtenue via le partitionnement des données sur les nœuds du réseau et l adaptation de la version séquentielle des algorithmes d évaluation. En dépit de quelques faiblesses, La technique de partitionnement est généralement performante. Bien que le concept de bases de données distribuées soit étroitement lié au partitionnement, les bases de données répliquées constituent aussi une autre variante des bases de données distribuées. La technique de réplication est historiquement employée pour la haute disponibilité et la tolérance aux pannes, mais rarement pour la haute performance. Injecter du parallélisme dans les bases de données répliquées est catégoriquement différent des bases de données partitionnées. A travers cette étude, on a adressé la problématique de parallélisation dans le contexte de réplication. Le travail mené a aboutis à la réalisation d un prototype de test, qui implémente le partitionnement virtuel avec ces deux techniques, en l occurrence SVP (simple Virtual Partitioning) et AVP (Adaptive Virtual Partitioning). La suite de ce chapitre est consacrée aux détails de l architecture et le fonctionnement général de l application Présentation de la solution FastDBC: A l instar des prototypes universitaires présentés dans le cadre de cette étude, on a opté pour l implémentation d un nouveau prototype, qu on a baptisé FastDBC (Fast DataBase Cluster). FastDBC constitue la pierre angulaire de ce travail, ou il servira à la validation des résultats théoriques et mettre en application les concepts, les algorithmes et les techniques présentés dans les chapitres précédents. FastDBC est un cluster de base de données conçu pour offrir de la haute performance, dans un environnement de bases de données parallèles et distribuées. Contrairement aux systèmes traditionnels de bases de données parallèles, caractérisées par un fort couplage logiciel/matériel, et tournant sur des supercalculateurs coûteux, FastDBC est une solution middleware, dont le rôle est d orchestrer l évaluation des requêtes sur un ensemble de sites connectés par un réseau d interconnexion, aucune contrainte n est établie sur le type de réseau, ou la vitesse de connexion (souvent un réseau LAN est largement suffisant). Chaque site est doté d une instance d un SGBD séquentiel. Pour cette implémentation, le SGBD PostgreSQL est retenu, cependant d autres SGBDs peuvent être facilement supportés, moyennant quelques petites modifications. Pour le schéma de partitionnement des données, on a adopté un schéma basé sur la réplication, ou l entièreté de la base de données est dupliquée sur chaque site. Le mécanisme de réplication est implémenté à l aide d une solution OpenSource appelé Slony (au cas où le système cible ne dispose 69

81 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication pas d une solution de réplication). Evidemment, le choix du schéma de partitionnement détermine la stratégie de parallélisation et le type de parallélisme. Ainsi, on a mis en œuvre le parallélisme intrarequête, via la technique de partitionnement virtuel, avec ces deux variantes SVP (simple virtual partitionning) et AVP (adaptatif virtual partitionning) Systèmes cibles: La haute performance n est jamais une curiosité scientifique, mais un besoin, qui se fait de plus en plus insistant, d autant que les applications évoluent en volume de données et en complexité, menant à la multiplication des systèmes de haute performance. Toutefois, l adoption de l un d entre eux, implique un changement d architecture matérielle et logicielle, souvent coûteux et lourd à mettre en place. Dans une application, Le besoin en haute performance est identifié lors de la phase de conception, mais plus fréquemment après sa mise en production. Idéalement, une solution de haute performance doit s intégrer à l existant sans aucunes modifications, une exigence qui est rarement remplies. FastDBC est appelé à être une solution non intrusive, qui tend à offrir de la haute performance sans opérer des changements majeurs sur l infrastructure. En effet, l accélération est obtenue grâce à la mise en place d un mécanisme de réplication, et l ajout de nouvelles machines, qui vont héberger une copie de la base de données cible et participer au schéma de réplication. Dans le cas de figure où le système dispose déjà de son propre mécanisme de réplication, la première phase est omise, FastDBC se contente uniquement d exploiter l infrastructure existante Architecture générale: FastDBC est un composant logiciel externe, typiquement un middleware, qui se base sur l infrastructure existante pour proposer de la haute performance. On estime que ce type d architecture se fait de plus en plus adopté pour ce genre de solutions, grâce à son faible coût, et sa capacité d exploiter le patrimoine matériel et logiciel existant. Architecturalement, FastDBC est composé des couches suivantes : 70

82 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Client Client Client Client Middleware FastDBC DB DB PostGres PostGres DB PostGres Solution de réplication (Slony) Figure 37: Architecture générale de FastDBC La couche client : Elle comprend tout composant applicatif capable de consommer les services exposés par notre solution. Principalement, un client peut soumettre des requêtes, définir la technique de parallélisation (SVP, AVP) et renseigner les paramètres associés, spécifier le degré de parallélisme (l identité et le nombre des serveurs impliqués dans l exécution parallèle), et bien sûr lancer l exécution parallèle. Une fois l exécution est terminée, le résultat lui sera restitué. La couche middleware (FastDBC): C est à ce niveau que se situe la logique de parallélisation. En effet, cette couche représente le cœur de la solution et l interface d accès exposée aux clients. Elle permet de gérer tout le cycle d exécution parallèle, en commençant par intercepter, analyser, puis faire exécuter les requêtes soumises sur l ensemble des sites, tout en veillant sur le déroulement de l exécution parallèle. Le cycle est clôturé par la restitution du résultat final, ou par un message d erreur le cas échéant. 71

83 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Les serveurs de bases de données : Cette couche représente l infrastructure matérielle de l exécution parallèle. Elle est formée d un ensemble de stations de travail (PC de bureau avec une configuration usuelle), connectées par un réseau de communication. Sur chaque station est installée une instance de PostgreSQL, qui stocke une copie de la base de données, évalue les requêtes (sous-requêtes) en provenance du middleware, et lui renvoie les résultats intermédiaires. La solution de réplication : Bien que l objet de notre prototype soit l évaluation parallèle des requêtes consultatives (requêtes en lecture seule, typiquement des requêtes SQL de type «SELECT»), prétendre à une solution complète, qui éventuellement peut être mise dans un environnement de production, implique la prise en charge de tous les types de requêtes, entre autre les insertions, les mises à jour et les suppressions. Le choix de réplication comme un schéma de partitionnement rend l implémentation des opérations de mise à jour très complexe, ou les aspects de cohérence des replicas, validité des données, transactions distribuées et accès concurrent doivent être impérativement gérés, ce qui absolument sort du cadre de ce travail. Cependant, la technique de réplication a suscité beaucoup d intérêts ces dernières années de la part de la communauté scientifique, comme chez les grands éditeurs des SGBDs commerciaux. Actuellement, la réplication est supportée par la plupart des SGBDs commerciaux (Oracle, DB2, SQLServer) via des modules supplémentaires, fournis avec le SGBD. Dans le monde d OpenSource, le champ est encore plus ouvert, ou on a l embarras du choix entre plusieurs solutions de réplication, pour chaque SGBD. PostgreSQL est réputé comme étant le plus puissant SGBD OpenSource. Ainsi, il est au centre de nombreux projets scientifiques, et la réplication ne fait pas l exception. Plusieurs solutions sont venues pour offrir le support de la réplication sur PostgreSQL, chacune présente des caractéristiques spécifiques, le tableau ci-dessous récapitule les plus importantes solutions, avec la méthode et le type de réplication correspondant. 72

84 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Solution Méthode de réplication Synchronisation WAL Shipping Master/Slave Asynchrone Slony Master/Slave Asynchrone Londiste Master/Slave Asynchrone Mammoth Master/Slave Asynchrone Bucardo Master/Slave or Master/Master Asynchrone Rubyrep Master/Slave or Master/Master Asynchrone PgCluster Master/Master Synchrone Postgres-XC Master/Master Synchrone pgpool-ii Approche middleware Synchrone Tableau 4: solutions de réplication avec PostgreSQL De ce fait, on a décidé de s appuyer sur l une des solutions sus-évoquées, pour permettre la prise en charge des requêtes de mise à jour, et garantir la réplication. Pour notre implémentation, on a retenu la solution Slony. Cette dernière est la plus ancienne et la plus mature des solutions de réplication sur PostgreSQL. Sa robustesse, sa fiabilité, sa flexibilité et ses performances en ont fait une solution de qualité, qui répond à la plupart des besoins Architecture détaillée: Dans le souci d avoir une solution de bonne qualité, non seulement en matière de performances, mais aussi en matière de qualité de code produit, on a essayé de réaliser une architecture solide, qui met en avant les aspects de modularité, extensibilité et testabilité. FastDBC est constitué de plusieurs modules élémentaires, chacun est censé accomplir une fonction prédéfinie. La figure ci-dessous illustre les détails de l architecture. Selon le mode d exécution les modules FastDBC sont répartis en deux catégories : séquentielle et parallèle. Un module séquentiel s exécute sur le thread principal de l application, alors qu un module parallèle possède son propre thread d exécution. De ce fait, plusieurs modules parallèles peuvent s exécuter simultanément, ce qui n est pas le cas pour les modules séquentiels. Modules séquentiels SQLParser VirtualPartitioner DataCatalogue Modules parallèle DistributionExecutionManager QueryExecutor ResultCollector DataWriter Tableau 5: Modules parallèles et module séquentiels 73

85 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Requête utilisateur Requête SQL FastAdmin SQLParser ResultCollector Métadonnées Requête de lecture (Plan logique) Requête de d écriture VirtualPartitioner Métadonnée s Plan de partitionnement Résultats intermédiaires Rafraichissemen Requête SQL DataCatalogue Résultat final StatCalculator DistributionExecutionManager DataWriter PostGres BD répliquée Slony Sous-requête/Résultat Sous-requête/Résultat QueryExecutor QueryExecutor PostGres BD répliquée Slony PostGres Paramètres Fichiers de configuration Requête/code de retour BD répliquée Figure 38: Architecture interne de FastDBC Dictionnaire de données (DataCatalogue) : Le Dictionnaire de données (appelé aussi catalogue de données) permet de stocker les métadonnées relatives à la base de données en cours, ainsi que les informations requises pour l implémentation de la technique de partitionnement virtuel. Lors de l établissement de la connexion à la base de données, le contenu du catalogue est publié par le module «Gestionnaire de l exécution distribué».il est composé de deux parties : une fiche descriptive de la base et une collection des fiches des tables existantes. 74

86 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Une fiche table comporte les champs suivants : Les informations descriptives (clé, nom, cardinalité, ) La liste des colonnes de la table La liste des indexes liés à la table Informations de partitionnement (attribut, valeur max, valeur min) La figure ci-dessous montre la structure du catalogue : Fiche base de données Clé nom taille La liste des fiches tables : Fiche table : clé Nom Cardinalité Nombre de colonnes... La liste des colonnes Clé Nom Type La liste des indexes Clé Nom Type Colonnes informations de partitionnement attribut Valeur max Valeur min Figure 39: Structure de catalogue Le catalogue de données est scruté pendant l analyse de la requête pour la vérification syntaxique, mais surtout lors de la génération du plan de partitionnement (les sous-requêtes). Cela dit que le rôle du catalogue est primordial dans l approche de parallélisation. Un catalogue avec des informations erronées ou peu fraiches, conduit systématiquement à un plan d exécution de mauvaise qualité. De ce fait, on a essayé d élaborer une politique de rafraichissement simple, qui propose deux modes : Automatique : le dictionnaire est mis à jour périodiquement, la période est un paramètre d exécution. Manuelle : la mise à jour est lancée explicitement par l utilisateur. Ce procédé offre un bon compromis entre la fraîcheur des données, et la consommation des ressources. Car n oubliant pas que les informations du catalogue sont récupérées à l aides de 75

87 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication requêtes SQL, qui seront évaluées sur les SGBDs, ces derniers sont consacrés à l exécution des requêtes utilisateur, et ils ne doivent pas être surchargés par des requêtes de contrôle Interpréteur SQL (SQLParser) : L interpréteur SQL (appelé aussi analyseur de requêtes SQL) intercepte les requêtes SQL soumises sous sa forme textuelle. Il procède à l analyse syntaxique et sémantique, si la requête est inconsistante (erreur de syntaxe, évocation de tables ou attributs inexistants, violation d une règle sémantique, ), un message d erreur est retourné, sinon, selon le type de requête traitée, on distingue deux cas de figure : Requête «SELECT» : un plan d exécution logique est généré en direction du module de partitionnement virtuel «VirtualPartitioner». le plan logique comporte : la liste des colonnes retournées (nom, alias et fonction d agrégation si elle existe), les tables référencées, le prédicat de condition, les colonnes d agrégation et les colonnes (avec la sens de tri) de tri. La figure ci-dessous décrit son format Requête «UPDATE, INSERT, DELETE» : la requête est transférée au «Gestionnaire de l exécution distribué», qui se charge de l exécuter par le biais du «DataWriter». Les colonnes de sortie Les tables référencées condition de restriction les colonnes d agrégation Nom colonne1 Type colonne1 Alias colonne1 Fonction d agg Nom table1 Alias table1 les colonnes et le sens de tri Nom colonne2 Type colonne2 Alias colonne2 Fonction d agg Nom table2 Alias table2 Nom colonnen Type colonnen Alias colonnen Fonction d agg Nom tablen Alias tablen Hiérarchie de prédicat de condition(en cas d existence, sinon vide) Nom colonne1 Nom colonne2 Nom colonne1 Sens de tri (ASC/DESC) Nom colonne2 Sens de tri (ASC/DESC) Nom colonnen Nom colonnen Sens de tri (ASC/DESC) Figure 40: Format de plan d execution logique Ce module se présente comme un élément clé de l architecture de FastDBC. En effet, la nature de la technique de partitionnement virtuel, qui s appuie sur la réécriture de la requête de base, implique une visibilité parfaite sur la structure de la requête (type de requête, présence de clause WHERE, clause GROUPBY, ORDERBY, ) et les entités référencées (tables, colonnes, fonctions, ). Notons que le L interpréteur SQL développé à l issue de cette thèse, n est qu une version primitive, ne couvrant qu une partie de la syntaxe SQL standard (SQL99). Les requêtes reconnues doivent respecter la grammaire ci-dessous : 76

88 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication select_statement: select_clause from_clause where_clause groupby_clause orderby_clause (SEMICOLON)?; select_clause: SELECT distinct_op columns_result; distinct_op: DISTINCT ; columns_result: column_expresion list_columns ASTERISK; list_columns: COMMA column_expresion ((AS)? alias_expression)? list_columns ; alias_expression: ALIAS data_identifier; column_expresion: data_object_path aggregate_expression; data_object_path: data_identifier (DOT data_identifier)*; data_identifier :IDENTIFICATION_VARIABLE QUOTED_IDENTIFICATION_VARIABLE; aggregate_expression : ( AVG MAX MIN SUM COUNT ) BRACKET1 data_object_path BRACKET2; from_clause : FROM table_declaration (COMMA table_declaration)*; table_declaration : data_object_path ((AS)? alias_expression)?; where_clause : WHERE conditions_block ; conditions_block :conditional_term (OR conditional_term)*; conditional_term: conditional_factor (AND conditional_factor)* conditional_factor : (NOT)? conditional_primary; conditional_primary: simple_cond_expression ; simple_cond_expression : comparison_expression between_expression like_expression; between_expression : data_object_path (NOT)? BETWEEN constant AND constant; like_expression: data_object_path (NOT)? LIKE STRING; comparison_expression :arithmetic_expression comparison_operator arithmetic_expression; comparison_operator: EQUAL GREATER GREATER_EQ LESS LESS_EQ NOT_EQ; arithmetic_expression: (arithmetic_term) (( PLUS MINUS ) arithmetic_term)*; arithmetic_term: (arithmetic_factor) (( ASTERISK SLASH ) arithmetic_factor)*; arithmetic_factor : constant data_object_path BRACKET1 conditions_block BRACKET2; constant: FLOAT INT STRING CON_TRUE CON_FALSE; groupby_clause:groupby data_object_path (COMMA data_object_path)* ; orderby_clause:orderby order_by_columns (COMMA order_by_columns)* ; order_by_columns:data_object_path (ESC DESC)?; Figure 41: Grammaire implémenté par ParserSQL de FastDBC 77

89 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Partitionneur virtuel (VirtualPartitioner): Ce module se charge d implémenter la première phase de la technique de partitionnement virtuel, qui est la réécriture de la requête d origine. Suite à la réception du plan d exécution logique produit par le translateur SQL, et le nombre de sites participants à l exécution parallèle, le Partitionneur virtuel procède à la génération des sous-requêtes en appliquant une série de transformations : Génération des colonnes résultantes : cette phase permet de générer la clause «SELECT» des sousrequêtes. Comme indiquer sur la figure 4, le plan d exécution logique recense la liste des attributs retournés par la requête. Pour chaque colonne, Le Partitionneur effectue les opérations suivantes Attribuer un alias de contrôle, qui sert à identifier la colonne (sous la forme [COL_Numero_Seq]) Si la colonne courante comporte une fonction d agrégation, elle est remplacée par son équivalente, relativement à la table ci-dessous : Fonction dans la requête d origine Fonction dans la sous-requête MAX(a) MAX(a) MIN(a) MIN(a) SUM(a) SUM(a) COUNT(a) COUNT(a) AVG(a) SUM(a), COUNT(a) Tableau 6: Transformations effectués par le partitionner en cas de fonctions d'agrégation Génération de condition de partitionnement : pendant cette phase, le partitionneur consulte la liste des tables présentes dans le le plan logique. Le catalogue de données est examiné afin de déterminer la table la plus volumineuse, l attribut de partitionnement de cette dernières sera employé pour construire la condition de partitionnement, et sa plage de valeurs sera scindée en intervalles à l aide de la formule ci-dessous: ()=[ +, ( + 1) + ] La condition de partitionnement est rattachée à la clause «WHERE» de la requête avec l opérateur logique «AND», si la requête ne comporte pas de clause «WHERE», elle est ajoutée avec la condition de partitionnement. le prédicat de condition est de la forme «attribut_patitionnement BITWEEN :val_min and :Val_max». Notons qu on a opté pour les requêtes paramétrées (l utilisation de paramètres est quasiment supporté par tous les SGBD), en vue d éviter la construction de plusieurs copies de la même sous-requête (seul l intervalle qui change), d un côté, et de séparer la syntaxe de la requête des intervalles de fragmentation de l autre côté. Génération du reste des clauses : les autres parties de la sous-requête (FROM, GROUP BY, ORDER BY) sont copiées à partir de la requête de base sans aucunes modifications. 78

90 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication La fin du traitement est sanctionnée par un plan de partitionnement, qui sera transféré au «Gestionnaire de l exécution distribué». Il est composé des sections suivantes : La sous requête Les intervalles de partitionnement Le plan d exécution logique DataCatalogue Les caractéristiques des tables référencées Plan logique : -Colonnes résultats -Tables impliquées -Attribut d aggri -Attribut de tri VirtualPartitioner Plan de partitionnement : -sous-requête -les intervalles -plan logique Figure 42: Diagramme fonctionnel de partitionneur Pour illustrer le fonctionnement du partitionneur prenons l exemple de la requête analytique cidessous, qui calcule le nombre de facture, la facture la plus récente et la moyenne des montants pour chaque client. Le nombre de sites d exécution est 3, et les tailles des tables Client et Facture son respectivement 1200 et (les valeurs des clés sont séquentielles). SELECT CodeClient, NomClient, COUNT(CodeFacture), MAX(DateFacture), AVG(MontantFacture) FROM Client, Facture WHERE Client.CodeClient = Facture.CodeClient GROUP BY CodeClient Le partitionneur associe à chaque colonne un alias identifiant. La table «facture» est la plus volumineuse, du coup, elle est sélectionnée pour le partitionnement virtuel, avec l attribut «CodeFacture». Le plan de partitionnement final est de la forme : Sous-requête : SELECT CodeClient COL_1, NomClient COL_2, COUNT(CodeFacture) COL_3, MAX(DateFacture) COL_4, SUM(MontantFacture) COL_5, COUNT(MontantFacture) COL_6 FROM Client, Facture WHERE (Client.CodeClient = Facture.CodeClient) and (CodeFacture BITWEEN :Val_min and :Val_max) GROUP BY CodeClient 79

91 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Les intervalles : [ ] [ ] [ ] Collecteur de résultat (ResultCollector): L exécution distribuée aboutit à la génération de plusieurs résultats partiels issus de l évaluation des sous-requêtes, le résultat final est obtenu suite à leur fusion. Le collecteur offre un support pour le stockage des résultats intermédiaires et l exécution des traitements nécessaires à la fusion. Stockage : Le collecteur doit pouvoir sauvegarder les résultats temporaires générés au fur et à mesure de l exécution. Pour des raisons de performance, la mémoire est le premier support de stockage, dans des cas extrême (un résultat de très grande taille), on peut recourir au disque. En guise de développer un système de stockage personnalisé, on a préféré l utilisation d un SGBD embarqué, plus précisément SQLite. SQLite [KRE 10] est une bibliothèque OpenSource, qui fournit une bonne alternative pour embarquer un SGBD au sein d une application. La première version est apparue en Elle est présentée comme une solution élégante et efficace destinée aux applications, qui gèrent leurs données en interne, en évitant le surcoût dû à l utilisation des systèmes de bases de données dédiés. SQLite est réputé d être complet (supporte la majorité des rubriques d un SGBD classique : base de données, table relationnelles, indexes, contraintes d intégrité, triggers et le Standard SQL99), portable, efficace, fiable et simple à utiliser. Figure 43:SGBD classique VS SGBD embarqué [KRE 10] La caractéristique principale de SQLite est le fait d être embarqué. Plutôt de s exécuter sur un processus indépendant, son code s intègre comme une partie de l application hébergeante, en s exécutant sur son processus. De l extérieure, l application apparait comme une seule unité logicielle, mais derrière, il y a toute un SGBD, qui tourne. L emploi d un SGBD embarqué dissimule 80

92 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication plusieurs avantages. Nul besoin d une configuration réseau spécifique, du moment que le client et le serveur résident sur le même processus. Ceci facilite d avantage l administration de la base de données et élimine le surcoût lié aux appels réseau. La phase de déploiement est considérablement simplifiée depuis que tous les composants applicatifs sont incorporés dans un seul exécutable. SQLite constitue une nouvelle alternative pour les applications, qui manipule de larges collections de données sans reposer sur un SGBD. En effet, les structures de données d une application peuvent être aisément modélisées sous forme de tables relationnelles, au sein d une base de données SQLite. Cela va prendre une nouvelle dimension, si l application a besoin d implémenter certaines fonctions inhérentes au modèle relationnel (contrainte sur les données, le tri, les agrégations, ), SQLite permet de faire le gros du travail, en agissant sur les données d une manière relationnelle, avec toute la puissance du langage SQL. Communément, une base de données SQLite est sauvegardée dans un seul fichier. Toutefois, SQLite peut être configuré pour stocker une base de données en mémoire, avec la possibilité de passer à un stockage disque, si la base de données dépasse un certain volume. Dans le contexte de ce travail, SQLite est employé dans l implémentation du module «collecteur de résultat». En effet, lors de l instanciation du collecteur, une base de données SQLite est initialisée. La nature de notre application (stockage temporaire) suggère l utilisation de la mémoire comme support de stockage. De ce fait, la base de données est configurée pour être sauvegardée en mémoire (un stockage disque est optionnel). Lors du lancement de chaque requête, le collecteur crée une table temporaire, qui servira à sauvegarder les résultats partiels. En fin d exécution, la table est détruite et son contenu est renvoyé au client. Fonctionnement : Le fonctionnement du collecteur s étale sur tout le processus d exécution parallèle. Ainsi, on convient de le décliner en trois phases : Initialisation de l exécution : Lors du lancement de l exécution parallèle par le «Gestionnaire de l exécution distribué», le plan de partitionnement est passé au collecteur. Ce dernier analyse le plan logique associé, notamment les colonnes résultats. Pour chaque colonne il : Il extrait le nom et l alias ; Il calcule le type ; Il marque la présence d une fonction d agrégation. Ces informations sont employées pour construire trois requêtes : Requête de création de la table temporaire : elle sert à créer la table temporaire, qui hébergera les résultats intermédiaires Requête d insertion des tuples résultats : elle est exécutée pour chaque tuple résultat, en vue de l insérer dans la table temporaire. La requête est paramétrée, ce qui permet de construire la requête une seule fois, puis renseigner les valeurs des paramètres pour chaque exécution. 81

93 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Requête de récupération du résultat final : elle est évaluée pour obtenir le résultat final, une fois tous les résultats intermédiaires sont récupérés et fusionnés dans la table temporaire. En la présence d une fonction d agrégation, Le collecteur applique les règles suivantes : Fonction dans la requête d origine Fonction dans la requête finale MAX(a) MAX(a) MIN(a) MIN(a) SUM(a) SUM(a) COUNT(a) SUM(a) AVG(a) SUM(a)/COUNT(a) Tableau 7: règle d'écriture de requête de récupération en cas de fonction d'agrégation Cette phase est clôturée par la création de la table temporaire à l aide de la requête générée précédemment. Consolidation des résultats partiels : Lors de la réception d un résultat partiel, le collecteur exécute la requête d insertion pour chaque tuple le composant, bien évidemment après avoir mappé les attributs du tuple aux paramètres correspondants sur la requête. Notons qu une transaction est initialisée sur la base de données temporaire, avant d effectuer la première insertion. Si une erreur se produit la transaction est annulée, sinon elle sera validée. Production du résultat final : Pendant cette phase, le collecteur réalise la composition du résultat final, via l évaluation de la requête de récupération sur l ensemble des données. Le résultat est renvoyé au client et la table temporaire est supprimée. 82

94 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication 1. Réception de Plan de Partitionnement et génération des requêtes 2. Création de la table temporaire 3. Réception des résultats temporaires 4. Insertion des tuples dans la base SQLite 5. Fusion du résultat final et suppression de la table temporaire 6. Renvoi du résultat au client FastAdmin 6 DistributionExecution Manager ResultCollector SQLite 4 BD temporaire 5 Figure 44: fonctionnement de collecteur Afin d illustrer le fonctionnement du collecteur, reprenons la requête précédente (exemple de partitionneur), les 3 requêtes générées seront : Requête de création de la table temporaire : CREATE TABLE temp_table { COL_1 int, COL_2 text, COL_3 int, COL_4 date, COL_5 double, COL_6 double } Requête d insertion des tuples résultats : INSER INTO temp_table(col_1, COL_2, COL_3, COL_4, COL_5, COL_6) VALUES( :par_col_1, :par_col_2, :par_col_3, :par_col_4, :par_col_5, :par_col_6) Requête de récupération du résultat final : SELECT COL_1 as CodeClient, COL_2 as NomClient, SUM(COL_3), MAX(COL_4), SUM(COL_5)/SUM(COL_6) FROM temp_table Exécuteur de requête (QueryExecutor): Ce module est responsable de l exécution effective des requêtes. Pour chaque site participant au schéma d exécution, une instance de «QueryExecutor» est créée et une connexion pointant vers l instance locale de PostgreSQL, lui est assignée. «QueryExecutor» est une entité parallèle, qui attend en permanence les demandes d exécution en provenance du «Gestionnaire d exécution distribué». La structure transmise par le gestionnaire est composée de : 83

95 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication La sous-requête L intervalle d exécution La méthode d exécution (SVP ou AVP) A la réception d une demande d exécution, «QueryExecutor» examine l état de la connexion, en cas où elle est fermée, il tente de l ouvrir, si les tentatives échouent, l exécution est interrompue et un code d erreur est retourné au gestionnaire. Ensuite, «QueryExecutor» extrait la sous-requête et l intervalle d exécution. La stratégie d exécution spécifiée détermine le reste du traitement : SVP : avec cette méthode, «QueryExecutor» se contente d affecter l intervalle aux deux paramètres de la sous-requête et la soumettre au SGBD pour l évaluation, en cas de succès, il signale la fin de l exécution au gestionnaire et il renvoie le résultat intermédiaire au collecteur, qui se charge de construire le résultat final. AVP : le processus de traitement AVP est plus complexe. En effet, «QueryExecutor» évalue progressivement la sous-requête sur l intervalle d exécution d origine. Les intervalles partiels sont générés à l aide de l algorithme proposé par Lima [CAM 05], avec un léger ajustement. L algorithme commence par une phase de recherche, ou l exécution porte sur des petites partitions, qu on élargit graduellement, tout en mesurant l impact sur le temps d exécution. La phase de recherche est achevée quand la taille optimale est trouvée. L algorithme rentre dans la phase de contrôle, ou il continue d analyser les fluctuations du temps d exécutions, et de corriger la taille de la partition si nécessaire. Notons que tous les résultats partiels sont transférés au collecteur au fur et à mesure de l exécution. 84

96 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Arrivée d une demande d exécution AVP SVP Technique d exécution Calculer la taille d intervalle Exécuter la sous-requête sur tout l intervalle Exécuter la sous-requête sur l intervalle calculé Renvoyer le résultat au collecteur NON Renvoyer le résultat au collecteur Fin d intervalle OUI Fin d exécution Figure 45: fonctionnement de QueryExecutor int partsize, newsize, decexeccounter; float sizeincrfactor, timeincrease, lastexectime, currentexectime; bool intolered_time_increase; qint64 skey, bkey; partsize = InitPartSize ; sizeincrfactor = SizeIncrFactor ; decexeccounter=0; newsize = partsize; lastexectime = -1; int searchinglive = 3; int searching = searchinglive; while (bkey < Intervalle()->getMaxBorn()) { //calculer les bornes d intervalle et avancer le pointeur 85

97 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication skey = getstate()->getpointer ; bkey = qmin(skey + newsize - 1,Intervalle()->getMaxBorn()); //exécuter la sous-requête query->getparameters()->insert(getminparametername(),skey); query->getparameters()->insert(getmaxparametername(),bkey); getstate()->setpointer(bkey + 1); currentexectime = execsubquery(query); if(currentexectime < 0) { getstate()->setpointer(skey); return false; } intolered_time_increase = false; if(lastexectime < 0) { timeincrease = 0; } else { if(lastexectime > 0) timeincrease=(currentexectime-lastexectime)/lastexectime; else timeincrease = currentexectime; } // phase de recherche if(searching > 0) { //élargit l intervalle tant que l augmentation en temps //d exécution est inferieure au taux spécifié if(timeincrease < IncExecTimeSearching*sizeIncrFactor) { partsize = newsize; newsize = partsize*(1+sizeincrfactor); searching = searchinglive; } else { intolered_time_increase = true; searching--; if(searching == 0) { newsize = partsize; } } } // phase de contrôle else { //si l augmentation dépasse le seuil spécifié if(timeincrease > IncExecTimeMonitoring) { decexeccounter++; intolered_time_increase = true; //si le nombre de mauvaise exécution consécutive va au delà //de nombre autorisé if(decexeccounter > getnbbadexec) { searching = searchinglive; decexeccounter = 0; newsize = newsize*(1- SizeRedFactor); 86

98 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication sizeincrfactor=sizeincrfactor*(1sizeincfactorresearching); } } else { decexeccounter = 0; } } if(!intolered_time_increase) { // sauvegarder le temps d exécution lastexectime = currentexectime; } } Figure 46: implémentation d AVP Exécuteur de requête d écriture (DataWriter): L exécution de toute requête d écriture est confiée au «DataWriter». Les requêtes SQL de type «INSERT, UPDATE» sont détectées par l interpréteur SQL, qui les étiquète et les renvoie au gestionnaire, ce dernier les route directement vers «DataWriter» sans effectuer aucun traitement. L exécution de la requête s achève par sa soumission au SGBD. «DataWriter» ne lance pas les requêtes d écriture sur tous les sites. Cependant, il se connecte à un site particulier, précisément le site maitre de réplication. En effet, la solution de réplication sélectionnée (SLONY) est de type «maitre/esclave». Le site maitre est appelé le «fournisseur de réplication», il est censée exécuter les requêtes d écriture et propager les modifications d une manière asynchrone vers les sites esclaves appelés «abonnés» Gestionnaire de l exécution distribué (DistributionExecutionManager) : Le gestionnaire est la pièce maitresse de FastDBC. Son rôle s étale sur toutes les phases du fonctionnement du système, entre autre, la gestion de la communication inter modules, l ordonnancement de l exécution parallèle, la gestion des sites, le contrôle d exécution et la mise à jour du catalogue. Initialisation de l application : Le «DistributionExecutionManager» est un module parallèle, qui est lancé dès le démarrage de l application. Le gestionnaire commence par lire le fichier de configuration, qui stocke les paramètres d exécution, notamment les chaînes de connexion (pointant sur les instances PostgreSQL des différents sites d exécution). Le gestionnaire s en sert pour construire un pool de connexion, ou il garde des connexions PostgreSQL vers tous les sites d exécution. Via cette technique, on compte améliorer les performances globales du système, grâce à la réduction de surcharge due à l'établissement des connections. Une surcharge qui risque d être très importante, si on considère notre implémentation, où l exécution d une seule requête peut requérir l ouverture de plusieurs connections. 87

99 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Gestion des sites : Le gestionnaire maintient la collection des sites d exécution, qui est stockée sur le fichier de configuration. Il propose des routines simples qui permettent de manipuler la collection des sites : Ajouter Site : ajouter un nouveau site d exécution en soumettant : le nom hôte (ou adresse IP), le port de et un compte PostgreSQL valide. Exclure site : supprimer un site de la collection Désactiver site : le site reste dans la collection, toutefois il ne participera pas à l évaluation des requêtes client En outre, le gestionnaire contrôle la disponibilité des sites. En effet, après une erreur d exécution sur un site particulier, le gestionnaire teste la connectivité vers ce site et peut, par conséquence, l exclure du schéma d exécution. Gestion de l exécution : Le gestionnaire intervient dans le cycle d exécution d une requête après la réception de plan de partitionnement virtuel. Le gestionnaire commence par initialiser le contexte d exécution, ou il crée une instance de «ResultCollector», et une instance de «QueryExecutor» pour chaque site d exécution actif (n est pas désactivé et n est pas en panne), en lui assignant une connexion à partir du pool et une sous-requête à évaluer (requête + l intervalle), il poursuit l exécution par le transfert du plan de partitionnement au collecteur, et lancer l exécution de toutes les entités parallèles. Pendant l évaluation des sous-requêtes, le gestionnaire se met à l écoute des messages provenant des différentes entités. Le type de message reçu détermine l action à entreprendre Résultat partiel : le résultat partiel est renvoyé au collecteur pour la fusion. Message d erreur : le gestionnaire émit un signal de fin pour toutes les entités parallèles (les exécuteurs et le collecteur). Il attend les messages de terminaison, puis il renvoie un message d erreur à destination du client. Fin d exécution d une sous-requête : si la technique de partitionnement SVP est employée, le gestionnaire se contente de marquer la fin d exécution de la sous-requête et arrêter l exécuteur émetteur. Cependant, avec la technique AVP, il calcule le taux d avancement de chaque exécuteur (taille de l intervalle évalué/taille de l intervalle assigné). L exécuteur ayant le plus faible taux voit son intervalle réduit à moitié. L autre moitié est renvoyée à l exécuteur émetteur pour évaluation. A la réception de chaque message de ce type, le gestionnaire inspecte l état de l exécution distribuée, si la terminaison est détectée, un message de fin est renvoyé au collecteur pour réaliser la fusion et renvoyer le résultat final au client. Mise à jour de catalogue : Si la politique de rafraichissement du catalogue est mise à «Automatique», le gestionnaire se charge de mettre à jour périodiquement le contenu du catalogue. A Chaque top de période, il lance une tâche parallèle, qui exécute l ensemble des requêtes SQL nécessaires à récupérer les informations du catalogue, sans interrompre l exécution des requêtes utilisateurs. 88

100 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Calculateur des statistiques (StatCalculator) : En se basant sur les statistiques internes, calculées par PostgreSQL, FastDBC permet de retourner un ensemble de statistiques, qui illustrent la qualité de l exécution distribuée. Les statistiques sont calculées à l aide du module «StatCalculator». Si le mode statistique est activé, le gestionnaire émet un ordre de calcul lors du début de l évaluation de chaque requête. Le «StatCalculator» instruit le moteur de statistiques associé à PostgresSQL d initialiser les structures internes pour toutes les tables référencées par la requêtes en cours. En fin d exécution, Le «StatCalculator» récupère une capture sur les tables de statistiques, et la renvoie à FastAdmin pour visualisation. Notons, que les statistiques PostgreSQL ne sont pas exactes, toutefois elles permettent de donner une vue synthétique sur la consommation des ressources et les opérations internes (type de jointure, les accès : séquentiel ou par indexe, le cache SGBD, ). Par table, les statistiques retournées comprennent les informations suivantes : Colonne signification relid Identifiant de la relation relname Nom de la relation seq_scan Nombre d accès séquentiel seq_tup_read Nombre de tuples lus à partir du disque idx_scan Nombre d accès par indexe idx_tup_read Nombre d entrées retournées par un parcours d indexe heap_blks_read Nombre de blocs de données lus à partir de disque heap_blks_hit Nombre de blocs de données récupérés à partir du cache SGBD idx_blks_read Nombre de blocs d indexe lus à partir de disque idx_blks_hit Nombre de blocs d indexe récupérés à partir du cache SGBD 89

101 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Interface utilisateur (FastAdmin) : Afin d appuyer l aspect ergonomique de notre solution, on a décidé de l équiper d un client graphique baptisé FastAdmin, qui fournit un accès facile et intuitive à l ensemble des fonctionnalités rendues par FastDBC. Figure 47: Fenêtre principale de FastAdmin Selon la vocation des éléments composant l interface graphique FastAdmin, on les classe en trois catégories : Eléments de visualisation : ils servent à visualiser l état du système, notamment le catalogue, ou toute sa hiérarchie est chargée, avec la possibilité de consulter les détails de chaque objets. Figure 48: visualiser les propriétés d'un objet du catalogue 90

102 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Figure 49: visualiser la structure du catalogue Eléments de paramétrage : ils permettent d introduire les paramètres d exécution, particulièrement les sites d exécutions et les paramètres AVP. Figure 50: Ajouter un site d'exécution 91

103 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Figure 51: liste des sites d'exécution Figure 52: paramétrage de la stratégie AVP 92

104 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Eléments d exécution: ils comprennent tous les éléments qui participent à l exécution effective d une requête client. On trouve la zone de saisi d une requête, le panneau résultat, le panneau erreurs et le panneau statique. Figure 53: interface de saisi de la requête Figure 54: Fenêtre de résultat Figure 55: Fenêtre des statistiques 93

105 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication 4.6. Évaluation des requêtes avec FastDBC : Avec FastDBC, Le cycle d exécution complet comprend les actions suivantes : Spécifier le site maitre : comme expliquer auparavant, il joue le rôle du fournisseur de réplication, en plus d évaluation des requêtes de mise à jour ; Ajouter les sites d exécutions ; Spécifier la méthode d exécution (SVP ou AVP) ; Renseigner les paramètres d exécution, notamment avec la méthode AVP ou toutes une panoplie de paramètres doit être fournie ; Spécifier si les statistiques doivent être calculées ; introduire la requête à évaluer ; Lancer l exécution de la requête ; FastDBC retourne le résultat et les statistiques d exécution en cas de besoin Caractéristique de FastDBC : Solution multiplateforme : FastDBC est une application multiplateforme, qui supporte les trois systèmes d exploitation de référence en l occurrence : Linux avec la plupart des ses distribution (RedHat, debian, Ubuntu, Fedora, Suse, ), Windows (XP, Vista, Windows7, Windows Server 2008, ), MacOS avec ses différentes versions. Ceci offre une grande flexibilité lors de l allocation des sites, d autant plus que PostgreSQL est aussi un logiciel multiplateforme. Ainsi, on peut bien faire fonctionner FastDBC sur une architecture logicielle complètement hétérogène, où on peut avoir, par exemple, des serveurs PostgreSQL tournant sur Linux, d autre sur Windows et l outil client sur MacOs Solution non intrusive : A l encontre des systèmes de parallélisation lourds, qui nécessitent une révision parfois complète de l architecture logicielle et matérielle. FastDBC est une solution légère, qui se greffe à l existant. Les applicatifs déjà mis en place demeurent parfaitement fonctionnelle sans aucune reconfiguration. Le processus de déploiement est simplifié, seul l outil de réplication doit être configuré au besoin Tolérance aux pannes : Sur un système distribué, les pannes sont beaucoup plus fréquentes qu un système centralisé. Ceci est dû au support matériel, souvent un ensemble d ordinateurs liés par un réseau de communication. Une telle architecture rend le système vulnérable aux pannes : une rupture de connexion, un ordinateur défaillant ou le crash d un composant logiciel peuvent provoquer l arrêt de tout le système. De ce fait, le degré de tolérance aux pannes reflète la robustesse du système distribué. Notre implémentation met l accent sur cet aspect. En effet, FastDBC vérifie continuellement l état des sites d exécution. Les sites jugés défaillants (les sites inaccessibles après plusieurs tentatives de connexion) sont exclus automatiquement du schéma d exécution, et leurs états sont notifiés à l utilisateur, qui peut les inclure ultérieurement, suite à leur réparation, ou les remplacer par des nouveaux sites La haute disponibilité: En observant notre architecture, la haute disponibilité est une caractéristique triviale de FastDBC. Le choix de réplication des données pour la mise en œuvre de parallélisme requiert la multiplication de 94

106 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication plusieurs copies de données sur des sites distincts. Ainsi, si un site tombe en panne, aucune perte de données n est produite, la totalité de la base de données reste accessible sur les autres sites Equilibre de la charge de travail : Le principe d une exécution parallèle est de répartir la charge de travail sur un ensemble de sites. Théoriquement, l utilisation de n sites aboutit à une accélération proche de n. toutefois, l exécution parallèle n est achevée qu après la terminaison de toutes les exécutions partielle. Le temps d exécution globale correspond à celui du site le plus chargé. Ainsi, les performances optimales ne sont atteignables qu avec un bon équilibrage de la charge de travail. Avec FastDBC, l équilibrage de la charge de travail est réalisée à l aide la technique AVP. Lors de la phase de répartition de charge, AVP ne propose pas des techniques sophistiquées, par conséquent un bon équilibre de charge n est pas forcement obtenu à ce stade. Cependant l aspect dynamique d AVP lui permet de rectifier la distribution de la charge lors de l exécution. Comme expliqué cidessus (chapitre 3), si un site termine l exécution de la requête sur son propre intervalle, le gestionnaire peut lui assigner une partie d un intervalle, qui a été initialement affecté à un autre site. De cette manière, tous les sites continueront à partager le reste du travail jusqu à avoir évalué la requête sur tout l intervalle d exécution Support de l hétérogénéité des sites : Les machines composant un cluster ne possèdent pas nécessairement la même configuration matérielle (nombre et type de processeurs, taille de la RAM, taille disque ), donnant issue au cluster hystérogène. Moyennant de quelques astuces, FastDBC peut être adapté pour exploiter efficacement ce genre de cluster. On peut envisager d ouvrir plusieurs connexions par machine, le nombre de connexions est proportionnel à la puissance de calcul proposée. Ainsi, un site avec une configuration sophistiquée sera considéré comme plusieurs sites ayant une capacité normale Parallélisme inter-utilisateurs : Dans sa version actuelle, FastDBC ne supporte pas les connexions simultanées (un seul utilisateur est connecté à la fois). Néanmoins, on peut remédier à cette contrainte, par le lancement d une instance FastDBC par utilisateur, toute en exploitant les mêmes sites d exécution. Cela permet de partager la puissance de calcul offerte par l entièreté du cluster sur l ensemble des utilisateurs connectés via FastDBC. Cette approche s avère raisonnable d autant que FastDBC est une application légère, caractérisée par une consommation modérée des ressources physiques Scalabilité : Augmenter la capacité de FastDBC consiste à connecter de nouvelles machines sur le réseau, qui doivent être configurées pour la réplication et incorporées au schéma d exécution. Théoriquement, FastDBC peut tourner sur un cluster de grande taille. Cependant, la limitation vient de l outil de réplication. Malgré l emploi d une solution de réplication asynchrone (Slony), la scalabilité est sensiblement diminuée. En effet, au-delà de quelques dizaine de sites, le processus de réplication devient très lourd et les performances globales du système subissent une dégradation significative. L adaptation de FastDBC pour d autres SGBD, notamment SQLServer et Oracle, va certainement ouvrir de larges perspectives, ou le support de réplication est plus mature et plus performant. Ce qui va améliorer la qualité de notre solution, particulièrement l aspect scalabilité. 95

107 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication 4.8. Détails de mise en œuvre: Système d exploitation : FastDBC est conçu pour être un logiciel multiplateforme (Windows, Linux, MacOS). Ce choix vise à augmenter la portabilité du système et donner plus de flexibilité lors de l allocation des nœuds. Aucune contrainte n est établie sur le système exploitation, l application peut être déployée sur toutes les infrastructures logicielles et matérielles SGBD : Pour cette implémentation, notre choix a porté sur Le SGBD PostgreSQL, avec sa dernière version stable (actuellement 9.0). PostgreSQL est un SGBD de libre droit, son code source est disponible sous la licence GPL, ce qui permet de personnaliser le source pour avoir des solutions dédiées. PostgreSQL est réputé être un SGBD de qualité, doté des toutes les fonctionnalités avancées que nous ne trouvons que dans les SGBD commerciaux lourds. Ces fonctionnalités nous permettent d implémenter notre solution. Parmi lesquelles : DBLink, qui permet d exécuter une requête sur une base de données distante. PostgreSQL offre aussi une interface de programmation client, à base du langage C appelée libpq, sur laquelle sont écrite d'autres interfaces de programmation, telles que libpq++ (C++), libpgtcl (TCL), Perl, ECPG, et beaucoup d'autres Langage de programmation : A l instar de la plupart des systèmes de hautes performances, FastDBC est implémenté à l aide du langage C++. C est un langage de développement très connu pour ses performances, sa portabilité (une panoplie de compilateur standard sur toutes les plateformes), et son extensibilité (possibilité de rajouter de bibliothèques externes). Le langage C++ est apparue suite à l intégration des concepts de la programmation orienté objet (POO) au langage C. la première version a vu le jour en Dès lors, beaucoup de compilateurs et de librairies ont été bâtis sur C et C++. Aujourd'hui, C et C++ sont très répandus [GES 01]. Beaucoup de logiciels ont été développés avec : Les noyaux des systèmes d exploitation (Unix, Windows), les SGBDs (PostgreSQL, SQLServer, Oracle), les moteurs graphiques (OpenGL), sont les exemples les plus parlants. En outre, la communauté PostgreSQL propose une interface de programmation C++ (libpq++) assez robuste, ce qui facilite considérablement le développement des clients PostgreSQL à base de C Bibliothèque de programmation : Lors du développement de notre prototype, on a fait appel aux bibliothèques suivantes : Qt : Pour le développement de la plus part des composants, on s est appuyé sur la bibliothèque Qt. C est un Framework multiplateforme développé entièrement en C++. Il propose des outils de création des interfaces graphiques (IHM) complètement indépendantes de la plateforme utilisée, ainsi que une large panoplie d API, qui, pratiquement touchent tous les champs de développement(les structures de données, gestion des I/O, la programmation parallèle, les communications réseau, ). A l aide de la bibliothèque Qt, on peut écrire des applications une seule fois et les déployer ensuite sur de nombreux systèmes d'exploitation du bureau comme embarqués, sans avoir à retoucher le code source. 96

108 Chapitre 4 : Conception et mise en œuvre d une solution de parallélisation à base de réplication Libpq ++: c est une interface de programmation pour les applications développées en C++ avec PostgreSQL. Elle offre une large gamme de fonctions permettant aux programmes clients de : Établir des connexions avec les serveurs PostgreSQL ; Envoyer des requêtes aux serveurs PostgreSQL ; Recevoir les résultats des requêtes envoyées ; Initialiser, valider ou annuler des transactions ; Recevoir les erreurs d exécution Conclusion : Dans ce chapitre nous avons mis l accent sur le prototype FastDBC, développé pour appuyer l étude théorique menée tout au long de cette thèse. FastDBC est un cluster de base de données conçu pour fournir de la haute performance, dans un environnement de bases de données répliquées, à l aide des deux techniques SVP et AVP. Au début de ce chapitre, nous avons donné un aperçu sur l architecture générale de l application ainsi que le système cible de parallélisation. Par la suite, on s est étalé sur les composantes de FastDBC. Chaque module a été décrit en détails : le rôle, le fonctionnement, la structure et la communication avec le reste du système. En fin, on a conclus avec les caractéristiques et les avantages liés à notre solution FastDBC. 97

109 Chapitre5 : Etude expérimentale Chapitre 5 : Etude expe rimentale 98

110 Chapitre5 : Etude expérimentale 5. Etude expérimentale : 5.1. Introduction : L objectif de ce chapitre est de dresser une comparaison exhaustive entre les deux techniques du partitionnement virtuel implémentées (SVP et AVP), mais aussi de démontrer, dans un environnement réel, qu en plus de la haute disponibilité, les bases de données répliquées peuvent être exploitées pour offrir de la haute performance. A travers le jeu de test mis en place pour cette étude, on va essayer d évaluer les performances de notre prototype FastDBC sous différentes condition d exécutions. Ainsi, les deux techniques SVP et AVP seront mises en test sur des collections de données de différentes caractéristiques (données uniformément distribuées, déséquilibrage de données), et sur des clusters de différentes tailles, tout en variant les paramètres d exécutions. Les expérimentations seront sanctionnées par un récapitulatif, qui éclaircit les points forts et les points faibles de chacune des deux techniques, en mettant l accent sur les configurations matérielles et logicielles où l utilisation de l une des deux technique, est optimale Benchmark de test : Pour les tests, on a retenu le benchmark TCP-H [TCP 2011], ce dernier est une base de données d analyse (entrepôt de données), conçue et maintenue par le «Transaction Processing Performance Council (TPC)», qui représente une référence mondiale dans le domaine. Le TCP-H est constitué de schéma de la base, un outil de génération de données aléatoire, et un ensemble de requêtes de différent degré de complexité. Le TCP-H offre une bonne alternative pour mesurer les performances des applications qui: Manipule des grands volumes de données Exécute des requêtes de haute complexité Examine un débit transactionnel élevé Conceptuellement, le schéma physique est composé de huit tables (Region, Nation, Supplier, Part, Customer, Partsupp, Orders et Lineitem) comme illustré sur la figure56. Les cardinalités des tables sont calculées à base d un facteur de taille (Scale Factor SF) à l exception des deux tables «Region» et «Nation» ayant une taille fixe de 25 et 5 tuples respectivement. Le tableau suivant montre la formule de calcul pour chacune des tables. table cardinalité Supplier SF*10,000 Customer SF*150,000 Part SF*200,000 Partsupp SF*800,000 Orders SF*1,500,000 Lineitem SF*6,000,000 Tableau 8: Formules de calcul des cardinalités des tables 99

111 Chapitre5 : Etude expérimentale Pour la réalisation de nos tests, on a généré une TCP-H avec un SF=4, ce qui donne une base de données de plus de 8 giga-octet, avec les cardinalités listées ci-dessous : table cardinalité Supplier 40,000 Customer 600,000 Part 800,000 Partsupp 3,200,000 Orders 6,000,000 Lineitem 24,000,000 Tableau 9:Cardinalités des tables pour les tests Figure 56: Schéma de TCP-H benchmark [TCP 2011] En plus de la base de données, TCP-H benchmark propose 22 requêtes (voir Annexe B), ayant différents degrés de complexité et permettant d évaluer les performances de tous les aspects d un système de gestion de base de données (gestion I/O, algorithme d évaluation, utilisation des indexes, ). Dans ce qui suit on se focalisera sur les requêtes Q1, Q2, Q3, Q4, Q5, Q6, Q14, Q17 et Q18 (voir annexe B), notons que certaines requêtes sont légèrement modifiées pour les faire 100

112 Chapitre5 : Etude expérimentale accepter par notre Parser SQL. On juge que cette collection de requêtes est assez représentative dans le cadre de cette étude, ou elle permet de montrer l impact du partitionnement virtuel sur le temps d exécution. Le résultat des différentes exécutions sont exprimés en seconde Récriture des requêtes avec le partitionnement virtuel: FastDBC analyse, puis récrit les requêtes soumises automatiquement, sans aucune intervention manuelle. Cette section décrit l ensemble des requêtes de test, et les sous-requêtes produites suite à l application de la technique de partitionnement virtuel : La requête 1 : La requête 1 réalise une agrégation et un tri sur la table «lineitem», ainsi l attribut de partitionnement est «l_orderkey». La requête2 : Dans la requête 2, on fait la jointure de 5 tables (part, supplier, partsupp, nation, region), et une opération de tri. En outre, la clause «WHERE» comporte une sous-requête, qui réalise aussi la jointure de 4 tables (supplier, partsupp, nation, region). La table de partitionnement est «partsupp» avec l attribut «ps_partkey». La requête 3 : La requête 3 réalise la jointure entre trois tables (customer, orders, lineitem), suivi d une agrégation et un tri. La table la plus volumineuse est «lineitem», ainsi elle est choisie comme table de partitionnement, avec l attribut «l_orderkey». La requête 4 : La requête 4 opère une agrégation et un tri sur la table (orders), par ailleurs la clause «WHERE» comporte une sous-requête assez lourde, qui référence la table «lineitem». La table de partitionnement est «orders», avec l attribut «o_orderkey». La requête 5 : La requête 5 effectue la jointure entre 6 tables (customer, orders, lineitem, supplier, nation, region), suivi d une agrégation. De ce fait, la table «lineitem» est sélectionnée pour le partitionnement, avec l attribut «l_orderkey». La requête 6 : La requête 6 réalise une agrégation sur la table (lineitem ). Ainsi le partitionnement virtuel porte sur la table «lineitem», avec l attribut «l_orderkey». La requête 14 : La requête 14 effectue la jointure entre 2 tables (lineitem, part), suivi d une agrégation. De ce fait, la table «lineitem» est sélectionnée pour le partitionnement, avec l attribut «l_orderkey». 101

113 Chapitre5 : Etude expérimentale La requête 17 : La requête 17 réalise la jointure entre 2 tables (lineitem, part), suivi d une agrégation. La table «lineitem» est choisie pour le partitionnement, avec l attribut «l_orderkey». La requête 18 : La requête 18 effectue la jointure entre 3 tables (customer, orders, lineitem), suivi d une agrégation et un tri. La clause «WHERE» est composée d une sous-requête indépendante (ne contient aucune référence externe), qui référence la table «lineitem».ainsi le partitionnement virtuel porte sur la table «lineitem», avec l attribut «l_orderkey» Environnement de test : Afin de réaliser nos expérimentations, on a construit un cluster de base de données composé de 6 nœuds. La configuration matérielle de chaque nœud comprend un processeur CoreDuo, une mémoire RAM de 2GB et un disque de 160GB. Les nœuds sont connectés via un LAN Ethernet de 100MB. Sur chaque nœud est installé le système d exploitation Windows7 et le SGBD PostgreSQL 9.0 avec une copie de la base de la données de TCP-H benchmark Performances SVP : Le tableau ci-dessous récapitule les temps d exécutions (en seconde) de la technique SVP, pour les 9 requêtes sur les 6 machines. Notons que les temps listés représentent la moyenne de 5 exécutions. Requêtes\Nœuds Q Q Q Q Q Q Q Q Q Tableau 10:temps d'exécution SVP sans Data Skew 102

114 Chapitre5 : Etude expérimentale Q Temps (s) Temps (s) Q Nombre de sites Q Temps (s) Temps (s) 5 Nombre de sites Q Nombre de sites 3 4 Nombre de sites Q5 Q Temps (s) Temps (s) Nombre de sites Nombre de sites 103

115 Chapitre5 : Etude expérimentale Q Temps (s) Temps (s) Q Nombre de sites Nombre de sites Q Temps (s) Nombre de sites Figure 57: Graphes de temps d'exécution SVP L analyse du plan d exécution généré par PostgreSQL permet d expliquer les différentes variations du temps d exécution : Q1 et Q6 présentent les mêmes caractéristiques. Elles référencent une seule table «lineitem», avec une clause «WHERE» peu restrictive. Sur un seul nœud, PostgreSQL génère un plan d exécution, qui accède séquentiellement à la table «lineitem». A partir de deux nœuds, l accès séquentiel est remplacé par l utilisation d indexe crée sur «l_orderkey». L impact est considérable, le temps d exécution est réduit à la moitié. L augmentation de la taille de cluster mène à une accélération linéaire, voir super-linéaire, par exemple, avec 6 nœuds, on obtient respectivement une accélération de 7,69 pour Q1 et 7,68 pour Q6. Q2 et Q4 partage une propriété très importante, leurs clauses «WHERE» contiennent des sousrequêtes lourdes à exécuter. L ajout de prédicat de partitionnement virtuel mène à un changement significatif du plan d exécution généré : Sur un seul nœud, PostgreSQL accède à toutes les tables référencées par Q2 en séquentiel, les jointures sont exécutées à l aide de l algorithme de hachage, sauf la plus conséquente 104

116 Chapitre5 : Etude expérimentale (entre part et le résultat de jointure de : supplier, partsupp, nation, region) qui est évaluée via le «Merge join», le sous-plan relatif à la sous-requête ne comprend que des «Nested loop join», et des accès par indexe. L ajout d un deuxième nœud ne provoque aucun changement sur les types de jointure ou le sous-plan lié à la sous-requête, uniquement les deux tables «part» et «partsupp» sont scrutées par indexe. le même comportement est observé avec respectivement : 3, 4, 5, 6 nœuds. Pour Q4, la sous-requête est transformée en semi-jointure entre la table «orders» et «lineitem», qui est évaluée par l algorithme de hachage, les deux tables sont accédées séquentiellement. Avec l augmentation de la taille de cluster, la semi-jointure est exécutée à l aide de «Nested loop join» et les deux tables sont accédées par indexe. Les changements observés sur le plan d exécution sont suffisant pour produire une accélération quasi-linéaire sur un cluster de très petite taille (2 ou 3 nœuds), par exemple sur 3 nœuds : l accélération obtenue est respectivement 2,52 et 3,07. Sur des clusters de moyenne ou grande taille, l accélération est réduite et loin d être linéaire, sur notre cluster de test, l ajout d un sixième nœud n apporte qu un gain négligeable. Cela peut être expliqué par le coût d évaluation des sous-requêtes, qui domine le coût global, en plus du temps d accès aux tables non affectées par le partitionnement. Cependant l accélération final demeure acceptable (sur 6 nœuds, Q2 : 4,5 et Q4 : 4,4). Q3 et Q5 accèdent à plusieurs tables volumineuses (customer, orders, lineitem). L exécution séquentielle produit des plans avec des accès séquentiel, et des «hash join» en cascade. A partir de deux nœuds, la table «lineitem» est accédée par indexe, le reste des tables sont parcourues séquentiellement, l ordre de jointure change aussi pour Q5. L accélération obtenue est quasi-linéaire pour les différentes taille de cluster (sur 6 nœuds, Q3 :5,67, Q5 :7,27). On conclut que le gain acquis par le partitionnement de «lineitem» l emporte sur l accès séquentiel du reste des tables. Q14 et Q17 accèdent exactement à deux tables (lineitem, part). Le plan séquentiel met la jointure en «hash join» avec un accès séquentiel des deux tables. Dés l ajout de deuxième nœud, la table «lineitem» est accédée par indexe, l accélération obtenue est quasi-linéaire, sur 6 nœuds on a eu une accélération de 5,13 pour Q14 et 6,59 pour Q17. Ainsi, on peut affirmer que le partitionnement de la plus grande table «lineitem» compense le coût de l accès séquentiel de l autre table. Q18 affiche un comportement étrange par rapport aux requêtes précédentes. Certes la requête est similaire à Q4, cependant la sous-requête est indépendante, c'est-à-dire elle n a aucune référence sur les tables de la requête. Dans ce cas de figure, la sous-requête est évaluée une seule fois pour l ensemble des tuples produits par la requête mère. Cela donne une explication pertinente des résultats obtenus, puisque l exécution parallèle de la requête implique de multiples exécutions de la sous-requête associée, ce qui a un effet néfaste sur les performances globales, une faible accélération est enregistrée sur un cluster de taille 6, de l ordre de 2,24. Ainsi, on déduit que la technique SVP ne pourra pas accélérer l exécution de ce genre de requête. La technique SVP s avère performante dans la plupart des requêtes sujettes de test. Des accélérations quasi-linéaires ont été obtenues pour les différentes tailles de cluster. Pour les requêtes, qui ne font référence qu aux tables de partitionnement, ou à des tables de petite taille, l accélération est super-linéaire. Dans le cas de figure ou la requête met en relation plusieurs tables volumineuses, les performances baissent, mais restent acceptables. La présence des sous-requêtes 105

117 Chapitre5 : Etude expérimentale affecte négativement les formances SVP, ou même produit des exécutions plus lentes que l exécution séquentielle Performances AVP : Le tableau ci-dessous récapitule les temps d exécutions (en seconde) de la technique AVP, pour les 9 requêtes sur les 6 machines. Notons que les temps listés représentent la moyenne de 5 exécutions. Les paramètres AVP sont fixés aux valeurs données par le tableau 11. Paramètre valeur Taille de la partition initiale Facteur d augmentation (sizeincrfactor) 100% Augmentation permise en temps d exécution pendant la recherche de la taille optimale 50% * sizeincrfactor Augmentation permise en temps d exécution après stabilité 10% Nombre de mauvaises exécutions consécutives 4 Facteur de réduction appliqué sur la taille de la partition, suite à une détérioration de performances 10% Facteur d augmentation après détérioration de performances 25% Tableau 11:Valeurs de test pour les paramètres AVP Requêtes\Nœuds Q Q Q Q Q Q Q Q Q Tableau 12:Temps d'exécution AVP sans Data Skew 106

118 Chapitre5 : Etude expérimentale Q Temps (s) Temps (s) Q Nombre de sites Q Temps (s) Temps (s) 5 Nombre de sites Q Nombre de sites 3 4 Nombre de sites Q5 Q Temps (s) Temps (s) Nombre de sites Nombre de sites 107

119 Chapitre5 : Etude expérimentale Q Temps (s) Temps (s) Q Nombre de sites Nombre de sites Q Temps (s) Nombre de sites Figure 58: graphes de temps d'exécution AVP L analyse des plans d exécutions relatifs aux sous-requêtes produites par la technique AVP avec l optimiseur PostgreSQL, nous permet d expliquer les résultats ci-dessus: Q1 et Q6 : Les plans d exécution générés pour les sous-requêtes AVP sont identiques à ceux produits par les sous-requêtes SVP. Les tailles des partitions virtuelles varient entre et Cela a permis d achever l exécution complète avec un nombre restreint de sous-requêtes, et éviter le coût commulatif engendré par les traitements pré et post exécution. L accélération acquise est superlinéaire, sur 6 nœuds, on a eu 10,81 pour Q1 et 6,48 pour Q6. L application de la technique AVP sur Q2 et Q4 a mené à des plans d exécutions différents de ceux de SVP. En effet, rajouter un prédicat de condition avec un petit intervalle influence les choix de l optimiseur PostgreSQL: Pour Q2, la jointure exécutée avec le «Merge join» passe en «Nested loop join», et l ordre des jointures change. Pour Q4, la sous-requête est transformée en semi-jointure entre la table «orders» et «lineitem», qui est évaluée uniquement à l aide de «Nested loop join». 108

120 Chapitre5 : Etude expérimentale Les plans d exécutions générés ont conduit à des exécutions plus rapides. En dépit du nombre élevé des sous-requêtes évaluées, une accélération quasi-linéaire est observée (sur 6 nœuds : 6,44 pour Q2 et 5,17 pour Q4). Ce résultat est dû éventuellement à l utilisation de «Nested loop join» combiné avec les indexes, cet algorithme nécessite peut de mémoire, et rend des bonnes performances avec des petites collections de données. En outre, la technique AVP garantit l équilibrage de la charge de travail. Ainsi, un nœud plus performant se fera assigné la moitié de l intervalle de nœud le plus chargé. Un comportement, qui a été constaté dans la plupart des exécutions. Q3 et Q5 : avec AVP, la majorité des tables sont accédées par indexe (sauf les petite tables : region et nation) et la plupart des jointures sont réalisées avec le «Nested loop join». L accélération résultante n est pas linéaire, mais reste acceptable pour Q3 (4,54), tandis qu elle est super-linéaire pour Q5 (8,26). Cela peut être expliqué par les mêmes raisons citées ci-dessus. Q14 et Q17 : les plans générés indiquent des accès par indexe sur les deux tables, avec des jointures en «Nested loop join». L accélération obtenue est linéaire, sur 6 nœuds : 5,33 pour Q14, et 7,13 pour Q17. Les sous-requêtes AVP sont exécutées beaucoup plus efficacement, ce qui réduit le temps d exécution global, malgré le coût du traitement d un nombre élevé de sous-requêtes. A l instar de SVP, la requête Q18 est évaluée très inefficacement avec la technique AVP. En effet, la raison évoquée avec SVP est encore plus valable avec AVP, à chaque exécution d une sous-requête AVP, la sous-requête interne est réévaluée de nouveau. Vu le nombre important de sous-requêtes générées par AVP, les performances chutent, à point que l exécution séquentielle est plus rapide qu une exécution parallèle sur 6 nœuds. De ce fait, la technique AVP n est plus adéquate pour ce type de requête. Les résultats réalisés démontrent l efficacité de la technique AVP. En effet, les accélérations abstenues sont linéaires ou quasi-linéaires pour toutes les requêtes. Bien que la technique AVP génère souvent un nombre important de sous-requêtes, des changements considérables ont été observés sur les plans d exécution correspondants, aboutissants à des exécutions plus efficaces. Le mécanisme d équilibrage de charge, proposé par AVP, mène à un partage équitable de la charge de travail entre les différents nœuds, et réduit par conséquent le temps de répit. 109

121 Chapitre5 : Etude expérimentale 5.7. Performances avec le Data Skew : Dans cette section, on a réévalué les requêtes Q1 et Q6 avec SVP et AVP sur des données n étant pas uniformément distribuées. Ainsi, un jeu de données qui présente un déséquilibre de distribution (Data Skew) a été injecté dans la base de données, à l aide d un outil spécifique disponible sur le site TCP. Les résultats sont récapitulés dans le tableau 13. Requêtes \ Nœuds Q SVP AVP SVP AVP Q Tableau 13: Temps d'exécution SVP/AVP avec le data skew Q Temps (s) Temps (s) Q Nombre de sites SVP AVP Nombre de sites SVP AVP Figure 59: Graphes temps d'execution SVP/AVP en présence de Data Skew L analyse des temps d exécution permet d illustrer le comportement de SVP et AVP vis-à-vis le data skew. La technique SVP rend de mauvaises performances si la distribution des données n est pas uniforme. Avec 2 nœuds l accélération résultante est (Q1 :1,6 Q6 :1,48), qui s améliore au fur et à mesure de l ajout de nouveau nœud, en atteignant (Q1 :5,40 Q6 :3,33) sur 6 nœuds. La technique AVP affiche un comportement complètement différent, le data skew a un impact négligeable sur les temps d exécution, les accélérations obtenues sont linéaires en passant de (Q1 :2,93 Q6 :2,91) sur 2 nœuds à (Q1 :8,55 Q6 :7,36) sur 6 nœuds. En présence de data skew, les performances SVP sont considérablement détériorées. Le calcul des intervalles avec SVP ne repose que sur l intervalle [Min, Max] de l attribut de partitionnement, si les valeurs ne sont pas réparties uniformément sur l intervalle, les partitions virtuelles n auront pas les mêmes tailles. Ainsi, un mauvais équilibrage de charge se manifestera, certains nœuds auront un volume de travail plus important que le reste, ces derniers tarderont à achever leur exécution, et contribueront à rallonger le temps d exécution global. La technique AVP a tendance à ne pas être influencée par le data skew. Le procédé du calcul des intervalles initiaux est commun à SVP et AVP. Cependant, AVP met en place un mécanisme de 110

122 Chapitre5 : Etude expérimentale rééquilibrage de charge, qui corrige un éventuel mauvais partitionnement. Un nœud évalue progressivement sa propre sous-requête sur l intervalle, qui lui a été assigné, dès que l intervalle est terminé, le système rééquilibre la charge en prenant une partie d intervalle du nœud le plus chargé, et pour l affecter au nœud libre. De cette façon, les nœuds continuent de partager la charge de travail jusqu à l exécution complète de la requête AVP vs SVP : La technique de partitionnement virtuel a rendu un niveau de performance très acceptable, avec une accélération quasi-linéaire, sous différentes conditions. Néanmoins, selon le cas, une des variantes peut s avérer plus performante que l autre. La distribution des données : Avec une distribution uniforme des données, les deux variantes SVP et AVP affichent approximativement les mêmes performances. Sur un cluster de deux nœuds, les accélérations obtenues sont relativement meilleures pour AVP. Cela est dû aux facteurs cités ci-dessus : changement du plan d exécution, équilibrage de charge, utilisation des indexes. Au-delà de deux nœuds, l écart commence à rétrécir, comme illustré dans la figure 60. Si un phénomène de data skew est observé sur la collection des données cible, la variante AVP est significativement plus efficace que SVP (voir figure 59). Le mécanisme d équilibrage de charge AVP fait la différence. En dépit d une mauvaise distribution de charge initiale, AVP rééquilibre la charge de travail au fur et mesure de l exécution. L écart s affaiblit avec l augmentation de la taille de cluster. La requête : Les opérations de base (jointure, tri, agrégation), la présence des sous-requêtes et les tables référencées peut impacter considérablement les performances des deux variantes. On peut recenser les cas suivants : Requête avec sous-requêtes : une requête avec une sous-requête lourde à exécuter au niveau de la clause «WHERE», peut être évaluée plus efficacement avec SVP qu avec AVP, à cause du nombre de requêtes important produit par la technique AVP (pour chaque sous-requête AVP, la sous-requête est réévaluée de nouveau). Notons que pour certaines sous-requêtes, le partitionnement virtuel est même déconseillé. L accès de plusieurs tables volumineuses : moins de tables référencées par la requête, plus la technique AVP est plus performante, généralement les tables ayants une petite taille n affectent pas les performances AVP (souvent elles sont lues une seule fois, puis résident en mémoire cache SGBD), pour cette raison, on ne considère que les tables ayants une grande taille. Les agrégations : si le résultat d agrégation est trop important, la technique SVP peut être plus performante. La baisse de performances AVP s explique par l agrégation finale nécessaire à la composition de résultat final. En effet, cette phase est relativement lourde avec AVP, car les résultats intermédiaires à agréger sont plus nombreux avec AVP que SVP (chaque sous-requête génère un résultat intermédiaire). 111

123 Chapitre5 : Etude expérimentale Autre aspect à ne pas négliger lors de la comparaison SVP/AVP, est la difficulté du paramétrage. La mise en place de la technique SVP ne requiert aucun paramètre hors le nombre de nœuds. Par ailleurs, la technique AVP nécessite une palette de paramètres. Trouver la combinaison optimale de leurs valeurs initiales, nécessite des efforts supplémentaires de la part de l administrateur du système. Q Temps (s) Temps (s) Q Nombre de sites SVP AVP AVP Q3 Temps (s) Temps (s) Nombre de sites SVP SVP Q Nombre de sites AVP Nombre de sites SVP AVP 112

124 Chapitre5 : Etude expérimentale Q Temps (s) Temps (s) Q Nombre de sites SVP AVP SVP Temps (s) Temps (s) AVP Nombre de sites SVP 5 Q Nombre de sites Q Nombre de sites AVP SVP AVP Q18 Temps (s) Nombre de sites SVP AVP Figure 60: Temps d'exécution SVP vs AVP 113

125 Chapitre5 : Etude expérimentale 5.9. Conclusion : Ce chapitre est consacré à l étude expérimentale, ou on a fait tourner notre prototype sur un cluster de 6 stations de travail. Les deux techniques de partitionnement virtuel SVP et AVP ont été mises à l épreuve sur le benchmark TCPH. Les résultats obtenus démontrent l efficacité de la technique du partitionnement virtuel. Des accélérations quasi-linéaires voire linéaires ont été observées pour plupart des requêtes et sous les différentes conditions d exécutions. La technique du partitionnement virtuel affiche une bonne scalabilité, où jusqu à 6 sites, les accélérations demeurent acceptables. En effet, les variantes SVP et AVP rendent approximativement les mêmes performances, si les données sont uniformément distribuées. Toutefois, en l absence de cette caractéristique (phénomène de data skew), AVP tend à être plus efficace, le mécanisme d équilibrage de charge fourni par la technique est employé pour remédier au problème de data skew. L analyse des différents résultats nous mène à déduire que l efficacité de la technique du partitionnement virtuel est étroitement liés à la structure et la sémantique de la requête à traiter. Certaines requêtes sont plus adaptées au partitionnement virtuel que d autres, par exemple les requêtes qui référencent peu de tables, et ne comportent pas de sous-requêtes, sont plus rapide à évaluer à l aide du partitionnement virtuel que celles qui comprennent des sous-requêtes ou référencent plusieurs tables volumineuses. 114

126 Conclusion et perspective : Dans cette contribution, nous avons mené une étude approfondie dans un domaine de recherche en plein essor : les SGBDs et les bases de données distribuées. En effet, une large variété d applications modernes manipule des grands volumes de données, avec des traitements très complexes. Par conséquent, ils ont besoin d une puissance de calcul accrue, afin de garder un niveau de performance acceptable. Les SGBDs séquentiels n étaient pas en mesure de répondre efficacement à ce genre de besoins, donnant suite à l apparition des SGBDs distribués. Les SGBDs distribués fournissent les mêmes fonctionnalités que les SGBDs séquentiels. Cependant les données sont distribuées, voire dupliquées, sur un réseau de stations. Les bases de données distribuées ont permis l expansion des bases de données par le simple ajout de nouvelles machines. Afin de faire face aux exigences croissantes, en termes de performances, les SGBDs distribuées doivent marier harmonieusement les divers techniques et stratégies de distribution des données avec les approches de parallélisation des requêtes. La littérature informatique a abondamment abordé les stratégies de parallélisme dans le cas du partitionnement des données. Une large panoplie d algorithmes parallèles a été proposée, traitant toutes les formes de parallélisme. Néanmoins, le partitionnement n est pas la solution parfaite, l exécution des requêtes peut entrainer le transfert des volumes de données conséquents à travers le réseau. En outre, La panne d un site prive le système d accéder à une partie des données. Initialement, la réplication est présentée comme une solution de haute disponibilité, l amélioration des performances était un objectif secondaire. La littérature traitante la réplication s est concentrée sur les protocoles de mise à jour, rare sont les travaux qui ont portés sur l exécution concurrente des requêtes. Toutefois, on retient deux approches de parallélisme dans le contexte de réplication : le routage des requêtes, qui met en avant le parallélisme inter-requête, a attiré plus d attention car il a été jugée plus adaptée à la réplication. La deuxième approche est le partitionnement virtuel, qui simule le partitionnement réel, en agissant sur la requête à traiter. En effet, le travail réalisé au long de cette thèse, se focalise sur les différentes possibilités d intégration du parallélisme dans un environnement de bases de données répliquées, notamment le partitionnement virtuel. A l encontre des techniques de routage, cette technique permet de mettre en œuvre le parallélisme intra-requête, ce qui est nouveau dans ce contexte. En outre, sa mise en œuvre ne requiert aucun changement sur l infrastructure existante (pas de sites supplémentaires, aucune modification sur le schéma de la base, pas de distribution physique des données), le parallélisme est achevé par la simple réécriture de la requête à évaluer. Le partitionnement virtuel se décline en deux versions : SVP caractérisée par sa simplicité, avec des performances assez bonnes en l absence de Data Skew, et AVP qui introduit un mécanisme de répartition de charge, elle s avère beaucoup plus efficace en la présence de Data Skew. L étude théorique était appuyée par l implémentation d un prototype complet baptisé FastDBC, ou la technique de partitionnement virtuel a été mise en application avec ses deux variantes SVP et AVP. FastDBC est un middleware, qui s exécute au-dessus d un réseau de stations, sur chacune est installée une instance PostgreSQL. La base de données est répliquée sur l ensemble des sites. FastDBC propose une interface de configuration simple, qui permet de composer le cluster, choisir la technique d exécution et évaluer la requête sur le cluster. 115

127 Nos expérimentations ont été effectuées avec le benchmark TCP-H, sur un cluster de bases de données constitué de 6 nœuds. Durant la phase de tests, on a relevé les performances relatives aux différentes configurations (en variant le nombre de nœuds et les paramètres d exécution de chaque technique), en vue de mesurer l impact de chaque paramètre sur le temps d exécution et repérer les configurations optimales pour chaque technique. Le travail réalisé durant cette thèse n est qu une modeste contribution, qui nécessite d être complétée et perfectionnée sur plusieurs aspects, d autant plus que le parallélisme de données conjugué à la réplication reste peu exploré, et nécessite beaucoup plus d efforts pour aboutir à des techniques plus efficaces. Comme perspectives, on peut citer les points suivants : Intégrer autre SGBD : actuellement FastDBC repose sur PostgreSQL comme SGBD. Autres extensions doivent être développées pour le support des autres SGBD (oracle, SQLServer, MySQL) Améliorer le parser SQL : le parser développé dans cette version ne prend en charge qu une partie de la syntaxe SQL. Ainsi, il est primordial de supporter tous le standard SQL. Implémenter la réplication partielle : l une des techniques présentée dans cette thèse, est la réplication partielle, qui est une hybridation entre la réplication et le partitionnement. De ce fait, il serait intéressant de l implémenter. Utilisation des histogrammes : avec le partitionnement virtuel, le calcul des intervalles est très simpliste, aboutissant souvent à des fragments déséquilibrés. Une approche judicieuse consiste à exploiter les histogrammes mis à jour par les SGBDs, lors du calcul des intervalles. Pousser la technique de partitionnement virtuel : dans l état actuel, le partitionnement virtuel s appuie sur la fragmentation de la plus grande table référencée, sur un attribut de type numérique (attribut de partitionnement). Cela peut être étendu par la fragmentation de plusieurs tables et sur des attributs de n importe quel type. En outre, les clauses de condition peuvent être incorporées dans le calcul des intervalles En fin, on peut affirmer que la réplication est une technique prometteuse, qui peut allier efficacement la haute disponibilité à la haute performance. Accorder plus d intérêt au parallélisme dans les bases de données répliquées, va favoriser la conception de nouvelles techniques et stratégies, qui mènent à l implémentation du SGBDs plus robustes, garantissant : la haute disponibilité des données, l optimisation des temps d exécution des requêtes, l augmentation de débit global du système, la tolérance aux pannes et l atteinte de la haute performance. 116

128 Annexe A : PostgreSQL : Introduction PostgreSQL est un système de gestion de bases de données relationnel Object (SGBDR). A l origine, PostgreSQL est un projet de recherche initié à l'université de Californie au département des sciences informatiques de Berkeley [PGD 11]. Au cours des deux dernières décennies, le produit a connu une évolution fulgurante pour être le meilleure SGPD open source, qui est souvent considéré comme équivalent à ses concurrents commerciaux (Oracle, SQLServer, DB2). PostgreSQL est un SGBD fiable et complet. Il implémente la majeure partie du standard SQL, en plus d une large panoplie de fonctionnalités modernes : requêtes imbriquées, clés étrangères, triggers, vues simples et matérialisées, intégrité transactionnelle, contrôle des versions concurrentes (MVCC ou multiversion concurrency control). Actuellement PostgreSQL est incorporé dans des applications d une grande envergure, ceci témoigne sa robustesse et sa fiabilité. Ses performances sont très bonnes, avec des améliorations considérables au fil des versions. En outre, PostgreSQL offre le maximum de portabilité du moment qu il est supporté par la quasi-totalité des systèmes d exploitation, notamment les compatibles UNIX (Ubantu, RedHat, FreeBSD, Solaris, ), Mac OS et la famille Microsoft (Windows Server 2003/2008/2008R2, XP, Vista, Windows7). Historique : Au cours des trois dernières décennies, le projet POSTGRES est passé d un modeste projet universitaire entretenu par une petite équipe, à un système de gestion de base de donnés complet, utilisé par des milliers, voire des millions d utilisateurs. Cette section retrace son évolution : Le projet POSTGRES à Berkeley En 1986, à l université de Berkeley, le professeur Michael Stonebraker lance officiellement un projet ambitieux de réalisation d un prototype de SGBD, qu il baptisé POSTGRES. L architecture générale du système était détaillée dans [STON 86], ou les concepts de base ont été introduits. L année prochaine a connu la publication de plusieurs compléments de consolidation, qui traitent les différentes composantes de POSGRES : la définition du modèle de données initial [ROW 87], le système de règles [STO 87] et l architecture du gestionnaire de stockage dans [STO 87]. Dès lors, plusieurs versions majeures de POSTGRES se sont succédé. La première version opérationnelle est rendu disponible en Elle a été présentée en 1988 lors de la conférence ACM-SIGMOD. En 1989, POSTGRES quitte les couloirs de Berkeley pour être livré à quelques utlisateurs externes dans sa première version officielle. Le feedback recueilli a permis d apporter plusieurs améliorations notamment sur le mécanisme de règles, le gestionnaire de stockage, l exécuteur de requête et l optimiseur, donnant issue à deux versions successives : version2 et version3. Jusqu'à Postgres95, les versions, qui sont apparues, se sont focalisées sur l aspect portabilité et fiabilité. La réussite de POSTGRES a mené à son utilisation dans nombreux projet du caractère scientifique comme commercial. En effet, POSTGRES a été intégré avec succès dans : 117

129 Des systèmes d'analyse de données financières Des bases de données de suivi d'astéroïdes Des bases de données médicales Plusieurs systèmes d'informations géographiques Au cours de l'année 1993 POSTGRES a connu une augmentation importante de nombre des utilisateurs. De manière évidente, la maintenance du prototype et le support prenaient un temps considérable. Dans un souci de réduction du travail de support, le projet POSTGRES de Berkeley a été clôturé officiellement avec la version 4.2. Postgres95 [KHE 10] : En 1994, Andrew Yu et Jolly Chen ajoutèrent un interpréteur de langage SQL à POSTGRES. Sous le nouveau nom de Postgres95, le projet fut publié sur le Web comme descendant libre (OpenSource) du code source initial de POSTGRES, version Berkeley. Le code de Postgres95 était écrit en pur C ANSI. Il avait connu Des améliorations et devenait plus performant et maintenable. Les principales améliorations furent les suivantes [PGD 08] : Le langage PostQUEL est remplacé par SQL, les requêtes imbriquées pouvaient être Imitées dans Postgres95 à l'aide de fonctions SQL utilisateur, les agrégats sont reprogrammés, la clause GROUP BY ajoutée. Un nouveau programme, psql, qui utilise GNU Readline, permet l'exécution interactive de requêtes SQL. Ainsi qu une nouvelle bibliothèque cliente, libpgtcl, supporte les programmes écrits en Tcl et un shell exemple, pgtclsh, fournit de nouvelles commandes Tcl pour interfacer des programmes Tcl avec Postgres95. L interface de gestion des «Large Objects» est réécrite ; jusque-là, le seul mécanisme de stockage de ces objets passait par le système de fichier Inversion («Inversion file system») ; ce système est abandonné. La version GNU de make est utilisée pour la construction. Postgres95 peut également être compilé avec un GCC sans correctif (l'alignement des doubles est corrigé). PostgreSQL [KHE 10] : En 1996, le nom «Postgres95» commence à mal vieillir. Le nom choisi, PostgreSQL, souligne le lien entre POSTGRES et les versions suivantes qui intègrent le SQL. En parallèle, la version est numérotée 6.0 pour reprendre la numérotation du projet POSTGRES de Berkeley. [PGD 08] Beaucoup de personnes font référence à PostgreSQL par «Postgres» (il est rare que le nom soit écrit en capitales) par tradition ou parce que c'est plus simple à prononcer. Cet usage est accepté comme alias ou pseudo. PostgreSQL est renforcé par les éléments suivants [PGD 11] : Contrôle de concurrence multi version, qui permet à des lecteurs de continuer la lecture de données consistantes pendant l'activité d'écriture et permet de faire des sauvegardes tandis que la base de données reste disponibles pour des requêtes. Implémentation de nouveaux outils tels que les contraintes, les triggers... ainsi que le langage SQL-92 qui contient les clés primaires, le forçage de type (cast) et l entrée des entiers binaires et hexadécimaux. Amélioration de type de données (large intervalle de type date time, des types géométriques additionnels) et la performance de traitement et d exécution des requêtes. 118

130 Avec PostgreSQL l enjeu devient le développement des nouvelles fonctionnalités contrairement au Postgres95 où l'identification et la compréhension des problèmes dans le code était le but de développeurs. Architecture [NEK 10] : PostgreSQL adopte un modèle client/serveur, offrant un bénéfice énorme pour les développeurs. Une session PostgreSQL se compose de différents programmes coopérant dont : Le processus serveur, appelé postmaster, qui gère les fichiers de la base de données, accepte les connections à la base de données des applications clientes, et qui exécute les requêtes sur la base pour les clients. Il est exécuté en permanence, en attente de nouvelles connections. L'application d'utilisateur client qui veut procéder à des opérations sur la base de données. Ces applications clientes peuvent être très diverses : outil texte, application graphique, serveur Web qui utilise une base de données pour stocker des informations etc. Il s'agit d'une application serveur/client typique, le client et le serveur peuvent être sur des postes différentiels. Dans ce cas, ils se servent de connections TCP/IP, utilisant un réseau local LAN ou via un réseau étendu comme Internet (voir figure suivant). Un serveur PostgreSQL peut supporter de multiples connections, pour cela il lance de nouveaux processus ("forks") à chaque connexion. Ainsi, le client d'un nouveau processus peut communiquer avec la base de données sans l'intervention du processus postmaster original (Figure 25 : Architecture du SGBD PostgreSQL). A l'instar des SGBD commerciaux, PostgreSQL ne fournit pas directement des mécanismes de haute disponibilité et de répartition de la charge, mais peut être combiné avec certaines solutions afin de fournir ces avantages. Pour plus de détails sur ces solutions, le lecteur pourra se référer à [PGD 11]. Caractéristiques : PostgreSQL s'appuie sur le modèle relationnel mais apporte les extensions suivantes : les classes, l'héritage, les types de données utilisateurs (tableaux, structures, listes..), les fonctions, Cela permet de qualifier PostgreSQL de système de gestion de base de données relationnel-objet (SGBDOR). PostgreSQL offre de nombreuses fonctionnalités modernes [PGD 11] : La possibilité d imposer des contraintes à l insertion des données Les requêtes complexes Les clés étrangères La gestion des événements (déclencheurs ou triggers) Les contraintes d intégrités (garantie d intégrité des données) Création des vues L'héritage des tables et des types de données Les procédures stockées (programmation coté serveur) Les transactions (plusieurs étapes en une seule opération) et leur intégrité 119

131 Contrôle des accès concurrents (MVCC ou MultiVersion Concurrency Control). De plus, PostgreSQL est extensible par l'utilisateur de plusieurs façons [PGDG10]. En ajoutant, par exemple, de nouveaux : Types de données, Fonctions, Opérateurs, Fonctions d'agrégat, Méthodes d'indexage, Langages de procédure. 120

132 Annexe B : Requêtes TCPH benchmark : TCPH benchmark est composé des 22 requêtes suivantes [TCP 2011]: Requête 1 : SELECT l_returnflag,l_linestatus,sum(l_quantity) as sum_qty, sum(l_extendedprice) as sum_base_price, sum(l_extendedprice * (1 l_discount)) as sum_disc_price, sum(l_extendedprice * (1 - l_discount) * (1 + l_tax)) as sum_charge, avg(l_quantity) as avg_qty, avg(l_extendedprice) as avg_price, avg(l_discount) as avg_disc, count(*) as count_order FROM lineitem WHERE l_shipdate <= date ' ' - interval ':1' day (3) GROUP BY l_returnflag, l_linestatus ORDER BY l_returnflag, l_linestatus; Requête 2 : SELECT s_acctbal, s_name, n_name, p_partkey, p_mfgr, s_address, s_phone, s_comment FROM part, supplier, partsupp, nation, region WHERE p_partkey = ps_partkey and s_suppkey = ps_suppkey and p_size = :1 and p_type like '%:2' and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = ':3' and ps_supplycost = ( SELECT min(ps_supplycost) FROM partsupp, supplier, nation, region WHERE p_partkey = ps_partkey and s_suppkey = ps_suppkey and s_nationkey = n_nationkey and n_regionkey = r_regionkeyand r_name = ':3' ) ORDER BY s_acctbal desc, n_name, s_name, p_partkey; Requête 3 : SELECT l_orderkey, sum(l_extendedprice * (1 - l_discount)) as revenue, o_orderdate, o_shippriority FROM customer, orders, lineitem WHERE c_mktsegment = ':1' and c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate < date ':2' and l_shipdate > date ':2' GROUP BY l_orderkey, o_orderdate, o_shippriority ORDER BY revenue desc, o_orderdate; Requête 4 : SELECT o_orderpriority, count(*) as order_count FROM orders WHERE o_orderdate >= date ':1' and o_orderdate < date ':1' + interval '3' month and exists (SELECT * FROM lineitem WHERE l_orderkey = o_orderkey and l_commitdate < l_receiptdate) GROUP BY o_orderpriority ORDER BY o_orderpriority; 121

133 Requête 5: SELECT n_name, sum(l_extendedprice * (1 - l_discount)) as revenue FROM customer, orders, lineitem, supplier, nation, region WHERE c_custkey = o_custkey and l_orderkey = o_orderkey and l_suppkey = s_suppkey and c_nationkey = s_nationkey and s_nationkey = n_nationkey and n_regionkey = r_regionkey and r_name = ':1' and o_orderdate >= date ':2' and o_orderdate < date ':2' + interval '1' year GROUP BY n_name ORDER BY revenue desc; Requête 6 : SELECT sum(l_extendedprice * l_discount) as revenue FROM lineitem WHERE l_shipdate >= date ':1' and l_shipdate < date ':1' + interval '1' year and l_discount between : and : and l_quantity < :3; Requête 7 : SELECT supp_nation, cust_nation, l_year, sum(volume) as revenue FROM ( SELECT n1.n_name as supp_nation, n2.n_name as cust_nation, extract(year FROM l_shipdate) as l_year, l_extendedprice * (1 l_discount) as volume FROM supplier, lineitem, orders, customer, nation n1, nation n2 s_suppkey = l_suppkey and o_orderkey = l_orderkey and c_custkey = o_custkey and s_nationkey = n1.n_nationkey and c_nationkey = n2.n_nationkey and ( (n1.n_name = ':1' and n2.n_name = ':2') or (n1.n_name = ':2' and n2.n_name = ':1'))and l_shipdate between date ' ' and date ' ' ) as shipping GROUP BY supp_nation, cust_nation, l_year ORDER BY supp_nation, cust_nation, l_year; Requête 8: SELECT o_year, sum(case when nation = ':1' then volume else 0 end) / sum(volume) as mkt_share FROM ( SELECT extract(year FROM o_orderdate) as o_year, l_extendedprice * (1 - l_discount) as volume, n2.n_name as nation FROM part, supplier, lineitem, orders, customer, nation n1, nation n2, region WHERE p_partkey = l_partkey and s_suppkey = l_suppkey and l_orderkey = o_orderkey and o_custkey = c_custkey and c_nationkey = n1.n_nationkey and n1.n_regionkey = r_regionkey and r_name = ':2' and s_nationkey = n2.n_nationkey and o_orderdate between date ' ' and date ' ' and p_type = ':3' ) as all_nations GROUP BY o_year ORDER BY o_year; 122

134 Requête 9 : SELECT nation, o_year, sum(amount) as sum_profit FROM ( SELECT n_name as nation, extract(year FROM o_orderdate) as o_year, l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount FROM part, supplier, lineitem, partsupp, orders, nation WHERE s_suppkey = l_suppkey and ps_suppkey = l_suppkey and ps_partkey = l_partkey and p_partkey = l_partkey and o_orderkey = l_orderkey and s_nationkey = n_nationkey and p_name like '%:1%' ) as profit GROUP BY nation, o_year ORDER BY nation, o_year desc; Requête 10: SELECT c_custkey, c_name, sum(l_extendedprice * (1 - l_discount)) as revenue, c_acctbal, n_name, c_address, c_phone, c_comment FROM customer, orders, lineitem, nation WHERE c_custkey = o_custkey and l_orderkey = o_orderkey and o_orderdate >= date ':1' and o_orderdate < date ':1' + interval '3' month and l_returnflag = 'R' and c_nationkey = n_nationkey GROUP BY c_custkey, c_name, c_acctbal, c_phone, n_name, c_address, c_comment ORDER BY revenue desc; Requête 11 : SELECT ps_partkey, sum(ps_supplycost * ps_availqty) as value FROM partsupp, supplier, nation WHERE ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = ':1' GROUP BY ps_partkey having sum(ps_supplycost * ps_availqty) > ( SELECT sum(ps_supplycost * ps_availqty) * :2 FROM partsupp, supplier, nation WHERE ps_suppkey = s_suppkey and s_nationkey = n_nationkey and n_name = ':1' ) ORDER BY value desc; 123

135 Requête 12 : SELECT l_shipmode, sum(case when o_orderpriority = '1-URGENT' or o_orderpriority = '2-HIGH' then 1 else 0 end) as high_line_count, sum(case when o_orderpriority <> '1-URGENT' and o_orderpriority <> '2-HIGH' then 1 else 0 end) as low_line_count FROM orders, lineitem WHERE o_orderkey = l_orderkey and l_shipmode in (':1', ':2') and l_commitdate < l_receiptdate and l_shipdate < l_commitdate and l_receiptdate >= date ':3' and l_receiptdate < date ':3' + interval '1' year GROUP BY l_shipmode ORDER BY l_shipmode; Requête 13 : SELECT c_count, count(*) as custdist FROM ( SELECT c_custkey, count(o_orderkey) FROM customer left outer join orders on c_custkey = o_custkey and o_comment not like '%:1%:2%' GROUP BY c_custkey ) as c_orders (c_custkey, c_count) GROUP BY c_count ORDER BY custdist desc, c_count desc; Requête 14: SELECT * sum(case when p_type like 'PROMO%' then l_extendedprice * (1 - l_discount) else 0 end) / sum(l_extendedprice * (1 - l_discount)) as promo_revenue FROM lineitem, part WHERE l_partkey = p_partkey and l_shipdate >= date ':1' and l_shipdate < date ':1' + interval '1' month; Requête 15 : create view revenue:s (supplier_no, total_revenue) as SELECT l_suppkey, sum(l_extendedprice * (1 - l_discount)) FROM lineitem WHERE l_shipdate >= date ':1' and l_shipdate < date ':1' + interval '3' month GROUP BY l_suppkey; SELECT s_suppkey, s_name, s_address, s_phone, total_revenue FROM supplier, revenue:s WHERE s_suppkey = supplier_no and total_revenue = (SELECT max(total_revenue) FROM revenue:s) ORDER BY s_suppkey; drop view revenue:s; 124

136 Requête 16 : SELECT p_brand, p_type, p_size, count(distinct ps_suppkey) as supplier_cnt FROM partsupp, part WHERE p_partkey = ps_partkey and p_brand <> ':1' and p_type not like ':2%' and p_size in (:3, :4, :5, :6, :7, :8, :9, :10) and ps_suppkey not in ( SELECT s_suppkey FROM supplier WHERE s_comment like '%Customer%Complaints%' ) GROUP BY p_brand, p_type, p_size ORDER BY supplier_cnt desc, p_brand, p_type, p_size; Requête 17 : SELECT sum(l_extendedprice) / 7.0 as avg_yearly FROM lineitem, part WHERE p_partkey = l_partkey and p_brand = ':1' and p_container = ':2' and l_quantity < ( SELECT 0.2 * avg(l_quantity) FROM lineitem WHERE l_partkey = p_partkey ); Requête 18: SELECT c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice,sum(l_quantity) FROM customer, orders, lineitem WHERE o_orderkey in ( SELECT l_orderkey FROM lineitem GROUP BY l_orderkey having sum(l_quantity) > :1 ) and c_custkey = o_custkey and o_orderkey = l_orderkey GROUP BY c_name, c_custkey, o_orderkey, o_orderdate, o_totalprice ORDER BY o_totalprice, o_orderdate; Requête 19: SELECT sum(l_extendedprice* (1 - l_discount)) as revenue FROM lineitem, part WHERE (p_partkey = l_partkey and p_brand = ':1' and p_container in ('SM CASE', 'SM BOX', 'SM PACK', 'SM PKG') and l_quantity >= :4 and l_quantity <= : and p_size between 1 and 5 and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON') or ( p_partkey = l_partkey and p_brand = ':2' and p_container in ('MED BAG', 'MED BOX', 'MED PKG', 'MED PACK') and l_quantity >= :5 and l_quantity <= : and p_size between 1 and 10 and l_shipmode in ('AIR', 'AIR REG') and l_shipinstruct = 'DELIVER IN PERSON')or ( p_partkey = l_partkey and p_brand = ':3' and p_container in ('LG CASE', 'LG BOX', 'LG PACK', 'LG PKG') and l_quantity >= :6 and l_quantity <= : and p_size between 1 and 15 and l_shipmode in ('AIR', 'AIR REG')and l_shipinstruct = 'DELIVER IN PERSON'); 125

137 Requête 20 : SELECT s_name, s_address FROM supplier, nation WHERE s_suppkey in ( SELECT ps_suppkey FROM partsupp WHERE ps_partkey in ( SELECT p_partkey FROM part WHERE p_name like '[COLOR]%') and ps_availqty > (SELECT 0.5 * sum(l_quantity) FROM lineitem WHERE l_partkey = ps_partkey and l_suppkey = ps_suppkey and l_shipdate >= date('[date] ) and l_shipdate < date('[date] ) + interval 1 year ) ) and s_nationkey = n_nationkey and n_name = '[NATION]' ORDER BY s_name; Requête 21 : SELECT s_name, count(*) as numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.l_suppkey and o_orderkey = l1.l_orderkey and o_orderstatus = 'F' and l1.l_receiptdate > l1.l_commitdate and exists ( SELECT * FROM lineitem l2 WHERE l2.l_orderkey = l1.l_orderkey and l2.l_suppkey <> l1.l_suppkey ) and not exists ( SELECT * FROM lineitem l3 WHERE l3.l_orderkey = l1.l_orderkey and l3.l_suppkey <> l1.l_suppkey and l3.l_receiptdate > l3.l_commitdate ) and s_nationkey = n_nationkey and n_name = ':1' GROUP BY s_name ORDER BY numwait desc, s_name; 126

138 Requête 22 : SELECT cntrycode, count(*) as numcust, sum(c_acctbal) as totacctbal FROM( SELECT substring(c_phone FROM 1 for 2) as cntrycode, c_acctbal FROM customer WHERE substring(c_phone FROM 1 for 2) in (':1', ':2', ':3', ':4', ':5', ':6', ':7') and c_acctbal > ( SELECT avg(c_acctbal) FROM customer WHERE c_acctbal > 0.00 and substring(c_phone FROM 1 for 2) in (':1', ':2', ':3', ':4', ':5', ':6', ':7')) and not exists ( SELECT * FROM orders WHERE o_custkey = c_custkey) ) as custsale GROUP BY cntrycode ORDER BY cntrycode; 127

139 Annexe C : Configuration de Slony-I avec pgadmin[apg 11]: Préambule : Les objets de Slony-I sont intégrés dans le navigateur de pgadmin, permettant d'avoir une seule interface pour gérer les objets de la base et pour administrer la réplication. L'onglet de statistiques pour la collection de nœuds ainsi que pour les nœuds individuels montre le statut de la queue des événements de réplication, et permet la surveillance du bon fonctionnement de Slony. Comme exemple, la situation montrée ci-dessus affiche le statut d'un nœud sans réponse pendant une heure, avec 381 événements en attente de réplication. 128

140 Pré requis : Comme pré requis de l'exécution de Slony-I sur PostgreSQL, les modules Slony-I xxid et slony1_funcs doivent être présents sur tous les serveurs correspondant à un nœud de réplication Slony-I. Cela se fait habituellement par la routine d'installation de Slony-I. Configurer Slony-I la première fois est un gros travail. Les sections suivantes vous guident dans la création de votre premier cluster de réplication. Étape 1 : Créer le cluster sur le nœud maître. Étape 2 : Ajouter les nœuds esclaves au cluster. Étape 3 : Configurer les chemins de chaque nœud vers tous les autres nœuds. Étape 4 : Configurer les écoutes de chaque nœud vers tous les autres nœuds (Note : cela n'est pas requis avec Slony-I v1.1 ainsi que les versions ultérieures). Étape 5 : Créer un ensemble de réplication. Étape 6 : Ajouter les tables et séquences à l'ensemble. Étape 7 : Abonner les esclaves à l'ensemble. Note : à ce moment, les démons slon (services sous Windows) doivent être démarrés. Créer le cluster et le premier nœud 129

141 Pour installer un cluster Slony-I sur la première base de données, la fenêtre «Ajouter un cluster Slony-I» est utilisée. Il exécute les scripts SQL officiels de création de cluster Slony-I, qui sont situés dans le répertoire configuré dans la fenêtre des options. pgadmin a besoin de stocker des informations sur comment contacter chaque nœud individuel dans le cluster. Pour cela, pgadmin utilise le concept de «Nœuds administratifs». Joindre des nœuds supplémentaires au cluster Après la création réussie du premier nœud dans le cluster de réplication Slony-I, tous les nœuds suivants prennent leur configuration et les procédures des premiers nœuds. Ce processus est appelé «Joindre un cluster» dans pgadmin. Habituellement, vous devez aussi sélectionner un nœud existant au nœud d'administration pour vous assurer son accès plus tard dans pgadmin. Après avoir ajouté un nouveau nœud au cluster Slony-I, vous avez besoin de configurer les chemins de réplication entre les nœuds pour activer la communication entre eux. Mise à jour d'un nœud avec le nouveau logiciel 130

142 Quand un cluster doit être mis à jour avec une nouvelle version du logiciel Slony-I, le processus de mise à jour doit être exécuté sur tous les nœuds du cluster. Pour chaque nœud, le démon slon a besoin d'être arrêté, puis la fenêtre de mise à jour est lancé et un nœud avec le nouveau logiciel est sélectionné (pgadmin extraira tous les logiciels de ce nœud), enfin le démon slon est redémarré. Actuellement, pgadmin ne supporte pas la mise à jour à partir des scripts de création Slony-I. À la place, créez un cluster intermédiaire à partir des scripts de création, utilisez-le comme source pour la fenêtre de mise à jour et supprimez le cluster après usage. Vous pouvez aussi utiliser l'outil slonik pour mettre à jour le premier nœud, puis utiliser ce dernier comme source pour les mises à jour des autres nœuds. Créer des chemins vers d'autres nœuds Slony-I a besoin d'informations sur le chemin pour définir comment un processus slon peut communiquer avec d'autres nœuds. La chaîne de connexion (conninfo) est décrite dans la documentation sur la connection avec libpq. Habituellement, vous aurez besoin de spécifier le nom de l'hôte, le nom de la base de données et celui de l'utilisateur. Le mot de passe doit être stocké dans le fichier.pgpass. 131

143 Vous pouvez créer un chemin vers tous les autres nœuds, sur chaque nœud. Par exemple, dans un cluster à deux nœuds, vous avez besoin de créer un chemin vers l'esclave sur le maître et un vers le maître sur l'esclave. Créer des écoutes vers d'autres nœuds Après la définition du chemin de communication, les processus slon ont besoin d'être avertis pour écouter les événements provenant des autres nœuds. Note : cette étape n'est pas nécessaire pour Slony-I v1.1 et les versions ultérieures car l'information listen est générée automatiquement quand les chemins sont définis. Créer des ensembles de réplication Slony-I groupe les tables et les séquences qu'il doit répliquer d'un maître vers des esclaves dans des ensembles de réplication. L'ensemble est créé sur le nœud source des données. 132

144 Définir une table à répliquer Si la table source a des triggers, ils doivent être désactivés sur les nœuds cibles de la réplication. Mais dans les environnements de réplication, les rôles maître et esclave pourraient être échangés, donc il est nécessaire de les activer et les désactiver dans ces situations. La page 'Trigger' permet la sélection des triggers que Slony-I doit activer/désactiver si nécessaire. Attention : si une table que vous voulez répliquer n'apparaît pas dans la liste déroulante des tables, cela signifie habituellement que la table n'a pas d'index unique. Slony-I réclame que chaque ligne des tables qui doivent être répliquées soit identifiable de façon unique. Habituellement, cela se fait avec une clé primaire mais dans le cas de la réplication, une clé unique suffit. Bien que Slony-I a une fonction d'aide pour définier des clés uniques intermédiaires, ceci n'est pas supporté pour les tables ajoutées dans des ensembles de réplication avec pgadmin III. Nous recommendons fortement de définir une clé primaire sur les tables à répliquer. Définir une séquence à répliquer La séquence permet l'ajout de séquences dans un ensemble de réplication. 133

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation Base de données S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Présentation du module Contenu général Notion de bases de données Fondements / Conception Utilisation :

Plus en détail

Présentation du module Base de données spatio-temporelles

Présentation du module Base de données spatio-temporelles Présentation du module Base de données spatio-temporelles S. Lèbre slebre@unistra.fr Université de Strasbourg, département d informatique. Partie 1 : Notion de bases de données (12,5h ) Enjeux et principes

Plus en détail

Cours Bases de données

Cours Bases de données Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles

Plus en détail

Programmation parallèle et distribuée

Programmation parallèle et distribuée Programmation parallèle et distribuée (GIF-4104/7104) 5a - (hiver 2015) Marc Parizeau, Département de génie électrique et de génie informatique Plan Données massives («big data») Architecture Hadoop distribution

Plus en détail

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec.

3A-IIC - Parallélisme & Grid GRID : Définitions. GRID : Définitions. Stéphane Vialle. Stephane.Vialle@supelec.fr http://www.metz.supelec. 3A-IIC - Parallélisme & Grid Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Principes et Objectifs Evolution Leçons du passé Composition d une Grille Exemple d utilisation

Plus en détail

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer

BD réparties. Bases de Données Réparties. SGBD réparti. Paramètres à considérer Bases de Données Réparties Définition Architectures Outils d interface SGBD Réplication SGBD répartis hétérogènes BD réparties Principe : BD locales, accès locaux rapides accès aux autres SGBD du réseau

Plus en détail

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales Ecole des Hautes Etudes Commerciales HEC Alger Évolution des SGBDs par Amina GACEM Module Informatique 1ière Année Master Sciences Commerciales Evolution des SGBDs Pour toute remarque, question, commentaire

Plus en détail

Forthcoming Database

Forthcoming Database DISS.ETH NO. 15802 Forthcoming Database A Framework Approach for Data Visualization Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH for the degree of Doctor of

Plus en détail

Module BDR Master d Informatique (SAR)

Module BDR Master d Informatique (SAR) Module BDR Master d Informatique (SAR) Cours 6- Bases de données réparties Anne Doucet Anne.Doucet@lip6.fr 1 Bases de Données Réparties Définition Conception Décomposition Fragmentation horizontale et

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBLITÉ CONTINUE ET MOBILITÉ DES DONNÉES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN

PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN PROGRAMME DU CONCOURS DE RÉDACTEUR INFORMATICIEN 1. DÉVELOPPEMENT D'APPLICATION (CONCEPTEUR ANALYSTE) 1.1 ARCHITECTURE MATÉRIELLE DU SYSTÈME INFORMATIQUE 1.1.1 Architecture d'un ordinateur Processeur,

Plus en détail

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters

FAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBILITE CONTINUE ET MOBILITE DES DONNEES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue

Plus en détail

agility made possible

agility made possible DOSSIER SOLUTION CA VM:Manager Suite for Linux on System Z Comment réduire le coût et la complexité de la gestion et de la sécurisation des environnements z/vm et Linux on System z? agility made possible

Plus en détail

Programmation parallèle et distribuée

Programmation parallèle et distribuée Programmation parallèle et distribuée (GIF-4104/7104) 5a - (hiver 2014) Marc Parizeau, Département de génie électrique et de génie informatique Plan Mégadonnées («big data») Architecture Hadoop distribution

Plus en détail

Chapitre 1 : Introduction aux bases de données

Chapitre 1 : Introduction aux bases de données Chapitre 1 : Introduction aux bases de données Les Bases de Données occupent aujourd'hui une place de plus en plus importante dans les systèmes informatiques. Les Systèmes de Gestion de Bases de Données

Plus en détail

Bases de données Cours 1 : Généralités sur les bases de données

Bases de données Cours 1 : Généralités sur les bases de données Cours 1 : Généralités sur les bases de données POLYTECH Université d Aix-Marseille odile.papini@univ-amu.fr http://odile.papini.perso.esil.univmed.fr/sources/bd.html Plan du cours 1 1 Qu est ce qu une

Plus en détail

Technologie de déduplication de Barracuda Backup. Livre blanc

Technologie de déduplication de Barracuda Backup. Livre blanc Technologie de déduplication de Barracuda Backup Livre blanc Résumé Les technologies de protection des données jouent un rôle essentiel au sein des entreprises et ce, quelle que soit leur taille. Toutefois,

Plus en détail

C-JDBC. Emmanuel Cecchet INRIA, Projet Sardes. http://sardes.inrialpes.fr

C-JDBC. Emmanuel Cecchet INRIA, Projet Sardes. http://sardes.inrialpes.fr Emmanuel Cecchet INRIA, Projet Sardes http://sardes.inrialpes.fr Plan Motivations Idées principales Concepts Caching Perspectives /ObjectWeb 15 octobre 2002 Emmanuel.Cecchet@inrialpes.fr 2 - Motivations

Plus en détail

INTRODUCTION AUX BASES de DONNEES

INTRODUCTION AUX BASES de DONNEES INTRODUCTION AUX BASES de DONNEES Équipe Bases de Données LRI-Université Paris XI, Orsay Université Paris Sud Année 2003 2004 1 SGBD : Fonctionnalités et Principes Qu est qu une base de données? Un Système

Plus en détail

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Cours Base de données relationnelles. M. Boughanem, IUP STRI Cours Base de données relationnelles 1 Plan 1. Notions de base 2. Modèle relationnel 3. SQL 2 Notions de base (1) Définition intuitive : une base de données est un ensemble d informations, (fichiers),

Plus en détail

Introduction aux bases de données

Introduction aux bases de données Introduction aux bases de données Références bibliographiques Jeff Ullman,Jennifer Widom, «A First Course in Database systems», Prentice-Hall, 3rd Edition, 2008 Hector Garcia-Molina, Jeff Ullman, Jennifer

Plus en détail

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par.

THÈSE. présentée à TÉLÉCOM PARISTECH. pour obtenir le grade de. DOCTEUR de TÉLÉCOM PARISTECH. Mention Informatique et Réseaux. par. École Doctorale d Informatique, Télécommunications et Électronique de Paris THÈSE présentée à TÉLÉCOM PARISTECH pour obtenir le grade de DOCTEUR de TÉLÉCOM PARISTECH Mention Informatique et Réseaux par

Plus en détail

Structure fonctionnelle d un SGBD

Structure fonctionnelle d un SGBD Fichiers et Disques Structure fonctionnelle d un SGBD Requetes Optimiseur de requetes Operateurs relationnels Methodes d acces Gestion de tampon Gestion de disque BD 1 Fichiers et Disques Lecture : Transfert

Plus en détail

Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS

Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS Sauvegarde collaborative entre pairs 1 Sauvegarde collaborative entre pairs Ludovic Courtès LAAS-CNRS Sauvegarde collaborative entre pairs 2 Introduction Pourquoi pair à pair? Utilisation de ressources

Plus en détail

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE

INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE I N T E RS Y S T E M S INTERSYSTEMS CACHÉ COMME ALTERNATIVE AUX BASES DE DONNÉES RÉSIDENTES EN MÉMOIRE David Kaaret InterSystems Corporation INTERSySTEMS CAChé CoMME ALTERNATIvE AUx BASES de données RéSIdENTES

Plus en détail

Systèmes d informations nouvelles générations. Répartition, Parallèlisation, hétérogénéité dans les SGBD. Exemple d application d un futur proche

Systèmes d informations nouvelles générations. Répartition, Parallèlisation, hétérogénéité dans les SGBD. Exemple d application d un futur proche Répartition, Parallèlisation, hétérogénéité dans les SGBD AI Mouaddib Département Informatique Université de Caen Systèmes d informations nouvelles générations! Constat :! Utilisation de nouveaux support

Plus en détail

Métriques de performance pour les algorithmes et programmes parallèles

Métriques de performance pour les algorithmes et programmes parallèles Métriques de performance pour les algorithmes et programmes parallèles 11 18 nov. 2002 Cette section est basée tout d abord sur la référence suivante (manuel suggéré mais non obligatoire) : R. Miller and

Plus en détail

Pascale Borla-Salamet Consultante Avant Vente Oracle France. Oracle Exadata Performance et Optimisation de votre Datawarehouse

Pascale Borla-Salamet Consultante Avant Vente Oracle France. Oracle Exadata Performance et Optimisation de votre Datawarehouse Pascale Borla-Salamet Consultante Avant Vente Oracle France Oracle Exadata Performance et Optimisation de votre Datawarehouse Agenda Les nouveaux challenges Exadata Storage Server Oracle Database Machine

Plus en détail

Introduction aux bases de données Cours 1 : Généralités sur les bases de données

Introduction aux bases de données Cours 1 : Généralités sur les bases de données Cours 1 : Généralités sur les bases de données ESIL Université de la méditerranée Odile.Papini@esil.univmed.fr http://odile.papini.perso.esil.univmed.fr/sources/bdmat.html Plan du cours 1 1 Qu est ce qu

Plus en détail

Initiation au HPC - Généralités

Initiation au HPC - Généralités Initiation au HPC - Généralités Éric Ramat et Julien Dehos Université du Littoral Côte d Opale M2 Informatique 2 septembre 2015 Éric Ramat et Julien Dehos Initiation au HPC - Généralités 1/49 Plan du cours

Plus en détail

Du 10 Fév. au 14 Mars 2014

Du 10 Fév. au 14 Mars 2014 Interconnexion des Sites - Design et Implémentation des Réseaux informatiques - Sécurité et Audit des systèmes - IT CATALOGUE DE FORMATION SIS 2014 1 FORMATION ORACLE 10G 11G 10 FEV 2014 DOUALA CAMEROUN

Plus en détail

Sécuristation du Cloud

Sécuristation du Cloud Schémas de recherche sur données chiffrées avancés Laboratoire de Cryptologie Thales Communications & Security 9 Avril 215 9/4/215 1 / 75 Contexte Introduction Contexte Objectif Applications Aujourd hui

Plus en détail

Système de stockage IBM XIV Storage System Description technique

Système de stockage IBM XIV Storage System Description technique Système de stockage IBM XIV Storage System Description technique Système de stockage IBM XIV Storage System Le stockage réinventé Performance Le système IBM XIV Storage System constitue une solution de

Plus en détail

Garantir une meilleure prestation de services et une expérience utilisateur optimale

Garantir une meilleure prestation de services et une expérience utilisateur optimale LIVRE BLANC Garantir une meilleure prestation de services et une expérience utilisateur optimale Mai 2010 Garantir une meilleure prestation de services et une expérience utilisateur optimale CA Service

Plus en détail

INF6500 : Structures des ordinateurs. Sylvain Martel - INF6500 1

INF6500 : Structures des ordinateurs. Sylvain Martel - INF6500 1 INF6500 : Structures des ordinateurs Sylvain Martel - INF6500 1 Cours 4 : Multiprocesseurs Sylvain Martel - INF6500 2 Multiprocesseurs Type SISD SIMD MIMD Communication Shared memory Message-passing Groupe

Plus en détail

Cours n 12. Technologies WAN 2nd partie

Cours n 12. Technologies WAN 2nd partie Cours n 12 Technologies WAN 2nd partie 1 Sommaire Aperçu des technologies WAN Technologies WAN Conception d un WAN 2 Lignes Louées Lorsque des connexions dédiées permanentes sont nécessaires, des lignes

Plus en détail

Prestations de conseil en SRM (Storage Ressource Management)

Prestations de conseil en SRM (Storage Ressource Management) Prestations de conseil en SRM (Storage Ressource Management) Sommaire 1 BUTS DE LA PRESTATION 2 PRESENTATION DE LA PRESTATION 3 3 3 ETAPE 1 : ELEMENTS TECHNIQUES SUR LESQUELS S APPUIE LA PRESTATION DE

Plus en détail

Bases de données réparties: Fragmentation et allocation

Bases de données réparties: Fragmentation et allocation Pourquoi une base de données distribuée? Bibliographie Patrick Valduriez, S. Ceri, Guiseppe Delagatti Bases de données réparties: Fragmentation et allocation 1 - Introduction inventés à la fin des années

Plus en détail

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles)

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles) SGBDR Systèmes de Gestion de Bases de Données (Relationnelles) Plan Approches Les tâches du SGBD Les transactions Approche 1 Systèmes traditionnels basés sur des fichiers Application 1 Gestion clients

Plus en détail

AVRIL 2014. Au delà de Hadoop. Panorama des solutions NoSQL

AVRIL 2014. Au delà de Hadoop. Panorama des solutions NoSQL AVRIL 2014 Panorama des solutions NoSQL QUI SOMMES NOUS? Avril 2014 2 SMILE, EN QUELQUES CHIFFRES 1er INTÉGRATEUR EUROPÉEN DE SOLUTIONS OPEN SOURCE 3 4 NOS EXPERTISES ET NOS CONVICTIONS DANS NOS LIVRES

Plus en détail

Le stockage. 1. Architecture de stockage disponible. a. Stockage local ou centralisé. b. Différences entre les architectures

Le stockage. 1. Architecture de stockage disponible. a. Stockage local ou centralisé. b. Différences entre les architectures Le stockage 1. Architecture de stockage disponible a. Stockage local ou centralisé L architecture de stockage à mettre en place est déterminante pour l évolutivité et la performance de la solution. Cet

Plus en détail

CESI Bases de données

CESI Bases de données CESI Bases de données Introduction septembre 2006 Bertrand LIAUDET EPF - BASE DE DONNÉES - septembre 2005 - page 1 PRÉSENTATION GÉNÉRALE 1. Objectifs généraux L objectif de ce document est de faire comprendre

Plus en détail

Les environnements de calcul distribué

Les environnements de calcul distribué 2 e Atelier CRAG, 3 au 8 Décembre 2012 Par Blaise Omer YENKE IUT, Université de Ngaoundéré, Cameroun. 4 décembre 2012 1 / 32 Calcul haute performance (HPC) High-performance computing (HPC) : utilisation

Plus en détail

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l

L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i n f r a m e, un b e s o i n c r u c i a l Siège social : 5 Speen Street Framingham, MA 01701, É.-U. T.508.872.8200 F.508.935.4015 www.idc.com L I V R E B L A N C P r o t ég e r l e s a p p l i c a t i o n s m ét i e r s c r i t i q u e s M a i

Plus en détail

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques

DÉVELOPPEMENT INFONUAGIQUE - meilleures pratiques livre blanc DÉVELOPPEMENT INFONUAGIQUE MEILLEURES PRATIQUES ET APPLICATIONS DE SOUTIEN DÉVELOPPEMENT INFONUAGIQUE - MEILLEURES PRATIQUES 1 Les solutions infonuagiques sont de plus en plus présentes sur

Plus en détail

Oracle 11g Optimisez vos bases de données en production (ressources matérielles, stockage, mémoire, requêtes)

Oracle 11g Optimisez vos bases de données en production (ressources matérielles, stockage, mémoire, requêtes) Avant-propos 1. Lectorat 11 2. Pré-requis 12 3. Objectifs 12 4. Environnement technique 13 Choisir la bonne architecture matérielle 1. Introduction 15 2. Architecture disque 16 2.1 La problématique de

Plus en détail

<Insert Picture Here> Solaris pour la base de donnés Oracle

<Insert Picture Here> Solaris pour la base de donnés Oracle Solaris pour la base de donnés Oracle Alain Chéreau Oracle Solution Center Agenda Compilateurs Mémoire pour la SGA Parallélisme RAC Flash Cache Compilateurs

Plus en détail

TP Bases de données réparties

TP Bases de données réparties page 1 TP Bases de données réparties requêtes réparties Version corrigée Auteur : Hubert Naacke, révision 5 mars 2003 Mots-clés: bases de données réparties, fragmentation, schéma de placement, lien, jointure

Plus en détail

Table des matières PRESENTATION DU LANGAGE DS2 ET DE SES APPLICATIONS. Introduction

Table des matières PRESENTATION DU LANGAGE DS2 ET DE SES APPLICATIONS. Introduction PRESENTATION DU LANGAGE DS2 ET DE SES APPLICATIONS Depuis SAS 9.2 TS2M3, SAS propose un nouveau langage de programmation permettant de créer et gérer des tables SAS : le DS2 («Data Step 2»). Ces nouveautés

Plus en détail

Bases de Données. Stella MARC-ZWECKER. stella@unistra.u-strasbg.fr. Maître de conférences Dpt. Informatique - UdS

Bases de Données. Stella MARC-ZWECKER. stella@unistra.u-strasbg.fr. Maître de conférences Dpt. Informatique - UdS Bases de Données Stella MARC-ZWECKER Maître de conférences Dpt. Informatique - UdS stella@unistra.u-strasbg.fr 1 Plan du cours 1. Introduction aux BD et aux SGBD Objectifs, fonctionnalités et évolutions

Plus en détail

La surveillance réseau des Clouds privés

La surveillance réseau des Clouds privés La surveillance réseau des Clouds privés Livre blanc Auteurs : Dirk Paessler, CEO de Paessler AG Gerald Schoch, Rédactrice technique de Paessler AG Publication : Mai 2011 Mise à jour : Février 2015 PAGE

Plus en détail

VMWare Infrastructure 3

VMWare Infrastructure 3 Ingénieurs 2000 Filière Informatique et réseaux Université de Marne-la-Vallée VMWare Infrastructure 3 Exposé système et nouvelles technologies réseau. Christophe KELLER Sommaire Sommaire... 2 Introduction...

Plus en détail

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15

MapReduce. Malo Jaffré, Pablo Rauzy. 16 avril 2010 ENS. Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 MapReduce Malo Jaffré, Pablo Rauzy ENS 16 avril 2010 Malo Jaffré, Pablo Rauzy (ENS) MapReduce 16 avril 2010 1 / 15 Qu est ce que c est? Conceptuellement Données MapReduce est un framework de calcul distribué

Plus en détail

ADMINISTRATION EXADATA

ADMINISTRATION EXADATA ADMINISTRATION EXADATA Abel Afonso Avant Vente abel.afonso@oracle.com The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated

Plus en détail

et les Systèmes Multidimensionnels

et les Systèmes Multidimensionnels Le Data Warehouse et les Systèmes Multidimensionnels 1 1. Définition d un Datawarehouse (DW) Le Datawarehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées

Plus en détail

Proposition d une architecture pour ebay, en mettant l accent sur les notions de scalabilité, de résilience, et de tolérance aux pannes.

Proposition d une architecture pour ebay, en mettant l accent sur les notions de scalabilité, de résilience, et de tolérance aux pannes. PROJET «EBAY» V1 MANUEL ROLLAND, SCIA 2009, REMIS LE 7 MARS 2008 1. Rappels sur le projet : Proposition d une architecture pour ebay, en mettant l accent sur les notions de scalabilité, de résilience,

Plus en détail

Architectures d implémentation de Click&DECiDE NSI

Architectures d implémentation de Click&DECiDE NSI Architectures d implémentation de Click&DECiDE NSI de 1 à 300 millions de ligne de log par jour Dans ce document, nous allons étudier les différentes architectures à mettre en place pour Click&DECiDE NSI.

Plus en détail

CH.3 SYSTÈMES D'EXPLOITATION

CH.3 SYSTÈMES D'EXPLOITATION CH.3 SYSTÈMES D'EXPLOITATION 3.1 Un historique 3.2 Une vue générale 3.3 Les principaux aspects Info S4 ch3 1 3.1 Un historique Quatre générations. Préhistoire 1944 1950 ENIAC (1944) militaire : 20000 tubes,

Plus en détail

Contrôlez et Maîtrisez votre environnement de messagerie Lotus Notes Domino

Contrôlez et Maîtrisez votre environnement de messagerie Lotus Notes Domino Contrôlez et Maîtrisez votre environnement de messagerie Lotus Notes Domino avec MailFlow Analyzer TM un produit de l Infrastructure Management Suite TM Copyright COOPERTEAM SOFTWARE 2013 La gestion de

Plus en détail

MYXTRACTION. 2009 La Business Intelligence en temps réel

MYXTRACTION. 2009 La Business Intelligence en temps réel MYXTRACTION 2009 La Business Intelligence en temps réel Administration Qui sommes nous? Administration et management des profils Connecteurs Base des données Gestion des variables et catégories de variables

Plus en détail

FAMILLE EMC RECOVERPOINT

FAMILLE EMC RECOVERPOINT FAMILLE EMC RECOVERPOINT Solution économique de protection des données et de reprise après sinistre en local et à distance Avantages clés Optimiser la protection des données et la reprise après sinistre

Plus en détail

Le data center moderne virtualisé

Le data center moderne virtualisé WHITEPAPER Le data center moderne virtualisé Les ressources du data center ont toujours été sous-utilisées alors qu elles absorbent des quantités énormes d énergie et occupent une surface au sol précieuse.

Plus en détail

Performances. Gestion des serveurs (2/2) Clustering. Grid Computing

Performances. Gestion des serveurs (2/2) Clustering. Grid Computing Présentation d Oracle 10g Chapitre VII Présentation d ORACLE 10g 7.1 Nouvelles fonctionnalités 7.2 Architecture d Oracle 10g 7.3 Outils annexes 7.4 Conclusions 7.1 Nouvelles fonctionnalités Gestion des

Plus en détail

Contributions à l expérimentation sur les systèmes distribués de grande taille

Contributions à l expérimentation sur les systèmes distribués de grande taille Contributions à l expérimentation sur les systèmes distribués de grande taille Lucas Nussbaum Soutenance de thèse 4 décembre 2008 Lucas Nussbaum Expérimentation sur les systèmes distribués 1 / 49 Contexte

Plus en détail

ORACLE 10g Découvrez les nouveautés. Jeudi 17 Mars Séminaire DELL/INTEL/ORACLE

ORACLE 10g Découvrez les nouveautés. Jeudi 17 Mars Séminaire DELL/INTEL/ORACLE ORACLE 10g Découvrez les nouveautés Jeudi 17 Mars Séminaire DELL/INTEL/ORACLE Le Grid Computing d Entreprise Pourquoi aujourd hui? Principes et définitions appliqués au système d information Guy Ernoul,

Plus en détail

IBM Tivoli Monitoring, version 6.1

IBM Tivoli Monitoring, version 6.1 Superviser et administrer à partir d une unique console l ensemble de vos ressources, plates-formes et applications. IBM Tivoli Monitoring, version 6.1 Points forts! Surveillez de façon proactive les éléments

Plus en détail

Limitations of the Playstation 3 for High Performance Cluster Computing

Limitations of the Playstation 3 for High Performance Cluster Computing Introduction Plan Limitations of the Playstation 3 for High Performance Cluster Computing July 2007 Introduction Plan Introduction Intérêts de la PS3 : rapide et puissante bon marché L utiliser pour faire

Plus en détail

Pourquoi IBM System i for Business Intelligence

Pourquoi IBM System i for Business Intelligence Améliorer les performances et simplifier la gestion de vos applications d aide à la décision (Business Intelligence ou BI) Pourquoi IBM System i for Business Intelligence Points clés Technologie IBM DB2

Plus en détail

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/

Information utiles. cinzia.digiusto@gmail.com. webpage : Google+ : http://www.ibisc.univ-evry.fr/ digiusto/ Systèmes de gestion de bases de données Introduction Université d Evry Val d Essonne, IBISC utiles email : cinzia.digiusto@gmail.com webpage : http://www.ibisc.univ-evry.fr/ digiusto/ Google+ : https://plus.google.com/u/0/b/103572780965897723237/

Plus en détail

Windows Internet Name Service (WINS)

Windows Internet Name Service (WINS) Windows Internet Name Service (WINS) WINDOWS INTERNET NAME SERVICE (WINS)...2 1.) Introduction au Service de nom Internet Windows (WINS)...2 1.1) Les Noms NetBIOS...2 1.2) Le processus de résolution WINS...2

Plus en détail

CHAPITRE 1 ARCHITECTURE

CHAPITRE 1 ARCHITECTURE 07/04/2014 Université des sciences et de la Technologie Houari Boumediene USTHB Alger Département d Informatique ADMINISTRATION ET TUNING DE BASES DE DONNÉES CHAPITRE 1 ARCHITECTURE RESPONSABLE DR K. BOUKHALFA

Plus en détail

Optimisations des SGBDR. Étude de cas : MySQL

Optimisations des SGBDR. Étude de cas : MySQL Optimisations des SGBDR Étude de cas : MySQL Introduction Pourquoi optimiser son application? Introduction Pourquoi optimiser son application? 1. Gestion de gros volumes de données 2. Application critique

Plus en détail

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft

Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source JShaft Augmenter la disponibilité des applications JEE grâce au clustering : Le projet open source Jérôme Petit, Serge Petit & Serli Informatique, ITMatic Jérôme Petit, Serge Petit & SERLI & ITMatic Serli : SSII

Plus en détail

Etude d Algorithmes Parallèles de Data Mining

Etude d Algorithmes Parallèles de Data Mining REPUBLIQUE TUNISIENNE MINISTERE DE L ENSEIGNEMENT SUPERIEUR, DE LA TECHNOLOGIE ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSITE DE TUNIS ELMANAR FACULTE DES SCIENCES DE TUNIS DEPARTEMENT DES SCIENCES DE L INFORMATIQUE

Plus en détail

FINI LA RÉCRÉ PASSONS AUX MÉGADONNÉES

FINI LA RÉCRÉ PASSONS AUX MÉGADONNÉES 1 FINI LA RÉCRÉ PASSONS AUX MÉGADONNÉES «Dans le concret, projets de transformation vers le BigData» V1-10/03/15 ABED AJRAOU CONNAISSEZ-VOUS PAGESJAUNES? CONNAISSEZ-VOUS PAGESJAUNES? LES MEGADONNEES RÉPONDENT

Plus en détail

Le passage à l échelle de serveur J2EE : le cas des EJB

Le passage à l échelle de serveur J2EE : le cas des EJB Le passage à l échelle de serveur J2EE : le cas des EJB Sylvain Sicard, Noël De Palma, Daniel Hagimont CFSE 4 5-8 Avril 2005 LSR 1 Plan de la présentation 1. Architecture de serveur J2EE en grappe 2. Problématique

Plus en détail

Perspectives pour l entreprise. Desktop Cloud. JC Devos IBM IT Architect jdevos@fr.ibm.com. 2010 IBM Corporation

Perspectives pour l entreprise. Desktop Cloud. JC Devos IBM IT Architect jdevos@fr.ibm.com. 2010 IBM Corporation Perspectives pour l entreprise Desktop Cloud JC Devos IBM IT Architect jdevos@fr.ibm.com Principe technique Disposer d un poste de travail virtuel accessible par la plupart des terminaux disponibles Ce

Plus en détail

Bases de données avancées Introduction

Bases de données avancées Introduction Bases de données avancées Introduction Dan VODISLAV Université de Cergy-Pontoise Master Informatique M1 Cours BDA Plan Objectifs et contenu du cours Rappels BD relationnelles Bibliographie Cours BDA (UCP/M1)

Plus en détail

Continuité d activité : le choix des armes

Continuité d activité : le choix des armes [ Rubrique à brac ] Continuité d activité : le choix des armes Beaucoup de Plans de Recouvrement d Activité (PRA) furent conçus dans le but de parer à des désastres tels que les incendies, les inondations

Plus en détail

EMC DATA DOMAIN HYPERMAX

EMC DATA DOMAIN HYPERMAX EMC DATA DOMAIN HYPERMAX Optimisation du stockage de protection EMC AVANTAGES CLÉS Déduplication évolutive et ultrarapide Jusqu à 58,7 To/h de débit Réduit de 10 à 30 fois le stockage de sauvegarde, et

Plus en détail

Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long,

Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long, Vous êtes bien à la bonne présentation, c est juste que je trouvais que le titre de cette présentation étais un peu long, en fait ça me faisait penser au nom d un certain projet gouvernemental je me suis

Plus en détail

LA VIRTUALISATION. Etude de la virtualisation, ses concepts et ses apports dans les infrastructures informatiques. 18/01/2010.

LA VIRTUALISATION. Etude de la virtualisation, ses concepts et ses apports dans les infrastructures informatiques. 18/01/2010. Guillaume ANSEL M2 ISIDIS 2009-2010 / ULCO Dossier d étude sur la virtualisation LA VIRTUALISATION 18/01/2010 Etude de la virtualisation, ses concepts et ses apports dans les infrastructures informatiques.

Plus en détail

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration

Julien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration Julien MATHEVET Alexandre BOISSY GSID 4 Rapport Load Balancing et migration Printemps 2001 SOMMAIRE INTRODUCTION... 3 SYNTHESE CONCERNANT LE LOAD BALANCING ET LA MIGRATION... 4 POURQUOI FAIRE DU LOAD BALANCING?...

Plus en détail

Les simulations dans l enseignement des sondages Avec le logiciel GENESIS sous SAS et la bibliothèque Sondages sous R

Les simulations dans l enseignement des sondages Avec le logiciel GENESIS sous SAS et la bibliothèque Sondages sous R Les simulations dans l enseignement des sondages Avec le logiciel GENESIS sous SAS et la bibliothèque Sondages sous R Yves Aragon, David Haziza & Anne Ruiz-Gazen GREMAQ, UMR CNRS 5604, Université des Sciences

Plus en détail

NoSQL. Introduction 1/23. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur)

NoSQL. Introduction 1/23. I NoSQL : Not Only SQL, ce n est pas du relationnel, et le contexte. I table d associations - Map - de couples (clef,valeur) 1/23 2/23 Anne-Cécile Caron Master MIAGE - BDA 1er trimestre 2013-2014 I : Not Only SQL, ce n est pas du relationnel, et le contexte d utilisation n est donc pas celui des SGBDR. I Origine : recherche

Plus en détail

DOSSIER SOLUTION : CA RECOVERY MANAGEMENT

DOSSIER SOLUTION : CA RECOVERY MANAGEMENT DOSSIER SOLUTION : CA RECOVERY MANAGEMENT Comment la solution CA Recovery Management peut-elle nous aider à protéger et garantir la disponibilité des informations essentielles au fonctionnement de notre

Plus en détail

Consolidation de stockage

Consolidation de stockage (Information sur la technologie Sto-2003-2) Wolfgang K. Bauer Spécialiste stockage Centre de compétence transtec AG Waldhörnlestraße 18 D-72072 Tübingen Allemagne TABLE DES MATIÈRES 1 RÉSUMÉ...3 2 INTRODUCTION...4

Plus en détail

Eric Bertrand ebertrand@ixis-cib.com. 08/11/06 Maître de conférence 1

Eric Bertrand ebertrand@ixis-cib.com. 08/11/06 Maître de conférence 1 Calcul parallèle des options MC. Eric Bertrand ebertrand@ixis-cib.com 1 Plan Contexte du calcul parallèle Qualités requises Architecture Outillage Problèmes rencontrés perspectives 2 Contexte du calcul

Plus en détail

Intégration de données hétérogènes et réparties. Anne Doucet Anne.Doucet@lip6.fr

Intégration de données hétérogènes et réparties. Anne Doucet Anne.Doucet@lip6.fr Intégration de données hétérogènes et réparties Anne Doucet Anne.Doucet@lip6.fr 1 Plan Intégration de données Architectures d intégration Approche matérialisée Approche virtuelle Médiateurs Conception

Plus en détail

VMware : De la Virtualisation. au Cloud Computing

VMware : De la Virtualisation. au Cloud Computing VMware : De la Virtualisation. au Cloud Computing Tunis, le 12 Décembre 2012 Jamal Belhachemi BDM South EMEA 2010 VMware, Inc. Tous droits réservés. 2010 #1 dans les priorités des Directeurs Informatiques

Plus en détail

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43

Techniques de stockage. Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Techniques de stockage, P. Rigaux p.1/43 Techniques de stockage Contenu de ce cours : 1. Stockage de données. Supports, fonctionnement d un disque, technologie RAID 2. Organisation

Plus en détail

IT203 : Systèmes de gestion de bases de données. A. Zemmari zemmari@labri.fr

IT203 : Systèmes de gestion de bases de données. A. Zemmari zemmari@labri.fr IT203 : Systèmes de gestion de bases de données A. Zemmari zemmari@labri.fr 1 Informations pratiques Intervenants : Cours : (A. Zemmari zemmari@labri.fr) TDs, TPs : S. Lombardy et A. Zemmari Organisation

Plus en détail

«Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de

«Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de 1 2 «Les documents référencés ci-dessus étant protégés par les droits d auteur et soumis à la déclaration au Centre Français d exploitation du droit de Copie, seules les références bibliographiques peuvent

Plus en détail

Chapitre 10. Architectures des systèmes de gestion de bases de données

Chapitre 10. Architectures des systèmes de gestion de bases de données Chapitre 10 Architectures des systèmes de gestion de bases de données Introduction Les technologies des dernières années ont amené la notion d environnement distribué (dispersions des données). Pour reliér

Plus en détail

Cours 6. Sécurisation d un SGBD. DBA - M1ASR - Université Evry 1

Cours 6. Sécurisation d un SGBD. DBA - M1ASR - Université Evry 1 Cours 6 Sécurisation d un SGBD DBA - M1ASR - Université Evry 1 Sécurisation? Recette d une application Vérification des fonctionnalités Vérification de l impact sur le SI existant Gestion du changement

Plus en détail

Bases de données relationnelles : Introduction

Bases de données relationnelles : Introduction Bases de données relationnelles : Introduction historique et principes V. Benzaken Département d informatique LRI UMR 8623 CNRS Université Paris Sud veronique.benzaken@u-psud.fr https://www.lri.fr/ benzaken/

Plus en détail

Leçon 1 : Les principaux composants d un ordinateur

Leçon 1 : Les principaux composants d un ordinateur Chapitre 2 Architecture d un ordinateur Leçon 1 : Les principaux composants d un ordinateur Les objectifs : o Identifier les principaux composants d un micro-ordinateur. o Connaître les caractéristiques

Plus en détail

CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise

CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise CloudBees AnyCloud : Valeur, Architecture et Technologie cloud pour l entreprise Alors que les plates-formes PaaS (Platform as a Service) commencent à s imposer comme le modèle privilégié auprès des entreprises

Plus en détail

e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France

e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France e need L un des premiers intégrateurs opérateurs Cloud Computing indépendants en France Sommaire Cloud Computing Retours sur quelques notions Quelques chiffres Offre e need e need Services e need Store

Plus en détail

IBM Systems & Technology Recentrer l informatique sur l innovation plutôt que sur la maintenance

IBM Systems & Technology Recentrer l informatique sur l innovation plutôt que sur la maintenance IBM Systems & Technology Recentrer sur l innovation plutôt que sur la maintenance Utiliser la plateforme IBM PureApplication System et ses modèles d expertise pour la consolidation, l optimisation, l innovation

Plus en détail