UNIVERSITE PARIS IX DAUPHINE UFR SCIENCES DES ORGANISATIONS C.E.R.I.A Interopérabilité d'un Serveur de Structures de Données Distribuées et Scalables et d'un SGBD relationnel-objet THÈSE Pour l obtention du titre de DOCTEUR EN INFORMATIQUE Yakham Ben Abdel Kader NDIAYE 13 Novembre 2001 Jury Directeur de Thèse : Rapporteurs : Suffragants : Witold LITWIN Professeur à l Université Paris IX Dauphine Tore RISCH Professeur à l Université de Uppsala, Suède Patrick VALDURIEZ Professeur à l Université Pierre et Marie Curie Gérard LEVY Professeur à l Université Paris IX Dauphine Charles BERTHET Professeur à l Université Paris IX Dauphine Ronald FAGIN Directeur Centre du Département D Informatique Fondamentale - Centre de recherche d IBM Almaden. Samba NDIAYE Sous-Directeur de la Planification et du Développement - Centre d Enseignement Supérieur Africain en Gestion. Pierre-Yves SAINTOYANT Directeur des relations Universitaires - Centre de recherche de Microsoft à Cambridge.
Remerciements Je tiens à exprimer tout particulièrement ma gratitude au professeur Witold Litwin, pour m avoir proposé le sujet de cette thèse, conseillé et dirigé tout au long de ce travail. Je le remercie pour le temps qu il m a consacré, et pour la relecture minutieuse des publications qui sont nées de ce travail. Je remercie également Monsieur Gérard Levy, professeur à l Université Paris Dauphine et responsable du DEA Informatique de l Université Cheikh Anta Diop de Dakar, de l honneur qu il me fait de présider cette thèse. J exprime ma plus profonde reconnaissance au professeur Tore Risch de l Université d Uppsala en Suède pour l intérêt constant qu il a manifesté pour mes travaux, pour sa collaboration enthousiaste et les informations techniques sur AMOS-II. Je remercie vivement le professeur Patrick Valduriez de l Université Pierre et Marie Curie pour l'intérêt qu'il a manifesté envers ce travail, en acceptant d'en être rapporteur et membre du jury. J adresse mes vifs remerciements au professeur Charles Berthet de l Université Paris Dauphine et à M. Ronald Fagin, Directeur du Département d Informatique Fondamentale au Centre de Recherche d IBM Almaden en Californie, pour avoir accepté de participer à mon jury de thèse. Je suis très honoré de leur présence. Je remercie tout particulièrement Monsieur Pierre-Yves Saintoyant, Directeur des Relations avec les Universités à Microsoft Research Europe, pour avoir accepté de participer à mon jury de thèse et pour le soutien financier, matériel de Microsoft à ce travail. Je remercie chaleureusement Monsieur Samba Ndiaye et Monsieur Tidiane Seck de l'ecole Supérieure Polytechnique de Dakar, pour l'encadrement local de ce travail, leurs conseils judicieux, leur disponibilité et leurs encouragements. Qu ils trouvent ici le témoignage de ma profonde reconnaissance. J exprime mes sincères remerciements à toute l équipe du C.E.R.I.A et à l équipe Bases de Données de l Université de Dakar, pour les fructueuses discussions qui ont beaucoup contribué à l aboutissement de mes travaux. Cette thèse a été financée par une bourse d alternance du Ministère Français de la Coopération. Je remercie la Mission Culturelle à Dakar et tout particulièrement le Conseiller Scientifique Monsieur Yves Gauffriau, pour la création de cette opportunité et le soutien constant et bienveillant de mes activités.
Résumé L évolution de l informatique lors de la dernière décennie a été caractérisée par la prolifération massive des ordinateurs interconnectés par des réseaux locaux à haute vitesse. Cette évolution a amené de nouveaux concepts d architecture matérielle. On parle souvent de multi-ordinateur, ou de Réseau de Stations de Travail ( «Network of Workstations» ) ou, plus récemment, de «Peer-to-Peer Computing» ou de «Grid Computing». Tous ces concepts ont pour but la construction d un système capable d offrir aux applications des capacités cumulées de calcul, de mémoire vive et de stockage des ordinateurs interconnectés de cette manière. Les multi-ordinateurs exigent de nouvelles organisations de données. Celles-ci doivent répondre à de nombreux impératifs. Il s agit notamment de stockage de grands volumes, d adressage décentralisé, de scalabilité, de haute-disponibilité et de sécurité accrue. Les Structures de Données Distribuées et Scalables (SDDS) sont une classe d organisation de données proposée dans ce but. Des prototypes de gestion d une SDDS ont été construits. L un d entre eux est le prototype appelé SDDS-2000 développé au CERIA. Les SDDS ont potentiellement des applications variées. Leur utilisation par les SGBDs apparaît parmi les plus prometteuses. Notre Thèse est une contribution aux techniques d application des SDDS dans un tel but. Nous étudions d abord l interopérabilité entre un SGBD et un fichier SDDS. Un tel couplage répond à un besoin connu d une application qui devrait d une part disposer d accès direct aux données, pour des manipulations de type non supporté par un SGBD. A travers le SGBD, l application devrait disposer néanmoins aussi d accès par le langage de requêtes, pour les manipulations de type SGBD. Nous examinons diverses architectures multi-ordinateur envisageables pour un tel couplage. Notre approche se base sur des techniques à la croisée des technologies des SDDS, des SGBDs en mémoire centrale, du relationnel-objet offrant la technologie de fonctions externes, et, enfin, des SGBD distribués/parallèles. Nous validons nos choix techniques par des prototypes et l étude expérimentale de performances. Cette étude amène celle d un autre volet d interopérabilité SGBD-SDDS, où un serveur SDDS utilise un SGBD en interne comme gestionnaire de mémoire. Nous montrons que ce type de système peut être vu comme une généralisation scalable d un SGBD parallèle où la partition de données devient automatique. Nous proposons des techniques correspondantes. Nous les validons également par le prototypage et les mesures de performance. Pour le prototypage et l étude expérimentale, nous utilisons le système SDDS-2000, et comme SGBD en mémoire centrale hautes performances et relationnel-objet, nous employons le prototype AMOS-II. Nous étudierons également le couplage avec DB2, comme représentant typique d un SGBD relationnel-objet commercial. L ensemble de nos résultats prouve que la technologie des SDDS ouvre effectivement de nouvelles perspectives pour celle des SGBDs. Mots clés : Multi-ordinateur, distribution de données, scalabilité, base de données en mémoire, traitement parallèle. - 1 -
Abstract The evolution of data processing in the last decade brought massive proliferation of computers inter-connected by high-speed local area networks. New architectural concepts have appeared such as the multi-computers, the Networks of Workstations and, more recently, Peer-to-Peer Computing or Grid Computing. The common goal of all these concepts is to offer to applications the cumulated CPU and storage capabilities of a large number of inter-connected computers. The multi-computers require new data organizations. Those should respond to new requirement of very large distributed data volumes, of decentralized addressing, of scalability, of highavailability and of increased security. The Scalable and Distributed Data Structures (SDDS) are a class of data structures proposed for this goal. Prototypes of SDDS management systems were built. Most recent and extensive is the SDDS-2000 system developed at CERIA and freely available for any non-commercial download at CERIA Web site. SDDS-2000 is a distributed system that stores data in the dynamically range partitioned files according to the RP* family of SDDS schemes. The data resides in the distributed RAM. Access times are many times faster than to a traditional disk file. In particular, the range queries are processed using the parallel scans. The SDDSs appear potentially useful to many applications. Their use by a DBMS appears among the most promising. Our Thesis contributes to this goal. On the one hand, we develop techniques for the interoperability of a DBMS with an external SDDS file. Many applications need such a coupling of a DBMS with an external data repository. Those require the direct fast data access for the manipulations not supported well, or at all, by a DBMS. On the other hand, they need the DBMS for the manipulations best handled through by the query language, e.g., involving joins or the aggregate functions. Those may concern the repository and other data stored internally by the DBMS. We examine various architectural issues, making such a coupling the most efficient. We base our approach on the techniques at the crossing of the SDDSs, of, the main memory DBMS, of the object-relational-dbms with the foreign functions, and, finally, of the distributed/parallel DBMS. We validate our technical choices by the prototyping and the experimental performances analysis. The latter focuses on the efficiency of complex DBMS queries to the SDDS data. We also study the coupling of DBMS and SDDS technologies where the client DBMS uses an SDDS, with the DBMS as the memory manager at each SDDS storage site. We show that such system appears as a scalable generalization of a parallel DBMS where the data partitioning becomes dynamic. We propose techniques for the efficient splits of the overloaded DBMS storage sites. We validate our proposals by the prototyping and the performances measurements. For prototyping and experimental performances analysis, we use on the one hand extensively the SDDS-2000 system. As the high-performances and object-relational- main memory DBMS, we have chosen the AMOS-II prototype developed by the University of Uppsala. We also study also the coupling with DB2, as the representative of a commercial relational- technology. Our overall results prove that the SDDS technology effectively opens new perspectives for those modern DBMSs. Key Words: Multicomputer, distributed data, scalability, main memory database, parallel processing. - 2 -
Sommaire Résumé... 1 Abstract... 2 Table des figures... 6 Chapitre 1... 7 Introduction... 7 Chapitre 2... 10 Les Structures de Données Distribuées et Scalables... 10 1 Les multi-ordinateurs... 10 1.1 Architecture à mémoire partagée... 10 1.2 Architecture à disques partagés... 11 1.3 Architecture sans mémoire partagée... 11 1.4 Scalabilité des systèmes parallèles... 12 2 Structures de Données Distribuées Scalables... 12 2.1 Structure et évolution du fichier SDDS RP*... 14 2.2 Manipulations d un fichier SDDS RP*... 17 3 Conclusion... 18 Chapitre 3... 19 Les systèmes de bases de données parallèles... 19 1 Historique des bases de données... 19 2 Les systèmes de bases de données parallèles... 20 2.1 Principes de base des SGBDs parallèles... 20 2.2 Schéma de fragmentation des données... 21 2.3 Optimisation dynamique des requêtes... 21 3 Les mécanismes de traitement parallèle... 22 3.1 Parallélisme indépendant...22 3.2 Parallélisme en tuyau... 22 3.3 Parallélisme par fragmentation... 23 4 Les principaux systèmes parallèles commerciaux... 23 4.1 Approche disque partagé... 23 4.2 Approche sans mémoire partagée... 24 5 Etude de cas... 24 5.1 Le système IBM DB2...24-3 -
5.2 Le système TERADATA NCR... 27 5.3 Le système ORACLE9i... 28 6 Conclusion... 30 Chapitre 4... 31 Couplage du SGBD AMOS-II avec les SDDS... 31 1 Hiérarchie des unités de stockage... 31 2 Les bases de données en mémoire centrale... 32 3 Le SGBD AMOS-II... 32 3.1 Interface CALLIN... 33 3.2 Interface CALLOUT... 33 3.3 Fonction externe simple...33 3.4 Implantation d une fonction externe... 34 4 Objectifs du couplage des SDDS avec AMOS-II... 34 5 Le système AMOS-SDDS... 36 5.1 Architecture de couplage AMOS-SDDS... 36 5.2 Traitement des requêtes dans AMOS-SDDS... 37 5.3 Conception du système AMOS-SDDS... 39 6 Le système SD-AMOS... 41 6.1 Architecture de couplage SD-AMOS... 41 6.2 Traitement des requêtes dans SD-AMOS... 42 6.3 Structure et évolution du fichier SD-AMOS... 42 6.4 Conception du système SD-AMOS... 43 7 Conclusion... 43 Chapitre 5... 44 Couplage du SGBD DB2 avec les SDDS...44 1 Les entrepôts de données externes... 44 2 Le SGBD IBM BD2... 44 2.1 Types de données définis par l utilisateur (UDT)... 44 2.2 Fonctions définies par l utilisateur(udf)... 44 2.3 Déclaration d une fonction externe... 46 3 Objectifs du couplage des SDDS avec DB2... 47 3.1 Architecture de couplage de DB2 avec les SDDS... 47 3.2 Traitement des requêtes dans DB2-SDDS... 48 3.3 Conception de l interface DB2-SDDS... 48-4 -
4 Conclusion... 49 Chapitre 6... 50 Implantation des prototypes... 50 1 Interface de communication entre processus distants... 50 1.1 Interface de communication entre processus distants... 50 1.2 Programmation multitâche... 57 2 Implantation du système AMOS-SDDS... 59 2.1 Client... 59 2.2 Serveur... 71 3 Implantation du système DB2-SDDS... 79 3.1 Interfaçage du client SDDS avec DB2... 79 3.2 Les fonctions externes... 79 3.3 Exemples de requêtes... 80 4 Conclusion... 81 Chapitre 7... 82 Expérimentations... 82 1 Environnement expérimental... 82 2 Etude de performances du système AMOS-SDDS... 82 2.1 Expérimentations de AMOS-II seul... 83 2.2 La Stratégie Externe... 84 2.3 La Stratégie d Importation... 85 2.4 Les Fonctions Agrégats...91 3 Etude de performances du système SD-AMOS... 93 3.1 Temps de création du fichier... 93 3.2 Temps de recherche simple... 94 3.3 Temps de recherche par intervalle... 94 4 Etude de performances du système DB2-SDDS... 95 5 Conclusion... 96 Chapitre 8... 98 Conclusion... 98 Bibliographie... 100 Annexe 1 Extended Abstract... 104 Annexe 2 Description des codes souces des prototypes... 109-5 -
Table des figures Figure 1. Multi-ordinateur avec mémoire partagée... 11 Figure 2. Multi-ordinateur à disques partagés... 11 Figure 3. Multi-ordinateur sans mémoire partagée... 12 Figure 4. Les Structures de Données Distribuées et Scalables (SDDS)... 13 Figure 5. Evolution du fichier à la suite d insertions d enregistrements... 14 Figure 6. Etat actuel du fichier... 16 Figure 7. Evolution de l image du client à la suite de la recherche d enregistrements... 16 Figure 8. Parallélisme indépendant... 22 Figure 9. Parallélisme en tuyau... 23 Figure 10. Parallélisme par fragmentation... 23 Figure 11. Parallélisme Intra-nœud de TERADATA... 28 Figure 12. Hiérarchie des mémoires... 31 Figure 13. Architecture globale de AMOS-SDDS... 35 Figure 14. Architecture globale de SD-AMOS...36 Figure 15. Architecture globale de AMOS-SDDS... 37 Figure 16. Traitement des requêtes sous AMOS-SDDS... 39 Figure 17. Architecture SD-AMOS... 41 Figure 18. Traitement des requêtes sous SD-AMOS... 42 Figure 19. Architecture de couplage DB2-SDDS... 47 Figure 20. Traitement des requêtes sous DB2-SDDS... 48 Figure 21. Correspondance entre le modèle OSI et TCP/IP... 51 Figure 22. Architecture du client... 61 Figure 23. structure du tampon avec des séparateurs... 64 Figure 24. structure du tampon avec des champs de longueur fixe... 65 Figure 25. Fichier sur quatre serveurs... 68 Figure 26. Evolution de la liste des réponses si tous les serveurs ont répondu... 68 Figure 27. Déroulement d'une fonction externe sur le client... 70 Figure 28. Architecture globale de couplage de AMOS-II avec les SDDS... 73 Figure 29. Protocole d'éclatement... 75 Figure 30. Déroulement d'une fonction externe sur le serveur AMOS-SDDS... 76 Figure 31. Déroulement d'une fonction externe sur le serveur SD-AMOS... 78 Figure 32. Temps d exécution de la requête 2 en fonction de la stratégie... 87 Figure 33. Temps d exécution de la requête 2 avec la Stratégie I et la fonction count... 87 Figure 34. Performance de AMOS-II, et de AMOS-SDDS sur un grand fichier... 88 Figure 35. Durée d exécution de la requête 2... 90 Figure 36. Extrapolation du temps de traitement de la requête 2... 90 Figure 37 Extrapolation du temps par tuple pour la requête 2 sur plusieurs serveurs... 91 Figure 38 Durée d exécution de la fonction Count... 92 Figure 39 Durée d exécution de la fonction Max...92 Figure 41. Temps moyen d insertion d un enregistrement (tuple de 100 octets)... 94 Figure 42. Temps moyen de recherche d un enregistrement... 95 Figure 43. Temps de traitement d'une requête à intervalle... 96 Figure 44. Temps par enregistrement... 96-6 -
Chapitre 1 Introduction L évolution de l informatique lors de la dernière décennie a été caractérisée par la prolifération massive des ordinateurs interconnectés par des réseaux. Il s agit surtout des ordinateurs personnels, de stations de travail et de serveurs, de moins en moins chers et sans cesse plus puissants, reliés par des réseaux locaux à haute vitesse, 10-100 Mb/s en général. Les organisations possèdent aujourd hui massivement de telles configurations. Elles comportent en général au moins un PC par employé, donc au moins plusieurs dizaines de machines interconnectées, voir plusieurs dizaines de milliers. De plus, quasiment toute machine est aujourd hui connectée à Internet. Ce dernier offre aussi la possibilité d interconnecter les ordinateurs sur des sites géographiquement distants d une organisation, ou de plusieurs organisations coopérantes. Cette évolution a amené de nouveaux concepts d architecture matérielle. On parle souvent de multi-ordinateur, ou de Réseau de Stations de Travail ( «Network of Workstations» ) ou, plus récemment, de «Peer-to-Peer Computing» ou de «Grid Computing». Ces concepts ont pour but la construction d un système capable d offrir aux applications des capacités cumulées de calcul, de mémoire vive et de stockage des ordinateurs interconnectés de cette manière[tan94]. Ces capacités apparaissent d une part potentiellement quasi illimitées. D autre part, elles semblent de facto à peine utilisées à l heure actuelle. Les multi-ordinateurs exigent de nouvelles organisations de données. Celles-ci doivent répondre à de nombreux impératifs. Il s agit notamment de stockage de grands volumes, d adressage décentralisé, de scalabilité, de haute-disponibilité et de sécurité accrue. Les Structures de Données Distribuées et Scalables (SDDS) sont une classe d organisation de données proposée dans ce but. Une SDDS répartit les données sur les nœuds de stockage interconnectés. Il peut s agir de stations de travail du multi-ordinateur. Plus généralement, il peut s agir aussi de processeurs d un super-ordinateur parallèle, ou de super-ordinateurs interconnectés ou de mémoires autonomes de type SAN («Storage Area Networks») ou NAS (Network Attached Storage) imbriqués dans un multi-ordinateur. La répartition est dynamique et transparente pour l application. Une SDDS peut notamment stocker de grands volumes de données en mémoire centrale du multi-ordinateur. L accès à ces données est bien plus rapide qu aux données stockées sur les disques. Des - 7 -
prototypes de gestion d une SDDS ont été construits, notamment celui appelé SDDS-2000 développé au CERIA. Les SDDS ont potentiellement des applications variées. Leur utilisation par les SGBDs apparaît parmi les plus prometteuses. Notre Thèse est une contribution aux techniques d application des SDDS dans un tel but. Nous étudions l interopérabilité entre un SGBD et un fichier SDDS. Un tel couplage répond à un besoin connu d une application qui devrait d une part disposer d accès direct aux données, pour des manipulations de type non supporté par un SGBD. D autre part à travers le SGBD, l application devrait également disposer d accès par le langage de requêtes, pour les manipulations de type SGBD. Un tel couplage permet enfin à un SGBD de gérer des volumes de données plus grands que la capacité de ses mémoires internes. Tout particulièrement, quand il s agit d un SGBD en mémoire centrale pour des applications à hautes performances. Nous examinons diverses architectures multi-ordinateur envisageables pour un tel couplage. Notre approche se base sur les techniques à la croisée des technologies des SDDS, des SGBDs en mémoire centrale, du relationnel-objet offrant la technologie de fonctions externes, et, enfin, des SGBD distribués/parallèles. Nous validons nos choix techniques par des prototypes et l étude expérimentale de performances. Cette étude amène celle d un autre volet d interopérabilité SGBD-SDDS, où un serveur SDDS utilise un SGBD en interne comme gestionnaire de mémoire. Nous montrons que ce type de système peut être vu comme une généralisation scalable d un SGBD parallèle où la partition de données devient automatique. Nous proposons des techniques correspondantes. Nous les validons également par l implantation de prototypes et les mesures de performance. Pour le prototypage et l étude expérimentale, nous utilisons le système SDDS-2000. Dans le cadre de cette Thèse nous avons contribué à la conception et l implantation de certaines fonctions de ce prototype. Comme SGBD en mémoire centrale hautes performances et relationnel-objet, nous employons le prototype AMOS-II. Nous étudierons aussi le couplage avec DB2, comme représentant typique d un SGBD relationnel-objet commercial. L ensemble des nos résultats montre que la technologie des SDDS ouvre effectivement de nouvelles perspectives pour celle des SGBDs. La suite du document est organisée comme suit : Le chapitre 2 présente les concepts de base des Structures de Données Distribuées et Scalables(SDDS). Nous passons en revue les multi-ordinateurs - un nouveau concept - 8 -
d architecture matérielle. Nous présentons ensuite les SDDS - une nouvelle classe d organisation de données, définie spécifiquement pour les multi-ordinateurs. Le chapitre 3 présente les concepts de base des systèmes parallèles. Nous passons en revue les mécanismes de traitement parallèle et les problèmes soulevés par leur mise en œuvre. Une attention est portée sur les solutions actuellement retenues par les systèmes commercialisés. Le chapitre 4 présente le système AMOS-II et ses possibilités d interopérabilité avec d autres systèmes, plus particulièrement les fonctions de manipulation de données externes. Les objectifs du couplage des SDDS avec les systèmes AMOS-II et les problèmes techniques relatifs à la conception d un système de base de données dynamique en mémoire principale sont soulevés à ce niveau. Le chapitre 5 présente les objectifs du couplage des SDDS avec le SGBD DB2 et donne une description détaillée du prototype qui a été implanté. Nous présentons d abord les possibilités de manipulation de données externes proposées par DB2. Nous étudions ensuite l utilisation d un fichier SDDS par un SGBD comme un entrepôt de données externes. Le chapitre 6 présente les architectures fonctionnelles retenues pour le couplage du gestionnaire SDDS avec les systèmes AMOS-II et DB2 ainsi que les mécanismes de traitement parallèle des requêtes. Les outils techniques pour la mise en œuvre des prototypes sont décrits en premier. Il s agit notamment des interfaces de communication entre processus distants et de la mise en œuvre du multitâche sous Windows. Le chapitre 7 présente l'environnement expérimental et les mesures de performance. L accent est mis sur l analyse de la scalabilité des prototypes qui ont été implantés. Le chapitre 8 conclut ce document et présente les perspectives de recherche. Un résumé étendu en anglais de la thèse est présenté en annexe. - 9 -
Chapitre 2 Les Structures de Données Distribuées et Scalables Dans ce chapitre, nous passons en revue les multi-ordinateurs - un nouveau concept d architecture matérielle qui est le résultat des progrès réalisés dans la vitesse des réseaux. Nous présentons ensuite une nouvelle classe d organisation de données définie spécifiquement pour les multi-ordinateurs. Les Structures de Données Distribuées et Scalables (SDDS) sont conçues pour contourner les insuffisances des structures de données distribuées classiques, notamment le point d accès unique ou les schémas de fragmentation statiques. Nous présentons les concepts de base des SDDS en insistant sur les algorithmes RP* qui ont été retenus dans l implantation des prototypes. 1 Les multi-ordinateurs Des recherches avancées sont menées pour mieux exploiter la puissance de calcul d un ensemble d ordinateurs interconnectés à travers des réseaux à haut débit (>10MBits) [MC99], [CACM97], [Gra96], [GW97]. De telles configurations existent déjà dans plusieurs organisations. Des termes sont apparus pour désigner les machines organisées de la sorte : multi-ordinateurs, Réseau de Stations de Travail ( «Network of Workstations» ) ou, plus récemment, de «Peer-to-Peer Computing» ou de «Grid Computing». Les capacités cumulées de traitement parallèle et de stockage d un multi-ordinateur sont impressionnantes et même supérieures aux performances des gros systèmes. De telles configurations sont évolutives et exploitent au mieux les progrès constants au niveau du matériel. Les multi-ordinateurs se caractérisent par la manière dont leurs composants de base (la mémoire principale, le processeur (CPU) et les mémoires secondaires) sont interconnectés. Ainsi les trois architectures, décrites par la suite, ont été proposées et implantées ces dernières années. 1.1 Architecture à mémoire partagée Dans un multi-ordinateur à mémoire partagée ou en grappe (ang. Shared-memory), tous les processeurs accèdent à une grande mémoire commune [Vra95]. L accès aux disques est également partagé. Ainsi, chaque processeur a un accès direct à toutes les portions de la mémoire ou des disques. Tout le système est en général regroupé dans une même machine. L équilibrage de charge ou la synchronisation des processeurs se réalise facilement à travers la mémoire partagée. L accès concurrent à la mémoire peut devenir un goulot d étranglement quand le nombre de - 10 -
processeurs devient important. Egalement, les accès fréquents aux disques entraînent un flux de données trop important sur le réseau. Cette surcharge du réseau ralentit tout le système. La Figure 1 schématise un multi-ordinateur à mémoire partagée avec les lettres P qui symbolisent les processeurs, M la mémoire centrale et D les disques. P P P Réseau Mémoire globale partagée D D D Figure 1. Multi-ordinateur avec mémoire partagée 1.2 Architecture à disques partagés Dans un multi-ordinateur à disques partagés (ang. Shared-disk), chaque processeur dispose d un accès direct à une mémoire privée. Seul l accès aux disques est partagé. Cette architecture élimine les interférences des processeurs sur la mémoire principale et réduit la congestion du réseau. La Figure 2 représente un multi-ordinateur à disques partagés. M M M P P P Réseau D D D Figure 2. Multi-ordinateur à disques partagés 1.3 Architecture sans mémoire partagée Dans un multi-ordinateur sans mémoire partagée (ang. Shared-nothing), chaque processeur dispose d un accès exclusif à la mémoire et aux disques qui lui sont reliés. L ensemble (processeur, mémoire et disque) est appelé nœud. Aucun processeur ne peut accéder directement à une mémoire ou un disque sur un poste distant. L échange d informations entre deux nœuds se fait à travers une connexion réseau. La Figure 3 présente un multi-ordinateur sans mémoire partagée. - 11 -
Réseau P P P M M M D D D Figure 3. Multi-ordinateur sans mémoire partagée En réduisant les ressources partagées, cette architecture élimine les interférences entre processeurs. Un multi-ordinateur sans mémoire partagée supporte la monté en charge mieux que les deux autres architectures. L équilibrage de charge entre les différents nœuds est plus difficile à mettre en œuvre dans les multi-ordinateurs sans mémoire partagée. 1.4 Scalabilité des systèmes parallèles La notion de scalabilité (anglicisme) est apparue avec les systèmes multiprocesseurs. C est une caractéristique des architectures qui sont capables de s'adapter à l'évolution des besoins tout en conservant leurs propriétés fonctionnelles. La scalabilité est aujourd'hui un critère déterminant dans la recherche d'une architecture, puisqu'elle est synonyme de souplesse et d'optimisation des choix technologiques[win99]. La mesure de la scalabilité d un système se fait principalement sur les trois paramètres suivants : la taille des données (size up), le temps de réponse (speed up), et la charge de travail (scale up). L analyse du comportement d un système en fonction de la variation de ces paramètres permet de le classer par rapport à l'idéal d une montée à l échelle linéaire. Le size up se rapporte au principe suivant: dans un système scalable en supposant une configuration matérielle constante, si la taille des données augmente d un facteur de n, alors le temps de réponse d une requête augmentera au plus d un facteur de n. Le speed up se rapporte au principe suivant: Si la capacité de traitement de la configuration matérielle augmente d un facteur de n, alors dans un système scalable, le temps de réponse d une requête doit diminuer au minimum d un facteur de n. Le scale up se rapporte au principe suivant: Si la charge de travail sur un système augmente d un facteur de n, alors dans un système scalable, il suffit d augmenter la capacité de traitement d un facteur pas plus de n pour maintenir le même temps de réponse. 2 Structures de Données Distribuées Scalables Les Structures de Données Distribuées et Scalables (SDDS) constituent une nouvelle classe d organisation de données, définie spécifiquement pour les multi-ordinateurs (voir Figure 4). Elles sont conçues pour contourner les insuffisances des structures de données distribuées - 12 -
classiques, notamment le point d accès unique ou les schémas de fragmentation statiques. Plusieurs SDDSs ont été proposées [LNS93], [LNS94], [LMRS00], [Knu98], Des serveurs SDDS prototypes ont été implantés à Paris 9 Dauphine notamment [Sah00] et à l'université de Dakar [Die97], [SND98]. Un fichier SDDS est stocké sur des sites désignés serveurs. Sur chaque serveur, les enregistrements sont stockés sur un espace mémoire appelé case. Un paramètre important d une case est sa capacité qui détermine le nombre maximum d enregistrements qu elle peut contenir. Un enregistrement comporte un champ-clé et des champs non-clés. Le champ clé identifie l enregistrement de manière unique sur l ensemble des serveurs. Les requêtes sont formulées à partir de sites autonomes désignés clients. Il n y a pas de répertoire central d accès. Chaque client dispose de sa propre image de la structure du fichier. Dés qu un serveur atteint sa capacité maximale, il transfère la moitié de ses enregistrements vers un nouveau serveur. Les mises à jour de la structure d une SDDS ne sont pas envoyées aux clients d une manière synchrone. Un client peut faire des erreurs d adressage. Chaque serveur vérifie l adresse de la requête et l achemine vers un autre serveur si une erreur est détectée. Le serveur adéquat envoie alors un message correctif (IAM - Image Adjustment Message) au client ayant commis l erreur d adressage. Ce dernier ajuste son image pour ne plus faire la même erreur. Les IAMs font converger l image d un client vers celle réelle. La fragmentation des données sur les sites de stockage se fait par hachage ou par intervalle. Nos travaux portent sur les algorithmes RP* permettant de créer un fichier qui peut s étendre de manière dynamique sur plusieurs serveurs, tout en maintenant les enregistrements triés suivant la valeur de leur clé [Ndi98]. RP* réalise la fragmentation dynamique par intervalle (Range Partitioning) et supporte, comme les arbres-b des requêtes à intervalle ou un parcours ordonné du fichier par rapport à la clé [DL00]. SDDS Structures de données Les classiques Hachage Arbre 1-d RP* Arbre k-d k-rp* LH*, LH*LH RP* N, RP* C, RP* S k-rp* N, k-rp* C, DDH, LH*RAIS k-rp* S Figure 4. Les Structures de Données Distribuées et Scalables (SDDS) - 13 -
2.1 Structure et évolution du fichier SDDS RP* Dans un fichier RP*, chaque case est munie d un en-tête contenant deux valeurs λ et Λ. Ces dernières sont respectivement la clé minimale et la clé maximale des enregistrements pouvant être insérés dans la case. Une case d intervalle ]λ, Λ] contient donc les enregistrements de clé c tel que λ < c Λ. A la création, un fichier RP* débute sur une case unique notée case 0. Toutes les insertions d enregistrements vont vers la case 0. Si le nombre d enregistrements atteint la capacité maximale, alors toute tentative d insertion provoque un éclatement qui se déroule en trois étapes : création d une nouvelle case, migration de la moitié des enregistrements de la case 0 vers la nouvelle case numérotée case 1, modification de l intervalle de la case 0 et détermination de celui de la case 1. Si cm est la clé de l enregistrement du milieu de la case en débordement, alors la case 0 devient : Case 0 ]λ, Λ ] => Case 0 ]λ, cm ] et Case 1 ]cm, Λ ]. Ce processus est répété pour toute case qui devient surchargée par les insertions. La Figure 5 présente l évolution d un fichier à la suite de trois éclatements. Un fichier peut ainsi s étendre sur un nombre infini de cases. Ce qui rend la capacité de stockage illimitée. 3 37 34 21 21 7 37 7 3 34 + 21 + 21 0 0 1 18 21 16 37 16 7 34 7 3 21 30 + 3 16 21 0 1 0 8 16 13 7 3 16 0 37 34 30 + 21 1 21 20 18 21 16 2 37 34 21 30 18 + 21 21 16 1 2 8 37 21 7 34 20 16 3 30 18 13 8 + 21 21 16 16 8 0 1 2 3 Figure 5. Evolution du fichier à la suite d insertions d enregistrements Une SDDS RP* est composée de trois variantes dénommées RP*N, RP*C et RP*S. Elles se distinguent par les techniques d adressage utilisées pour acheminer les requêtes d un client vers le serveur adéquat. Un client RP*N envoie les requêtes aux serveurs en utilisant uniquement des messages de diffusion. Un client RP*C est une reprise du client RP*N auquel on ajoute une image du fichier pour réduire l envoi de requêtes par une diffusion. Le client utilise des messages point à point pour envoyer les requêtes vers les serveurs connus de son image. Les serveurs utilisent toutefois des messages de diffusion pour rediriger les requêtes en cas d erreur d adressage. Finalement RP*S ajoute à RP*C un index distribué au niveau des serveurs. Les requêtes et les redirections sont envoyées par des messages point à point. - 14 -
Notre travail porte sur la variante RP*C. Les détails de la manipulation de fichier RP*C sont présentés dans les sections suivantes. 2.1.1 Structure de l'image du client L image du fichier est une collection d intervalles et d adresses de sites qui traduit la répartition des enregistrements sur les cases et les serveurs qui les hébergent. Elle est représentée par une table dynamique T[0, 1, ]. Chaque élément T[i] de cette table contient l adresse d une case et son intervalle. Logiquement, la table T est une liste ordonnée de couples T[i] = (A, C) avec : A : Adresse d une case du fichier SDDS Posons A = * (une adresse de diffusion) inconnue. si elle correspond à une adresse C : Clé maximale Λ(A) que peut contenir la case A. Initialement T =[(0, ), et évolue en fonction des messages correctifs (IAM) reçus qui entraînent l insertion ou la mise à jour des valeurs de la table. 2.1.2 Envoi d une requête par un client Une requête sur un enregistrement de clé c est exécutée de la manière suivante : Le client parcourt les couples t = (A, C) de son image et recherche le premier élément dont la clé est immédiatement supérieure à la clé c. - Si A(t) * alors envoyer la requête à la case d'adresse A par un message point à point. - Sinon, envoyer la requête par un message de diffusion. 2.1.3 Traitement d une requête par un serveur Chaque serveur qui reçoit une requête vérifie si la clé qui y est contenue appartient à son intervalle. Deux cas peuvent se présenter : 1) La clé n appartient pas à l intervalle du serveur: - Si c est par un message de diffusion, alors le serveur ne fait rien; - Si c est par un message point à point, alors le serveur insère dans le message reçu l adresse et l intervalle de la case puis l envoie par diffusion aux autres serveurs : il s agit de la redirection d une requête. 2) La clé appartient à l intervalle du serveur: - Si c est un message redirigé, alors le serveur traite la requête et envoie une réponse au client avec l adresse et l intervalle du serveur intermédiaire, l adresse et l intervalle du serveur courant. - 15 -
- Sinon envoyer la réponse avec l adresse et l intervalle du serveur courant au client. 2.1.4 Ajustement de l'image du client La réponse à une requête contient un champ IAM qui permet au client de corriger son image de la répartition du fichier sur les serveurs(cf. Figure 6). L IAM se présente sous forme d'un ou de deux triplets (λ, a, Λ) : l intervalle du serveur qui a traité la requête (]λ,λ ]) et «a» son adresse. L'ajustement de l'image du client se fait donc de manière asynchrone suivant l algorithme cidessous : (a) S'il n'existe pas un élément t appartenant à T avec C(t) = λ et λ alors insérer (*, λ) dans T. (b) S'il existe un élément t appartenant à T avec C(t) > Λ alors : si C(t) = + alors t = (a, Λ) et ajouter (*, + ) dans T. si C(t) < + alors t = (a, Λ). (c) S'il existe un élément t appartenant à T avec t = (*, Λ) alors t = (a, Λ). (d) S'il n'existe pas d élément t = (a, Λ) appartenant à T alors insérer (a, Λ) dans T. 8 37 21 7 34 20 16 3 30 18 13 8 + 21 16 21 16 8 C0 C1 C2 C3 Figure 6. Etat actuel du fichier La Figure 7 montre l évolution de l image du client à la suite de la recherche de quatre clés avec l état initial suivant : T0 [C 0, + ] Clé recherchée IAM évolution image du client 7 C 0 (-,8) T1 [C 0, 8] [*, + ] 19 C 2 (16,21) T2 [C 0, 8] [*, 16] [C 2, 21] [*, + ] 34 C 1 (21,+ ) T3 [C 0, 8] [*, 16] [C 2, 21] [C 1, + ] 11 C 3 (8,16) T4 [C 0, 8] [C 3, 16] [C 2, 21] [C 1, + ] Figure 7. Evolution de l image du client à la suite de la recherche d enregistrements - 16 -
2.2 Manipulations d un fichier SDDS RP* L accès au fichier se fait à travers des requêtes émises à partir des sites clients. Une requête du type recherche, modification ou suppression d un enregistrement est dite simple. Une requête parallèle est de trois types : une recherche par intervalle, une sélection avec des critères sur des champs non-clés ou un déport de fonction. Une requête à intervalle correspond à la recherche des enregistrements dont les clés appartiennent à l intervalle de recherche. Une recherche peut aussi correspondre à une sélection des enregistrements dont un champ non-clé vérifie certains critères. Un déport de fonction consiste à lancer un traitement prédéfini sur les serveurs et à récupérer les résultats sur le client. Un client peut aussi effectuer un parcours transversal du fichier qui consiste à examiner séquentiellement tous les enregistrements suivant l ordre croissant des clés. 2.2.1 Requête simple Avant d envoyer une requête simple, le client consulte son l image. La requête est traitée par le serveur S d intervalle ]λ, Λ] telle que c ]λ, Λ]. Le serveur S exécute la requête, puis envoie la réponse au client. 2.2.2 Requête à intervalle Elle consiste en la recherche ou la mise à jour d un ensemble d enregistrements de clé c appartenant à un intervalle [a, b], avec a < b. Une requête à intervalle est envoyée à l aide d un message de diffusion. Soit [a, b] R l intervalle d une requête de recherche R, envoyée par un client à un groupe de n serveurs, S 1, S 2, S n. Soit ]λ i, Λ i ] l intervalle du serveur S i, avec 1 i n. La requête R est traitée par tous les serveurs S i tels que ]λ i, Λ i ] [a, b] R {}. Le traitement de la requête se fait en parallèle sur ce groupe de serveurs. Chaque exécution porte sur un fragment de l intervalle [a, b] R. Après le traitement, les serveurs concernés envoient les résultats partiels au client. Ce dernier reçoit les enregistrements triés suivant la valeur de leur clé en effectuant l union des intervalles de réponse ]λ i, Λ i ] pour 1 i < n de telle sorte que λ i = Λ i+1. 2.2.3 Terminaison des requêtes à intervalle Le résultat d une requête à intervalle provient de plusieurs serveurs du fait du stockage distribué. Le client ne connaît pas d avance le nombre de serveurs devant répondre. Il se pose ainsi le problème de la terminaison d une requête. Il s agit de déterminer à quel moment sont reçues toutes les réponses. La terminaison est dite probabiliste si le client fixe un délai d attente à - 17 -
l expiration duquel il estime que toutes les réponses sont reçues. Dans ce cas, seuls les serveurs qui ont des données à envoyer répondent. Elle est dite déterministe si tous les serveurs sont tenus d envoyer pour chaque requête reçue, leur intervalle et éventuellement les données résultats. Le client arrête l attente des résultats d une requête dès qu il vérifie que l union des intervalles des serveurs qui ont répondu recouvre l intervalle de recherche. Des mécanismes de reprise peuvent être envisagés pour effectuer des relances sur les serveurs manquants. La bonne estimation du délai d attente se pose pour la terminaison probabiliste. Il doit être supérieur au temps de parcours aller et retour d un message sur le réseau, majoré du délai de prise en compte d une requête par un serveur. Une amélioration du temps de réponse peut être obtenue avec un délai qui prend deux valeurs : le temps d attente de la première réponse, puis le délai estimé entre l arrivée de deux messages. 3 Conclusion Nous avons essayé dans ce chapitre de faire ressortir les avantages des SDDS par rapport aux structures de données classiques. Nous avons exposé les principes de bases des SDDS et en particulier les algorithmes RP*. Nous pouvons retenir les caractéristiques suivantes des SDDS : les données d une SDDS résident en mémoire vive ce qui leur garantie les meilleurs temps d accès possibles. Un fichier SDDS débute sur un seul site de stockage et peut être étendu par des insertions à un nombre quelconque de sites. Ceci rend sa capacité de stockage potentiellement illimitée. Les données sont stockées sur plusieurs serveurs qui effectuent tous les traitements en parallèle, ce qui fait que l augmentation de la taille des données ne détériore pas les performances d accès. Ces caractéristiques doivent assurer aux SDDS des performances de traitement inconnues des structures de données classiques. Les SDDS ont potentiellement des applications variées et leur utilisation par les SGBDs apparaît parmi les plus prometteuses. - 18 -