Architecture des SGBD parallèles NSY 104
Introduction Présentation des options d architecture des serveurs et des systèmes de gestion de bases de données. Ces derniers ont des relations privilégiées avec les disques. Un SGBD parallèle exploite le parallélisme pour fournir un service autour d une base de données. Ce parallélisme est supporté par une architecture parallèle. Il ne faut pas confondre ce type de SGBD avec les SGBD distribués ou répartis. Ces derniers visent à fédérer en une vision de base de données unique des bases supportées par des systèmes différents.
CPU CPU MEM MEM MEM MEM CPU CPU Share Everything (typique SMP) RESEAU D INTERCONNEXION RESEAU D INTERCONNEXION Share Nothing Shared Disk (certains clusters et MPP) (certains clusters) L architecture Share Everything, l ensemble des processeurs du système fonctionne sous le contrôle d un seul système d exploitation. L architecture Share Nothing chacun des nœuds qui composent le système fonctionne sous le contrôle de sa propre copie du système d exploitation et a un accès exclusif aux disques qui lui sont attachés. L architecture Shared Disk chacun des nœuds qui composent le système fonctionne sous le contrôle de sa propre copie du système d exploitation mais peut accéder directement aux disques qui sont partagés entre les différents nœuds. CPU CPU
Ces trois modèles correspondent à des réalités différentes du point de vue des données et de l équilibrage des charges. Une analogie avec des clients attendant d être servis devant des guichets permet d appréhender les différences entre les modèles. Clients (processus) Guichets (processeurs/systèmes) Dossiers (données) Modèle Share Everything Modèle Share Disks Modèle Share Nothing
Dans le modèle Share Everything : Les clients sont placés dans une file d attente commune. Il y a un équilibrage de charge naturel, les clients se répartissent automatiquement sur les guichets en fonction de leur disponibilité. Tous les agents aux guichets disposent de possibilités identiques d accès aux dossiers. L ensemble des dossiers est partagé par l ensemble des agents. La synchronisation entre les agents pour la mise à jour des dossiers s effectuent par un dialogue direct (les processeurs partagent la même mémoire). Les limites du système se trouvent dans le nombre maximal d agents qui peuvent être mis en parallèle. Et aussi dans le débit de l accès aux données.
Dans le modèle Share Disks : La répartition des clients vers les différents guichets ne se fait pas naturellement, il est nécessaire de prévoir un agent en amont chargé d équilibrer les flux de clients vers les différents guichets. Dans les systèmes informatiques, ce rôle est dévolue à l un des nœuds du cluster qui recueille les informations sur la charge des nœuds et aiguille la requête vers les nœuds les moins chargés. Chacun des agents a accès à l ensemble des dossiers. La synchronisation entre les agents pour la mise à jour des données nécessitent un dialogue entre les différents guichets. Pour les systèmes informatiques, ce dialogue est réalisé au moyen d un réseau d interconnections, il est bien moins efficace que le dialogue au travers d une mémoire commune.
Dans le modèle Share Nothing : Chaque ensemble de guichets accède en propre à un sous ensemble de dossiers. Un guichet désirant accéder à des dossiers gérés par des guichets appartenant à un autre sous ensemble doit s adresser à ce sous ensemble. Ce modèle implique que la répartition des clients sur les sous ensembles de guichets, soit faite en foncton du sous ensemble de dossiers auquel le client souhaite accéder. L équilibrage de charge est donc étroitement lié à la répartition des dossiers entre les différents sous ensembles des guichets et à la distribution des demandes des clients vis-à-vis de ces dossiers. L accès d un sous ensemble de guichets donné à des données gérées par d autres sous ensembles de guichet nécessite des échanges entre ces sous ensembles.
Ces demandes peuvent être de deux sortes : Envoi de données (Data Shipping). Le guichet traitant la requête demande au sous ensemble de guichets possèdent la donnée de la lui adresser. Ce guichet se charge de la réalisation de l opération et du renvoi des données au sous ensemble de guichets qui gère ces données. Envoi de fonction (Function Shipping). Le guichet traitant la requête adresse au sous ensemble de guichets possédant la donnée la définition de la fonction à exécuter. Ce dernier retourne, le cas échéant, les résultats de la fonction qu il a exécutée. Les SGBD qui ont fait le choix pour l architecture Shared Disks ont opté pour l option «envoi de données», Les autres SGBD qui ont fait le choix pour l architecture Share Nothing ont opté pour l option «envoi de fonction».
Cas de la réplication de données : Une même donnée se trouve sur plusieurs disques dans le système, cela nécessite un protocole pour mise à jour, mais facilite l accès. Modèle Expédition de données pour l architecture Share Nothing : Le nœud désirant effectuer une opération sur des données gérées par un nœud distant expédie à ce nœud distant une demande d accès aux données. Le nœud distant réalise l accès et expédie les données via le réseau d interconnexion au nœud demandeur. Exécution de la requête Demande d accès aux données Données Hors cet accès distant, la requête est exécutée en totalité sur le même nœud. A à E F..J K..N O..S T..Z Expédition de la donnée (DataShipping)
Modèle expédition de fonction pour l architecture Share Nothing : Le nœud désirant effectuer une opération sur des données gérées par un nœud distant expédie au nœud distant une demande d exécution de partie de la requête (fonction) qui concerne les données gérées par ce nœud. Le nœud distant exécute la fonction sur les données concernées et expédie le résultat (c est à dire des données) via le réseau d interconnexion au nœud demandeur. Exécution de la requête (partielle) Demande d exécution de la fonction A à E F..J K..N O..S T..Z Expédition de fonction (Function Shipping) Résultat Exécution de la fonction Une requête peut être ainsi exécutée par plusieurs nœuds. Les avantages et inconvénients des deux modèles dépendent des quantités de données à exporter et de la quantité de traitement exportés.
Problématique des SGBD : Les ressources de traitement (processeurs). Les entrées sorties (contrôleurs et unités disques). Caractéristiques de la mémoire (capacité et temps moyen d accès). Performance du réseau d interconnexion (latence et débit). Nous allons nous intéresser surtout aux processeurs et aux entrées sorties. Deux types de saturation peuvent se produire : Saturation des ressources de traitement. Cette situation est applée CPU Bound La performance du système est limité par les processeurs. Saturation des entrées - sorties. Cette situation est appelée I/O Bound la performance du système est limité par les entrées sorties.
Deux types de parallélisation des requêtes existent : Parallélisme de traitement. La requête est décomposée en requêtes élémentaires qui sont exécutées en parallèle. Parallélisme de données. L exécution de la requête s opère en parallèle sur des sous ensembles des données. Ces deux techniques peuvent être mises en œuvre sur n importe lequel des modèles d architecture présentés : Share everything, Shared Disks, Share Nothing. Le parallélisme de traitement utilise la décomposition d une requête en un ensemble partiellement ordonné d opérateurs (indexation, tri, jointure etc.). Les différents opérateurs s exécutent dans des threads. Le parallélisme de données consiste à diviser une table en un certains nombres de partitions. L exécution d une requête se traduit alors par des exécutions sur chacune des partitions en simultanée.
Cela se traduit par le parallélisme inter-requête et le parallélisme intra-requête : Pour le parallélisme inter-requête, le SGBD procède à l exécution simultanée de plusieurs requêtes concernant des clients différents. Pour le parallélisme intra-requête, le SGBD transforme une requête soumise par un client en plusieurs sous requêtes susceptibles d être exécutées simultanément. Ces deux formes de parallélisme peuvent cohabiter ensemble. Le cas typique du parallélisme inter-requête est le transactionnel dans lequel le SGBD (et éventuellement le moniteur des transactions) se charge de traiter simultanément les transactions émises par le client. Le parallélisme intra-requête consiste à répartir l exécution d une même requête sur plusieurs processus. Pour cela le SGBD transforme la requête en plusieurs sous requêtes qui sont exécutées en parallèle. Chaque sous requête agit sur un partitionnement des données.
Le parallélisme inter-requête : DISPATCHER Processus serveurs Base de données
Le parallélisme intra-requête : Temps Table 1 Table 2 Etape 1 Scan 4 min Etape 2 join 4 min Etape 3 sort 4 min Temps total 12 min Exécution séquentielle Table 1 Temps total 3 min. Répartition des données sur plusieurs systèmes Table 2 Etape 1 Scan 1 min Etape 2 join 1 min Etape 3 sort 1 min Partionnement des données et exécution en parallèle
Le partitionnement peut être exécuté en pipeline (combinaison du partitionnement et du pipeline) : S o r t n J o i n S c a n S o r t n J o i n S c a n S o r t n J o i n S c a n S o r t n J o i n S c a n S o r t n J o i n S c a n Temps = 1 min Temps = 2 min Temps = 3 min Fin d exécution de la première requête Temps = 4 min Fin d exécution de la seconde requête Temps = 5 min Fin d exécution de la troisième requête TEMPS
Le partitionnement des données est particulièrement important dans les architectures de type Share Nothing. Il influence la performance du système dans les architectures de type Shared Disks car : Grâce à un aiguillage judicieux, il est possible de créer une affinité nœud données qui favorise l effet cache. Les mêmes données sont alors accédées par le même nœud et donc le cache de la base de données placé sur ce nœud a une très forte probabilité de contenir les données accédées par les requêtes. Le partitionnement des données cherche à atteindre les objectifs suivants : Réduction de la charge système au niveau de l accès aux données. Plusieurs ressources parallèles sont mises au service de l accès aux données. Equilibrage de la charge. Les traitements sont répartis en fonction de la répartition des données sur les différents nœuds composant le système. Accroissement de la capacité de travail du système du fait de la mise en parallèle de plusieurs nœuds.
Le partitionnement vertical Table Système 1 Système 2 Le partitionnement vertical sépare les attributs d une relation entre plusieurs systèmes. Ce type de partitionnement peut avoir des conséquences sur la programmation des applications. Deux cas peuvent se présenter : Si le SGBD supporte les bases de données distribuées, il y a transparence vis-à-vis de l application. Le SGBD se chargeant des problèmes liés à la distribution. Si le SGBD ne supporte pas les bases de données distribuées, l application doit tenir compte de la partition des données. Dans tous les cas, les performances sont impactées par la mise à jour des données portant sur plus d une partition.
Le partitionnement horizontal Système 1 Table Système 2 Le partitionnement horizontal ne présente pas les mêmes contraintes, son utilisation ne pose pas de problèmes au niveau application.
Exemple de techniques de partitionnement : Table Round Robin chaque tuple est rangé dans la partition suivante en séquence 1 2 3 4 5 Domaine les tuples sont répartis en fonction des domaines de valeur des clés Domaine de valeurs... Hachage un algorithme appliqué à la clé détermine son numéro de partition
Le partitionnement fondé sur les domaines de valeur de la clé permet des optimisations car il possible d aiguiller les requêtes vers un nœud en fonction de la valeur de la clé. Exemple : les clés sont des noms et la partition se fait en fonction de la première lettre du nom, ainsi les noms débutant par les lettres A à E appartiennent à la première partition, ceux débutant par les lettres F à J à la seconde et ainsi de suite. Le Round Robin possède, par définition, la propriété d équilibrer les partitions. En revanche, l équilibrage de la charge n est pas assurée puisqu elle dépend des articles qui sont accédés. La méthode fondée sur une fonction de hachage, pose le problème du choix de la fonction de hachage. Exemple de fonction de hachage : on considère les bits composants la clé comme un nombre entier de longueur variable. La valeur de fonction de hachage est le reste de la division de ce nombre par un nombre premier. Une fonction de hachage doit être simple à évaluer et fournir un bon équilibre des partitions.
Architecture d IBM DB2 Universal Database (version Enterprise et Enterprise extended) : DB2 est fondé sur une architecture de type Share Nothing. DB2 utilise le modèle d expédition de fonction. DB2 fonctionne sur les plateformes MVS, AIX, Solaris et Windows NT. Les architectures supportées sont les multiprocesseurs symétriques, les clusters et les machines parallèles. Pour les partitionnements, DB2 utilise le hachage en collaboration avec une méthode paramétrable de répartitions des données dans les partitions.
Architecture d IBM DB2 Universal Database (version Enterprise et Enterprise extended) : Exécution d une requête : Applications «client» Nœud 1 Nœud 2 Nœud 3 C E E E E E E E E E C Tache Coordinatrice E Tache Esclave L exécution d une requête est réalisée sous le contrôle d une tâche dite coordinatrice. Cette tâche distribue le traitement à des tâches esclaves et recueille les réponses.
Architecture d IBM DB2 Universal Database (version Enterprise et Enterprise extended) : Partitionnement des données : Colonne 1 (Clé de partition) Colonne 2 Colonne 3 XXXXX YYYYY ZZZZZ Fonction de hashing Résultat de fonction Nœud assigné 0 1 2 3 4 5 6 7 8 9 10 11.... 1 2 3 4 5 6 1 2 3 4 5 6.... N œ u d 1 N œ u d 2 N œ u d 3 N œ u d 4 N œ u d 5 N œ u d 6 Le partitionnement est fondé sur la valeur d un des attributs de la relation. Cet attribut appelé clé de partitionnement n est pas nécessairement la clé de la relation. La fonction de hachage prend ses valeurs dans l ensemble 0 à 4095. A chacune de ces valeurs, une table fait correspondre le nœud sur lequel sont rangés les tuples. On applique donc la fonction de hachage à la clé de partitionnement d un tuple. Le résultat de cette fonction est un index dans un tableau qui contient le numéro de la partition à laquelle appartient le tuple.
Architecture d IBM DB2 Universal Database (version Enterprise et Enterprise extended) : Stratégie de jointure : Tache Coordinatrice Tache Coordinatrice Tache Coordinatrice Taches esclaves Jointure Scan Scan Tâches esclaves 1 Scan Tâches esclaves 2 Jointure Dirigé Ou diffusé Scan Tâches esclaves 1 Scan Tâches esclaves 3 Jointure Scan Tâches esclaves 2 Table Table 1 2 Jointure locale Table Table 1 2 Jointure dirigée ou diffusée Table 1 Jointure répartie La jointure locale exploite deux partitions de tables placées sur le même nœud. La jointure dirigée ou diffusée exploite des partitions de tables placées sur des nœuds différents. Les tuples sélectionnés au niveau d un nœud doivent être dirigés vers un autre nœud pour que l opération de jointure y soit réalisée. La jointure dirigé correspond au cas où l on connaît à l avance le nœud sur lequel cette jointure va être réalisée. Lorsque l on ne connaît pas à l avance ce nœud, les données sélectionnées sont diffusées aux autres nœuds. La jointure répartie fonctionne sur le principe d un arborescence. Table 2
Mode Partagé Jérôme Dupire Oracle Parallel Server est basé sur une architecture de type Shared Disks. On appelle instance d Oracle l association des processus implémentant Oracle et d une zone de données globale appelée SGA (System Global Area). Dans la version non OPS d Oracle, il existe autant d instance d Oracle sur un système donné qu il y a de bases ouvertes, alors qu avec OPS plusieurs instances peuvent partager la même base de données. OPS supporte de l ordre d une dizaine de nœuds. Instance unique Instance Oracle Instance Multiples / Multiples bases Instance Oracle Instance Oracle Nœud Base Ouverte Nœud Base Ouverte Base Ouverte Mode Exclusif OPS : Nœud 1 Instance Oracle Instance Oracle Nœud 2 Base Ouverte
Structure générale d une instance d Oracle : Un utilisateur peut se connecté via une structure produite par un serveur dédié à sa connexion. Un utilisateur peut aussi se connecter via une structure partagée entre les utilisateurs gérée par un serveur multi threads. Dans le cas d un serveur dédié, une zone de données appelée PGA (Program Global Area) est associé à l utilisateur, cette zone contient des informations relatives à cette utilisateur : la pile (enchaînement des appels de procédures et fonctions) et données relatives à la session en cours. Dans le cas du serveur multi threads, une zone PGA est également associée à chaque utilisateur, mais cette zone ne contient qu un sous ensemble des informations qui sont stockées dans la PGA des serveurs dédiés. Les données relatives à la session sont rangées dans la SGA. Le cache de la base de données contient des blocs de données les plus récemment accédés et peut aussi contenir des blocs de données modifiés qui n ont pas encore été rangés sur le disque. Le journal «refaire» contient les informations qui permettent de rejouer les transactions. La zone de mémoire partagée contient des éléments tels que ceux associés à des utilisateurs ayant demandé l exécution du même ordre SQL.
Structure générale d une instance d Oracle Processus d arrière plan Processus d arrière plan Cache de la base de données Journal «refaire» ZONE GLOBALE SYSTEME (SGA) Zone partagée Zones SQL partagées Session utilisateur et états curseur pour MTS Serveur dédié PGA DISPATCHER PGA PILE PGA PILE PILE Session util Etat courant UTILISATEUR UTILISATEUR Serveur multithreaded UTILISATEUR
Oracle Paralle Server (OPS) : Structure générale d une instance multi threads d Oracle Processus d arrière plan Processus d arrière plan Cache de la base de données Zone partagée Zone globale système (SGA) Serveur partagé Queue des requêtes Queue des réponses Journal «refaire» DISPATCHER DISPATCHER LSNR Serveur dédié Utilisateur Utilisateur Utilisateur Utilisateur Utilisateur Utilisateur
Oracle Paralle Server (OPS) : Structure générale d une instance multi threads d Oracle Le serveur multi threads permet le partage d un petit nombre de processus entre les différents utilisateurs (c est une implémentation propre à Oracle du concept de thread). Cela améliore les performances du système du fait de la diminution du nombre de processus que le système doit géré et donc aussi du moindre coût de commutation entre les threads (par rapport aux processus). Le multiplexage entre les utilisateurs et les serveurs partagés est assuré par des processus dispatcher Deux queues, l une pour les requêtes et l autre pour les réponses assurent l interface entre ces processus dispatcher et les serveurs partagés. Le processus LSNR (Listener) est en permanence à l écoute des demandes des utilisateurs et connecte l utilisateur soit à un serveur dédié, soit à un dispatcher.
Oracle Paralle Server (OPS) : Processus d arrière plan d Oracle Ick0 Reco Reco Pmon Pmon Smon Smon System Global Area (SGA) Cache de la base de données Journal «refaire» D000 D000 S000 S000 Processus Processus Serveur Serveur partagé partagé Dbwr Dbwr Ckpt Ckpt Lgwr Lgwr Arch Arch Périphériques d archivage Fichiers de contrôle Processus utilisateur Fichiers journal «refaire» Fichiers base de données
Oracle Paralle Server (OPS) : Les différents processus d arrière plan d Oracle implémentent les fonctions principales : Arch (Archive). Processus d archivage qui enregistre le journal «refaire». Un état de la base de données peut être reconstitué à partir de ce journal et d une sauvegarde de la base. Cette sauvegarde est liée à une instance. Ckpt (CheckPoint). Processus de point de reprise qui signale à Dbwr qu un point de reprise est à effectuer et met à jour les fichiers supportant la base de données ainsi que les fichiers de contrôle. Dbwr (Data Base Writer). Processus qui écrit les blocs modifiés du cache sur disque de façon asynchrone. Dans le contexte d OPS, le Dbwr d une instance écrit sur les blocs de données requis par d autres instances. Lgwr (Log Writer). Processus qui alloue de l espace dans les fichiers journaux et écrit le contenu des journaux. Pmon (Process Monitor). Processus qui assure le recouvrement en cas de défaillance d un processus utilisateur. Reco (Distributed Transaction Recovery). Processus qui assure la récupération des transactions en attente du fait de défaillances du réseau ou d un système. Smon (System Monitor). Processus qui assure le recouvrement d une instance. Lock (Lock Process). Processus qui prend en compte la gestion du verrouillage. Jusqu à 10 processus de verrouillage peuvent être utilisés.
Oracle Paralle Server (OPS) : Les différents processus d arrière implémentent les fonctions principales : D000 (dispatcher). Ensemble de processus qui assurent le multiplexage des requêtes des utilisateurs sur les processus serveurs. S000 (Serveur). Ensemble de processus assurant l exécution des requêtes des utilisateurs. Deux techniques sont mises en œuvre pour optimiser les performances en transactionnel : Committement rapide et écriture différée (Fast commit / Deferred writte). Lors d une validation de transaction. Oracle ne met à jour que le journal. La base de données n est mise à jour que lorsque les blocs de données modifiés sont écrits par le gestionnaire du cache. Committement groupé (Group Commit). Les écritures sur le journal relatives à plusieurs transactions sont regroupés afin que le committement des transactions ne nécessite qu une seule écriture sur le journal. Il faut donc un nombre suffisant de transactions pour le committement puisse avoir lieu. Les écritures sur le journal sont alors réalisées en une seule opération d entrées sorties.
Oracle Paralle Server (OPS) : Architecture d Oracle Parallel Server Instance A Instance B Nœud 1 Nœud 2 Serveurs Partagés Smon Pmon Smon Pmon Serveurs Partagés SGA SGA arch Lgwr Dbwr Dbwr Lgwr arch DLM CGS CGS DLM Parallel Server API Parallel Server API CM I/O IPC IPC I/O CM
Oracle Paralle Server (OPS) : Les principaux composants d OPS sont : Le gestionnaire de cache parallèle (Parallel Cache Manager) (non représenté). Le groupe de service cluster CGS (Cluster Group Services). Le gestionnaire de verrous DLM (Distributed Lock Manager) qui coordonne les accès aux données entre les différentes instances. Le gestionnaire de cluster CM (Cluster Manager) surveille l état du cluster et connaît les nœuds qui en font partie. I/O pour les mécanismes d entrées sorties. IPC pour les mécanismes de communication interprocessus. Les composants CM, I/O et IC font partie du système. L interface entre ses différents composants et OPS est appelée Parallel Server API. Les processus de gestion de verrouillage gèrent des verrous distribués. Un verrou couvre plusieurs blocs de données. Source du cours: René J.Chevance