Jury. Directeur de Thèse :

Transcription

1 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.

2 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.

3 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

4 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

5 Sommaire Résumé... 1 Abstract... 2 Table des figures... 6 Chapitre Introduction... 7 Chapitre Les Structures de Données Distribuées et Scalables Les multi-ordinateurs Architecture à mémoire partagée Architecture à disques partagés Architecture sans mémoire partagée Scalabilité des systèmes parallèles Structures de Données Distribuées Scalables Structure et évolution du fichier SDDS RP* Manipulations d un fichier SDDS RP* Conclusion Chapitre Les systèmes de bases de données parallèles Historique des bases de données Les systèmes de bases de données parallèles Principes de base des SGBDs parallèles Schéma de fragmentation des données Optimisation dynamique des requêtes Les mécanismes de traitement parallèle Parallélisme indépendant Parallélisme en tuyau Parallélisme par fragmentation Les principaux systèmes parallèles commerciaux Approche disque partagé Approche sans mémoire partagée Etude de cas Le système IBM DB

6 5.2 Le système TERADATA NCR Le système ORACLE9i Conclusion Chapitre Couplage du SGBD AMOS-II avec les SDDS Hiérarchie des unités de stockage Les bases de données en mémoire centrale Le SGBD AMOS-II Interface CALLIN Interface CALLOUT Fonction externe simple Implantation d une fonction externe Objectifs du couplage des SDDS avec AMOS-II Le système AMOS-SDDS Architecture de couplage AMOS-SDDS Traitement des requêtes dans AMOS-SDDS Conception du système AMOS-SDDS Le système SD-AMOS Architecture de couplage SD-AMOS Traitement des requêtes dans SD-AMOS Structure et évolution du fichier SD-AMOS Conception du système SD-AMOS Conclusion Chapitre Couplage du SGBD DB2 avec les SDDS Les entrepôts de données externes Le SGBD IBM BD Types de données définis par l utilisateur (UDT) Fonctions définies par l utilisateur(udf) Déclaration d une fonction externe Objectifs du couplage des SDDS avec DB Architecture de couplage de DB2 avec les SDDS Traitement des requêtes dans DB2-SDDS Conception de l interface DB2-SDDS

7 4 Conclusion Chapitre Implantation des prototypes Interface de communication entre processus distants Interface de communication entre processus distants Programmation multitâche Implantation du système AMOS-SDDS Client Serveur Implantation du système DB2-SDDS Interfaçage du client SDDS avec DB Les fonctions externes Exemples de requêtes Conclusion Chapitre Expérimentations Environnement expérimental Etude de performances du système AMOS-SDDS Expérimentations de AMOS-II seul La Stratégie Externe La Stratégie d Importation Les Fonctions Agrégats Etude de performances du système SD-AMOS Temps de création du fichier Temps de recherche simple Temps de recherche par intervalle Etude de performances du système DB2-SDDS Conclusion Chapitre Conclusion Bibliographie Annexe 1 Extended Abstract Annexe 2 Description des codes souces des prototypes

8 Table des figures Figure 1. Multi-ordinateur avec mémoire partagée Figure 2. Multi-ordinateur à disques partagés Figure 3. Multi-ordinateur sans mémoire partagée Figure 4. Les Structures de Données Distribuées et Scalables (SDDS) Figure 5. Evolution du fichier à la suite d insertions d enregistrements Figure 6. Etat actuel du fichier Figure 7. Evolution de l image du client à la suite de la recherche d enregistrements Figure 8. Parallélisme indépendant Figure 9. Parallélisme en tuyau Figure 10. Parallélisme par fragmentation Figure 11. Parallélisme Intra-nœud de TERADATA Figure 12. Hiérarchie des mémoires Figure 13. Architecture globale de AMOS-SDDS Figure 14. Architecture globale de SD-AMOS...36 Figure 15. Architecture globale de AMOS-SDDS Figure 16. Traitement des requêtes sous AMOS-SDDS Figure 17. Architecture SD-AMOS Figure 18. Traitement des requêtes sous SD-AMOS Figure 19. Architecture de couplage DB2-SDDS Figure 20. Traitement des requêtes sous DB2-SDDS Figure 21. Correspondance entre le modèle OSI et TCP/IP Figure 22. Architecture du client Figure 23. structure du tampon avec des séparateurs Figure 24. structure du tampon avec des champs de longueur fixe Figure 25. Fichier sur quatre serveurs Figure 26. Evolution de la liste des réponses si tous les serveurs ont répondu Figure 27. Déroulement d'une fonction externe sur le client Figure 28. Architecture globale de couplage de AMOS-II avec les SDDS Figure 29. Protocole d'éclatement Figure 30. Déroulement d'une fonction externe sur le serveur AMOS-SDDS Figure 31. Déroulement d'une fonction externe sur le serveur SD-AMOS Figure 32. Temps d exécution de la requête 2 en fonction de la stratégie Figure 33. Temps d exécution de la requête 2 avec la Stratégie I et la fonction count Figure 34. Performance de AMOS-II, et de AMOS-SDDS sur un grand fichier Figure 35. Durée d exécution de la requête Figure 36. Extrapolation du temps de traitement de la requête Figure 37 Extrapolation du temps par tuple pour la requête 2 sur plusieurs serveurs Figure 38 Durée d exécution de la fonction Count 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) Figure 42. Temps moyen de recherche d un enregistrement Figure 43. Temps de traitement d'une requête à intervalle Figure 44. Temps par enregistrement

9 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, 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 -

10 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 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 -

11 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

12 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

13 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

14 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

15 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)

16 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 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

17 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 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 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 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

18 - Sinon envoyer la réponse avec l adresse et l intervalle du serveur courant au client 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 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

19 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 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 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 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 à

20 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

21 Chapitre 3 Les systèmes de bases de données parallèles Ce chapitre passe en revue les concepts de base des SGBDs parallèles et les problèmes que soulève leur mise en œuvre. Notre attention est portée sur les techniques de fragmentation des données et les mécanismes de traitements parallèles. Nous étudions en détail les solutions proposées par trois systèmes parallèles commerciaux : DB2, TERADATA et ORACLE. 1 Historique des bases de données Stocker et traiter les données furent les premiers objectifs des applications informatiques. Le premier système de gestion de base de données appelé «Integrated Data Store» fut proposé au début des années 60 par Charles Bachman de General Electric. Il était basé sur le modèle de données réseau qui a été normalisé par le CODASYL(Conference on Data Systems Languages) et qui a fortement influencé les bases de données dans les années 60. A la fin des années 60, IBM a développé le SGBD IMS (Information Management System) basé sur le modèle de données hiérarchique. En 1970, Edgar Codd du laboratoire de recherche IBM de San Jose a proposé un nouveau modèle de représentation des données, appelé modèle relationnel. Ce fut l élément précurseur du développement rapide de plusieurs SGBDs basés sur le modèle relationnel. Les bases de données deviennent une discipline académique et la popularité des SGBDs relationnels change le paysage informatique. Les avantages furent largement reconnus et l utilisation d un SGBD pour gérer les données de l entreprise devint une pratique courante. Dans les années 80, le modèle relationnel consolide sa position dominante dans les SGBDs. Les domaines d utilisation des bases de données s élargissent. Le langage de requêtes SQL pour les bases de données relationnelles, développé par IBM dans le cadre de son projet System R, devient un standard. La version SQL-92 est adoptée par l ANSI(American National Standards Institute) et par l'iso(international Standards Organisation). Les systèmes de base de données s enrichissent d un modèle d exécution concurrente de programmes, appelé transaction proposé par Jim Gray[GR93]. Les programmes sont écrits comme s ils s exécutaient seuls. Toutes les tâches de gestion des accès concurrents incombent au SGBD. Dans les années 90, des avancées ont été accomplies dans plusieurs domaines des SBGD. Des recherches intensives visent à enrichir le langage de requêtes et le modèle de représentation des données afin de supporter la complexité croissante des données à analyser. Des extensions ont

22 été apportées à plusieurs systèmes (IBM DB2, Oracle, Informix) pour stocker de nouveaux types de données tels que l image, le son ou le texte et pour formuler des requêtes complexes. Les performances des systèmes de base de données sont intrinsèquement liées aux vitesses de traitement et aux capacités de stockage des machines sur lesquelles ils opèrent. Au cours des dernières années, la vitesse des CPU a constamment augmenté. Parallèlement, la vitesse des réseaux a connu des améliorations importantes avec des débits de plus en plus élevés. Les débits de Mb sont aujourd hui courants sur les réseaux locaux. Mais, les disques durs sont restés limités au temps d accès de l ordre de 10 ms en moyenne par des contraintes mécaniques. Ainsi, grâce aux progrès réalisés sur les réseaux et la puissance de calcul des machines, nous constatons que l accès aux données sur une mémoire distante est maintenant plus rapide que la lecture de données stockées sur un disque local. 2 Les systèmes de bases de données parallèles 2.1 Principes de base des SGBDs parallèles Une base de données centralisée est gérée par un seul SGBD. Elle est stockée dans sa totalité à un emplacement physique unique et ses divers traitements sont confiés à une seule et même unité de traitement. Par opposition, une base de données parallèle est gérée par plusieurs processeurs, sites ou SGBDs. Les bases de données parallèles ont pour problématique la distribution des données sur plusieurs unités qui coopèrent pour traiter les requêtes en parallèle [OV99]. Un concept proche est celui de bases de SGBD Distribués. Une base de données est dite distribuée si les données sont stockées sur des sites, géographiquement distants, reliés par un réseau. La réunion de ces parties forme la base de données distribuée. Plusieurs projets de recherche, notamment gamma [Dew90], Bubba [Bor90], Mariposa [SAL96], ont étudié divers aspects de la conception de systèmes de bases de données parallèles. Les caractéristiques attendues des systèmes parallèles sont multiples : transparence de la gestion des données, meilleures performances, plus grande fiabilité et la scalabilité. La transparence vise à cacher aux utilisateurs les détails de l implantation et à leur présenter l image d un système unique. Elle s applique à la fragmentation et à la localisation des données, aux communications réseau, au choix des nœuds devant participer aux traitements parallèles. Les performances peuvent être améliorées par la répartition de la charge de travail sur plusieurs unités de traitement qui opèrent en parallèle. Un système parallèle dispose de plusieurs unités de traitement sur des ordinateurs différents. La panne d un composant n affecte pas tout le système. Il en résulte une plus grande fiabilité et une meilleure tolérance aux pannes. Un système est dit extensible s il supporte une croissance modulaire. Le but visé est de pouvoir

23 augmenter la puissance de calcul et la capacité de stockage en rajoutant simplement des modules supplémentaires au système existant. L'évolution progressive est alors assurée avec une réutilisation de l'existant. 2.2 Schéma de fragmentation des données L'affectation des fragments de données sur les sites peut être faite en fonction des types de requêtes qui seront les plus fréquemment exécutées sur les données. Le but est de placer les fragments sur les sites où ils sont le plus utilisés, pour minimiser les transferts de données. Notre expérimentation consiste à utiliser les algorithmes SDDS qui permettent une fragmentation dynamique des données par intervalle ou par hachage, sur un nombre indéfini de serveurs. C est une solution pour surmonter les schémas de fragmentation statiques des systèmes parallèles actuels, notamment DB2, NonStop SQL Tandem[Tand88], Sybase, Teradata NCR, Informix. 2.3 Optimisation dynamique des requêtes L optimisation de requêtes dans un environnement distribué est l objet d une recherche abondante [BDD99], [CHA98], [LIM93], [SD89], [KD99]. Les règles d'exécution et les méthodes d'optimisation de requêtes définies pour le contexte centralisé sont toujours valables. Mais il faut maintenant prendre en compte d'une part la fragmentation et la répartition des données sur différents sites et d'autre part le coût des communications entre sites pour les transferts de données. Le problème de la fragmentation avec ou sans duplication concerne principalement les mises à jours, tandis que le problème des coûts des communications concerne surtout les requêtes. Comme pour le traitement de requêtes sur les bases de données centralisées, l'arbre algébrique de la requête est généré et optimisé avec les mêmes critères. Chaque feuille de l'arbre représente une relation, et chaque nœud représente une opération algébrique (opérateur et opérandes). La requête algébrique optimisée est ensuite enrichie avec les informations sur la localisation des données, et sur l affectation des tâches aux sites de traitement. Le temps total d'exécution d'une requête tient compte du temps de calcul CPU nécessaire pour exécuter les opérations algébriques (jointures, sélections, projections...), mais aussi et surtout du temps de transfert des données. L'optimisation de requêtes dans les SGBDs centralisés est principalement statique. Le plan d exécution est d abord calculé en se basant sur le volume des données pour savoir si une opération peut être effectuée totalement ou partiellement en mémoire centrale. Les moyens d'accès (index, ordonnancement, tri) sont aussi pris en compte. L'optimisation de requêtes dans un environnement distribué se base en plus sur le temps de communication qui est fonction des critères suivants : volume de données à transférer, nombre de communications, temps d'accès et

24 temps de réponse, temps de calcul UC sur chaque site. 3 Les mécanismes de traitement parallèle Le plan d exécution d une requête relationnelle est un graphe d opérations algébriques. Certaines opérations du graphe peuvent être exécutées en parallèle. Le traitement de requêtes dans un environnement distribué a fait l objet d une recherche importante [CW98], [GW99], [Kos00]. Plusieurs algorithmes sont proposés pour exploiter au maximum le parallélisme des traitements [ASS94], [DNSS92], [HCY94]. Le parallélisme peut intervenir à différents niveaux. Des requêtes concurrentes peuvent être prises en charge par des processeurs différents. Chaque processeur se charge du traitement intégral d une requête. Il s agit du parallélisme inter-requêtes. Les différentes opérations d une même requête peuvent être exécutées en parallèle par des processeurs différents. Il s agit du parallélisme inter-opérations. Une même opération peut être traitée simultanément par plusieurs processeurs. Il s agit du parallélisme intra-opérations. Il existe trois mécanismes de base pour réaliser le parallélisme des traitements que sont, le parallélisme indépendant, le parallélisme en tuyau et le parallélisme indépendant. 3.1 Parallélisme indépendant Il s agit du cas où une requête comporte plusieurs opérations indépendantes dont l ordre d évaluation n influe pas sur le résultat. Par exemple, dans le cas de la jointure R 1 xr 2 xr 3 xr 4. Une stratégie consiste à évaluer en parallèle R 1 xr 2 et R 3 xr 4 et ensuite évaluer la jointure des deux sous-résultats : R 1.2 xr 3.4. La Figure 8 présente le traitement de plusieurs opérations par un parallélisme indépendant. Données Opération 1 Données Opération 2 Opérations complémentaires Résultat Données Opération n 3.2 Parallélisme en tuyau Figure 8. Parallélisme indépendant Il s agit du cas où les résultats d une opération constituent les données en entrée pour l opération suivante. La première opération doit produire des résultats partiels qui sont immédiatement transmis à la seconde. L initialisation des nœuds se fait progressivement. Ainsi, pendant que la première opération prépare le résultat partiel suivant, la seconde traite le résultat précédent. La Figure 9 présente le traitement de plusieurs opérations par un parallélisme en tuyau

25 Données Opération 1 Opération 2 Opération n Résultat R ésultats partiels Figure 9. Parallélisme en tuyau 3.3 Parallélisme par fragmentation Il s agit de fragmenter les données et d utiliser des processeurs différents pour le traitement. La même opération est exécutée en parallèle sur chaque processeur avec une partie des données en entrée. Le résultat final est obtenu en rassemblant les résultats partiels produits par les différents processeurs. La Figure 8 présente le traitement de plusieurs opérations par un parallélisme par fragmentation. processeur 1 Données Eclatement. Regroupement Résultat Processeur n Figure 10. Parallélisme par fragmentation 4 Les principaux systèmes parallèles commerciaux Les progrès technologiques de ces dix dernières années ont favorisé l apparition sur le marché de systèmes de base de données parallèles. Ces derniers se sont frayé un chemin dans le bastion traditionnel des gros systèmes, à savoir les grosses applications de base de données. Les systèmes de base de données parallèles sont conçus pour fonctionner sur des plate-formes multiprocesseurs spécifiques. Nous distinguons principalement deux approches. 4.1 Approche disque partagé Cette approche est fondée sur l'hypothèse que tous les nœuds de traitement ont un accès égal aux disques. Dans une architecture de base de données à disques partagés, les fichiers de données sont logiquement mis en commun entre les nœuds d'un système faiblement couplé. Chaque nœud peut accéder directement à toutes les données. L'accès disque partagé est réalisé à travers une interconnexion directe ou en utilisant une couche d'abstraction du système d'exploitation qui fournit une vue unique de toutes les ressources sur les différents nœuds. Dans l'approche disque partagé, une transaction s exécutant sur une instance donnée peut directement lire ou modifier une partie quelconque de la base de données. De tels systèmes exigent une communication inter-nœud pour synchroniser les opérations de mise à jour. La

26 scalabilité des bases de données à disques partagés dépend en grande partie de l'efficacité de la synchronisation des opérations entre les nœuds. Le disque partagé offre une excellente utilisation des ressources parce qu'il n'y a pas de concept de propriété des données et chaque nœud de traitement peut accéder à l ensemble des données. De plus, cette approche fournit un bon niveau de tolérance aux pannes avec l ensemble des données qui restent accessibles tant qu il y a au moins un nœud qui fonctionne. Si un nœud dans un système à disques partagés est défaillant, le système redistribue dynamiquement la charge de travail parmi les nœuds survivants. Ceci assure un service sans arrêt et une utilisation équilibrée des ressources. 4.2 Approche sans mémoire partagée Dans une architecture multi-ordinateur sans mémoire partagée, les fichiers de base de données sont distribués parmi les différents nœuds du système [MD97]. Chaque instance ou nœud gère un sous-ensemble distinct des données. Un système sans mémoire partagée utilise le schéma de fragmentation des données pour répartir les traitements parmi les différents nœuds. Le système offre une scalabilité linéaire quand les données sont réparties de manière uniforme. Le système ne tournera pas de façon optimale sans une redistribution appropriée des données pour équilibrer la charge du système et éviter des points d accumulation. Une redistribution est également nécessaire quand des nœuds supplémentaires sont rajoutés au système. Le temps d accès à l information est un facteur important à prendre en compte pour les traitements sur de grands volumes de données. Une solution potentielle est dès lors une augmentation de la bande passante des accès mémoires par la fragmentation des données sur plusieurs sites et des accès parallèles [DDG92], [MPTW94], [OV96], [Sto98]. 5 Etude de cas Dans ce qui suit, nous décrivons des SGBDDs commercialisés que sont : DB2, Teradata et Oracle9i. 5.1 Le système IBM DB2 L'édition parallèle de DB2 (PE DB2) est une solution logicielle de base de données qui peut s exécuter sur n'importe quelle plate-forme parallèle d'unix [Bar95]. Son modèle d'exécution est basé sur une architecture multi-ordinateur sans mémoire partagée (shared-nothing), dans laquelle le système de base de données se compose de plusieurs nœuds logiques indépendants. Chaque nœud logique représente une collection de ressources systèmes comprenant, un processeur, une mémoire centrale, un disque et une carte réseau. L ensemble est contrôlé par un gestionnaire de bases de données autonome. La communication entre les nœuds logiques est basée sur des échanges de messages. Les tables sont fragmentées à travers les nœuds en utilisant une stratégie

27 par hachage. Un utilitaire de maintenance permet de redistribuer les données entre les différents nœuds pour équilibrer la charge du système. L'optimiseur tient compte de l'information de hachage des tables pour produire les plans parallèles d'exécution des requêtes. Ainsi un ensemble de processus, tournant sur plusieurs processeurs, éventuellement sur des machines distinctes, peuvent servir un même utilisateur. En faisant travailler plusieurs processeurs sur une même requête SQL, il devient possible de balayer une grande quantité de données plus rapidement et réduire notablement le temps de traitement. Puisque dans une plate-forme shared-nothing les ressources ne sont pas partagées, le gestionnaire se base sur l envoi de fonctions sur des sites distants(function shipping). Les opérations de base de données sont exécutées là où les données résident. Ceci réduit au minimum le trafic réseau en filtrant les données sans importance, et réalise le bon parallélisme. Dans un système parallèle, une base de données peut être fragmentée en plusieurs parties distinctes appelées partitions sous DB2. Les enregistrements d une table de la base de données peuvent être répartis sur plusieurs partitions. Chaque partition de base de données a son propre journal de transactions et ses propres tables d index. DB2 peut appliquer deux types de parallélisme au traitement d'une requête SQL. Le parallélisme intra-partition se rapporte à plusieurs processus coopérant à l intérieur d une partition, et le parallélisme inter-partition se rapporte à des processus coopérant sur des partitions distinctes. Ces deux types de parallélisme sont indépendants l'un de l'autre, et leur importance relative dépend de la configuration matérielle utilisée. Le traitement d'une requête SQL pourrait impliquer le parallélisme intra-partition, le parallélisme inter-partition ou les deux Le parallélisme intra-partition Pour exploiter l intra-parallélisme, l'optimiseur produit des plans d'accès qui contiennent plusieurs threads qui peuvent être actifs en même temps pendant le traitement d'une requête. Chaque thread a accès à toutes les données de la partition. Le nombre de threads dans un plan d'accès peut être inférieur ou supérieur au nombre de processeurs physiques du système. S'il y a plus de threads que des processeurs, le temps-processeur est partagé de manière à les maintenir tous actifs Le parallélisme inter-partition Il implique habituellement plusieurs processeurs, dont chacun a sa propre mémoire centrale et ses propres disques. Chaque processeur gère une partition de la base de données et il n a pas un accès direct aux données sur les autres partitions

28 Le parallélisme inter-partition de DB2 UDB est souvent utilisé sur une architecture parallèle telle que le IBM SP2, qui contient plusieurs processeurs RISC reliés par un commutateur haut débit. Bien que les processeurs dans un système SP2 soient physiquement à l intérieur d un même boîtier, chaque processeur a sa propre mémoire centrale et ses propres disques. Le parallélisme inter-partition de DB2 UDB fonctionne également sur un ensemble d ordinateurs reliés par un réseau local ou étendu. Une partition de la base de données devient un nœud. Un fichier de configuration des nœuds doit être crée sur chaque machine où se trouve une partition. Le fichier contient les noms d'hôte des machines et les numéros de nœuds qui leur sont assignés. Un système parallèle DB2 peut être lancé ou arrêté à partir de n'importe quel nœud. La commande se propagera sur toutes les machines énumérées dans le fichier de configuration des nœuds. Une application ou un utilisateur peut se connecter à une base de données parallèle à partir de n importe quel nœud. Le nœud qui traite une demande de connexion est appelé coordinateur. Plusieurs sessions peuvent être ouvertes dans la base de données, en utilisant un ou plusieurs coordinateur. Pour une session donnée, le coordinateur est responsable de la communication avec le client et de la répartition du traitement sur les autres nœuds. Un coordinateur utilise le protocole de validation à deux phases pour s'assurer que si un nœud quelconque échoue alors la transaction est avortée sur tous les nœuds participants. Le rôle de l'optimiseur sur un nœud coordinateur est de créer un plan d exécution parallèle pour traiter chaque requête SQL. L'optimiseur essaye de diviser les opérations de manière à utiliser le maximum de processeurs tout en réduisant au minimum le transfert de données entre les partitions. Le plan parallèle est un ensemble de plusieurs sous-plans qui détaillent le travail à faire sur chaque partition. Les sous-plans sont distribués par le coordinateur aux différents nœuds participants. Après le traitement, les résultats sont envoyés au coordinateur qui les retourne au client. Les temps d'exécution des applications peuvent être améliorés considérablement en répartissant soigneusement les tables entre les partitions Reconfiguration d un système parallèle Un des avantages de l architecture shared-nothing, retenue par DB2 pour les bases de données distribuées, est qu'il est relativement facile d étendre le système pour l adapter à l augmentation de la charge d exploitation. Des commandes sont disponibles pour redistribuer les données sur les nœuds, ajouter un nouveau nœud ou supprimer un nœud existant. Pour ajouter un nouveau nœud au système, il faut modifier le fichier de configuration des nœuds sur chaque site. Il faut ensuite rééquilibrer le contenu de tous les nœuds en faisant migrer une partie des données vers le nouveau nœud

29 La suppression d un nœud consiste à redistribuer la partition de données qu il contenait aux autres nœuds et à le retirer du fichier de configuration des nœuds. Les opérations de reconfiguration d un système parallèle nécessitent le redémarrage complet du système. 5.2 Le système TERADATA NCR Teradata est un Système de Gestion de Bases de Données relationnelle développé par NCR pour la gestion des entrepôts de données(datawarehouse) [Ter85]. Il a été construit pour fonctionner sur plusieurs serveurs. Il est basé sur une architecture matérielle propriétaire. Teradata a été conçu pour le parallélisme, gérant automatiquement plusieurs threads d'exécution, pour utiliser entièrement toute la capacité de traitement d un ensemble de nœuds tout en rendant cette complexité complètement transparente aux utilisateurs. L'architecture propriétaire de Teradata permet de décomposer une charge de travail complexe en petites unités qui sont réparties sur les unités de traitement parallèles de la base de données. Ces unités virtuelles ou unités logicielles de traitement parallèle sont désignées sous le nom de Access Module Processors(AMPs). La base de données est fragmentée par hachage. Chaque AMP prend en charge une partie de la base de données. Plusieurs AMPs tournent sur un nœud de quatre processeurs indépendamment du système d'exploitation. Par conséquent, Teradata ne se fonde pas sur la plate-forme matérielle pour le parallélisme, la scalabilité, la fiabilité et la disponibilité. Ces capacités sont inhérentes à l'architecture logicielle. Teradata dispose de deux types de processeurs virtuels ou Vprocs : les AMPs et le moteur d'analyse désigné sous le nom de Parsing Engine (PE). Plusieurs PEs peuvent tourner sur un même nœud. Les PEs décomposent une requête ou une commande en petites unités et les repartissent entre les AMPs pour le traitement. La capacité de Teradata d'exécuter plusieurs AMPs et PEs sur le même nœud est réalisée par le Parallel Database Extentions (PDE). Le PDE fournit l'infrastructure qui permet au parallélisme de Teradata de fonctionner sur l'environnement Unix ou Windows NT. La couche PDE permet à Teradata de fonctionner indépendamment du système d'exploitation Parallélisme Intra-nœud Un exemple de parallélisme intra-nœud est décrit ci-dessous. Cette configuration particulière est un nœud de quatre processeurs SMP avec dix Vprocs. Il y a huit AMPs dans cette configuration aussi bien que deux moteurs d'analyse(pe). Il est important de noter que chaque PE a accès à chaque AMP, qui prend en compte le traitement parallèle complet de chaque requête. Comme dans la Figure 11, les données sont distribuées sur les AMPs

30 PE 1 PE 2 Interface de communication AMP 1 AMP 2 AMP 3 AMP 4 PDE AMP 5 AMP 6 AMP 7 AMP 8 Système d Exploitation Figure 11. Parallélisme Intra-nœud de TERADATA Parallélisme Inter-nœud Teradata utilise plusieurs nœuds pour former un système de traitement parallèle unique. La scalabilité linéaire et la haute disponibilité sont obtenues en reliant plusieurs nœuds Teradata de quatre processeurs par une interconnexion à haut débit. Chaque nœud contient une copie indépendante du système d'exploitation et n a pas de vue sur les autres nœuds reliés au système. Teradata gère la communication entre les nœuds et traite toutes les requêtes en parallèle en utilisant les mêmes principes que le parallélisme Intra- nœud. Chaque PE a toujours accès à tous les AMPs dans le système à travers tous les nœuds. 5.3 Le système ORACLE9i L'architecture de base de données parallèle Cache Fusion de Oracle est une nouvelle approche de caches partagés qui vise à fournir des systèmes de base de données scalables et à haute disponibilité sur des plate-formes clusters [0ra00]. Les composants primaires d un cluster sont une grappe de processeurs, une interconnexion réseau et un sous-ensemble partagé de disques. Les processeurs partagent l'accès disque, mais ne partagent pas la mémoire. Chaque nœud dispose d un système d'exploitation, d un système de gestion de base de données, et des logiciels d'application. L interconnexion réseau permet une communication à haut débit, l échange rapide de messages et un équilibrage de charge entre les nœuds. Les clusters fournissent une tolérance aux pannes et une croissance modulaire par ajout de composants. La redondance des composants logiciels, nœuds supplémentaires, et les disques, assurent une haute disponibilité. De telles architectures matérielles évitent l arrêt du système suite à la panne d un composant

31 5.3.1 Extensibilité Tandis que chaque nœud a une adresse physique distincte, les clients se connectent à un nom de service de base de données logique. Les adresses physiques des différents nœuds sont transparentes pour les clients. Oracle équilibre automatiquement la charge des utilisateurs parmi les différents nœuds dans le cluster. Chaque instance du serveur parallèle d'oracle sur les différents nœuds peut exécuter une partie ou l ensemble des services de base de données. Ceci fournit à l administrateur une flexibilité dans le choix des droits d accès. La capacité de traitement peut être augmentée quand les besoins changent par l ajout de nœuds supplémentaires. L'architecture Cache Fusion utilise immédiatement les ressources processeurs et mémoire du nouveau nœud. Les administrateurs n'ont pas besoin de redistribuer manuellement les données dans les caches suivant l évolution de la charge du système. L'architecture Cache Fusion alloue et fait migrer dynamiquement les ressources de base de données entre les nœuds en se basant sur les fréquences d'accès aux données. Ceci rend les données disponibles dans le cache local et permet au serveur parallèle Oracle d accroître le débit des traitements et de fournir un temps de réponse optimal Utilisation des caches serveurs locaux et distants Les systèmes traditionnels de base de données à disques partagés utilisent des lectures/écritures sur disque pour synchroniser les accès concurrents aux données à travers plusieurs nœuds. Typiquement, quand deux nœuds ou plus tentent d accéder au même bloc de données, le nœud qui a un verrou sur le bloc l'écrit sur disque avant que les autres nœuds ne puissent y accéder. Ceci nécessite des lectures/écritures sur disque qui par nature sont lentes. Ceci nécessite également la synchronisation sous forme de messages que les nœuds s échangent pour communiquer au sujet de l état des verrous. Tandis que les échanges de messages inter-nœud peuvent être exécutés plus efficacement à travers l interconnexion à haut débit du cluster, le coût des lectures/écritures sur disque pour la synchronisation est un obstacle significatif à la scalabilité du système. L'architecture Cache Fusion surmonte cette faiblesse en utilisant l ensemble des caches de tous les nœuds dans le cluster pour traiter les requêtes de base de données. Des demandes de lecture peuvent maintenant être satisfaites par le cache local ou n importe lequel des autres caches distants. Une lecture de données s effectue d abord dans le cache local, ensuite une recherche est effectuée dans les caches distants et en dernier lieu sur le disque. Les lectures/écritures sur disque sont seulement exécutées quand aucun des caches collectifs ne contient les données recherchées et pour la validation d une transaction de mise à jour qui exige une écriture sur disque. Cette

32 architecture élargie l utilisation de cache de base de données et réduit les lectures/écritures sur disque pour améliorer les performances. 6 Conclusion Il ressort de ce chapitre que le monde des SGBDs a beaucoup évolué en profitant des progrès constants au niveau de la puissance des machines et de la vitesse des réseaux. Les SGBDs parallèles sont devenus une réalité avec les différents systèmes actuellement commercialisés. Ces systèmes doivent supporter une montée en charge progressive mais les schémas de fragmentation statiques des données actuellement utilisés constituent un handicap

33 Chapitre 4 Couplage du SGBD AMOS-II avec les SDDS Ce chapitre présente les objectifs du couplage des SDDS avec le SGBD AMOS-II et donne une description détaillée des prototypes qui ont été implantés. Nous présentons d abord AMOS-II en mettant l accent sur ses possibilités de manipulation de données externes. Nous proposons ensuite deux stratégies de couplage. La première étudie l utilisation d un fichier SDDS par un SGBD et l interprétation parallèle de requêtes sur les sites serveurs. La seconde stratégie étudie la possibilité pour un SGBD d étendre dynamiquement son espace de stockage sur plusieurs sites en se basant sur les algorithmes SDDS. 1 Hiérarchie des unités de stockage Les unités de stockage d un ordinateur sont hiérarchisées. Au premier niveau se trouvent l antémémoire et la mémoire centrale qui offrent les temps d accès aux données les plus rapides, de l ordre de 100 nsecs. Ensuite, arrive la mémoire secondaire constituée de disques magnétiques avec des temps d accès plus lents, de l ordre de 10 ms. Au troisième niveau se trouvent les mémoires de masses : bandes magnétiques, disques lasers et optiques qui sont les unités de stockage les plus lentes. CPU Sens recherche information Mémoire centrale Disque magnétique Bande Figure 12. Hiérarchie des mémoires A capacité égale, le coût de la mémoire centrale est cent fois plus élevé que le disque. Stocker toutes les données en mémoire centrale coûtait très cher dans le passé. Les disques et les bandes magnétiques ont alors joué un rôle très important dans les bases de données, car la quantité de données à gérer pouvait être très importante. Les données sont stockées sur disque et chargées en mémoire pour les traitements. Les bandes magnétiques, disques lasers et optiques servent plutôt

34 comme des unités de sauvegarde. La Figure 12 présente la hiérarchie des mémoires relative au temps d accès. 2 Les bases de données en mémoire centrale Les bases de données en mémoire centrale se caractérisent par le fait que les données résident entièrement dans la mémoire centrale. De telles bases de données sont pertinentes pour des applications en temps réel ayant besoin de temps de réponse faibles et une haute disponibilité. L essor de tels systèmes était freiné dans le passé par le coût exorbitant de la mémoire principale et les limites de l espace adressable. La baisse des coûts des composants et les progrès technologiques au niveau des architectures des puces, ouvrent de nouvelles perspectives aux bases de données de mémoire centrale. Ainsi les systèmes 64 bits permettent d étendre l'espace d adresse d un nœud jusqu à 10 GB. La limite physique de la taille des bases de données en mémoire centrale peut également être dépassée en faisant travailler plusieurs systèmes en parallèle. Les opportunités offertes par les bases de données en mémoire centrale ont suscité une recherche abondante [AGKP99], [Boh97] et les premières solutions sont déjà disponibles : AMOS [FRS93], DataBlitz [BLRS97], TimesTen [TWP], STRIP [AKG96]. 3 Le SGBD AMOS-II AMOS-II, acronyme de Active Mediating Object System, est un SGBD relationnel-objet expérimental développé par le laboratoire EDSLAB de l université de Linköping en Suède. Dans AMOS-II, les données sont entièrement stockées en mémoire vive et une commande explicite permet d effectuer une sauvegarde sur disque. AMOS-II dispose également d un langage de manipulation déclaratif : AMOSQL. Le but du projet AMOS-II consiste à fournir des outils de développement de systèmes d'information capables d exploiter des données provenant de plusieurs sources distinctes pour les présenter sous une forme compréhensible aux utilisateurs[rj99],[rjk99]. Et ce, sachant qu une source de données peut être une base de données conventionnelle, mais également des fichiers textes, des documents XML, des pages web, des données non structurées. Plusieurs serveurs AMOS-II peuvent tourner sur des emplacements différents et communiquer entre eux en mode Client/Serveur pour effectuer des traitements spécifiques sur des données réparties sur un réseau. AMOS-II est aussi un noyau système qui peut être couplé avec d'autres systèmes. Il est ainsi ouvert aux langages de programmation C, java et Lisp. Il existe deux possibilités d interfacer AMOS-II avec un programme externe : les interfaces CALLIN et CALLOUT[Ris00]

35 L interface CALLIN permet à un programme externe d appeler des routines AMOS-II. L interface CALLOUT permet à AMOS-II lui-même d exécuter des routines externes. Une combinaison des deux est possible quand une routine externe elle-même fait appel à AMOS-II via l interface CALLIN. 3.1 Interface CALLIN Par l interface CALLIN, un programme externe peut soumettre à AMOS-II une requête contenant des clauses AMOSQL par la fonction a_execute. L expression subit alors une analyse syntaxique, une analyse sémantique, puis un résultat est généré. Le programme externe récupère le résultat de la requête à l aide de primitives AMOS-II. Ce processus est dit lent car chaque expression subit deux phases d analyse : syntaxique et sémantique. Il est alors possible de créer des procédures stockées et des fonctions AMOS-II dérivées pour toutes les opérations couramment effectuées par un programme externe. Par conséquent, les phases d analyse sont exécutées une seule fois à la déclaration de la fonction dérivée. L exécution d une requête prédéfinie se fait par l appel de la fonction AMOS-II a_callfunction. Une application peut être reliée à AMOS-II de deux manières : par une connexion dite stricte ou par une connexion Client/Serveur. La connexion stricte, où AMOS-II est imbriqué dans l application : les deux programmes partagent le même espace d adressage. L arrêt de l application provoque l arrêt de AMOS-II. Une seule application peut être reliée à AMOS-II de la sorte. La connexion Client/Serveur permet à plusieurs applications de se connecter simultanément à une instance de AMOS-II. Les applications et AMOS-II s exécutent séparément. 3.2 Interface CALLOUT L interface CALLOUT permet à AMOS-II d exécuter des routines contenues dans des programmes externes. Elle offre ainsi la possibilité d étendre les fonctionnalités prédéfinies de AMOS-II afin de répondre aux besoins spécifiques des utilisateurs. L interface CALLOUT est basée sur un mécanisme appelé fonction externe. Des structures de données et leurs routines de manipulation peuvent être développées dans un programme externe, et intégrées à AMOS-II. 3.3 Fonction externe simple Une fonction externe simple prend un ensemble de paramètres en entrée et génère un résultat sous la forme de tuple. Elle est définie de la manière suivante dans le programme hôte : 1) Coder en langage C les tâches à effectuer par la fonction ; 2) Transformer les paramètres d entrée de la fonction C en symbole de la base de données AMOS-II ; 3) Définir une fonction externe en AMOSQL qui sera reliée au code source en langage C

36 3.4 Implantation d une fonction externe La déclaration d une fonction externe en C se fait de la manière suivante : Void fn(a_callcontext ctx, a_tuple tpl) ; La variable ctx est une structure de donnée interne à AMOS-II pour gérer le contexte d appel de la fonction. La variable tpl est un tuple qui contient à la fois les paramètres d appel et les variables de sortie de la fonction. Le nombre de champs de tpl est égal à la somme du nombre de paramètres en entrée et du nombre de variables en sortie. Il est retourné par la fonction a_getarity(). AMOS-II gère actuellement quatre types de données : les booléens, les entiers, les réels et les chaînes de caractères. Trois commandes permettent de copier des données à partir d un tuple vers des variables C : a_getintelem(), a_getdoubleelem() et a_getstringelem(). La copie de données à partir de variable C vers un tuple se fait, selon les types à l aide des commandes : a_setintelem(), a_setdoubleelem() et a_setstringelem(). L implantation d une fonction externe doit faire appel à la fonction a_emit() pour retourner à AMOS-II les résultats sous forme de tuple. Si le résultat comporte plusieurs tuples, la fonction a_emit() est appelée autant de fois. Une fonction qui termine son exécution sans faire appel à la fonction a_emit() correspond à un résultat nul. Après l implantation d une fonction C, Il faut l enregistrer dans AMOS-II en lui donnant un nom interne. Cela se fait à l aide de la commande a_extfunction(nom_interne, nom_fonction_c) ; La dernière étape consiste à définir une fonction AMOS-II, dont l appel va provoquer l exécution de la fonction externe. C est à ce niveau qu il faut préciser les paramètres en entrée et les variables de sortie. Cela se fait à l aide de la commande : CREATE function <nom_fonction> (<liste_arguments>) -> <variables_retournées> AS FOREIGN <nom_interne> ; 4 Objectifs du couplage des SDDS avec AMOS-II Le gestionnaire SDDS est un système de gestion de fichiers distribués en mémoire centrale d un multi-ordinateur. AMOS-II est un SGBD complet en mémoire centrale. Nous distinguons deux stratégies de couplage. La première stratégie est dénommée AMOS-SDDS et vise trois objectifs : - Etendre le gestionnaire SDDS afin qu il puisse supporter des opérations de bases de données ; - Construction d une liaison entre un SGBD et un entrepôt de données externes avec des accès rapides hors SGBD ; - Effectuer les traitements en parallèle en se basant sur l envoi de fonctions sur des sites distants

37 La seconde stratégie dénommée SD-AMOS vise à ajouter au système AMOS-II des fonctionnalités lui permettant d étendre dynamiquement son espace de stockage sur plusieurs sites. La transparence de la fragmentation et de la localisation des données sera basée sur les algorithmes SDDS. Les données seront manipulées à partir de Client AMOS-II à l aide du langage AMOSQL étendu par des fonctions externes. AMOS-II sera aussi utilisé sur chaque site serveur pour interpréter et traiter les requêtes sur les données locales. Pour cela, les capacités de traitements de AMOS-II seront renforcées par des fonctions externes. La distribution des données permettra d effectuer plusieurs traitements en parallèle notamment les requêtes de recherche, les balayages et les jointures. Il faudra mettre en place pour cela une architecture de communication fiable entre un client et plusieurs serveurs. Les sites client doivent pouvoir envoyer des requêtes parallèles vers les sites serveurs et collecter les réponses de ces derniers sans perte Stockage des données dans une case SDDS Dans la stratégie appelée AMOS-SDDS, les données sont entièrement stockées dans la case SDDS. AMOS-II se base alors sur des fonctions externes pour accéder aux données. Pour le traitement des requêtes complexes, AMOS-II peut importer une partie ou la totalité de la case SDDS dans une table temporaire. Ceci permet d améliorer les temps de traitement de requêtes par l utilisation d index, tout en préservant l efficacité de traitement des requêtes de sélection obtenue sur les SDDS seules. La Figure 13 présente l architecture stratifiée du serveur AMOS- SDDS. Serveur AMOS-SDDS Callin AMOS-II Serveur SDDS Fonctions Externes Callout Case SDDS Réseau Figure 13. Architecture globale de AMOS-SDDS Stockage des données dans AMOS-II Cette stratégie est appelée AMOS-II Distribué et Scalable (SD-AMOS). Les données sont entièrement stockées dans AMOS-II. La couche SDDS est chargée de l exécution parallèle des requêtes en utilisant toutes les fonctionnalités offertes par le SGBD, notamment les fonctions

38 agrégats. La couche SDDS gère également la répartition dynamique des données à travers le multi-ordinateur. L objectif visé est la conception d un prototype de système de base de données parallèles et dynamiques. La Figure 14 présente l architecture stratifiée du serveur SD-AMOS. Serveur SD-AMOS Données Locales AMOS-II Callin Serveur SDDS Callin Module Eclatement Réseau Figure 14. Architecture globale de SD-AMOS 5 Le système AMOS-SDDS 5.1 Architecture de couplage AMOS-SDDS Chaque client SDDS est couplé avec un client AMOS-II. Nous désignons le client SDDS couplé avec AMOS-II comme client AMOS-SDDS. De même, chaque serveur SDDS est couplé avec un serveur AMOS-II. Nous désignons le serveur SDDS couplé avec AMOS-II comme le serveur AMOS-SDDS. Cette stratégie de couplage permet de formuler sur le client deux types de requêtes : les requêtes classiques SDDS et les requêtes AMOSQL. Nous disposons ainsi sur chaque serveur AMOS-SDDS de deux modules de traitement : un module de traitement des requêtes SDDS et un module de traitement des requêtes AMOSQL. Les deux modules coopèrent dans le traitement de certaines requêtes à travers les interfaces CALLIN et CALLOUT de AMOS-II. Le module SDDS invoque le serveur AMOS-II qui lui est couplé à chaque fois qu il reçoit une requête qu il ne sait pas traiter. Le traitement de telles requêtes par AMOS-II nécessite des accès aux données qui sont stockées dans la couche SDDS. La Figure 15 présente l'architecture globale de couplage du système AMOS-SDDS. La Figure 16 montre les étapes du traitement de requêtes sous AMOS-SDDS. Les clients et les serveurs SDDS prennent en charge tous les échanges de messages et de données entre les sites. Ils constituent une plate-forme de communication distribuée dynamique pour les clients et les serveurs AMOS-SDDS. Les serveurs SDDS sont aussi chargés du stockage des données en mémoire vive. Le rôle de AMOS-II sur le client est de permettre aux utilisateurs de

39 formuler les requêtes de manière interactive sur les données locales et externes. Sur le serveur, le rôle de AMOS-II est de traiter les requêtes complexes. Application SDDS Application AMOS-SDDS AMOS II Client SDDS Callout Serveur AMOS-SDDS AMOS II 2Callout 1Callin Serveur SDDS Serveur AMOS-SDDS AMOS II 2Callout 1Callin Serveur SDDS Client AMOS-SDDS Réseau Figure 15. Architecture globale de AMOS-SDDS 5.2 Traitement des requêtes dans AMOS-SDDS Les utilisateurs ou les applications accèdent au système AMOS-SDDS à partir des sites client. Les utilisateurs lancent les requêtes en mode interactif. Les applications utilisent l'interface CALLOUT à travers les fonctions AMOS-II a_execute et a_callfunction. Une requête AMOS-SDDS peut être une requête SDDS classique, par exemple une recherche par intervalle RP*. Le client SDDS traite de telles requêtes directement. Alternativement, une requête AMOS-SDDS peut être une requête AMOSQL. Elles sont alors traitées par le client AMOS-II. Une requête peut porter sur des données locales stockées sur AMOS-II ou sur des données externes dans une case SDDS sur une machine distante. L accès au fichier SDDS se fait à l aide de fonctions externes à travers l'interface CALLOUT. L'utilisateur qui accède aux données, ne se rend pas compte qu elles sont externes à la base AMOS-II locale. En effet, la formulation d une requête n est pas basée sur le schéma de fragmentation des données sur les serveurs. Elle est plutôt basée sur le mécanisme d envoi de fonction vers les sites distants(ship function). La distribution des données est ainsi transparente à l'utilisateur AMOS-SDDS. Une fonction ship est une fonction externe qui permet d accéder aux données stockées en dehors de AMOS-II, dans un fichier SDDS spécifiquement. Elle envoie un traitement à faire (requête et/ou paramètres d une fonction) aux serveurs. C'est une requête SDDS qui peut aussi contenir une sous-requête AMOSQL. Le client SDDS expédie une telle requête aux serveurs AMOS- SDDS. Le serveur extrait la requête AMOSQL et l exécute sur les données stockées localement

40 L invocation d'une requête AMOSQL par le client peut correspondre à une série d envoi de plusieurs fonctions ship aux serveurs et aux retours des résultats partiels au client. Le client envoie une requête AMOS-II par une fonction nommée Send-AMOS et une requête SDDS par Send-SDDS(voir Figure 16). Les routines Send-AMOS et Send-SDDS communiquent avec les serveurs à travers des ports de communication différents. Le dialogue Client/Serveur est basé sur l échange de messages point à point ou de diffusion. Les requêtes qui concernent plusieurs serveurs, sont envoyées par diffusion afin de tirer profit de la distribution des données pour effectuer les traitements en parallèle. Un serveur AMOS-SDDS qui reçoit une requête SDDS effectue le traitement sur ses données locales et envoie les résultats au client. S il s agit par contre d une requête AMOSQL, le serveur SDDS appelle le serveur AMOS-II locale par l interface CALLIN. Le serveur AMOS-II effectue un balayage des enregistrements et envoie ceux qui satisfont la requête au serveur SDDS dans une variable AMOS-II nommée SCAN. Le serveur SDDS extrait les enregistrements contenus dans la variable SCAN et les copie dans un tampon de transmission. Il envoie ensuite le tampon au client SDDS. Le client SDDS assemble les tampons qu il a reçus des serveurs. Il exécute un protocole de terminaison de requêtes pour déterminer la fin de la réception des réponses. Par la suite, le client SDDS extrait les enregistrements contenus dans les tampons reçus et les transmet au client AMOS-II en utilisant la fonction a_emit. Pour certain type de requêtes, le client AMOS-II peut exécuter un post traitement sur les données obtenues avant de les passer à l'application. Comme il apparaît, les clients et les serveurs AMOS-SDDS utilisent les clients et les serveurs SDDS en tant que plate-forme de communication. Les serveurs SDDS constituent également une structure de stockage de données en mémoire vive distribuée. Ces deux rôles exigent du client AMOS-SDDS la décomposition de requêtes AMOSQL en sous-requêtes appropriées au traitement distribué. Ceci inclut particulièrement une communication fiable et l'utilisation des serveurs en parallèle. Sur le client, la décomposition en sous-requêtes est réalisée à travers les fonctions externes. Il y a plusieurs façons de décomposer une requête de cette façon. De même, il y a plusieurs façons d'exécuter une sous-requête sur les serveurs AMOS-SDDS. Nous distinguons principalement deux stratégies détaillées plus loin : l une dite externe et l autre dite importation. Il y a enfin de nombreux choix pour la communication Client/Serveur. Tous ces choix de conception déterminent les performances du système AMOS-SDDS La Stratégie externe Sur le système AMOS-SDDS, les données sont stockées dans la couche SDDS et le traitement des requêtes est du ressort de la couche AMOS-II. La stratégie externe consiste à traiter les

41 requêtes en se basant exclusivement sur des fonctions externes. Elle nécessite pour chaque type de requêtes, de programmer des fonctions externes adaptées. Ce mécanisme reprend le principe des procédures stockées utilisées par les SGBDs La Stratégie d importation Elle consiste pour le traitement d une requête, à importer les données contenues dans la case SDDS locale dans une table temporaire de AMOS-II qui ensuite effectue sa propre évaluation. La stratégie d importation est potentiellement plus simple à mettre en œuvre et plus extensible. Elle permet d utiliser les capacités de traitement de requêtes de AMOS-II, au lieu de les reprogrammer dans des fonctions externes. En particulier, elle tient compte facilement de la consultation d'un index et de l utilisation des fonctions agrégats. La stratégie d importation est également plus flexible pour traiter d autres types de requêtes. Ainsi, chaque serveur AMOS-II peut manipuler entièrement et plus efficacement la décomposition et l exécution de requêtes locales en faisant appelle à ses propres algorithmes d optimisation de requêtes. Les inconvénients potentiels de la stratégie d importation sur la stratégie externe sont naturellement le coût supplémentaire de l opération d'importation et l encombrement mémoire du fait de la duplication des données. Client AMOS II 4Traiter-AMOS(requête) Serveur AMOS II 1Ship(requête) 7Résultats fonctions externes Results(scan) 2Send-AMOS(requête) 6Receive-AMOS(tampon) 3Receive-AMOS(requête) Case SDDS 5Send-AMOS(tampon) 2Send-SDDS(requête) Client SDDS 6Receive-SDDS(tampon) 3Receive-SDDS(requête) 4Traiter-SDDS(requête) 5Send-SDDS(tampon) Serveur SDDS Client AMOS-SDDS Serveur AMOS-SDDS Réseau Figure 16. Traitement des requêtes sous AMOS-SDDS 5.3 Conception du système AMOS-SDDS La mise en place du système AMOS-SDDS a exigé plusieurs choix de conception. Au niveau communication, est ce que le serveur doit envoyer les enregistrements au client un à un ou bien doit-il les regrouper dans un tampon et envoyer un seul message? Dans ce dernier cas, quelle est la taille optimale du tampon? [SMM98]. Il y a aussi un choix à faire entre la transmission des

42 données par messages ou par une connexion. Ensuite, comment formater les enregistrements dans un tampon pour la transmission des résultats d une requête? Particulièrement faut-il utiliser un tampon avec des champs de longueur fixe ou variable? Il existe aussi des choix à faire au niveau du client concernant la récupération des résultats d une requête. Notamment comment récupérer des résultats dont la taille n est pas connue, ni le nombre de serveurs devant répondre? L évaluation des opérations de sélection et de projection ne posent pas de problèmes particuliers dans un environnement distribué. Plusieurs algorithmes ont été proposés pour l évaluation d une requête de jointure dans un environnement distribué [ER93], [JD01], [LR99], [YS97]. Nous utiliserons dans nos expérimentations la boucle imbriquée(nested loop) qui est plus adaptée à la manière dont les données sont déjà placées sur les sites. Le traitement d une requête de jointure par une boucle imbriquée distribuée peut être effectué par le balayage de la table externe et l envoi des enregistrements par paquet (de combien?). Est-t-il pertinent de trier les paquets sur le client. Le tri permet de réduire de moitié le temps de balayage sur le serveur contre le temps supplémentaire de tri sur le client. En outre, Quel protocole de terminaison utiliser pour les balayages? Déterministe ou Probabiliste. Pour le dernier, le délai d attente doit être judicieusement choisi. Coté serveur, le choix porte sur le mécanisme de traitement des sous-requêtes. Il se répartit entre le serveur AMOS-II et le serveur SDDS à travers les fonctions externes. Beaucoup de choix existent en particulier pour la jointure distribuée. Pour une évaluation par une boucle imbriquée distribuée, la comparaison entre les tuples obtenus du client et ceux locaux au serveur peut être faite d'une part entièrement par les fonctions externes. Une autre stratégie est l'importation de tous les tuples reçus dans une table temporaire du serveur AMOS-II et ensuite confier l exécution de la jointure à ce système. Cette stratégie peut être plus efficace puisque AMOS-II est optimalisé pour le traitement des jointures. Aussi, l'importation permet de créer un index sur l'attribut de jointure, ce qui réduit considérablement le temps de traitement. De même, il y a des choix architecturaux semblables pour les fonctions agrégats. Elles peuvent être traitées entièrement par les fonctions externes ou en utilisant ceux qui sont prédéfinies dans AMOS-II. Leur traitement nécessite la décomposition globale de fonction, l envoi de sousrequête et un post-traitement sur le client. Une sous-requête peut être traitée entièrement par les fonctions externes, partiellement ou entièrement par le serveur AMOS-II après l'importation des données locales. Les choix discutés et autres relatifs à la conception du système AMOS-SDDS ne peuvent pas être faits sur une base théorique seulement. Il n'a pas semblé possible de déterminer de cette façon, le meilleur choix pour l'efficacité globale du système AMOS-SDDS. Ceci concerne particulièrement

43 l'analyse de la scalabilité. Les deux composants AMOS-II et le gestionnaire SDDS sont des logiciels complexes. Leur couplage ajoute un degré de complexité supplémentaire. En particulier, il ne semble pas y avoir de voie théorique facile pour mesurer l'efficacité du couplage par les interfaces CALLIN et CALLOUT. L'analyse des performances de tels systèmes passe par des mesures expérimentales. Notre approche consiste à déterminer expérimentalement les performances du système de couplage par l'exécution d opérations typiques de base de données raisonnablement complexes. Nous avons opté pour une requête sélective de jointure et des fonctions agrégats. 6 Le système SD-AMOS 6.1 Architecture de couplage SD-AMOS SD-AMOS reprend le schéma de couplage du système AMOS-SDDS mais en changeant la répartition des rôles de stockage des données et de traitement des requêtes entre AMOS-II et les SDDS. Nous désignons le client SDDS couplé avec AMOS-II comme client SD-AMOS. De même, un serveur SDDS couplé au serveur AMOS-II est désigné serveur SD-AMOS. La Figure 17 présente l'architecture globale de couplage du système SD-AMOS. Application SD-AMOS AMOS II Serveur SD-AMOS AMOS II Serveur SD-AMOS AMOS II Callout Callin Callin Client SDDS Client SD-AMOS Serveur SDDS Serveur SDDS Réseau local Figure 17. Architecture SD-AMOS Les échanges de messages et de données entre les sites sont toujours du rôle du client et du serveur SDDS. Par rapport au système AMOS-SDDS, les données sont maintenant entièrement stockées dans des tables internes AMOS-II. En cas de débordement, les serveurs SDDS sont chargés de l éclatement des tables internes AMOS-II : choix d un nouveau site et transfert des données. Sur le client, les utilisateurs formulent les requêtes de manière interactive sur l interface de AMOS-II. Il n existe pas de requêtes SDDS sur SD-AMOS. Les données locales et externes sont entièrement manipulées à l aide de requêtes formulées en langage AMOSQL étendu par des fonctions externes. Le serveur SD-AMOS dispose d un seul module de traitement qui est chargé d exécuter toutes les requêtes. Les avantages potentiels du système SD-AMOS sur la stratégie

44 d importation du système AMOS-SDDS sont naturellement l absence d opération d'importation et un moindre encombrement de la mémoire. 6.2 Traitement des requêtes dans SD-AMOS Les utilisateurs ou les applications accèdent également au système SD-AMOS à partir des sites client. Les utilisateurs lancent les requêtes en mode interactif et les applications utilisent l'interface CALLIN. Les applications ignorent la manière dont une table AMOS est répartie sur le multiordinateur. Elles font appel à des routines implantées au niveau du client. En effet, ce dernier se charge de structurer les requêtes et de les acheminer vers le ou les serveurs adéquats. Les mécanismes liés au protocole de communication entre clients et serveurs restent donc transparents aux applications et aux utilisateurs. Le client AMOS-II utilise l interface CALLOUT pour envoyer une requête à l aide d une fonction externe. Lorsqu un serveur SDDS reçoit une requête, il la transmet au serveur AMOS-II qui lui est couplé à travers son interface CALLIN. Le choix d une stratégie pour évaluer une requête ne se pose pas puisque le même module se charge du stockage et du traitement. Aucun traitement n est effectué par le serveur SDDS dans le système SD-AMOS. Le serveur AMOS-II traite alors toutes les requêtes et retourne les résultats au serveur SDDS dans un tampon de type SCAN. Le serveur SDDS parcourt le tampon SCAN, extrait les tuples et les copie dans un tampon de transmission avec le format approprié. Le tampon est envoyé au client SDDS par un message ou via une connexion selon la nature de la requête. La Figure 18 montre les différentes étapes du traitement d une requête par le système SD-AMOS. Client SD-AMOS AMOS-II local Serveur SD-AMOS AMOS-II local Données locales 1Ship(requête) 7Résultats 4Traiter(requête) Résultats (scan) Client SDDS Serveur SDDS 2Envoyer(requête) 3Recevoir(requête) 6Recevoir(tampon) 5Envoyer(tampon) Réseau Figure 18. Traitement des requêtes sous SD-AMOS 6.3 Structure et évolution du fichier SD-AMOS L objectif recherché est la création dynamique d un fichier AMOS-II sur plusieurs serveurs. Pour cela, une fragmentation des données par intervalle est appliquée selon le principe des algorithmes RP*. Un enregistrement comporte un champ-clé et des champs non-clé. Le champ clé identifie

45 l enregistrement de manière unique sur l ensemble des serveurs SD-AMOS. Sur chaque serveur, les données sont représentées par des valeurs de fonction dans AMOS-II. Le serveur SDDS local stocke et met à jour les paramètres de la case AMOS-II. Ce sont : la clé minimale, la clé maximale, le nombre total d enregistrements pouvant être inséré dans la case et le nombre courant d enregistrements. A la création, un fichier SD-AMOS débute sur un seul site. Toutes les insertions d enregistrements vont vers ce site. Si le nombre d enregistrements de la case atteint la capacité maximale, alors toute tentative d insertion entraîne son éclatement. L éclatement consiste à rechercher un nouveau site disponible et à faire migrer la moitié des enregistrements de la case en débordement vers la nouvelle case. La migration cherche à assurer une répartition homogène des enregistrements sur les différents sites. Le processus d éclatement est répété pour toute case qui devient surchargée par les insertions. Un fichier AMOS-II peut ainsi s étendre sur un nombre infini de sites. 6.4 Conception du système SD-AMOS Les choix de conception discutés dans la section 5.3 concernant la mise en œuvre du système AMOS-SDDS, se posent également pour le système SD-AMOS. Il s agit principalement de la gestion du dialogue Client/Serveur et des mécanismes liés au traitement des requêtes dans un environnement parallèle. Il s y ajoute les problèmes liés à l éclatement d une table interne de AMOS-II. A ce niveau, qui entre AMOS-II et le serveur SDDS, doit contrôler la taille courante du fichier pour déclencher un éclatement dès qu un débordement survient? Nous avons le choix entre utiliser le mécanisme des déclencheurs disponible sur AMOS-II ou faire une estimation par le serveur SDDS. Dans les deux cas, la recherche d un nouveau site est du ressort de la couche SDDS. 7 Conclusion Nous avons proposé dans ce chapitre deux stratégies de couplage entre les SDDS et AMOS-II. Pour chaque stratégie, nous avons présenté en détail l architecture de couplage, les mécanismes de traitement de requêtes et les choix de conceptions auxquels nous étions confrontés. Nous tenterons par des expérimentations de déterminer l'efficacité globale des prototypes. Ceci concerne particulièrement l'analyse de la scalabilité

46 Chapitre 5 Couplage du SGBD DB2 avec les SDDS Ce chapitre 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 manipulations 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. 1 Les entrepôts de données externes La nature et la complexité des informations à analyser ont fait naître un besoin de pouvoir manipuler à partir d un SGBD, des données qui se trouvent sur un support externe comme un fichier plat(suite d octets). Les données ne sont pas stockées dans la base pour avoir des accès rapides hors SGBD à partir d une autre application pour certain type de traitements. Un exemple pertinent est présenté dans [MC99]. L accès aux données externes permet de bénéficier des facilités du SGBDs comme son langage de requêtes. Certains SGBDs notamment AMOS [Ris00] et DB2 [DB2LM] offrent une interface qui permet de manipuler des données externes. 2 Le SGBD IBM BD2 DB2 est apparue en C est le résultat des travaux effectués dans les années 70 par le laboratoire de recherche d IBM de San Jose, où est aussi originaire le modèle relationnel et le langage SQL. «DB2 Universal Database» est la plus récente de la famille de produits DB2. IBM a introduit «DB2 Universal Database» comme nouvelle génération de base de données relationnelles. Le système combine des fonctionnalités relationnel-objet avec des possibilités de traitement parallèle. DB2, en plus des types de données et des fonctions standards, permet aux utilisateurs de créer leurs propres types et des fonctions externes pour répondre aux besoins spécifiques de leurs applications. 2.1 Types de données définis par l utilisateur (UDT) L utilisateur peut définir ses propres types de données en se basant sur les types prédéfinis. Les opérations de conversion et de comparaison sont automatiquement prises en charge par le système. 2.2 Fonctions définies par l utilisateur(udf) Les possibilités offertes par SQL ne suffisent pas toujours à répondre à tous les besoins d'une application. DB2 permet aux utilisateurs d étendre les fonctionnalités du SGBD en développant à

47 l aide de langages de programmation hôtes(c, C++, Java ou Basic), leurs propres routines qui vont enrichir la bibliothèque de fonctions prédéfinies. Les fonctions définies par l utilisateur(udf) peuvent ainsi renvoyer des valeurs scalaires uniques ou des tables entières si la source n'est pas une base de données. Les fonctions externes sont créées dans une base de données spécifique. Les UDFs peuvent être utilisées comme les fonctions prédéfinies, et sont accessibles à tous les utilisateurs. En fonction des paramètres d appel et des données de sortie, les UDFs sont regroupées en trois catégories : dérivée, scalaire et table Fonction dérivée Une fonction est dite dérivée quand sa définition fait appel à une fonction prédéfinie. C est une redéfinition de fonction en changeant les types de ses paramètres d appel et/ou de sortie. L utilité principale d une fonction dérivée est de permettre à un type de données utilisateur d hériter les fonctions et opérateurs qui s appliquent à son type de base. Quand une fonction dérivée est évoquée, ses arguments sont convertis vers les types de données de la fonction source. Elle est ensuite exécutée et les résultats obtenus sont en dernier lieu convertis vers le type de données résultat de la nouvelle fonction Fonction externe scalaire Une fonction est dite scalaire quand elle prend en entrée des variables, effectue des opérations dessus, et retourne en sortie une valeur unique Fonction externe table Une fonction externe est dite table quand elle retourne comme résultat une table. Elle permet d accéder à partir de DB2 à des données provenant de sources diverses. Il suffit d écrire une fonction C qui collecte les données désirées selon les variables passées en paramètre et retourne le résultat ligne par ligne. La table retournée peut participer à toutes les opérations SQL qui s appliquent à une vue en lecture seule(jointure, union, groupage, clause FROM ). Un inconvénient majeur des fonctions externes table est que celles-ci ne retournent qu un seul enregistrement par appel. L invocation d une fonction externe table entraîne alors plusieurs appels au programme externe qui lui est associé. La synchronisation entre DB2 et le programme externe se fait à travers un indicateur d appel. Le premier appel est signalé par l indicateur positionné à la valeur «SQL_TF_OPEN». Il permet d effectuer les tâches préliminaires telles que l ouverture de fichier, l allocation de mémoire, l initialisation des variables. Le premier appel ne retourne pas d enregistrement. Il est suivi d une série d appels avec l indicateur positionné à

48 «SQL_TF_FETCH». Le programme doit retourner une ligne de la table résultat par appel. Un indicateur d état (SQLSTATE) permet à DB2 de faire un compte rendu du déroulement de la fonction externe à l application. Il est positionné à «00000» pour un appel fructueux. Le programme signale qu il n y a plus de ligne à retourner en positionnant l indicateur d état à la valeur «02000». Le dernier appel est signalé par l indicateur d appel positionné à «SQL_TF_CLOSE» pour permettre au programme d effectuer les opérations de terminaison telles que la fermeture de fichiers et la libération de mémoire. 2.3 Déclaration d une fonction externe Cette opération précède l utilisation d une fonction externe et permet de cataloguer cette dernière dans la table système «FUNCTION». Pour les fonctions dérivées, l installation consiste à faire appel à la commande «CREATE FUNCTION». Pour les fonctions scalaires et tables, elle se déroule en quatre étapes : 1) Ecrire un programme C qui décrit les opérations à effectuer ; 2) Compiler le programme par un compilateur quelconque ; 3) Placer le fichier DLL obtenu dans un répertoire du serveur sur lequel tourne le système DB2 ; 4) Enregistrer la fonction externe associée au programme dans chaque base de données utilisatrice grâce à la commande «CREATE FUNCTION» Déclaration d une fonction externe scalaire CREATE FUNCTION nom de la fonction (les paramètres d entrée) RETURNS types de donnée en sortie EXTERNAL NAME 'nom librairie!nom fonction' DETERMINISTIC NO EXTERNAL ACTION NULL CALL LANGUAGE C PARAMETER STYLE DB2SQL NO SQL; Déclaration d une fonction externe table CREATE FUNCTION nom de la fonction (les paramètres d entrée) RETURNS TABLE (liste des champs avec leur type) EXTERNAL NAME 'nom librairie!nom fonction' DETERMINISTIC

49 NO EXTERNAL ACTION LANGUAGE C FENCED PARAMETER STYLE DB2SQL NO SQL SCRATCHPAD FINAL CALL DISALLOW PARALLEL; 3 Objectifs du couplage des SDDS avec DB2 DB2 offre des fonctionnalités de manipulation de données externes. L objectif du couplage est de faire des SDDS un espace de stockage de données secondaire pour DB2. Les serveurs SDDS permettent alors au SGBD de gérer certains types de données potentiellement plus rapidement et en plus grande quantité que si elles avaient été dans les tables internes du SGBD. Les données externes sur le fichier SDDS et les tables internes de DB2 forment une base de données unique. Le SGBD DB2 offre à l'usager une interface plus élaborée que celle du gestionnaire SDDS, notamment par son langage de requêtes. Ainsi, les opérations courantes de sélection, projection, restriction et jointure peuvent être formulées à partir de DB2 sur le fichier SDDS à l aide du langage SQL(Structured Query Language). 3.1 Architecture de couplage de DB2 avec les SDDS Le serveur DB2 est couplé avec un client SDDS à travers une interface DB2-SDDS définie à l aide des fonctions UDF. Les serveurs SDDS sont uniquement chargés du stockage de données en mémoire vive distribuée. Ils ne participent pas au traitement des requêtes de type base de données. DB2 se base sur le client SDDS pour accéder aux données stockées sur les cases SDDS distantes. Application Serveur DB2 Interface DB2-SDDS Client SDDS Serveur SDDS Serveur SDDS Réseau Figure 19. Architecture de couplage DB2-SDDS

50 Toutes les requêtes sont traitées par le serveur DB2. Le client SDDS et DB2 sont deux applications distinctes. Le client tourne comme un service et elle est accessible à toutes les applications qui tournent sur la même machine dont DB2. La Figure 19 présente l'architecture globale de couplage des SDDS avec DB Traitement des requêtes dans DB2-SDDS DB2 fonctionne dans un environnement client-serveur. Un serveur fournit des services aux autres ordinateurs du réseau, alors que le client demande des services. Dans un environnement client-serveur DB2, les serveurs gèrent les bases de données et les clients exécutent des applications qui accèdent aux bases de données. Une application client envoie une demande au serveur DB2 pour accéder à une base de données. La demande utilise le langage SQL. Le serveur traite la demande et renvoie les données à l'application client. Une requête peut porter sur des données stockées dans la base DB2, sur des données externes dans une SDDS ou sur les deux. Le serveur DB2 ignore la manière dont un fichier SDDS est réparti sur le multi-ordinateur. Il fait appel à des routines implantées au niveau du client SDDS. En effet, ce dernier se charge de structurer les requêtes et de les acheminer vers le ou les serveurs SDDS adéquats. Il récupère ensuite les résultats pour les transmettre au serveur DB2. Les mécanismes liés au protocole de communication entre clients et serveurs SDDS sont donc transparents pour DB2. La Figure 20 montre les étapes du traitement de requêtes sous DB2-SDDS. Serveur DB2 1fonction UDF 7Résultats Case SDDS 2Envoyer(requête SDDS) Client SDDS 6Recevoir(tampon) 3Recevoir(requête SDDS) 5Envoyer(tampon) 4Traiter(requête SDDS) Serveur SDDS Réseau Figure 20. Traitement des requêtes sous DB2-SDDS 3.3 Conception de l interface DB2-SDDS L'interopérabilité entre les deux systèmes est réalisée à travers les fonctions dites externes. Le couplage DB2-SDDS se fait uniquement au niveau du client. Il s agit en se basant sur les spécifications des UDFs, de concevoir l interface permettant à DB2 d utiliser les services du client SDDS pour envoyer une requête de recherche et récupérer les résultats sous forme d une table. L interface se présente sous la forme d une librairie dynamique(dll). Elle est appelée par le serveur à chaque fois qu une requête est formulée sur des données externes. Les choix de conception

51 concerne principalement la définition d un protocole de communication entre l interface DB2- SDDS et le client SDDS. Le serveur DB2 et le client SDDS sont deux programmes distincts qui tournent sur des espaces mémoire séparés. Il faut donc proposer un mécanisme de synchronisation pour gérer l envoi de requêtes et la réception du résultat. 4 Conclusion Nous avons proposé dans ce chapitre une stratégie de couplage entre les SDDS et DB2. Elle consiste à utiliser les SDDS comme un entrepôt de données externe de DB2 en se basant sur les fonctions définies par l utilisateur(udf). L entrepôt de données externe ainsi constitué a deux caractéristiques principales: les données sont en mémoire et elles peuvent s étendre dynamiquement. Le système proposé permet de formuler à partir de DB2 des requêtes sur des données externes sans se soucier de leur localisation. Nous tenterons dans les expérimentations de mesurer l efficacité du couplage par une comparaison des temps d accès à des données internes et externes

52 Chapitre 6 Implantation des prototypes Ce chapitre est consacré à l aspect technique de l'implantation des prototypes de couplage des SDDS avec les SGBDs AMOS-II et DB2. Nous présentons d abord les outils de communication entre processus distants et les concepts de la programmation multitâche que nous avons utilisés. Nous donnons ensuite une description détaillée de l architecture des prototypes et des opérations qu ils supportent. 1 Interface de communication entre processus distants 1.1 Interface de communication entre processus distants Le modèle des sockets a été initialement introduit dans Berkeley UNIX (BSD) au début des années 80. Les sockets ont été conçues comme des mécanismes de communication interprocessus (IPC) local. Plus tard, elles ont évolué vers des mécanismes de communication interprocessus réseau [Sin96], [Ric96] Caractéristiques d'une socket Propriétés d'une communication Une communication est évaluée à partir des propriétés suivantes : la fiabilité, le mode de communication, l ordre de réception des messages, la duplication des données, la préservation des limites de messages Le domaine d'une socket Une socket peut être utilisée sur plusieurs familles d adresses ou domaines. Chaque famille d adresses a sa propre syntaxe de représentation des adresses réseaux qui dépendent des protocoles utilisés. Les domaines suivants sont les plus utilisés: AF_INET pour le protocole TCP/IP, AF_IPX pour les protocoles IPX, SPX et AF_NETBIOS pour le protocole NetBeui Les types de sockets disponibles Le modèle des sockets Windows offre un service pour les communications avec connexion (socket séquence de données ou stream) et un service pour une communication sans connexion (socket datagramme). Le type SOCK_DGRAM supporte le mode non connecté avec des envois de datagrammes de taille limitée. Il y a préservation des limites de messages. Dans le domaine

53 Internet, le protocole sous-jacent est UDP. Le type SOCK_STREAM supporte des communications fiables en mode connecté. Dans le domaine Internet, le protocole sous-jacent est TCP La famille de protocoles TCP/IP Les Protocoles TCP/IP correspondent à un modèle composé des quatre couches suivantes : Application, Transport, Internet et Interface réseau. Ce modèle est souvent nommé famille de protocoles TCP/IP. Chaque couche du modèle TCP/IP correspond à une ou plusieurs couches du modèle OSI (Open Systems Interconnection) défini par l'iso (International Standards Organization). La Figure 21 présente la correspondance entre les couches du modèle OSI et TCP/IP. Application Présentation Session Transport Réseau Liaison de Données Physique Application Transport Internet Interface réseau Sockets TCP, UDP IP Réseaux locaux Modèle OSI Protocole Internet TCP/IP Figure 21. Correspondance entre le modèle OSI et TCP/IP La manière dont les ordinateurs sont connectés et communiquent dépend des protocoles définis à l'intérieur des quatre couches de TCP/IP. Les protocoles les plus utilisés sont TCP (Transmission Control Protocol), UDP (User Datagram Protocol), IP (Internet Protocol). Protocole TCP : Protocole de contrôle de transmission Il offre un service fiable de remise de paquets, orienté connexion, au-dessus du protocole IP. TCP garantit la remise des paquets et préserve l'ordre de transmission. Il fournit une somme de contrôle qui vérifie l'intégrité de l'en-tête des paquets et des données. TCP retransmet un paquet s il est endommagé ou perdu au cours de la transmission. Cette fiabilité fait de TCP un protocole bien adapté pour la transmission de données lors d'une session, pour les applications Client/Serveur et les services importants. Cette fiabilité engendre des contraintes : en effet, des bits supplémentaires sont nécessaires afin de remettre les informations dans l'ordre approprié ainsi que la somme de contrôle (checksum) obligatoire des paquets TCP. Afin d assurer la bonne remise des données, le destinataire est tenu émettre un accusé de réception par paquet. Les accusés de réception (ACK) génèrent un

54 supplément de trafic sur le réseau et ralentissent le débit de transmission des données mais en faveur d'une plus grande fiabilité. Protocole UDP : Protocole de datagramme utilisateur Si la fiabilité n'est pas un critère essentiel, UDP offre un service de datagrammes au-dessus du protocole IP. Ce service est sans connexion et ne garantit ni la remise, ni l'ordre d'arrivée des paquets délivrés. Ceci permet d'échanger des données sur des réseaux à fiabilité élevée sans encombrer inutilement le réseau. Le protocole UDP prend également en charge l'envoi de données d'un unique expéditeur vers plusieurs destinataires en même temps. Cette diffusion de groupe, appelée multipoint ou multicast, est un outil important pour la mise en œuvre de système Client/Serveur où un client désire s'adresser simultanément à un groupe de serveurs notamment lors des requêtes parallèles. Protocole IP : Protocole Internet Le protocole IP permet la remise des paquets pour tous les autres protocoles de la famille TCP/IP. Il fournit un système de remise de données optimisé, sans connexion. Il n'existe aucune garantie quant à la remise des paquets IP à leur destinataire ni leur réception dans l'ordre dans lequel ils ont été envoyés. Les protocoles de niveau supérieur sont ainsi responsables de la cohérence des données contenues dans les paquets IP et de leur ordre de délivrance à la couche application Création, identification et destruction d'une socket La création d'une socket se fait grâce à l'appel de la fonction socket(). Cette fonction rend un entier qui servira à identifier la socket créée. Il s'agit donc d'une ressource qui est du même genre que celle qui est allouée par la fonction d ouverture de fichier open(). De ce fait, la destruction de la socket se fait avec le même appel que celui de la fermeture d'un fichier : close(). Une socket a trois composantes primaires : l interface à laquelle elle est attachée (spécifiée par une adresse IP), le numéro de port et le mode de communication (séquence de données ou datagramme) Attachement d'une socket à une adresse Pour qu une socket soit une entité visible sur un réseau, il faut lui associer l adresse réseau de la machine sur laquelle elle est créée. L'attachement d'une adresse à une socket se fait grâce à l'appel de la fonction bind(). Du côté du récepteur, il faut obligatoirement appeler la fonction bind() pour que d'autres processus puissent le contacter à travers la socket ouverte. Cette fonction attend comme

55 argument l'adresse de la machine réceptrice. Il faut aussi y spécifier un numéro de port dans le deuxième champ. Le numéro de port permet de différencier plusieurs communications sur la même machine. En utilisant des numéros de port différents, il devient possible de démarrer en même temps plusieurs applications serveurs sur une machine. En affectant un numéro de port spécifique à chaque application, le système peut reconnaître les paquets appartenant à chacune d elles Communication par datagrammes Principe général La communication par datagramme permet à deux entités distantes d'échanger des messages. Il n'y a pas de connexion entre les deux entités communicantes. Un processus, après avoir ouvert une socket, peut l'utiliser pour communiquer avec plusieurs partenaires, aussi bien en émission qu'en réception. Chaque message doit contenir l'adresse du destinataire. Les frontières entre les messages sont conservées. Il n'y a pas de garantie autre que la qualité du contenu du message. Cela signifie que l expéditeur n'est pas assuré de la délivrance de son message : la fiabilité est plus ou moins bonne dans un réseau local (LAN), mais peut être très médiocre dans les WAN tel que le réseau mondial Internet. L expéditeur n est pas notifié de l'arrivée de son message. Un même message peut être délivré plusieurs fois. Deux messages émis successivement n'arrivent pas forcément dans le même ordre Exemple d'échange de données en mode datagramme Côté Emetteur Une fois la socket créée, il suffit de l'utiliser avec la fonction sendto(). Une application qui veut envoyer des données doit spécifier l adresse à laquelle les données sont destinées dans la fonction sendto(). Cette fonction retourne le nombre d'octets effectivement transmis et -1 en cas d'échec. Toutefois, les conditions d'échec ne sont que locales, en particulier, si un message est envoyé à une machine et un numéro de port sur lequel aucun processus n'écoute, il n'y aura pas de compte rendu d'erreur, et le message sera perdu sans que l'émetteur n en soit avisé. Par contre, la validité du descripteur de socket et la validité de l'adresse sont vérifiées. Côté récepteur Après l'ouverture de la socket et son attachement, le récepteur récupère les messages à l aide de la fonction recvfrom(). Cette fonction doit être appelée après l'attachement de la socket, et qu'un émetteur ait envoyé un message. Elle retourne le nombre d'octets reçus, ou le code erreur -1 en cas d'erreur. C'est une fonction bloquante si aucun caractère n'est disponible pour la lecture. Le

56 processus est alors réveillé dès qu'un caractère est disponible. Le récepteur peut connaître l'adresse de l'émetteur grâce à l'argument from retourné par la fonction recvfrom(). Côté émetteur Côté récepteur Créer une socket socket() Créer une socket socket() - - Attacher la socket à une adresse bind() Envoyer un message sendto() Recevoir le message recvfrom() Communication en mode connecté Principe général Dans le domaine Internet, ce mode de communication s'appuie sur le protocole TCP. Il augmente donc le volume d'octets transférés sur le réseau, mais assure en contrepartie la fiabilité de la communication. Avant la connexion, l'une des deux entités doit attendre une connexion, et l'autre la demander. Une fois la connexion établie, les deux entités jouent un rôle symétrique : émetteur et récepteur. Lorsqu une connexion est établie avec une socket séquence de données, un circuit virtuel est établi entre les deux entités communicantes sur les deux machines. Ce circuit reste ouvert jusqu à ce que l une des deux applications décide d arrêter l envoi de données sur le circuit (en appelant la fonction close()) ou jusqu à ce qu il y ait une erreur qui provoque la fin anormale du circuit de communication. Un autre aspect de la communication avec le protocole TCP est la continuité de l'information : il n'y a pas de frontières entre les messages Exemple d'échange de données en mode connecté L'attente et l'établissement de la connexion Une première socket d'écoute est ouverte par le récepteur et mise en attente de connexion avec la fonction listen(). Un paramètre important de cette fonction est la taille de la file d attente des demandes de connexions. Lorsqu'une demande de connexion arrive sur cette socket, l'appel de listen() est débloqué, le processus d écoute réveillé et une nouvelle socket est créée avec l'appel de la fonction accept(). C'est la deuxième socket qui est connectée à l'émetteur. Pour réaliser un véritable serveur, il faut créer un nouveau processus dès qu'une demande de connexion arrive, laisser le processus fils appeler la fonction accept(), et traiter le dialogue avec le nouveau client, pendant que le processus père reste en écoute de nouvelles demandes de

57 connexion sur la première socket qu'il a créée. En ne procédant pas de cette façon, le serveur ne peut alors traiter qu'une seule demande à la fois et toutes les nouvelles demandes provenant d'autres clients seront mises en attente jusqu'à ce que le serveur ait terminé la transaction avec le client en cours. La demande de connexion par le client La demande de connexion par le client est réalisée par l'appel de la fonction connect(). Cette fonction réussit à condition qu'il y ait bien un processus en attente de connexion (fonction listen()) sur la machine et le port désigné par l'adresse passée à la fonction connect() et que la file des demandes de connexions ne soit pas pleine. Le dialogue serveur/client L'envoi de données sur la connexion établie par connect() et accept(), est bidirectionnel. Chacune des deux entités peut alors envoyer des octets dans ce tuyau. L'ordre des octets est conservé. Une application envoie les données en utilisant la fonction send(). Cette fonction nécessite : le descripteur du socket, un pointeur sur le tampon à envoyer et la taille du tampon. Les appels de send() sont bloquants lorsque le tampon de réception de la socket distante est plein. Pour recevoir les données, l application utilise la fonction recv() qui nécessite un pointeur sur le tampon de réception et la taille du tampon. La fonction recv() renvoie le nombre d octets réellement reçu et send() renvoie le nombre d octets réellement envoyé. Notons que les applications client et serveur doivent toujours vérifier les codes retournés par les fonctions send() et recv() pour s assurer qu ils ne sont pas différents du nombre attendu. Cependant, un appel de send() d'un côté ne correspond pas nécessairement à un appel de recv() de l'autre côté. C'est-à-dire qu'il peut y avoir fragmentation ou assemblage par le destinataire des blocs de données envoyés par l'émetteur. Grâce à la nature orientée flux de données des sockets TCP, il n est pas nécessaire de faire des correspondances un à un entre les deux appels send() et recv(). Par exemple, une application client peut appeler dix fois la fonction send(), chacune de 100 octets. Le système peut combiner ces envois en un seul paquet réseau de telle façon que si l application serveur fait un appel recv() avec un tampon de 1000 octets, elle recevra toutes les données en une seule fois. Donc, une application ne doit faire aucune hypothèse concernant l arrivée des données. Un serveur attendant 1000 octets doit appeler la fonction recv() dans une boucle jusqu à ce que la somme des codes retour soit égale à

58 Côté émetteur Côté récepteur Créer une socket socket() Créer une socket socket() - - Attacher la socket à une bind() adresse - - Ecouter les demandes de listen() connexions Demander une connexion connect() Accepter la connexion accept() Envoyer des données send() Recevoir les données recv() La transmission multipoint(multicast) La notion de transmission de données en mode point à point (terminal-ordinateur, client-serveur) a évolué pour faire face à de nouveaux besoins : la communication d un émetteur vers plusieurs destinataires ou plusieurs vers plusieurs. Cette notion de transmission multipoint ou multicast vise à envoyer un message vers plusieurs sites en évitant de faire circuler de multiples exemplaires du même paquet sur un même lien, consommant ainsi de la bande passante. Des extensions ont donc été apportées au niveau de la couche IP pour supporter le multicast. Aux trois classes d'adressage IP traditionnelles (A, B et C) s'ajoute la classe D dite multipoint. Toute adresse IP commençant par les quatre bits 1110 appartient à cette classe et représente une adresse de groupe. Une adresse de groupe peut être partagée par un nombre quelconque d'équipements sur le réseau. En notation habituelle, les adresses de groupe vont de à Un certain nombre d'adresses sont réservées, parmi lesquelles qui ne doit pas être utilisée et qui représente l'ensemble des machines IP sur un réseau local. Les groupes évoluent dynamiquement, les systèmes rejoignent et quittent à la demande un nombre quelconque de groupes. A noter qu'il n'est pas nécessaire d'être membre d'un groupe pour émettre des messages vers ce groupe. Par contre une inscription est nécessaire pour recevoir les messages qui sont destinés à un groupe donné Mécanismes de communication inter-processus RPC Les RPC(Remote Procedure Call) permettent à un programme d exécuter des routines contenues dans un autre programme en dehors de son espace d adressage. Une application RPC est divisée en deux parties : Un serveur qui offre une interface composée d un ou de plusieurs procédures et un client qui fait appel aux services proposés. Le serveur et le client peuvent s exécuter sur des machines distantes et communiquer à travers un réseau. Le contrôle et la gestion de la communication réseau sont pris en charge par des routines RPC. Ils sont transparents pour les applications client et serveur. La table suivante montre le déroulement de l exécution d une application distribuée RPC sur le client et sur le serveur

59 Application Client 4. Appeler une procédure distante; 5. Convertir les paramètres d entrée au format d échange RPC ; 6. Transmettre les données au Serveur et se mettre en attente de résultat ; 12. Recevoir les résultats ; 13. Convertir les données au format des paramètres de sortie de la procédure appelée ; 14. Passer au traitement suivant. Application Serveur 1. Préciser les protocoles réseau à utiliser dans le cas ou le client et le serveur se trouvent sur des machines distantes ; 2. Déclarer les procédures supportées par le serveur ; 3. Se mettre en attente d appels ; 7. Recevoir un appel distant ; 8. Convertir les données au format des paramètres d entrée de la procédure appelée ; 9. Créer une tâche sur le serveur qui exécute la procédure ; 10. Convertir les résultats au format d échange RPC ; 11. Transmettre au Client le résultat ; 1.2 Programmation multitâche Processus et Threads Lorsqu'une application Win32 est activée, un processus est crée. Il s'agit d'une entité statique qui possède des éléments de l'application : code, données statiques et ressources diverses (telles que les fichiers ouverts ou les canaux). Mais, un processus n'existe jamais seul. En même temps que lui, se crée un thread. C'est la partie dynamique de l'application sur laquelle est basé le mécanisme du multitâche de Windows NT. En fait, l'ordonnanceur (la partie du système chargée de la mise en œuvre du multitâche) ne reconnaît que les threads et ignore les processus. Le premier thread d'une application, qui apparaît en même temps que le processus, s'appelle le thread principal. Une application peut créer d'autres threads de façon dynamique. Chaque thread dispose d'une pile spécifique, et est caractérisé par la valeur des registres du processeur indiquant son état d'exécution [Cus93], [Pet98]. La création d un nouveau thread se fait à l aide de la fonction CreateThread(), dont le principal paramètre est la fonction d'entrée du thread. Juste après l'appel de la fonction CreateThread(), l'application s'exécute en deux endroits différents : le premier thread continue son

60 fonctionnement à l'instruction qui suit l'appel ; le nouveau thread démarre à la fonction passée en paramètre lors de l'appel. Tous les deux s'exécutent alors parallèlement. Si la machine sur laquelle fonctionne l'application ne dispose que d'un processeur, les deux threads s'exécutent alternativement. Le système peut, à tout instant, interrompre un thread pour passer la main à un autre. Si le système est multiprocesseur, les deux threads sont susceptibles de fonctionner simultanément, chacun sur un processeur. Tout cela est transparent pour les applications. Le second thread poursuit son exécution jusqu'à ce que la fonction ExitThread() soit appelée ou qu'il sorte simplement lui-même de sa fonction d'entrée. Dans une application, le thread principal peut contenir les fonctions d'interface avec l'utilisateur (menu, boites de dialogue,...). Les threads créés dynamiquement peuvent servir à réaliser des tâches de fond Synchronisation de l'exécution des thread Il est nécessaire de synchroniser l'exécution des threads, c'est-à-dire disposer de mécanismes permettant de contrôler leur exécution. Considérons deux threads d'un même processus fonctionnant simultanément. Le premier écrit des données dans une structure globale de l'application, tandis que le second les lit. Puisqu'ils font partie du même processus, ils peuvent tous deux accéder à cette structure. Si, pendant que le premier thread écrit dans la structure, l'ordonnanceur effectue une commutation de contexte pour passer la main au second, celui-ci peut lire une structure dont les données sont incohérentes puisqu'en partie modifiées. Il faut mettre en place un blocage de la ressource partagée qu'est la structure globale. Le problème est le même pour des threads de processus différents, lorsque la ressource est un fichier, un périphérique ou une zone de mémoire partagée. Windows NT propose quatre mécanismes de synchronisation : Section critique, Mutex, Sémaphore et Event. La section critique ne peut être utilisée qu'à l'intérieur d'un même processus. Les trois autres permettent la synchronisation de threads situés dans des processus différents. La section critique assure l exclusion mutuelle entre les threads d un même processus. Elle assure la cohérence des données globales d un processus face aux accès concurrents des threads. Les fonctions EnterCriticalSection() et LeaveCriticalSection() imposent aux threads d'accéder séquentiellement aux ressources partagées. Le Mutex autorise un accès exclusif à une ressource par un thread. Le Sémaphore contrôle le nombre de threads utilisant simultanément une même ressource. L'Evénement (Event) permet d'avertir un ou plusieurs threads qu un événement attendu s est produit de façon qu'ils effectuent une action donnée. Un Mutex, un Sémaphore ou un Evénement sont des objets gérés par le système d'exploitation. Ils reçoivent un nom leur servant d'identification et peuvent être dans un des deux états suivants: signalé ou non signalé. La fonction WaitForSingleObject() est appelée par un thread pour attendre

61 qu'un objet de synchronisation soit en état signalé. Si c'est le cas, l attente se termine et le thread peut accéder à la ressource protégée par l'objet. S'il est en état non signalé, le thread est bloqué jusqu'à ce qu'un autre thread remette l'objet en état signalé ou jusqu'à ce qu'un délai d'attente soit épuisé. Le fait d'être bloqué sur l'appel d'une fonction n'empêche pas le système de passer la main aux autres threads Mémoire partagée L'autre problème qui se pose pour la réalisation d'une application multitâche est l'échange ou le partage de données. Windows NT se caractérise par une grande protection de la mémoire, ce qui fait que chaque processus dispose de son propre espace d'adressage. Les adresses en mémoire sont alors dites virtuelles, ce qui signifie que l'adresse 1792 dans un processus A, ne correspond pas au même emplacement physique que l'adresse 1792 du processus B. De cette manière, un processus n'a aucun moyen d'accéder aux données d'un autre processus. Si cela représente un avantage certain pour la sécurité et la fiabilité du système, il peut néanmoins constituer un handicap lorsqu'il est nécessaire de partager des données. Le partage de données entre deux processus différents se fait, dans Windows NT, à l'aide des fichiers mappés (mapped files). Un fichier mappé est un espace d'adressage virtuel auquel plusieurs processus peuvent accéder simultanément. La fonction CreateFileMapping() crée un fichier mappé. Lors de l'appel de cette fonction, il n'y a pas d'allocation de mémoire physique, mais simplement la mise en réserve d'un ensemble d'adresses virtuelles. Ce n'est que lors de l'appel de la fonction ViewMapOfFile() qu'une partie de la mémoire réservée est allouée, et que les threads peuvent y accéder. A la création avec la fonction CreateFileMapping(), le fichier mappé reçoit un nom grâce auquel les autres threads peuvent y accéder. 2 Implantation du système AMOS-SDDS Le système AMOS-SDDS est conçu, comme la plupart des applications réseau, en supposant qu'un côté se comporte comme un client et l'autre comme un serveur. La partie serveur de l'application a pour fonction de procurer des services définis pour les clients. Le transport des messages entre processus distants est assuré par l interface des sockets Windows. Cette interface permet le choix entre les protocoles TCP et UDP selon l importance et la taille des données à envoyer. Le parallélisme sur le client comme sur le serveur est basé sur le mécanisme du multitâche sous Windows NT avec les threads. 2.1 Client Le couplage du client SDDS avec AMOS-II se fait à travers une connexion stricte. Les deux systèmes sont regroupés dans le même fichier exécutable. Sur le plan fonctionnel, nous

62 distinguons deux couches distinctes qui communiquent par des appels de fonction. Ainsi, AMOS-II peut formuler des requêtes sur un fichier SDDS sans tenir compte du protocole de communication entre client et serveur. Il fait appel à des routines implantées au niveau du client qui se charge de structurer les requêtes et de les acheminer vers les serveurs adéquats. Cet ensemble de routines constitue une interface permettant l accès à un fichier SDDS de la même manière qu une ressource système Architecture du client Le client est composé de plusieurs threads de traitement regroupés en deux modules: le module d envoi et le module de réception. Le premier réceptionne les messages en provenance des applications pour les envoyer aux serveurs. Le second réceptionne les réponses provenant des serveurs pour les transmettre aux applications. Le module d envoi est composé de deux threads : le threads d'écoute des messages émis par les applications et le thread de traitement des renvois de requêtes. Le module de réception est aussi composé de deux threads : le thread d'écoute des réponses envoyées par les serveurs et le thread de traitement des réponses reçues. La synchronisation des threads est basée sur les événements. Un événement est signalé à chaque fois qu une réponse est reçue d un serveur. Le client utilise deux files d attente. La première contient les requêtes envoyées par le client mais qui n ont pas encore reçu d acquittement de la part des serveurs. La deuxième file d attente contient les réponses reçues qui ne sont pas encore traitées. L initialisation du client se fait en quatre étapes : Création des sockets de communication, création des files d attente, démarrage du thread d écoute et des threads de traitement. La Figure 22 présente l architecture globale de couplage du client SDDS avec AMOS-II File d'attente des requêtes en attente d'acquittement C est une liste linéaire dont chaque nœud comprend six champs : un pointeur vers le nœud suivant, l heure d envoi, le nombre de renvois déjà effectués, la clé, une chaîne de caractères contenant la requête et enfin l adresse de destination. La différence entre l heure courante et l heure d envoi renseigne sur la durée de séjour de la requête dans la file d attente. Le champ nombre de renvois est utilisé dans le cas où une requête devrait être abandonnée après un certain nombre d envois sans réponse de la part des serveurs. Le champ adresse mémorise le serveur de destination de la requête pour faciliter les renvois. La structure de donnée suivante en langage C est utilisée pour représenter un nœud. typedef struct lrequete {

63 struct lrequete * suivant; clock_t t_envoi; int nb_envoi; int cle; char * req; struct sockaddr_in addr; } listerequete; 1 Client Interface AMOS-SDDS Requête Image du Client Clé Adresse Réponse ChercheAdresseServeur() MAJ_image() Requête File d attente requête Requête... File d attente réponses Thread_Traiter_reponse() Réponse... Thread_EnvoyerRequête() Thread_RenvoyerRequête() Thread_RecevoirRéponse() Requête Réponse Canal Réseau Figure 22. Architecture du client File d'attente des réponses reçues C est une liste linéaire dont chaque nœud comprend trois champs : un pointeur vers le nœud suivant, une chaîne de caractères contenant le résultat d une requête et l adresse du serveur qui a envoyé la réponse. Un nœud de la file d attente des réponses est représenté par la structure de données suivante en langage C. typedef struct lmess { struct lmess * suivant; char * mess; struct sockaddr_in addr; } listemess;

64 Le thread d'écoute des messages émis par les applications Ce thread est chargé d envoyer les requêtes vers les serveurs concernés. Il adopte le fonctionnement suivant : 1. Attendre l arrivée d une requête émise par une application. 2. Chercher l adresse du serveur adéquat. 3. Envoyer la requête vers ce serveur. 4. Si la requête nécessite un acquittement alors la mettre dans la file d attente des requêtes en attente d acquittement. 5. Retourner à l étape Le thread de traitement des renvois de requêtes Les requêtes qui nécessitent un acquittement sont mises dans une file d attente avec leur temps d envoi et leur adresse de destination. Le thread de traitement des renvois est chargé de sonder la file d attente à intervalle de temps régulier. Il calcule la durée pendant laquelle chaque requête est restée, et si celle-ci dépasse un seuil alors la requête est renvoyée. Ce thread adopte le fonctionnement suivant : 1. Attendre l expiration d un délai d attente ; 2. Parcourir la file d attente des requêtes en attente d acquittement ; 3. Envoyer à nouveau toutes les requêtes qui sont restées dans la file d attente plus de 300ms ; 4. Retourner à l étape Le thread d'écoute des réponses envoyées par les serveurs Ce thread écoute en permanence l arrivée de nouveaux messages sur le port de réception du client. Son rôle consiste à empiler les messages qui arrivent sur le tampon UDP dans une file d attente. Il adopte le fonctionnement suivant : 1. Attendre l arrivée d un paquet sur le tampon UDP; 2. Mettre le message dans la file d attente des réponses en attente de traitement; 3. Signaler l'événement «arrivée d une réponse» au thread de traitement des réponses ; 4. Retourner à l étape Le thread de traitement des réponses reçues Ce thread est couplé avec celui qui écoute les réponses envoyées par les serveurs. Il est chargé de traiter les messages reçus. Il adopte le fonctionnement suivant : 1. Attendre que l'événement «arrivée d une réponse» soit signalé. 2. Prendre une réponse de la file d attente des réponses reçues. 3. Retirer la requête correspondante de la file d attente des requêtes en attente d acquittement

65 4. Retourner la réponse à l application. 5. Mettre à jour l image du client avec l IAM contenu dans le message réponse. 6. Si la file d attente des réponses en attente de traitement n est pas vide passer à l étape 2, sinon passer à l étape Le dialogue Client/Serveur Le client et le serveur SDDS communiquent en utilisant le protocole et les formats de messages définis dans [Die98]. Le système SD-AMOS utilise un format de message simplifié décrit dans la section suivante. Le protocole UDP est utilisé pour la communication dans le sens client vers serveur. C est principalement pour l envoi de requêtes aux serveurs. Le client envoie une requête par un message unicast si elle concerne un seul serveur dont l adresse est connue. Si par contre, il s agit d une requête parallèle ou si le client ne connaît pas l adresse alors un message multicast est utilisé. A la réception d une requête, les serveurs effectuent le traitement en parallèle et un résultat est généré dans un tampon sur chaque site. Le schéma de collecte des résultats par le client dépend principalement de la taille globale des tampons. Si elle n est pas importante, les serveurs peuvent établir des connexions TCP avec le client simultanément pour transférer leur tampon. Dans ce cas, le protocole de terminaison déterministe est utilisé pour détecter la fin du traitement de la requête. Si la taille de la réponse à une requête est assez importante pour ne pas tenir sur le client alors la solution consiste à constituer un fichier temporaire sur les serveurs. Le client pourra ensuite parcourir ce fichier pour récupérer les résultats par bloc Le format des messages dans SD-AMOS Nous distinguons trois types de message : l envoi d une requête dans le sens client vers serveur, la redirection de requêtes dans le sens serveur vers serveur et l envoi d une réponse dans le sens serveur vers client. Une requête envoyée par le client comporte trois champs : ( Type message, Code requête, Données) Type Message : type de message utilisé pour envoyer la requête. 0 = unicast, 1 = multicast Code Requête : identifiant de la commande passée par le message. 1 = Insertion, 2 = Recherche simple, 3 = Recherche par intervalle, 4 = Suppression et 5 = Requête AMOS-II. Données : Le nombre de champs dépend du code de la requête

66 Nous avons trois champs pour une insertion (Clé, Nom, Ville), un champ pour une recherche simple (Clé) et deux champs pour une recherche par intervalle (Clé début, Clé fin). Clé début et Clé fin sont les bornes inférieure et supérieure de l intervalle de recherche. Les redirections concernent les requêtes envoyées par un message unicast. Un serveur qui reçoit un message qui ne lui est pas destiné, change le type de requêtes, ajoute ses propres informations et renvoie le message par multicast. Un message est redirigé avec le format suivant : (Type message, Code requête, Clé Min serveur 1, Clé Max serveur 1, Adresse serveur 1, Port serveur 1, Adresse Client, Donnée) Type message : 2 Code requête : 11 = Redirection insertion, 22 = Redirection recherche simple et 33 = Redirection suppression. Le message de réponse peut comporter un ou deux champs IAM selon le nombre de serveurs qu a traversés la requête. Le premier champ indique donc le nombre d IAM pour permettre au client de connaître le nombre de champs à extraire du message. Réponse avec 1 IAM : (Nb_IAM, Code réponse, Clé Min serveur, Clé Max serveur, Port serveur, Données) Réponse avec 2 IAM : (Nb_IAM, Code réponse, Clé Min serveur 1, Clé Max serveur 1, Adresse serveur 1, Port serveur 1, Clé Min serveur 2, Clé Max serveur 2, Port serveur 2, Données) Les structures de données Le transfert de données entre client et serveur se fait à l aide de tampon de communication. Deux types de tampon sont utilisés : un tampon avec des champs de longueur variable et un tampon avec des champs de longueur fixe. Le tampon avec des champs de longueur variable est une chaîne de caractères qui utilise un caractère spécial pour délimiter deux enregistrements. Les différents champs d un même enregistrement n ont pas la même longueur. Ils sont séparés par un caractère spécial. Les caractères de séparation ne sont pas des valeurs permises à l intérieur d un champ. L utilisation de ce type de tampon nécessite une opération de groupage des enregistrements à l envoi et une opération de dégroupage à la réception. Le dégroupage consiste à parcourir le tampon caractère par caractère pour en extraire les enregistrements et leurs différents champs. Les caractères de séparation sont alors utilisés pour délimiter les différentes valeurs. La Figure 23 présente le schéma d un tampon avec séparateur. Figure 23. structure du tampon avec des séparateurs

67 Un tampon avec des champs de longueur fixe contrairement au précédent, n utilise pas de séparateurs. Une structure de données est définie avec des champs de longueur fixe. Le tampon devient une table de structures. Il est alors possible d accéder à un enregistrement à partir de sa position. L utilisation de tampon nécessite de déclarer sur le client et sur le serveur les mêmes structures de données avec le même nombre de champs. Cela suppose que les types de données qui seront échangés par le client et le serveur sont connus d avance avant la compilation du programme. En effet la déclaration des structures de données ne peut pas se faire de manière dynamique même si ces derniers offrent une plus grande facilité d utilisation. La Figure 24 présente le schéma d un tampon avec des champs de longueur fixe. Figure 24. structure du tampon avec des champs de longueur fixe Structures de données pour le traitement de la requête de jointure Le traitement de la requête de jointure peut être découpé en trois étapes : - Balayage parallèle des serveurs pour récupérer tous les enregistrements du fichier dans un tampon au niveau du client. - Découpage du tampon en petits paquets au niveau du client et boucle d envoi des paquets aux serveurs. Le traitement sur un serveur consiste à faire la jointure des tuples contenus dans le paquet reçu avec ceux stockés dans la case SDDS locale. - Collecte par le client du résultat du traitement d un paquet. Une structure de données spécifique est utilisée pour chacune des étapes ci-dessus. Le balayage utilise une structure de données à champ fixe. Elle est définie comme suit en langage C : typedef Struct OnePerson { int Cle; char nom[20]; char ville[20]; } listeperson; Le données envoyées aux serveurs sont formatées dans un tampon avec des champs de longueur variable. Le caractère slash / et le caractère blanc sont utilisés respectivement comme séparateur d enregistrements et séparateur de champs. Une structure binaire est plus adaptée mais les fonctions externes AMOS-II ne permettent pas actuellement de gérer des chaînes de bits. Le résultat du traitement d un tampon est une structure binaire. Elle est définie comme suit en langage C:

68 typedef struct OneItem { int Cle1; int Cle2; } listeitem; Protocole de terminaison déterministe Ce protocole concerne les requêtes parallèles qui impliquent plusieurs serveurs. Il traite le cas où le client désire récupérer les résultats en établissant autant de connexions TCP qu il y a de serveurs qui désirent envoyer des données. Après l envoi d une requête, une première socket d'écoute est ouverte par le client. Cette socket est mise en attente de connexion avec la fonction listen(). Un paramètre important de la fonction listen() est la taille de la file d attente des demandes de connexions(5 sur Windows NT 4 Serveur et 200 sur Windows 2000 Serveur). Lorsqu'une demande de connexion arrive sur cette socket, l'appel de listen() est débloqué et le processus d écoute réactivé. Une nouvelle socket est alors créée par l'appel de la fonction accept(). Un nouveau processus est crée dès qu'une demande de connexion arrive, ce processus fils appelle la fonction accept(), et traite le dialogue avec le serveur. Parallèlement le processus père vérifie si tous les serveurs ont répondu et selon le cas arrêtera l écoute ou attendra de nouvelles demandes de connexions sur la première socket qu'il a créée. Chaque processus dispose de son propre tampon de réception que nous supposons assez grand pour contenir toutes les réponses provenant d un serveur. La réponse globale d une requête est constituée de l union des tampons de réception Recouvrement des réponses et Test de serveur manquant Avec le protocole de terminaison déterministe, chaque serveur qui reçoit une requête, est tenu d envoyer une réponse. Si le résultat du traitement de la requête n est pas vide, la réponse comporte deux parties : un intervalle et un tampon d enregistrements. Si le résultat est vide alors le serveur envoie uniquement l intersection de son intervalle avec l intervalle de la requête. L union des intervalles des serveurs qui ont répondu doit recouvrir l intervalle de la requête. Ainsi, il est facile de détecter les serveurs n ayant pas répondu pour effectuer une relance ou détecter la panne d un site. La collecte des données envoyées par les serveurs se fait à l aide d une structure de données sous forme de liste linéaire. Chaque nœud comprend trois champs : une clé, un tampon et un drapeau. - Le champ clé permet de représenter l intervalle des serveurs. - Le tampon est destiné à recevoir les enregistrements envoyés par un serveur

69 - Le drapeau permet de détecter les intervalles manquants. Il peut prendre deux valeurs : vrai(valeur 1) ou faux(valeur 0). Avant d envoyer une requête parallèle, le client initialise la liste de réception avec deux nœuds. Le premier contient la clé minimale de la requête et le second contient la clé maximale. Les tampons des deux nœuds sont initialement vides et les drapeaux prennent la valeur 0. Un nœud est défini comme suit en langage C: typedef struct lrange { struct lrange * suivant; unsigned int cle; listeperson *Buf; int nb; } listerange; La liste est mise à jour à l aide des trois champs contenus dans la réponse d un serveur : la clé minimale, la clé maximale et le tampon. La mise à jour se fait suivant l algorithme ci-dessous : (a) S'il n'existe pas un nœud dans liste dont la clé est égale à la clé minimale reçue Alors insérer un nouveau nœud avec les valeurs clé minimale et tampon. Mettre le drapeau à «vrai» (b) S'il existe un nœud dans liste dont la clé est égale à la clé minimale reçue Alors mettre le tampon reçu dans le tampon du nœud trouvé et le drapeau à «vrai». (c) S'il n'existe pas un nœud dans liste dont la clé est égale à la clé maximale reçue Alors insérer un nouveau nœud avec comme valeurs la clé maximale. Mettre le tampon à vide et mettre le drapeau à «faux». Les nœuds sont insérés dans l ordre croissant des intervalles de serveurs. Ainsi l état final de la liste ne dépend pas de l ordre d arrivé sur le client des réponses des serveurs. A la fin de la requête, il suffit de parcourir la liste du début à la fin pour récupérer les résultats déjà triés dans l ordre croissant des clés. Ce résultat est aussi dû au fait que les enregistrements à l intérieur de chaque tampon, sont triés dans l ordre croissant des clés à cause de la fragmentation des données à l aide des algorithmes RP*. Les serveurs manquants sont symbolisés dans la liste par les drapeaux avec la valeur «faux». Ainsi, en parcourant la liste nous pouvons retrouver les intervalles pour lesquels une réponse d un serveur n a pas été reçue. Un intervalle manquant correspond à un ou plusieurs serveurs manquants. En effet, si deux serveurs dont les intervalles sont contigus ne répondent pas, cela est représenté dans la liste par un seul nœud avec un drapeau à «faux» et comme valeur de clé, la clé minimale du premier serveur. La Figure 26 donne un exemple de constitution de la liste des

70 réponses en formulant une requête à intervalle sur un fichier réparti sur quatre serveurs(cf. Figure 25) S0 S1 S2 S3 Figure 25. Fichier sur quatre serveurs Etat initial de la liste pour une requête portant sur l intervalle [0, 30] : L0 [0, faux] [30, faux] Serveur Intervalle réponse évolution de la liste S0 (0,8) L1 [0, vrai] [8, faux] [30, faux] S2 (16,21) L2 [0, vrai] [8, faux] [16, vrai] [21, faux] [30, faux] S1 (21,30) L3 [0, vrai] [8, faux] [16, vrai] [21, vrai] [30, faux] S3 (8,16) L4 [0, vrai] [8, vrai] [16, vrai] [21, vrai] [30, faux] Figure 26. Evolution de la liste des réponses si tous les serveurs ont répondu L état final de la liste est L4. Tous les drapeaux ont la valeur «vrai» sauf sur le dernier nœud qui n est pas pris en compte. Cette situation représente le cas idéal où toutes les réponses des serveurs concernés par la requête, sont bien parvenues au client. Les exemples suivants présentent les cas où deux serveurs concernés par la requête, ne répondent pas. Exemple 1 : Evolution de la liste des réponses si les serveurs 2 et 3 n ont pas répondu. Etat initial de la liste : L0 [0, faux] [30, faux] Serveur Intervalle réponse évolution de la liste S0 (0,8) L1 [0, vrai] [8, faux] [30, faux] S1 (21,30) L2 [0, vrai] [8, faux] [21, vrai] [30, faux] L état final de la liste est : [0, vrai] [8, faux] [21, vrai] [30, faux] Le drapeau du deuxième nœud à «faux» indique que l intervalle entre les clés des nœuds deux et trois est manquant. Cet intervalle [8, 21], correspond physiquement à deux serveurs(2 et 3). Exemple 2 : Un autre cas possible est celui ou par exemple les serveurs 0 et 2 ne répondent pas. Etat initial de la liste : L0 [0, faux] [30, faux] Serveur Intervalle réponse évolution de la liste S1 (21,30) L1 [0, faux] [21, vrai] [30, faux] S3 (8,16) L2 [0, faux] [8, vrai] [16, faux] [21, vrai] [30, faux] L état final de la liste est : [0, faux] [8, vrai] [16, faux] [21, vrai] [30, faux]

71 Les drapeaux du premier et du troisième nœud à «faux» indiquent que les intervalles [0,8] et [16,21] sont manquants. Ces intervalles correspondent physiquement aux serveurs 0 et Contrôle de flux et Gestion des acquittements Pour envoyer les requêtes, le client utilise le protocole UDP. Des pertes peuvent survenir si le flux d envoi est trop important sur un client ou s il y a plusieurs clients qui envoient simultanément vers le même serveur. Ce dernier n arrive alors plus à vider son tampon de réception à la même vitesse qu il se remplit. Pour se prémunir contre les pertes de message, le client peut demander au serveur de lui envoyer un accusé de réception par requête. Dans ce cas, s il ne reçoit pas l acquittement au bout d un certain temps, il suppose le message perdu et relance la requête. Pour contrôler le flux d envoi sur le client, un crédit de requêtes en attente d acquittement est fixé. Après chaque envoi le client décrémente le chiffre et l incrémente après chaque réception d un acquittement. Le client arrête les envois dès que le crédit est nul Interfaçage du client SDDS avec AMOS-II La présente version du client offre quatre fonctionnalités aux applications : l insertion d un enregistrement, la recherche d un enregistrement, la recherche par intervalle et le balayage complet du fichier. Un enregistrement est composé de deux champs : une clé numérique et un champ texte. Le champ texte peut être subdivisé par l application en plusieurs sous-champs. Dans le cas du couplage avec AMOS-II, le champ texte est subdivisé en deux sous-champ avec comme séparateur le caractère souligné. Le format utilisé par une application pour représenter les données dans le champ texte d un enregistrement est transparent pour le gestionnaire SDDS. Dans le cas d une recherche par exemple, le client SDDS ne retourne à l application que deux valeurs : la clé et une chaîne de caractères. C est à la charge de l application de parcourir la chaîne de caractères pour en extraire les différents champs qui le composent. AMOS-II ne peut pas faire appel directement aux quatre fonctions de base disponibles sur le client SDDS. Le couplage consiste à programmer des fonctions externes qui font appel aux fonctions SDDS suivant les spécifications de l API AMOS-II. Une fonction externe adopte le fonctionnement suivant : récupérer les paramètres d entrée dans un format propre à AMOS-II, convertir les paramètres dans le format C et faire appel selon le traitement désiré à la fonction SDDS appropriée, récupérer les résultats de la fonction SDDS au format C, les convertir au format AMOS-II et en dernier lieu retourner le résultat final au système AMOS-II à l aide de la fonction a_emit. La Figure 27 illustre le déroulement d'une fonction externe. Il n y a pas de limites sur le nombre de fonctions externes qui peuvent être définies dans AMOS- II à partir des fonctions SDDS. Chaque fonction externe effectue un traitement particulier. Elles

72 sont donc définies en fonction des types de requêtes qui sont destinées à être exécutés sur le système. Une fonction externe est déclarée dans AMOS-II à l aide de l instruction CREATE FUNCTION. C est après la déclaration que la fonction devient accessible aux utilisateurs au même titre que les fonctions prédéfinies de AMOS-II. La déclaration permet de définir le schéma de la fonction externe: c est à dire le nom, les paramètres d entrée et les paramètres de sortie. Pour les besoins des expérimentations du couplage de AMOS-II avec les SDDS, un fichier de personnes est crée avec trois champs : une clé numérique, un champ texte pour le nom et un champ texte pour la ville. Les fonctions externes décrites ci-dessous permettent d effectuer des insertions et des recherches sur le fichier personne à partir de AMOS-II. Client AMOS II 1Appel fonction externe 10Résultats 2Conversion AMOS-C 9Conversion C-AMOS 3Appel fonction SDDS Case SDDS 4Envoyer requête 5Recevoir requête 6Traiter requête Client SDDS 8Recevoir résultats 7Envoyer résultats Serveur SDDS Client AMOS-SDDS Serveur AMOS-SDDS Réseau Figure 27. Déroulement d'une fonction externe sur le client Insertion d un enregistrement dans le fichier SDDS personne depuis AMOS-II. create function inserer(integer cle, charstring nom, charstring ville) -> charstring resultat as foreign 'insererbf'; A partir de la ligne de commande de AMOS-II, l insertion d une personne avec la clé 13, le nom «Jean» et la ville «Paris», se fait à l aide de la requête suivante : inserer (13, "jean","paris"). Recherche du nom et de la ville d une personne connaissant sa clé. create function sdds_access(integer cle) -> <charstring nom, charstring ville> as foreign 'recherchebf'; A partir de la ligne de commande de AMOS-II, la recherche de la personne de clé 13 se fait à l aide de la requête suivante : sdds_access (13). Le résultat sera <"jean","paris"> Recherche du nom d une personne connaissant sa clé. create function champ1(integer cle) -> charstring nom as foreign 'champ1bf'; Recherche de la ville d une personne connaissant sa clé

73 create function champ2(integer cle) -> charstring ville as foreign 'champ2bf'; Recherche par intervalle pour retrouver les personnes dont la clé est comprise entre une valeur minimale et une valeur maximale. create function sdds_range(integer cle_min, integer cle_max) -> <integer cle, charstring nom, charstring ville> as foreign 'rangebf'; Balayage complet du fichier personne. Les enregistrements sont retournés un à un. create function sdds_fullextent() -> <integer cle, charstring nom, charstring ville> as foreign 'fullscanbf'; Balayage complet du fichier personne en retournant les enregistrements par paquet non trié dans un tampon. create function sdds_fullextent1() -> <integer cle, charstring nom, charstring ville> as foreign 'fullscan1bf'; Balayage complet du fichier personne en retournant les enregistrements par paquet trié dans l ordre croissant du champ ville. Cette fonction est utilisée dans le traitement de la jointure distribuée. create function sdds_fullextent2() -> <integer cle, charstring nom, charstring ville> as foreign 'fullscan2bf'; Envoyer une fonction non plus à un serveur SDDS distant mais au serveur AMOS-II qui lui est couplé. Le paramètre d entrée de cette fonction est une requête AMOSQL. create function f_ship(charstring requete) -> <integer cle, charstring nom, charstring ville> as foreign 'fshipbf'; Envoyer un tampon contenant plusieurs enregistrements aux serveurs AMOS-II distants. A la réception de ce message, le serveur SDDS appelle une fonction AMOS-II à travers l interface CALLIN et lui passe en paramètre d entrée le tampon reçu. create function f_ship1(charstring chaine) -> <integer cle1, integer cle2> as foreign 'fship1bf' 2.2 Serveur Le serveur SDDS adopte un fonctionnement concurrent en se basant sur la mise en œuvre du multitâche sous Windows NT grâce à l utilisation des threads ou processus légers et des mécanismes de synchronisation par les événements Architecture du serveur Conçu pour servir un grand nombre de clients, le programme serveur comporte un module d écoute qui se charge de recevoir les requêtes. Le serveur utilise une file d attente pour les requêtes envoyées par le client, non encore traitées. Dans le système AMOS-SDDS nous disposons de deux threads d écoute sur des ports différents, l un spécifiquement pour les requêtes SDDS et l autre pour les requêtes AMOSQL. Dans le système SD-AMOS nous disposons d un seul thread d écoute, puisque ce système ne supporte que les requêtes AMOSQL. Chaque serveur comporte également un module de traitement composé d un groupe de threads qui tournent en parallèle. La tâche d un thread de traitement consiste à sonder en permanence la file d attente

74 pour traiter les requêtes qui s y trouvent. Un thread de traitement effectue une boucle sur les étapes suivantes : 1. Retirer une requête de la file d attente ; 2. Effectuer les traitements demandés ; 3. Retourner les résultats au client. Le nombre de threads est fixé en fonction de la puissance de la machine sur laquelle tourne le serveur. L utilisation de plusieurs threads permet de tirer profit de l intra-parallélisme pour augmenter la vitesse de traitement des requêtes. Le parallélisme exige la mise en œuvre de mécanismes de synchronisation afin de garantir la cohérence des données partagées. La synchronisation des threads d écoute et de traitement est basée sur les événements. Un événement est signalé à chaque fois qu une requête est reçue d un client. L initialisation du serveur se fait en quatre étapes : Création des sockets de communication, création de la file d attente des requêtes en attente de traitement, démarrage du thread d écoute et des threads de traitement. La Figure 28 présente l architecture globale de couplage du serveur SDDS avec AMOS-II File d'attente des requêtes en attente d être traitées C est une liste linéaire dont chaque nœud comprend trois champs : un pointeur vers le nœud suivant, une chaîne de caractères contenant la requête et l adresse de l expéditeur. Les requêtes sont traitées suivant leur ordre d arrivée sur le serveur. Le thread d écoute insère un nouveau nœud en fin de liste et un thread de traitement retire toujours l élément situé en tête de liste. Si plusieurs threads de traitement tournent en parallèle, alors ils accèdent à la file d attente en section critique afin d éviter qu une même requête ne soit traitée plus d une fois. La structure de donnée suivante en langage C est utilisée pour représenter un nœud. typedef struct lmess { struct lmess * suivant; char * mess; struct sockaddr_in addr; } listemess;

75 Serveur Interface AMOS-SDDS 1 Fonctions externes Interface Callin Case SDDS Réponse Requête AMOS... Thread_Traiter_SDDS() Thread_Traiter_SDDS() Réponse File d attente... File d attente... Thread_Ecoute_Requete_SDDS() Thread_Ecoute_Requete_AMOS() Réponse Port SDDS Requête Réponse Requête Port AMOS Réseau Figure 28. Architecture globale de couplage de AMOS-II avec les SDDS Module de communication Ce module comporte deux threads dans la configuration AMOS-SDDS et d un seul thread dans SD-AMOS. Un thread écoute en permanence l arrivée de nouvelle requête sur le port de réception du serveur. Son rôle est de vider les messages qui arrivent dans le tampon UDP et les mettre dans une file d attente du serveur. Il adopte le fonctionnement suivant : 1. Ecouter au niveau de la socket de communication les requêtes émises par un client; 2. Placer les requêtes reçues dans la file d'attente et signaler l'événement «arrivée requête»; 3. Retourner à l étape Module de traitement Ce module peut comporter plusieurs threads actifs. Ces derniers traitent les requêtes reçues sur les données locales du serveur. Les threads de traitement vident progressivement la file d attente des requêtes en attente de traitement. Ils adoptent le fonctionnement suivant : 1. Attendre que l'événement «arrivée requête» soit signalé ; 2. Prendre une requête de la file d attente ; 3. Analyser la requête pour voir le traitement demandé ; 4. Selon le cas, effectuer le traitement en local, rediriger la requête ou lancer le processus d'éclatement de la case ;

76 5. Si la file d attente n est pas vide passer à l étape 2. sinon retourner à l étape Procédure d éclatement Si le nombre d enregistrements de la case atteint la capacité maximale, alors toute tentative d insertion entraîne un débordement. C est le thread de traitement qui a constaté le débordement qui se charge d exécuter la procédure d éclatement. La procédure d éclatement se déroule en plusieurs étapes. La case est d abord verrouillée. Les threads de traitement ne prennent plus de nouvelles requêtes dans la file d attente. Les traitements en cours vont jusqu à leur terme. L étape suivante consiste à choisir un nouveau site et à y transférer la moitié des enregistrements de la case en débordement. Le choix d un nouveau site est la phase la plus cruciale de l éclatement. Elle est traitée en détail dans la section suivante. Le transfert de la moitié de la case selon les spécifications des algorithmes RP*, consiste à identifier la clé du milieu, puis à déplacer tous les enregistrements dont la clé est supérieure vers le nouveau site. La clé du milieu reste sur la case en débordement et devient sa nouvelle borne supérieure. Dans SD-AMOS, retrouver la clé du milieu d une case est une opération coûteuse puisque AMOS-II ne dispose pas d instruction permettant d accéder à un enregistrement à partir de son rang dans le fichier. Retrouver la clé du milieu revient à lancer une requête de balayage puis, à parcourir le tampon résultat enregistrement par enregistrement à l aide de l instruction a_nextrow() jusqu à la position du milieu. Pour contourner cela nous faisons une estimation de la clé du milieu à partir de la clé minimale et maximale de la case. Ces deux valeurs sont retournées par les fonctions AMOS-II maxagg() et minagg(). A l issue du transfert, la case est déverrouillée et les threads reprennent le traitement des requêtes. Pendant toute la durée du transfert, le thread d écoute continue à tourner et à recevoir de nouvelles requêtes dans la file d attente. A l issue de l éclatement, toutes les requêtes qui portent sur des données déplacées seront redirigées vers le nouveau serveur Choix d un nouveau site Le système SDDS distingue deux types de serveurs : ceux qui sont actifs de ceux qui sont en veille. Deux adresses multicast différentes sont affectées aux deux groupes. Un serveur en débordement envoie une demande de site disponible en multicast aux serveurs en état de veille, puis se met en attente de connexion TCP. Tout serveur libre qui reçoit un tel message récupère l adresse du serveur en débordement qu il contient et tente aussitôt d établir une connexion TCP avec lui. Le choix est fait sur le serveur qui réussit la connexion TCP. Les autres retournent en mode veille. Le serveur en débordement transfert alors la moitié de ses enregistrements vers le nouveau serveur, et met à jour son intervalle. Le nouveau serveur crée une table AMOS-II, y

77 insère tous les enregistrements qu il a reçus, initialise son intervalle et démarre ensuite les processus de traitement. Il passe ainsi en mode actif. Dans le cas où un serveur plein ne trouverait pas de site disponible, il continue son fonctionnement normal, tandis que la demande d éclatement est relancée à intervalle régulier. Ce protocole de choix de nouveau site, basé sur des échanges de messages réseau offre un maximum de souplesse pour l ajout de nouveaux nœuds au système SDDS sans affecter le fonctionnement des serveurs qui ne sont pas concernés pas l éclatement. En effet, il n existe pas de liste des serveurs à maintenir sur chaque site, ni de site coordinateur. La Figure 29 schématise le processus d éclatement. Serveur plein Serveur libre i Serveur libre 1 Serveur libre 2 Figure 29. Protocole d'éclatement Interfaçage du serveur SDDS avec AMOS-II 1 Demande_Eclatement 2 Demande_ConnexionTCP 3ConnexionTCP&Transfert Le couplage de AMOS-II avec les SDDS revêt deux volets sur le serveur. Dans la première configuration dénommée AMOS-SDDS, il s agit de stocker des données dans la case SDDS et de définir dans AMOS-II les fonctions externes qui permettent d y accéder. Dans le second cas dénommé SD-AMOS où les données sont stockées dans la base AMOS-II, il s agit d utiliser le serveur SDDS pour soumettre des requêtes parallèles au serveur AMOS-II Le serveur AMOS-SDDS Le déroulement d une fonction externe sur le serveur est pareil que sur le client : récupérer les paramètres d entrée dans un format propre à AMOS-II, convertir les paramètres dans le format C et faire appel selon le traitement désiré à la fonction SDDS appropriée, récupérer les résultats de la fonction SDDS au format C, les convertir au format AMOS-II et en dernier lieu retourner le résultat final au système AMOS-II à l aide de la fonction a_emit. La principale différence est que les fonctions externes sur le serveur permettent uniquement à AMOS-II d accéder aux données qui se trouve dans la case SDDS qui lui est couplé. Il n y a pas de communication directe ni d échange de données entre serveurs dans le traitement des requêtes. Les transferts de données de serveur à serveur ne se font que durant l éclatement d une case. Une fonction externe sur le

78 serveur accède donc directement à la case SDDS via l interface CALLOUT sans passer par la couche réseau. La Figure 30 schématise le déroulement d'une fonction externe sur le serveur AMOS-SDDS. Serveur AMOS II 1Appel fonction externe 6Résultats 2Conversion AMOS-C 5Conversion C-AMOS 3Appel fonction SDDS 4Résultats Case SDDS Serveur SDDS Réseau Serveur AMOS-SDDS Figure 30. Déroulement d'une fonction externe sur le serveur AMOS-SDDS Les fonctions externes suivantes ont été définies dans AMOS-II et permettent d effectuer différentes opérations de base de données sur une case SDDS. Balayage complet d une la case SDDS à partir du serveur AMOS-II qui lui est couplé. Les enregistrements sont retournés un à un. create function sdds_fullextent() -> <integer Cle, charstring nom, charstring ville> as foreign 'fullscanbf'; Créer une table temporaire dans AMOS-II qui servira dans le traitement des requêtes avec la stratégie d importation. create function person_temp(integer Cle)-> charstring nom, charstring ville as stored; Importer la totalité de la case SDDS dans la mémoire interne de AMOS-II. create function load_bucket() -> boolean as foreign 'load_bucketbf'; Importer un tampon d enregistrement dans la table temporaire interne de AMOS-II. create function importer(charstring chaine) -> boolean as foreign 'importerbf'; Vider la table temporaire interne de AMOS-II. Cette fonction est appelée après chaque traitement d une requête avec la stratégie d importation. create function remove_person()->boolean as begin clear_function('person_temp'); end; Traiter une requête de jointure avec la stratégie externe. Cette fonction prend en paramètre un enregistrement et un tampon. Le traitement consiste à parcourir les enregistrements contenus dans le tampon et à les comparer avec celui fourni en paramètre

79 create function compare11(integer Cle, charstring nom, charstring ville, charstring chaine) -> integer as foreign 'compare11bf'; Le serveur SD-AMOS Par rapport au système AMOS-SDDS, les données sont maintenant entièrement stockées dans des tables internes AMOS-II. Il n existe plus de fonctions externes définies sur le serveur et dont le rôle est de gérer les accès aux données stockées dans une case SDDS. Le système SD-AMOS utilise des fonctions mémorisées qui jouent plutôt le rôle de procédures stockées et permettent de réduire les temps de traitement. En effet, l optimiseur de requêtes de AMOS-II n est pas invoqué à chaque fois que la requête est exécutée, mais une seule fois à la création de la fonction. Des fonctions vont être définies pour toutes les tâches fréquemment exécutées sur le serveur. Les fonctions mémorisées sont appelées par le serveur SDDS à partir de l interface CALLIN de AMOS-II. L exécution d une fonction se fait en cinq étapes : 1. Convertir les paramètres d entrée dans le format AMOS-II ; 2. Faire appel selon le traitement désiré à la fonction mémorisée appropriée ; 3. Récupérer les résultats de la fonction dans une structure de données AMOS-II ; 4. Extraire les enregistrements qu elle contient et les mettre dans un tampon ; 5. Retourner le tampon au client. La Figure 31 schématise le déroulement d'une fonction mémorisée sur le serveur SD-AMOS. Pour les besoins des expérimentations sur le système SD-AMOS, un fichier de personnes est crée dans la mémoire interne de AMOS-II. Le fichier est identique à celui utilisé dans le système AMOS-SDDS. Il comporte trois champs : une clé numérique, un champ texte pour le nom et un champ texte pour la ville. Un index en B-arbre est crée sur la clé afin de pouvoir récupérer les enregistrements triés dans l ordre croisant des clés. La création du fichier et de l index est faite comme suit en AMOSQL. create function person(integer Cle)-> <charstring nom, charstring ville> as stored; create_index('person', 'Cle', 'mbtree', 'unique'); Les fonctions externes suivantes ont été définies dans SD-AMOS et permettent d effectuer différentes opérations. Récupérer le nombre courant d enregistrements contenus dans la table personne. create function card2()->integer as select index_cardinality(primary_index(functionnamed('person'))); Rechercher le nom et la ville d une personne à partir de la clé. create function search_person(integer Cle)-> < charstring nom, charstring ville> as select nom, vile from charstring nom, charstring ville where person(cle)=<nom, ville> ;

80 Serveur AMOS II Base de données AMOS 3Effectuer le traitement 4Produire un résultat 2Appeler une fonction 5Récupérer les tuples 1Arrivée requête Serveur SDDS 6Envoyer Tampon Réseau Serveur SD-AMOS Figure 31. Déroulement d'une fonction externe sur le serveur SD-AMOS Balayage complet de la table interne personne. create function person_fullextent()-> <integer Cle,charstring nom, charstring ville> as select Cle, nom, ville from integer Cle, charstring nom, charstring ville where person(cle)=<nom, ville>; Recherche par intervalle pour retrouver les personnes dont la clé est comprise entre une valeur minimale et une valeur maximale. create function person_range(integer deb, integer fin)-> integer Cle, charstring nom, charstring ville as select Cle, nom, ville from integer Cle, charstring nom, charstring ville where person(cle)=<nom, ville> and Cle>=deb and Cle<=fin; Calculer la clé minimale des enregistrements contenus dans la table personne. create function person_min()-> integer cle_min as select minagg(select Cle from integer Cle, charstring nom, charstring ville where person(cle)=<nom, ville>); Calculer la clé maximale des enregistrements contenus dans la table personne. create function person_max()-> integer cle_max as select maxagg(select Cle from integer Cle, charstring nom, charstring ville where person(cle)=<nom, ville>); Effectuer la jointure de deux tables AMOS-II. Lors de l appel de cette fonction, AMOS- II utilise directement le plan d exécution déjà mémorisé pour exécuter la requête sans passer par l optimiseur. create function allsamecity()-> integer Cle1, integer Cle2 as select Cle1, Cle2 from charstring nom1, charstring nom2, charstring ville1, integer Cle1, integer Cle2 where person_temp(cle1)=<nom, ville> and person(cle2)=<nom2, ville2> and Cle1<Cle2;

81 3 Implantation du système DB2-SDDS 3.1 Interfaçage du client SDDS avec DB2 Le client SDDS et le serveur DB2 sont deux programmes distincts qui tournent sur la même machine. Ils communiquent à travers des appels de procédures locales fournis par l interface RPC. Le client SDDS représente la partie serveur RPC, et ainsi exporte trois fonctions que DB2 peut appeler directement. Il s agit d une recherche simple, d une recherche par intervalle et d un parcours transversal du fichier. L interfaçage du client SDDS avec DB2 se fait en deux étapes : Il s agit de développer la partie cliente RPC sous forme d une librairie dynamique puis, de déclarer les fonctions externes dans une base. 3.2 Les fonctions externes Les expérimentations sont basées sur un fichier SDDS comportant deux champs : un champ clé de type entier et un champ texte. Trois fonctions externes sont déclarées dans DB2 pour utiliser les service du client SDDS. La fonction recherche permet d effectuer une recherche simple. Elle prend en paramètre la clé d un enregistrement. recherche(clé)->champ texte La déclaration se fait sous DB2 par l instruction suivante : CREATE FUNCTION enreg(integer) RETURNS Varchar(100) EXTERNAL NAME 'sdds!rechercher' DETERMINISTIC NO EXTERNAL ACTION NULL CALL LANGUAGE C PARAMETER STYLE DB2SQL NO SQL; La fonction suivante permet d effectuer une recherche par intervalle. Elle prend deux paramètres : la clé minimale et la clé maximale. intervalle(clemin, clemax) -> liste enregistrements dont clemin < clé < clemax La déclaration se fait sous DB2 par l instruction suivante : CREATE FUNCTION intervalle(integer, Integer) RETURNS TABLE (Cle integer, nom Varchar(20), ville Varchar(20))

82 EXTERNAL NAME 'Tsdds!range' DETERMINISTIC NO EXTERNAL ACTION LANGUAGE C FENCED PARAMETER STYLE DB2SQL NO SQL SCRATCHPAD FINAL CALL DISALLOW PARALLEL; La fonction suivante permet d effectuer un parcours transversal du fichier SDDS. Elle ne prend pas de paramètres. scan()-> liste de tous les enregistrements du fichier La déclaration se fait sous DB2 par l instruction suivante : CREATE FUNCTION scan(varchar(20)) RETURNS TABLE (Cle integer, nom Varchar(20), ville Varchar(20)) EXTERNAL NAME 'scanfnt!fullscan' DETERMINISTIC NO EXTERNAL ACTION LANGUAGE C FENCED PARAMETER STYLE DB2SQL NO SQL SCRATCHPAD FINAL CALL DISALLOW PARALLEL; 3.3 Exemples de requêtes Liste des enregistrements du fichier SDDS dont la clé est comprise entre 1 et 100. select * from table( intervalle(1, 100) ) as table_sdds(cle, Nom) order by Nom

83 4 Conclusion Ce chapitre nous a permis de présenter de manière détaillée les architectures fonctionnelles des prototypes implantés. La communication entre processus distants est basée sur les sockets. Le parallélisme des traitements sur une même machine est basé sur les threads. Ces choix techniques de mise en œuvre sont validés par les mesures de performances présentées dans le chapitre suivant

84 Chapitre 7 Expérimentations Ce chapitre présente l'environnement expérimental et les mesures de performances. Pour la stratégie AMOS-SDDS, nous présentons les performances obtenues pour le traitement de requêtes de jointure distribuée avec déport de fonctions sur les serveurs et les temps de traitement des fonctions agrégats. Pour les expériences sur SD-AMOS, nous présentons les performances obtenues pour la création d un fichier sur plusieurs sites et les temps d accès aux données. Les expériences avec DB2 visent à mesurer les temps d accès aux données en fonction de leurs lieux de stockage. 1 Environnement expérimental Les expérimentations ont été menées sur un multi-ordinateur composé de six postes Pentium III, processeurs 700 MHz avec 256 MB de mémoire vive sous Windows Les postes sont reliés par un réseau Ethernet de 100Mbit/s. Un site est utilisé comme client et les cinq autres comme serveurs. Il peut y avoir plusieurs serveurs SDDS par machine pour simuler des fichiers de grande taille et pour les mesures de scalabilité. 2 Etude de performances du système AMOS-SDDS Les expériences utilisent une table personne avec trois champs: Personne(Cle, nom, ville). Les valeurs du champ clé sont des nombres entiers consécutifs. Les champs nom et ville sont des chaînes de caractères de longueur variable. Pour les mesures de performance du système AMOS-II seul, la table est créée entièrement dans ce système. Pour les expériences avec AMOS-SDDS elle est stockée dans un fichier RP* qui s étend sur un à plusieurs serveurs. Le champ clé est utilisé comme clé de répartition du fichier. La taille d un enregistrement varie suivant les expériences. La requête de référence est une jointure pour trouver les couples de personnes habitant la même ville. La répartition des enregistrements suivant le champ ville est aléatoire, ainsi deux personnes qui habitent la même ville peuvent être stockées dans deux cases SDDS différentes. La table personne contient cinquante villes différentes de sorte que la sélectivité de la jointure, c.-à-d., le rapport du nombre de tuples choisis par rapport à la taille du produit cartésien, soit environ 1,6%. Nous avons formulé et exécuté la requête, nommée à cette fin Requête 1, sur le système AMOS-II seul. Sa formulation en AMOSQL est:

85 (Requête 1) select cle1, cle2 from integer cle1, integer cle2 charstring nom1, charstring nom2, charstring ville where Personne(cle1)=<nom1, ville> and Personne(cle2)=<nom2, ville> and cle1<cle2; La requête est évaluée en utilisant une boucle imbriquée avec ou sans index sur l attribut de jointure ville. Pour le système AMOS-SDDS, la requête de référence avec des fonctions externes, nommée Requête 2, est formulée comme suit: (Requête 2) select cle1, cle2 from integer cle1, integer cle2, charstring buffer where sdds_fullextent()=buffer and f_ship(buffer)=<cle1, cle2>; Les expériences avec la requête 2 évaluent diverses stratégies d'exécution décrites dans les sections 2.2 et 2.3. Le calcul de la jointure est basé sur le principe général de la boucle imbriquée distribuée. Des détails de l'algorithme et des conditions de l'exécution, varient avec les expériences. Les premières expériences utilisent la stratégie dite externe. Nous avons également expérimenté la stratégie d importation. Cette dernière permet d utiliser un index pour le traitement de la jointure. Des index locaux peuvent être crées sur chaque serveur pendant le processus d importation en utilisant les capacités standard de AMOS-II. Ci-dessous nous présentons d'abord les expériences avec AMOS-II seul. Ensuite, nous évaluons la stratégie externe suivie de la stratégie d importation avec les détails de mise en œuvre. Nous évaluons la stratégie d importation dans un premier temps sur le même fichier que pour la stratégie externe. Le résultat favorable nous incite à l évaluer pour un fichier cinq fois plus grand de tuples. Puis, nous étendons le fichier de base de tuples sur plus de serveurs AMOS-SDDS, jusqu'à 15 avec au total tuples. 2.1 Expérimentations de AMOS-II seul Les expérimentations portent sur la table Personne(cle, nom, ville). Le fichier contient enregistrements de 25 octets en moyenne. Le résultat de la jointure est de tuples. AMOS-II exécute d'abord la requête 1, en utilisant la boucle imbriquée. Il l exécute ensuite en créant un index sur l'attribut de jointure. Table 1 et Table 2 présentent les résultats obtenus: Durée exécution (s) Temps par tuple (ms) Sans index ,15 Avec index 45 2,25 Table 1. Durée d exécution de la requête 1 sur un fichier de enregistrements

86 La requête 1 est exécutée ensuite sur un fichier de enregistrements. Il y a au total sur le fichier cinquante villes différentes. Le résultat de la requête de jointure passe à tuples. Nous avons obtenu les durées d'exécution suivantes: Durée exécution (s) Temps par tuple (ms) Sans index ,57 Avec index ,81 Table 2. Durée d exécution de la requête 1 sur un fichier de enregistrements Le temps de traitement de la jointure avec index est presque sept fois plus rapide ici que la jointure par boucles imbriquées. 2.2 La Stratégie Externe La stratégie externe est basée sur des boucles imbriquées distribuées. La boucle externe s exécute sur le client AMOS-SDDS à l aide de la fonction externe Sdds_fullextent(). Cette fonction effectue un balayage complet de l ensemble des cases SDDS qui contiennent des enregistrements de la table personne. Le balayage est traité par le client SDDS comme une requête à intervalle RP*. Le protocole de terminaison déterministe est utilisé sur le client pour contrôler la fin de l'exécution de la requête. Les expérimentations ont montré que la terminaison déterministe est plus efficace que le protocole probabiliste. Pour récupérer les résultats, le client SDDS établit autant de connexions TCP/IP qu il y a de serveurs qui désirent envoyer des données. Les enregistrements reçus sont ensuite fragmentés dans des tampons relativement petits. La fonction Sdds_fullextent() retourne les tampons au client AMOS-II sous forme d une chaîne de caractères. Les résultats reviennent au client SDDS qui les transmet au client AMOS-II. La boucle interne est exécutée sur les serveurs AMOS-SDDS. Pour chaque tampon reçu, le client AMOS-II appelle la fonction externe f_ship() qui permet de lancer un traitement en parallèle sur les serveurs. Les expériences ont montré que la taille optimale du tampon est de 50 enregistrements, et qu il est avantageux de les trier sur le client suivant l attribut de jointure. Le traitement d un tampon est effectué par le serveur AMOS-II local à l aide de la fonction suivante: AllSameCity(tampon)-> integer cle1, integer cle2 as select cle1, cle2 from integer cle1, integer cle2, charstring nom, charstring ville where bucket_fullextent()=<cle1, nom, ville > and compare (cle1, nom, ville, tampon )=cle2; La fonction AllSameCity() effectue la jointure entre les tuples contenus dans le tampon et ceux contenus dans la case locale à l aide d une boucle imbriquée. La case locale est choisie comme table externe. Le tampon sert de table interne. La fonction AllSameCity() fait appel aux fonctions bucket_fullextent() et compare(). La fonction externe bucket_fullextent() effectue le balayage d une case SDDS et retourne les enregistrements un à un. La fonction Compare() prend en paramètre

87 l enregistrement courrant et le compare suivant la valeur du champ ville aux enregistrements contenus dans le tampon. Il produit les couples de personnes (cle1, cle2) habitant la même ville mais avec une valeur cle1 plus élevée que cle2, pour éviter les doublons. Chaque serveur AMOS- SDDS envoie ses résultats au client par une connexion TCP/IP. La Table 3 présente la durée d'exécution de la requête 2 sur un fichier de enregistrements. Le fichier est réparti successivement sur 1 à 5 serveurs. La Figure 32 présente une comparaison des temps d exécution de la requête 2 avec les deux stratégies. 2.3 La Stratégie d Importation Nombre de serveurs Durée exécution (s) Temps par tuple (ms) 67, ,4 17,9 14,4 Table 3. Durée d exécution de la requête 2 avec la stratégie externe De nouvelles fonctions externes sont définies sur le client et sur les serveurs pour traiter la stratégie d importation. La requête 2 est formulée de la même manière que dans la stratégie externe, ceci à l exception de la nouvelle fonction externe Sdds_fullextent2() sur client: (Requête 2 pour la stratégie d importation) select cle1, cle2 from integer cle1, integer cle2, charstring buffer where sdds_fullextent2()=buffer and f_ship(buffer)=<cle1, cle2>; Sdds_fullextent2() effectue le balayage de la table personne, comme Sdds_fullextent(), mais retourne les enregistrements dans des tampons non triés de enregistrements. La taille d un tampon ne doit pas excéder la longueur maximum d'un paquet UDP(64Ko). Le tri n'est pas utile pour l importation du tampon dans AMOS-II. A la réception du premier tampon, un serveur AMOS-SDDS appelle une nouvelle fonction Load_bucket() qui permet d importer le contenu de la case locale dans une table interne de AMOS- II dénommée personne. Une deuxième fonction externe, Import_tuples() est appelée à la réception de chaque tampon. Elle importe le contenu du tampon dans une table temporaire de AMOS-II dénommée Person_Temp. L'importation permet de créer un index sur l'attribut de jointure de la table personne. Ce sont des index locaux à chaque serveur. La fonction externe AllSameCity2() effectue alors la jointure entre les deux tables internes personne et Person_temp. Elle est formulée comme suit : AllSameCity2 ()-> integer cle1, integer cle2 as select cle1, cle2 from charstring nom1, charstring nom2, charstring ville, integer cle1, integer cle2 where personne(cle1) = <nom1, ville> and person_temp(cle2)=<nom2, ville> and cle1<cle2;

88 Une fois le traitement d un tampon terminé, le serveur AMOS-SDDS envoie les résultats partiels au client. Il appelle également la fonction interne Clear_function() de AMOS-II pour vider la table Person_Temp en un seul appel. Ceci évite l'effacement coûteux des tuples un à un. Le serveur AMOS-SDDS est alors prêt pour traiter le prochain tampon du client. Une fonction externe Count_AllSameCity() est créée sur les serveurs afin d évaluer le temps de transmission des tuples résultant de la requête 2. Elle effectue le même traitement que la fonction AllSameCity() mais envoie la taille du résultat de la jointure au lieu des tuples en entiers. Count_AllSameCity() est écrite en AMOSQL comme suit: Count_AllSameCity()-> integer size as select count( select cle1, cle2 from charstring nom1, charstring nom2, charstring ville, integer cle1, integer cle2 where Personne(cle1) = <nom1, ville> and Person_temp(cle2)=<nom2, ville> and cle1<cle2) ; Variation du nombre de serveurs Les Tables 4(a) et 4(b) présentent les temps d exécution de la requête 2 avec la stratégie d importation sur un fichier de enregistrements reparti successivement sur 1 à 5 serveurs. La jointure est exécutée avec et sans index sur l attribut de jointure. Nombre de serveurs Sans index (s) Avec index (s) Table 4(a). Temps d exécution de la requête 2 avec la Stratégie I Nombre de serveurs Sans index (ms) 6,4 3,9 3,2 2,7 2,4 Avec index (ms) 3 1,9 1,8 1,8 1,6 Table 4(b). Temps par tuple Le résultat montre que la stratégie d importation est plus avantageuse. Pour 5 serveurs, le taux est 6 fois pour la boucle imbriquée, et 9 fois si un index est crée. Ainsi, l'utilisation des fonctions externes est très coûteuse. La création de l index sur chaque serveur apporte un coût supplémentaire à l importation, mais justifiée du point de vue performance. En effet, le temps d exécution diminue de moitié pour deux serveurs, et de 1,5 pour cinq serveurs. Le temps résultant par enregistrement est en dessous de 2ms pour le fichier sur plus d'un serveur, atteignant 1,6ms pour le fichier sur 5 serveurs. Les figures montrent une efficacité tout à fait impressionnante du système entier

89 Temps par tuple(en ms) Strategie-E Strategie-I sans index Strategie-I avec index Nombre de serveurs Figure 32. Temps d exécution de la requête 2 en fonction de la stratégie Les Tables 5(a)-5(b) et la Figure 33 présentent le temps d exécution de la requête 2 avec la stratégie d importation et la fonction Count_AllSameCity() sur les serveurs. Le nombre de serveurs varie de 1 à 5. Comme le montre la comparaison des tables ci-dessous, le temps de transmission reste constant, et est de l ordre de 11s. L augmentation du nombre de serveurs n'améliore pas ainsi l'efficacité de la transmission. La majeure partie des transmissions de données entre le client et les serveurs concerne le transfert du résultat de la jointure(4m d enregistrements), plus le multicast des 20K d enregistrements par le client. Etant donné la taille de ces enregistrements, le débit de transmission observé est de 23 Mb/s. Ainsi le réseau local de 100 Mb/s est utilisé à 23% de sa pleine largeur de bande, qui est encore tout à fait efficace. Nombre de serveurs Sans index (s) Avec index (s) Table 5(a). Temps d exécution de la requête 2 avec la Stratégie I et la fonction count Nombre de serveurs Sans index (ms) 5,8 3,1 2,6 2,2 1,8 Avec index (ms) 2,4 1,4 1,3 1,2 1,0 Table 5(b). Temps par tuple Temps par tuple(en ms) Strategie-I sans index Nombre de serveurs Strategie-I avec index Figure 33. Temps d exécution de la requête 2 avec la Stratégie I et la fonction count

90 2.3.2 Variation de la taille du Fichier Dans l expérience suivante, la taille du fichier est portée à enregistrements, comme pour AMOS-II. Sur AMOS-SDDS le fichier est réparti sur 5 serveurs. La Table 6 présente les temps obtenus. Durée exécution (s) Temps par tuple (ms) Sans index Avec index 691 6,91 Table 6. Performance de la requête 2 avec la Stratégie I sur un grand fichier La comparaison de la Table 6 et de la Table 5(b) pour un fichier de enregistrements, montre une légère meilleure scalabilité pour les boucles imbriquées. Le temps par tuple augmente en effet de 2,4 à 10ms, soit un facteur de 4,2. De même, pour la jointure avec index, le facteur est de 4,3. La Figure 34 compare le temps d exécution de requête 2 sur AMOS-SDDS à celui de requête 1 sur AMOS-II seul(table 2). Pour les boucles imbriquées, le taux d'amélioration est de 6,5 soit 85%. Pour l'utilisation de l index sur l attribut de jointure, le taux d'amélioration est d environ 1,7 soit 41%. La comparaison avec les résultats de AMOS-II avec le fichier de enregistrements de la Table 1, montre également, une meilleure montée à l échelle pour AMOS-SDDS. Ainsi pour les boucles imbriquées le temps de traitement par tuple de AMOS-II passe de 13,15 à 65,57ms, soit une augmentation d un facteur de 5. Pour l'utilisation de l index sur l attribut de jointure, le temps passe de 2,25 à 11ms, soit un facteur 4,8. Les temps de traitement de la Table 2 n'inclut pas le temps de création de l'index. Durée execution(en s) Requête 1 sans index Requête 1 avec index Strategie-I sans index Strategie-I avec index Figure 34. Performance de AMOS-II, et de AMOS-SDDS sur un grand fichier Montée à l échelle La Table 8 et la Figure 35 présentent les durées d exécution de la requête 2 sur un fichier dont la taille varie de à enregistrements, et qui s étend sur plusieurs

91 serveurs AMOS-SDDS. La taille maximale d un serveur est fixée à enregistrements. Nous avons initialisé jusqu à 3 serveurs par machine, c.-à-d., 15 serveurs au total. La Table 7 montre le nombre de machines utilisées et le nombre de serveurs par machine en fonction de la taille du fichier. Le calcul de la jointure utilise la boucle imbriquée distribuée avec la stratégie d importation. Celle-ci importe le contenu de la case locale et chaque tampon qui arrive sur le serveur AMOS-II. L importation d un fichier de enregistrements, et la création d un index sur l attribut de jointure ville durent 3 secondes. AMOS-II exécute sa propre évaluation de requêtes. Nous utilisons la fonction externe Count_AllSameCity() pour évaluer le temps de transmission des résultats de la requête 2. Cette fonction effectue la jointure sur chaque serveur, et retourne la taille du résultat au lieu des tuples en entiers. Le temps extrapolé est une estimation de la durée d exécution de la requête 2 qui serait obtenu si les serveurs tournaient sur des machines distinctes. Il est obtenu en divisant le temps de traitement effectif sur les serveurs par le nombre de serveurs par machine. Taille du fichier # SDDS serveurs # Machines Serveur / Machine Table 7. Nombre de serveurs en fonction de la taille du fichier Q1 = jointure sur AMOS-SDDS; Q2 = jointure sur AMOS-SDDS avec Count. Taille du fichier # SDDS serveurs Taille des résultats Q1 (s) Q2 (s) Q1 extrap. (s) Q2 extrap. (s) AMOS-II (s) Temps création Index(s) Table 8. Durée d exécution de la requête de jointure (extrapolé pour AMOS-SDDS)

92 Durée execution (en s) # enreg. AMOS-II # serveurs AMOS-SDDS jointure AMOS-SDDS jointure & count Figure 35. Durée d exécution de la requête 2 Durée execution (en s) AMOS-II AMOS-SDDS jointure AMOS-SDDS jointure & count # enreg. # serveurs Figure 36. Extrapolation du temps de traitement de la requête 2 La Figure 36 compare les temps de traitement des requêtes 1 et 2 de la Table 8. Le taux d'amélioration pour le fichier enregistrements est de 1,96 c.-à-d. 49%. La Figure 37 présente l'extrapolation des temps d'exécution de la requête 2 sur plusieurs serveurs AMOS-SDDS distinctes. Le taux d'amélioration attendu pour le fichier enregistrements est de 2,86 c.-à-d. 65%. Taille du fichier # SDDS serveurs Q1 (ms) 3,05 5,02 6,84 11,36 12,77 16,25 18,55 Q2 (ms) 2,55 3,08 3,35 6,16 6,39 8,43 8,75 Q1 extrap. (ms) 3,05 5,02 6,84 8,28 9,6 10,64 12,72 Q2 extrap. (ms) 2,55 3,08 3,35 3,11 3,2 2,84 2,94 AMOS-II (ms) 2,30 7,17 12,01 19,41 24,12 29,08 36,44 Table 9. Temps par tuple Le temps de traitement d une requête distribuée peut être divisé en deux parties : Le temps de traitement effectif sur les serveurs et le temps de transfert des résultats des serveurs vers le client. Le traitement d une requête s effectue en parallèle sur les serveurs et sa durée est en rapport direct avec le nombre de serveurs. Ainsi, l augmentation du

93 nombre de serveurs réduit le temps de traitement du même facteur. Le temps de transfert est quant à lui limité par la bande passante du réseau. L extrapolation du temps de traitement de la requête avec la fonction count montre une scalabilité linéaire : Le temps par enregistrement reste constant quand la taille du fichier et le nombre de serveurs augmentent du même facteur. Temps par tuple (en ms) AMOS-II AMOS-SDDS jointure AMOS-SDDS jointure & count # enreg. # servers Figure 37 Extrapolation du temps par tuple pour la requête 2 sur plusieurs serveurs 2.4 Les Fonctions Agrégats Les expériences suivantes visent à mesurer les temps d'exécution des fonctions agrégats COUNT et MAX sur le système AMOS-SDDS avec la stratégie externe et la stratégie d importation. Ces temps sont ensuite comparés à ceux obtenus sur le AMOS-II seul. L expérience sur AMOS-II consiste à mesurer les temps d exécution des fonctions agrégats Count() et Maxagg(cle) sur la table Personne(cle, nom, ville) avec enregistrements. Sur AMOS-SDDS, le fichier est réparti successivement sur 1 à 5 serveurs. Chaque serveur exécute la fonction Count() ou Max(cle), et envoie le résultat au client. Le post-traitement sur le client consiste à effectuer la somme des Counts partiels ou le Max des Max. Sur les serveurs, la stratégie externe calcule les valeurs demandées en utilisant les fonctions externes SDDS_Count() et SDDS_Max(). La fonction SDDS_Count() lit simplement le nombre d enregistrements courant qui est une valeur stockée dans l'en-tête de la case. La fonction SDDS_Max() effectue un balayage complet de la case locale et retourne la plus grande valeur du champ Clé. Pour la stratégie d importation, les serveurs importent en parallèle chacun le contenu de sa case locale dans une table temporaire personne. Ils exécutent ensuite les fonctions

94 agrégats AMOS-II Count() et Maxagg(cle) sur la table personne. La table temporaire est vidée à la fin du traitement à l aide de la commande Clear_function(). Les résultats suivants ont été obtenus sur AMOS-II : 280ms pour le temps de traitement de la fonction Count() et 471ms pour la fonction Maxagg(cle). Les tables 10 et 11, ainsi que les Figures 38 et 39 présentent les temps d'exécution des fonctions agrégat sur AMOS- SDDS en fonction de la stratégie. Nombre de serveurs Strategie-E (ms) Strategie-I (ms) Table 10. Durée d exécution de la fonction Count sur un fichier de enregistrements Durée execution(en ms) Count avec importation(échelle gauche) Count avec les fonctions externes(échelle droite) Nombre de serveurs Figure 38 Durée d exécution de la fonction Count Nombre de serveurs Stratégie-E (ms) Stratégie-I (ms) Table 11. Durée d exécution de la fonction Max sur un fichier de enregistrements Durée execution(en ms) Max avec les fonctions externes Max avec importation Nombre de serveurs Figure 39 Durée d exécution de la fonction Max Contrairement à la requête de jointure, la stratégie externe est ici gagnante. La fonction count est presque 19 fois plus rapide. Ceci est du au temps d'importation des données dans la table temporaire. L'utilisation des fonctions externes peut ainsi être très avantageuse pour certains types de requêtes. Aussi, pour la stratégie d importation, le

95 calcul de la fonction MAX est toujours plus long que celui de la fonction COUNT. C'est dû aux fonctions internes de AMOS-II utilisées où le même rapport est observé. 3 Etude de performances du système SD-AMOS 3.1 Temps de création du fichier L expérience vise à mesurer le temps de création d un fichier sur plusieurs sites et l impact des éclatements sur les temps d insertion d un enregistrement. Elle consiste à démarrer un serveur actif et quatre serveurs en veille. Nous lançons ensuite à partir d un client une série d insertion. Nous fixons la taille d un enregistrement à 100 octets. La taille maximale d'une case est fixée à enregistrements. Nous mesurons sur le client le temps d insertions de enregistrements de clé aléatoire. Ceci provoque quatre éclatements et à la fin des insertions, le fichier se retrouve fragmenté sur cinq serveurs. La table suivante et la Figure 40 présentent les temps de création du fichier en fonction du nombre d enregistrements et du nombre de serveurs. Taille Nombre de fichier serveurs Temps création du fichier (ms) Moyenne globale (ms) Moyenne glissante (ms) ,15 0, ,15 0, ,15 0, ,15 0, ,16 0, ,16 0, ,16 0, ,20 0, ,19 0, ,18 0, ,18 0, ,18 0, ,17 0, ,17 0, ,22 0, ,26 0, ,25 0, ,25 0, ,24 0, ,24 0, ,23 0, ,22 0, ,22 0, ,22 0, ,21 0, ,21 0, ,21 0, ,21 0, ,20 0, ,21 0,42 Table 12. Temps de création du fichier

96 Temps moyen (ms) 1,20 1,00 0,80 0,60 0,40 0,20 0, M.G. M.C. # serveurs # tuples x 100K Figure 40. Temps moyen d insertion d un enregistrement (tuple de 100 octets) Les mesures montrent un speed-up linéaire du système SD-AMOS. Le temps moyen d insertion d un enregistrement est de 0,15ms. Nous remarquons que le temps de verrouillage d une case pendant l éclatement est compensé par les insertions parallèles après l éclatement. Les pics sur la courbe de la moyenne glissante correspondent aux éclatements et les creux représentent les gains du fait du parallélisme. Le temps d insertion est de 0,12ms, et est obtenu après le quatrième éclatement qui rend les cinq serveurs actifs en même temps. 3.2 Temps de recherche simple L expérience vise à mesurer le temps moyen de recherche synchrone et asynchrone d un enregistrement. Il s agit de lancer une série de recherche aléatoire de enregistrements sur le fichier crée dans l expérience précédente. La taille du fichier est de enregistrements. La durée d une recherche synchrone comporte : le temps d envoi sur le réseau du message vers le serveur concerné, le temps de lecture de l enregistrement sur le serveur et le temps d envoi de la réponse au client. Les Tables 13 et 14 présentent les temps de recherche synchrone et asynchrone en fonction du nombre d enregistrements. Nombre de serveurs Temps total (ms) Temps par tuple (ms) , , , , ,11 Table 13. Recherche asynchrone 3.3 Temps de recherche par intervalle Nombre de serveurs Temps total (ms) Temps par tuple (ms) , , , , ,12 Table 14. Recherche synchrone L expérience vise à mesurer la durée d exécution d une requête à intervalle en fonction du nombre de serveurs. Il s agit de lancer une série de recherche aléatoire de enregistrements sur le fichier crée dans l expérience précédente. La table suivante donne les temps obtenus sur un

97 fichier de enregistrements reparti successivement sur 1 à 5 serveurs. La Figure 41 montre les temps par enregistrement d une recherche simple et d une recherche par intervalle. Nombre de serveurs Temps total (ms) Temps par tuple (ms) , , , , ,02 Table 15. requête à intervalle Temps par tuple (ms) Requête par intervalle Rcherche asynchrone Recherche synchrone #serveurs Figure 41. Temps moyen de recherche d un enregistrement 4 Etude de performances du système DB2-SDDS Les mesures suivantes visent à comparer les temps d accès aux données en fonction de leur lieu de stockage. Nous distinguons trois cas : Le temps d accès aux données dans une table DB2, Le temps d accès au fichier SDDS à partir des fonctions externes de DB2 (DB2-SDDS) et le temps d accès au fichier SDDS à partir d un client SDDS. Nous utilisons la même table personne avec trois champs: Personne(Cle, nom, ville). La taille d un enregistrement est de 100 octets. Une table de enregistrements est créée dans la base DB2. Un fichier RP* de enregistrements est également crée sur 5 serveurs. La répartition des enregistrements est homogène, soit enregistrements par serveur. Nous formulons une requête à intervalle en faisant varier la taille des résultats. Les Tables 16 et 17 présentent les temps obtenus. Nombre d enregistrements DB2-SDDS(ms) DB2(ms) SDDS(ms) Table 16. Temps de traitement d une requête à intervalle Nombre d enregistrements DB2-SDDS(ms) 0,085 0,087 0,084 0,093 0,083 DB2(ms) 0,073 0,073 0,073 0,073 0,073 SDDS(ms) 0,024 0,024 0,023 0,022 0,024 Table 17. Temps par enregistrement

98 Temps de traitement (ms) DB2-SDDS Nombre d'enregistrements DB2 SDDS Figure 42. Temps de traitement d'une requête à intervalle Temps par enreg. (ms) 0,100 0,080 0,060 0,040 0,020 0, DB2-SDDS DB2 Nombre d'enregistrements SDDS Figure 43. Temps par enregistrement La Figure 43 montre clairement que le temps d accès au fichier SDDS l emporte largement sur le temps d accès à une table DB2: 0,02ms contre 0.07ms. De même il apparaît que l accès à des données externes à partir de DB2 (0.08ms), est moins performant que l accès aux données internes (0.07ms). Ces résultats confortent nos hypothèses et justifient le couplage de DB2 avec les SDDS. En effet, 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. 5 Conclusion Nous avons mesuré les performances du système AMOS-SDDS sur une requête de jointure et sur les fonctions agrégats. L évaluation des requêtes est faite par les fonctions externes et par AMOS-II. Les résultats ont montré un net avantage de la stratégie d importation sur la stratégie externe pour l évaluation de la jointure. L extrapolation du temps de traitement de la requête de jointure avec count montre une scalabilité linéaire du système: Le temps de traitement par enregistrement reste constant quand la taille du fichier et le nombre de serveurs augmentent du même facteur. Contrairement à la requête de jointure, la stratégie externe est gagnante pour l évaluation des fonctions agrégats. L'utilisation des fonctions externes peut ainsi être très avantageuse pour certains types de requêtes

99 Nous avons mesuré les performances du système SD-AMOS pour la création d un fichier sur plusieurs site, la recherche d un enregistrement et le balayage parallèle. Le temps moyen d insertion d un enregistrement avec les éclatements est de 0,15ms. Le temps d accès moyen à un enregistrement sur un fichier distribué de 0,12ms est 100 fois plus rapide que celui à un fichier traditionnel sur disque. Ces excellents résultats encouragent une étude plus approfondie de la stratégie SD-AMOS

100 Chapitre 8 Conclusion Nos travaux ont porté sur le couplage des SDDS avec deux SGBDs : AMOS-II et DB2. A chaque étape, les choix techniques ont été validés par l implantations de prototypes et des mesures de performances. Dans la première partie de la thèse, nous avons proposé deux stratégies de couplage des SDDS avec AMOS-II. La stratégie dénommée AMOS-SDDS visait trois objectifs : - Etendre le gestionnaire SDDS afin qu il puisse supporter des opérations de bases de données ; - Construction d une liaison entre un SGBD et un entrepôt de données externes avec des accès rapides hors SGBD ; - Effectuer les traitements en parallèle en se basant sur l envoi de fonctions sur des sites distants. Les résultats obtenus sur cinq serveurs ont montré une bonne scalabilité pour le traitement de requêtes distribuées. Les temps extrapolés nous font espérer une scalabilité linéaire sur un nombre plus important de serveurs. Ce travail a fait l objet de deux publications : [NDLR00] et [NDLR01]. Avec la stratégie dénommée SD-AMOS, nous avons pu ajouter au système AMOS-II des fonctionnalités lui permettant d étendre dynamiquement son espace de stockage sur plusieurs sites. Le système SD-AMOS est ainsi un prototype de SGBD distribué dynamique en mémoire centrale. Nous avons testé trois fonctionnalités : - Création d un fichier sur plusieurs sites ; - Recherche d un enregistrement ; - Balayage parallèle. Le temps moyen d insertion d un enregistrement avec les éclatements est de 0,15ms. Le temps d accès moyen à un enregistrement sur un fichier distribué sur SD-AMOS de 0,12ms est 100 fois plus rapide que celui à un fichier traditionnel sur disque. Ces excellents résultats encouragent une étude plus approfondie de la stratégie SD-AMOS. Dans la seconde partie de la thèse, un schéma de couplage des SDDS avec le SGBD DB2 a été proposé. Il a permis de faire du gestionnaire SDDS, un entrepôt de données de DB2 en se basant sur les fonctionnalités de manipulation de données externes offertes par ce SGBD. L entrepôt de

101 données a deux caractéristiques principales : il est entièrement en mémoire centrale et il peut s étendre dynamiquement sur un nombre indéterminé de sites. A l aide des fonctions définies par l utilisateur(user Defined Functions: UDF Table), nous avons pu formuler des requêtes de recherche sur des données externes, à partir de DB2. Les performances obtenues confortent nos hypothèses et justifient le couplage de DB2 avec les SDDS. En effet, 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. Notre travail constitue une contribution à la création des SGBDs distribuées dynamiques. L usage des algorithmes SDDS a permis de surmonter l obstacle d une fragmentation statique des données uniquement sur les sites désignés à l avance. L évolution croissante de l espace mémoire adressable sur une seule machine avec les architectures 64 bits et les performances des réseaux, favorisent l avènement des SGBDs parallèles en mémoire centrale. Les systèmes scalables et haute performance ouvrent de nouvelles perspectives aux applications modernes, en particulier les SGBDs. Des recherches en cours portent sur des algorithmes qui exploitent au mieux les possibilités de décomposition de requêtes AMOSQL en sous-requêtes appropriées au traitement parallèle sur le système distribué SD-AMOS. L optimisation de requêtes dans un environnement distribué avec la répartition dynamique des données sur des sites qui ne sont pas connus d avance pose un nouveau défis dans ce domaine

102 Bibliographie [AGKP99] Ahmed I., Ghafoor A, Khan M. F., Paul R., Intensive Data Management in Parallel Systems: A Survey, Distributed and Parallel Databases, 7(4), October 1999 [AKG96] B. Adelberg B. Kao, H. Garcia-Molina, An Overview of the Stanford Real-time Information Processor, SIGMOD RECORD, 25(1), [ASS94] Amin M., Schneider D., Singh V., An Adaptive, Load Balancing Parallel Join Algorithm. 6 th International Conference on Management of Data, Bangalore, India, December [Bar95] Baru C., & al. DB2 Parallel Edition. IBM Syst. Journal, 34(2), [BDDP99] R. Bagrodia, E. Deelman, S. Docy, T. Phan, Performance Prediction of Large Parallel Applications using Parallel Simulations, Proc of the 7 th ACM SIGPLAN Symp. on Principles and Practice of Parallel Programming, Atlanta, May [BLRS97] P. Bohannon, D. Lieuwen, R. Rastogi, S. Seshadri, A. Silberschatz, S. Sudarshan, The Architecture of the Dali Storage Manager, Published in the Journal of Multimedia Tools and Applications, 4/2, [Boh97] Philip Bohannon et al, The Architecture of the Dali Main-Memory Storage Manager, Multimedia Tools and Applications, 4(2), 1997 [Bor90] Boral H., et al, Prototyping Bubba, A Highly Parallel Database System, IEEE Transactions on Knowledge and Data Engineer-ing, 2(1), March [CACM97] Comm. of ACM. Special Issue on high-performance Computing.(Oct. 1997). [CHA98] S. Chaudhuri, An Overview of Query Optimization in Relational Systems. In Proceedings of the ACM PODS, pages 34-43, June [Cus93] H. Custer. Au cœur de WINDOWS NT. Microsoft Press, [CW98] Clement T., Yu Meng W. Principles of Database Query Processing for Advanced Applications. Morgan Kaufmann, [DB2LM] IBM DB2 Data Links Manager - Nouvelle fonction introduite en 1998 dans DB2 Universal Database et supportant la gestion de fichiers sur des plate-formes AIX et Windows NT. [DDG92] David J. DeWitt, Jim Gray, Parallel Database Systems: The Future of High Performance Database Processing, Communications of the ACM, june [Dew90] D. Dewitt, S. Ghandeharizadeh, D. Schneider, A.Bricker, H. Hsiao, R. Rasmussen, The Gamma Database Machine Project, IEEE Transactions on Knowledge and Data Engineering, 2(1), March [Die97] Diène A. W., Organisation interne des SDDS RP*, Rapport de DEA., Faculté des Sciences, U. de Dakar,

103 [DL00] Diène A. W., Litwin W. Performance Measurements of RP*: A Scalable Distributed Data Structure for Range Partitioning Intl. Conf. on Information Society in the 21 st Century: Emerging Techn. and New Challenges. Aizu City, Japan, [DNSS92] D. J. DeWitt, J. F. Naughton, D. A. Schneider, S. Seshadri, Practical Skew Handling in Parallel Joins, Proceedings of the 18 th Conference on Very Large Databases, Morgan Kaufman pubs. (Los Altos {CA}), Vancouver, [ER93] R.Marek, E. Rahm, On the Performance of Parallel Join Processing in Shared Nothing Database Systems, PARLE-93 (5 th Int. Conf. On Parallel Architectures And Languages Europe) [FRS93] G. Fahl, T. Risch, M. Sköld, AMOS An Architecture for Active Mediators. Workshop on Next Generation Information Technologies and Systems (NGITS 93), Haifa, Israel, June [GJP97] V. Gottemukkala,A. Jhingran, S. Padmanabhan, Interfacing Parallel Applications and Parallel Databases, ICDE [GR93] Jim Gray, Andreas Reuter, Transaction Processing: Concepts and Techniques,Morgan Kaufmann, [Gra96] Gray J. Super-Servers: Commodity Computer Clusters Pose a Software Challenge. Microsoft, ( [GW99] Groff J. R., & Weinberg Paul N. SQL The complete Reference. Osborne/McGraw-Hill [GW97] Grimshaw A., Wulf W. The Legion Vision of a Worldwide Virtual Computer. Comm. of ACM, Jan [HCY94] H.-I Hsiao, M.-S. Chen, P. S. Yu. On Parallel Execution of Multiple Pipelined Hash Joins. In Proc. of the 1994 ACM SIGMOD Intl. Conf., May [JD01] S. Jalali, S. Dandamudi, Pipelined Hash Joins Using Network of Workstations, 14 th Intl. Conference on Parallel and Distributed Computing Systems 2001, Texas USA. [KD99] N. Kabra, D. J. DeWitt, OPT++: an object-oriented implementation for extensible database query optimization, The VLDB Journal (1999) 8: 55 78, [Knu98] Knuth D., The Art of Computer Programming. 3 rd Ed. Addison Wesley, [Kos00] D. Kossmann, The State of the Art in Distributed Query Processing, ACM Computing Surveys, 32(4), [LIM93] LIM E. et al, Query Optimization and Processing in Federated Database Systems. In Proceedings of 2 nd International Conference on Information and Knowledge Management

104 [LMRS00] Litwin W., Menon J., Risch T., Schwarz Th. Design Issues For Scalable Availability LH* Schemes with Record Grouping. Distributed Data and Structures. Carleton Scientific, (publ.) [LNS94] Litwin W., Neimat M-A., Schneider D., RP* : A Family of Order-Preserving Scalable Distributed Data Structures. 20 th Intl. Conf on Very Large Data Bases (VLDB), [LNS93] Litwin W., Neimat M-A., Schneider D., LH* : Linear Hashing for Distributed Files. ACM-SIGMOD Intl. Conf. On Management of Data, [LR99] Z. Li, K. A. Ross, Fast Joins Using Join Indices, VLDB Journal: Very Large Data Bases, 8(1), [MC99] Musick R., Critchlow T. Practical Lessons in supporting Large-Scale Computational Science, ACM Sigmod Record, December [MD97] M. Mehta, D. J. DeWitt, Data placement in shared-nothing parallel database systems, VLDB Journal: Very Large Data Bases, 6(1), [MPTW94] C. Mohan, H. Pirahesh, W. Tang, Y. Wang, Parallelism in relational database management systems. IBM System Journal, 33(2), [Ndi98] Ndiaye Y. Architecture de communication pour les SDDS RP*, Rapport de DEA., Faculté des Sciences, U. de Dakar, juin [NDLR01] Ndiaye Y., Diene A. W., Litwin W., Risch T., AMOS-SDDS: A Scalable Distributed Data Manager for Windows Multicomputers, 14 th Intl. Conference on Parallel and Distributed Computing Systems 2001, Texas USA. [NDLR00] Ndiaye Y., Diene A. W., Litwin W., Risch T., Scalable Distributed Data Structures for Hight-Performance Databases, T.3-rd Intl. Workshop on Distributed Data Structures 2000, Italy. [Ora00] Sohan DeMel, Oracle9i Parallel Server Cache Fusion Delivers Scalability, An Oracle White Paper, October [OV99] Ozsu T., Valduriez P., Principles of Distributed Database Systems. 2 nd Ed. Prentice Hall, [OV96] M. T Ozsu, P. Valduriez, Distributed and parallel database systems, ACM Computing Surveys, 28(1), [Pet98] Petzold C. Programming Windows, The Definitive Guide to the Win32 API, Microsoft Press, December [Ric96] Richter J, Advanced Windows 3 rd edition, Microsoft Press, [Ris00] Risch T., AMOS-II External Interfaces, Dept. of Information Science, Uppsala University, Feb (

105 [RJ99] Risch T., Josifovski V, Integrating Heterogeneous Overlapping Databases through Object-Oriented Transformations, Presented at 25 th Intl. Conf. On Very Large Databases, Edinburgh, Scotland, September [RJK99] Risch T., Josifovski V., Katchaounov T., AMOS II Concepts, Dept. of Information Science, ( Uppsala University, Nov [Sah00] F. B. Sahli, Un Gestionnaire de Structures de Données Distribuées et Scalables pour les Multiordinateurs Windows : Application à la Fragmentation par Hachage. Thèse CERIA Université Paris Dauphine, juin [SAL96] Stonebraker M., Aoki P., Litwin W., Pfeffer A.,Sah A., Sidell J., Staelin C., Yu A, Mariposa: a wide-area distributed database system. The VLDB Journal 5(1), [SD89] D. Schneider, D. DeWitt. A performance evaluation of four parallel join algorithms in a shared nothing multiprocessor environment. In Proc. ACM SIGMOD, Portland, OR, June [Sin96] Alok k. Sinha, Network Programming in Windows NT. Addison-Wesley Publishing Company, [SMM98] J. Semke, J. Mahdavi, M. Mathis, Automatic TCP Buffer Tuning, in Computer Communication Review, ACM SIGCOMM, 28(4), October [SND98] Seck M.T., Ndiaye S., Diene A.W., Implémentation d une bibliothèque de primitives d accès aux fichiers distribués et scalables RP*. CARI [Sto98] M. Stonebraker & Heller, Readings in Database Systems 3 rd edition, Morgan Kaufmann Publishers, [Tan94] Tanenbaum, A., S. Distributed Operating Systems. 1 rd edition, Prentice Hall, [Tand88] Tandem Performance Group, A benchmark of Non-Stop SQL on the debit credit transaction, Proc. ACM SIGMOD Conf., Chicago, June [Ter85] Teradata Corp., DBC/1012 Data Base Computer System Manual, Teradata Corp. Document No. C , Release 2.0, November [TWP] TimesTen s Core In-Memory Database Technology White Paper ( [YS97] Y. Yang, M. Singhal, A Comprehensive Survey of Join Techniques in Relational Databases, [Vra95] Z. Vranesic et Al, The NUMAchine Multiprocessor, Technical Report 324, University of Toronto, April [Win99] Richard Winter, Lexicology of Scale, Intelligent Enterprise, february 1999 (

106 Annexe 1 Extended 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

107 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. The thesis is organized in eight chapters. Chapter 1 introduced the Thesis. Chapter 2 presents the theory of SDDSs, focusing on the RP* schemes, which were retained in the prototype implementation. We discuss the advantages of the SDDS as compared to the traditional data structures. Chapter 3 reviews the basic concepts of parallel DBMS. We show that these systems must support a workload scaling, while their data partitioning schemes currently in use constitute a handicap through their static nature. We present more in depth three commercial parallel systems: DB2, TERADATA and ORACLE. Chapter 4 presents the coupling of the SDDS manager with AMOS-II DBMS, and gives a detailed description of the prototypes, that we have implemented. The AMOS-II choice is justified by three reasons: (i) it is a main memory DBMS, (ii) it offers functionalities to handle external data and (iii) the source codes are available. We first present AMOS-II by insisting in its capabilities to handle external data. We propose then two coupling architectures. The first one, called AMOS-SDDS, studies the use of a SDDS file by a DBMS and the parallel query processing on the server sites. That requires the query decomposition in subqueries appropriate to the parallel processing. First experiments used a query processing strategy called E-Strategy. The name recalls that subquery processing at the servers side is done externally to AMOS-II, entirely within the foreign functions. We have also experimented with an alternative implementation design called I-Strategy. This one imports the bucket content and each buffer when it comes into the AMOS-II server. The latter

108 performs its own query evaluation. I-Strategy is potentially simpler to implement and more extensible than E-Strategy. It allows reusing processing capabilities of AMOS-II, instead of reprogramming them in the foreign functions. New queries are also potentially easier to accommodate. The second coupling architecture we experiment with was called SD-AMOS. We study there another possibility for a DBMS and an SDDS interoperability. Here, we consider that the DBMS partitions its data using an SDDS scheme with each SDDS server using also locally a DBMS as its memory manager. This allows to dynamically extend a DBMS storage space and the number of processing nodes, enhancing the DBMS scalability. SD-AMOS uses for this purpose AMOS-II specifically. We show that such a system appears as a scalable generalisation of a parallel DBMS where the data partitioning becomes automatic. We propose design techniques, which we validate by the prototyping and performances measurements. We show in Chapter 4 that the design choices we faced couldn t be made in general on the theoretical basis only. We performed therefore many experiments, to determine the resulting effectiveness of the prototypes. This concerned especially the scalability analysis. Probably best approach to the experimental performance determination is to use benchmark data sets and queries. Those well known to the database literature were designed for other purpose, hence we have designed a suitable benchmark on our own. The goal was to realize reasonably complex typical database operations. We have designed an extensible data set and the queries to it with joins, selections, projections and aggregate functions. We have extensively experimented the system using our benchmark under various conditions. Chapter 5 studies the coupling of the SDDS with DB2, as a typical representative of a commercial relational-object DBMS. The choice of DB2 is justified by its capabilities to handle external data through the user-defined functions (UDF). As for AMOS-SDDS, we study the use of a SDDS file by a DBMS as a scalable external RAM data repository. SDDS manager makes it possible to the user to manage some data potentially more quickly than if they were in the DB2 internal tables. The user may access these data directly using the SDDS interface. DB2 offers in addition the SQL interface, as if the SDDS data were transparently among its relational tables. Chapter 6 is devoted to the technical aspect of the implementation of prototypes coupling the SDDS manager with AMOS-II and DB2 DBMS. We present the communication tools between remote processes with the Windows sockets and the multi-task programming concepts with threads. We also present in detail the functional architectures of the prototypes and the various operations, which they support

109 Chapter 7 presents the experiments and the performance measurements of the prototypes described earlier. We focus particularly on the scalability analysis. For AMOS-SDDS strategy, we present the results for the distributed join queries with functions shipping, and for the queries with aggregate functions. For the experiments on SD-AMOS, we present the results of experiments creating scalable file. For coupling SDDS manager and DB2, our measurements aim at comparing the access times to the data in database table with those to an SDDS file. The experiments were carried out on a multi-computer of six Pentium III stations, with 700 MHz processors and 256 MB of RAM running Windows An Ethernet network of 100Mbit/s connects the stations. One site was used as client and the five others as servers. We run several SDDS servers on the same machine to simulate big files sizes. On system AMOS-SDDS, the queries were carried out on the servers by the external functions and the strategy of importation in AMOS-II. The results showed an important advantage of I- Strategy on E-Strategy for the evaluation of the join query. For 5 servers, the rate is 6 times for the nested loop, and 9 times if an index is creates. The extrapolation of the processing time of the join query with count shows a linear scalability of the system: the processing time per tuple remains constant when the file size and the number of servers increase. On a file, which extends up to records distributed up to 15 servers, time by tuple is of 2,94 ms. These results show the scalability of the coupling scheme for complex database operations. We explain our results also by the use of a memory main DBMS. Contrary to the join query, the external strategy is largely winning for the aggregate functions computations. The use of the external functions can thus be very advantageous for certain kind of operations. The average insertion time of a record into SD-AMOS system is of 0,15 ms, including the time for the overloaded server sites splits. The average search time of a tuple is 0,12 ms. It is thus 100 times faster than that to a traditional disk file. These results encourage further studies of the SD- AMOS. For performance measurements under DB2, we distinguish three cases: (i) access time to the data in a DB2 table, (ii) access time to SDDS file from the DB2 external functions (DB2-SDDS) and (iii) direct access time to SDDS file from a SDDS client. As expected, the access time (range query per record search time) to the SDDS file appears faster than to a DB2 table: 0,02 ms against 0.07 ms. In the same way it appears as the access to external data from DB2 (0.08 ms), is slower than the access to the internal data (0.07 ms). This probably points out to some

110 inefficiency in the DB2 design of the UDF interface. All together, our results confirm the practical interest of DB2-SDDS coupling. Chapter 8 concludes this document and presents future research directions. Basically, we recall that we have coupled a manager of Scalable Distributed Data Structures SDDS-2000 with a main-memory DBMS AMOS-II and DB2 to improve the current technologies for highperformance databases and for the coupling with external data repositories. The technical choices were validated by a prototype application and performance measurements. We stress then that many design problems lays still ahead and we discuss some. Especially challenging appears the design of a scalable distributed query optimizer handling the dynamic data partitioning. Our work was presented at three international conferences [NDLR00] i, [NDLR01] ii and [NL01] iii. The experiments we have reported in the articles and in the Thesis prove the efficiency of the system. The scalability that appeared from our experiments abolishes the cumbersome storage limits of a single site RAM DBMS technology. The RAM query processing and scalable data partitioning are an improvement over the current parallel DBMSs. The increasing capacity of RAM storage, the advent of 64 byte architectures and the increasing network speed, should make our technology soon practical at the industrial level. i [NDLR01] Ndiaye Y., Diene A. W., Litwin W., Risch T., AMOS-SDDS: A Scalable Distributed Data Manager for Windows Multicomputers, 14 th Intl. Conference on Parallel and Distributed Computing Systems 2001, Texas USA. ii [NDLR00] Ndiaye Y., Diene A. W., Litwin W., Risch T., Scalable Distributed Data Structures for Hight- Performance Databases, T.3-rd Intl. Workshop on Distributed Data Structures 2000, Italy. iii [NL01] Ndiaye Y., Litwin W. Presentation of AMOS-SDDS: A Scalable Distributed Data Manager for Windows Multicomputers at the International Workshop on Performance-Oriented Application Development for Distributed Architectures (PADDA 2001 Munich)

111 Annexe 2 Description des codes sources des prototypes Nos travaux ont porté sur le couplage des SDDS avec deux SGBDs : AMOS-II et DB2. A chaque étape, les choix techniques ont été validés par l implantations de prototypes et des mesures de performances. Dans la première partie de la thèse, nous avons proposé deux stratégies de couplage des SDDS avec AMOS-II. Les systèmes AMOS-SDDS et SD-AMOS, comme la plupart des applications réseau, comportent deux parties un client et un serveur. La communication entre processus distants est assuré par l interface des sockets Windows. Dans la seconde partie de la thèse, un schéma de couplage des SDDS avec le SGBD DB2 a été proposé. Il a permis de faire du gestionnaire SDDS, un entrepôt de données de DB2 en se basant sur les fonctionnalités de manipulation de données externes offertes par ce SGBD. Ce document est organisé en trois parties qui présentent respectivement les systèmes AMOS- SDDS, SD-AMOS et DB2-SDDS. 6 Implantation du système AMOS-SDDS Les codes sources se trouvent dans le répertoire Release. Pour chaque prototype, il y a un répertoire pour le client et un répertoire pour le serveur. 6.1 Liste des prototypes : La Stratégie externe La stratégie externe comporte plusieurs versions qui se distinguent principalement par les mécanismes de récupération des résultats d une requête et par les structures de données utilisées. La première version utilisait le protocole UDP. Les versions suivantes utilisent le protocole TCP. Le transfert de données entre client et serveur se fait à l aide de tampon de communication. Deux types de tampon sont utilisés : un tampon avec des champs de longueur variable et un tampon avec des champs de longueur fixe. Les meilleurs temps de réponse ont été obtenus en utilisant un tampons avec des champs de longueur fixe. - Couplage AMOS-SDDS avec Transfert de données par UDP : Répertoire Client : AmosSDDS Répertoire Serveur : SRV_AmosSDDS

112 - Couplage AMOS-SDDS avec Transfert de données par un tampon avec des champs de longueur variable avec séparateur : Répertoire Client : AmosSDDS_TCP_sep Répertoire Serveur : Serveur_TCP_sep - Couplage AMOS-SDDS avec Transfert de données par un tampon avec des champs de longueur variable avec séparateur : Répertoire Client : AmosSDDS_TCP_sep_1buf Répertoire Serveur : Serveur_TCP_sep_1buf - Couplage AMOS-SDDS avec Transfert de données par un tampon avec des champs de longueur fixe : Répertoire Client : AmosSDDS_TCP Répertoire Serveur : Serveur_TCP La Stratégie d importation - Couplage AMOS-SDDS avec un serveur par machine : Répertoire Client : AmosSDDS_TCP_imp Répertoire Serveur : Serveur_TCP_imp - Couplage AMOS-SDDS avec plusieurs serveurs par machine : Répertoire Client : AmosSDDS_TCP_imp_M Répertoire Serveur : Serveur_TCP_imp_M Les fonctions agrégats Couplage AMOS-SDDS avec des fonctions externes agrégats : Répertoire Client : AmosSDDS_TCP_aggr Répertoire Serveur : Serveur_TCP_aggr 6.2 Liste des fichiers d une application Client: 1. calloutdemo.dsw : Fichier permettant de charger l environnement de développement d une application client sous visual studio. 2. callout.h : fichier d entête de AMOS-II permettant la compilation de fonctions externes. 3. CalloutDemo.c : fichier principal contenant les codes sources de toutes les fonctions externes développées sur le client. 4. ClientRPN.c : Fichier contenant l ensemble des fonctionnalités d un client SDDS-RP, notamment la gestion des threads, des sockets, des fonctions d envoi et de réception de messages UDP

113 5. ClientTCP.c : Fichier regroupant les fonctions de gestion de toutes les étapes d une communication TCP entre le client et le serveur. 6. image.c : Fichier contient les fonctions spécifiques du client SDDS-RP*C. Il s agit de la gestion de l image du client, notamment l initialisation et les mises à jours. 6.3 Liste des fichiers d une application Serveur: 1. serveur.dsw : Fichier permettant de charger l environnement de développement d une application serveur sous visual studio. 2. callout.h : fichier d entête de AMOS-II permettant la compilation de fonctions externes. 3. serveur.c : fichier principal contenant les codes sources de toutes les fonctions externes développées sur le serveur. 4. Fichiers de gestion d une case SDDS ( EnteteSer.c, FSocket.c, CaseRP.def, FDef.c, FMessages.c, Biblio.c, FEclate.c, FCase.c, Simple.c, Range.c, Init.c). 7 Implantation du système SD-AMOS Les codes sources se trouvent dans le répertoire AmosII. Il y a un répertoire pour le prototype client(client) et un répertoire pour le prototype serveur(serveur). 7.1 Liste des fichiers de l application Client: 1. calloutdemo.dsw : Fichier permettant de charger l environnement de développement d une application client sous visual studio. 2. callout.h : fichier d entête de AMOS-II permettant la compilation de fonctions externes. 3. enteteclient.c : Fichier contenant la déclaration des variables globales et des structures de données utilisées par l application client. 4. CalloutDemo.c : fichier principal contenant les codes sources de toutes les fonctions externes développées sur le client. 5. ClientTCP.c : Fichier regroupant les fonctions de gestion de toutes les étapes d une communication TCP entre le client et le serveur. 6. imagerpc.c : Fichier contient les fonctions spécifiques du client SDDS-RP*C. Il s agit de la gestion de l image du client, notamment l initialisation et les mises à jours. 7.2 Liste des fichiers de l application Client: 1. calloutdemo.dsw : Fichier permettant de charger l environnement de développement d une application serveur sous visual studio. 2. callout.h : fichier d entête de AMOS-II permettant la compilation de fonctions externes. 3. enteteserv.c : Fichier contenant la déclaration des variables globales et des structures de données utilisées par l application serveur

114 4. CalloutDemo.c : fichier principal contenant les codes sources de toutes les fonctions externes développées sur le serveur. 5. eclate.c : Fichier regroupant les fonctions de gestion de toutes les étapes de l éclatement d une table interne AMOS par la couche SDDS. 6. range.c : Fichier contient les fonctions de traitement des opérations supportées par le serveur. Il s agit de la recherche(simple et par intervalle), d une insertion et d une requête AMOSQL. 8 Implantation du système DB2-SDDS Les codes sources se trouvent dans le répertoire DB2_PROG. Le client SDDS et le serveur DB2 sont deux programmes distincts qui tournent sur la même machine. Ils communiquent à travers des appels de procédures locales fournis par l interface RPC. Le client SDDS représente la partie serveur RPC, et ainsi exporte trois fonctions que DB2 peut appeler directement. Il s agit d une recherche simple, d une recherche par intervalle et d un parcours transversal du fichier. 8.1 L interfaçage du client SDDS avec DB2 Les codes sources de l interfaçage du client SDDS avec DB2 se trouve dans le répertoire DB2_SDDS. Ce module comporte la liste des fonctions suivantes: 1. serveur.dsw : Fichier permettant de charger l environnement de développement du service client SDDS pour DB2 sous visual studio. 2. db2_sdds.h : fichier d entête généré par l utilitaire MIDL permettant de définir la liste des fonctions avec leurs paramètres d entrée et de sortie pour les appels RPC. 3. db2_sdds_s.c : Fichier généré contenant la définition des fonctions supportées par l application serveur RPC. 4. ClientRPN.c : Fichier contenant l ensemble des fonctionnalités d un client SDDS-RP, notamment la gestion des threads, des sockets, des fonctions d envoi et de réception de messages UDP. 5. ClientTCP.c : Fichier regroupant les fonctions de gestion de toutes les étapes d une communication TCP entre le client et le serveur. 8.2 les fonctions externes Il s agit d une recherche simple, d une recherche par intervalle et d un parcours transversal du fichier recherche simple: Les codes sources de la fonction externe de recherche simple se trouve dans le répertoire SDDS. Ce module comporte la liste des fonctions suivantes:

115 1. sdds.dsw : Fichier permettant de charger l environnement de développement de la fonction externe de recherche simple sous visual studio. 2. db2_sdds.h : fichier d entête généré par l utilitaire MIDL permettant de définir la liste des fonctions avec leurs paramètres d entrée et de sortie pour les appels RPC. 3. db2_sdds_c.c : Fichier généré contenant la définition des fonctions supportées par l application client RPC. 4. sdds.c : Fichier principal contenant la définition de la fonction externe de recherche simple avec les appels RPC. La déclaration de cette fonction externe se fait sous DB2 à l aide de la commande suivante : CREATE FUNCTION enreg(integer) RETURNS Varchar(100) EXTERNAL NAME 'sdds!rechercher' DETERMINISTIC NO EXTERNAL ACTION NULL CALL LANGUAGE C PARAMETER STYLE DB2SQL NO SQL; recherche par intervalle: Les codes sources de la fonction externe de recherche par intervalle se trouve dans le répertoire Tsdds. Ce module comporte la liste des fonctions suivantes: 5. Tsdds.dsw : Fichier permettant de charger l environnement de développement de la fonction externe de recherche simple sous visual studio. 6. db2_sdds.h : fichier d entête généré par l utilitaire MIDL permettant de définir la liste des fonctions avec leurs paramètres d entrée et de sortie pour les appels RPC. 7. db2_sdds_c.c : Fichier généré contenant la définition des fonctions supportées par l application client RPC. 8. Tsdds.c : Fichier principal contenant la définition de la fonction externe de recherche par intervalle avec les appels RPC. La déclaration de cette fonction externe se fait sous DB2 à l aide de la commande suivante : CREATE FUNCTION intervalle(integer, Integer) RETURNS TABLE (ssn integer, name Varchar(50), city Varchar(50))

116 EXTERNAL NAME 'Tsdds!range' DETERMINISTIC NO EXTERNAL ACTION LANGUAGE C FENCED PARAMETER STYLE DB2SQL NO SQL SCRATCHPAD FINAL CALL DISALLOW PARALLEL; parcours transversal: Les codes sources de la fonction externe de balayage(scan parallel) se trouve dans le répertoire SCAN. Ce module comporte la liste des fonctions suivantes: 1. SCANFNT.dsw : Fichier permettant de charger l environnement de développement de la fonction externe de recherche simple sous visual studio. 2. db2_sdds.h : fichier d entête généré par l utilitaire MIDL permettant de définir la liste des fonctions avec leurs paramètres d entrée et de sortie pour les appels RPC. 3. db2_sdds_c.c : Fichier généré contenant la définition des fonctions supportées par l application client RPC. 4. SCANFNT.c : Fichier principal contenant la définition de la fonction externe de balayage(scan parallel) d un fichier SDDS. La déclaration de cette fonction externe se fait sous DB2 à l aide de la commande suivante : CREATE FUNCTION scan(varchar(20)) RETURNS TABLE (ssn integer, name Varchar(50), city Varchar(50)) EXTERNAL NAME 'scanfnt!fullscan' DETERMINISTIC NO EXTERNAL ACTION LANGUAGE C FENCED PARAMETER STYLE DB2SQL NO SQL SCRATCHPAD

117 FINAL CALL DISALLOW PARALLEL; 8.3 Application de test Les codes sources de l application test se trouve dans le répertoire emb_sql. Elle permet d effectuer des requêtes en SQL qui font appel aux fonctions externes définies précédemment. Ce module comporte la liste des fonctions suivantes: 1. adhoc.dsw : Fichier permettant de charger l environnement de développement de l application de test sous visual studio. 2. adhoc.c : Fichier principal contenant la définition des fonctions permettant de formuler des requêtes de manière interactive