1 / 32

Présentation en vue de la Thèse Yakham NDIAYE 13 Novembre 2001

Interopérabilité d'un Serveur de Structures de Données Distribuées et Scalables et d'un SGBD Relationnel-Objet. Présentation en vue de la Thèse Yakham NDIAYE 13 Novembre 2001. Objectifs. Étudier les possibilités d'interopérabilité d’une SDDS avec un SGBD.

nola
Télécharger la présentation

Présentation en vue de la Thèse Yakham NDIAYE 13 Novembre 2001

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Interopérabilité d'un Serveur de Structures de Données Distribuées et Scalables et d'un SGBD Relationnel-Objet Présentation en vue de la Thèse Yakham NDIAYE 13 Novembre 2001

  2. Objectifs • Étudier les possibilités d'interopérabilité d’une SDDS avec un SGBD. • Proposer des architectures de couplage. • Valider les choix techniques par l’implantation de prototypes et l’étude expérimentale de performances. • Ce travail se situe à la croisée des technologies des SGBDs en mémoire centrale, du relationnel-objet supportant les fonctions externes, et des SGBD distribués/parallèles.

  3. Plan • Multiordinateurs • SDDSs • SGBDs AMOS-II et DB2 • Couplage SDDS & AMOS-II • Couplage SDDS & IBM DB2 • Mesures de Performances  • Conclusion

  4. Les Multiordinateurs • Collection d’ordinateurs faiblement couplés. • Collection de stations de travail interconnectées par un réseau local haut-débit et sans mémoire partagée(0Mb/s) • Rapport coût-performance. • Moins chère et plus puissant qu’un gros système. • Disponible presque partout. • Puissance de calcul. • Capacités quasi illimitées de calcul, de mémoire vive et de stockage...

  5. Les SDDS • Nouvelle classe de structures de données pour les Multiordinateurs. • Données structurées : enregistrement avec une clé. balayage parallèle & envoi de fonctions. • Données stockées sur des sites désignés serveurs. • Un serveur qui déborde, transfère la moitié de ses enregistrements vers un nouveau serveur. • Requêtes formulées à partir de sites autonomes désignés clients. Pas de répertoire d’accès central.

  6. SGBD AMOS-II • AMOS-II :SGBD relationnel-objet expérimental développé par EDSLAB Université de Linköping en Suède. (http://www.dis.uu.se/~udbl/). • Données entièrement stockées en RAM. • Langage de manipulation déclaratif: AMOSQL. • Interface AMOS-II avec un programme externe: -call-level interface(callin) -fonctions externes (callout)

  7. DB2 Universal Database  • SGBD relationnel-objet d’IBM. « DB2 Universal Database ». • Représentant typique d’un SGBD relationnel-objet commercial. • Accéder à des données stockées en dehors de la base DB2 à travers les fonctions définies par l’utilisateur (User Defined Functions).

  8. Stratégies de Couplage avec AMOS • Stratégie AMOS-SDDS: - Étendre 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.

  9. Le Système AMOS-SDDS Traitement de requêtes sous AMOS-SDDS

  10. Stratégies de Couplage avec AMOS • Stratégie SD-AMOS: - Un serveur SDDS utilise un SGBD en interne comme gestionnaire de mémoire. - Stockage des données dans AMOS-II. - Couche SDDS gère la répartition scalable des données.

  11. Le Système SD-AMOS Traitement de requêtes dans SD-AMOS

  12. Couplage SDDS & DB2 • Stratégie DB2-SDDS: - Construction d’une liaison entre un SGBD et un entrepôt de données externes avec des accès rapides hors SGBD. -Concevoir l’interface permettant à DB2 d’utiliser les services du client SDDS pour envoyer une requête de recherche sur des données distantes.

  13. Couplage SDDS & DB2 Architecture de couplage DB2 et SDDS Déclaration d’une fonction UDF sous DB2 : CREATE FUNCTION scan(Varchar(20)) RETURNS TABLE (ssn integer, name Varchar(20),city Varchar(20)) EXTERNAL NAME ‘interface!fullscan'

  14. Couplage SDDS & DB2 Fonctions externes pour accéder à un fichier SDDS à partir de DB2: intervalle(cleMin, cleMax) -> liste enregistrements dont cleMin < clé < cleMax scan(nom_fichier)-> liste de tous les enregistrements du fichier Exemple de requêtes : - Parcours transversal Liste de tous les enregistrements du fichier SDDS. select * from table( scan(‘fichier’) ) as table_sdds(SSN, NAME,CITY) - Requête à intervalle Liste des enregistrements du fichier SDDS dont la clé est comprise entre 1 et 100. select * from table(intervalle(1, 100) ) as table_sdds(SSN, NAME,CITY) order by Name

  15. Environnement Expérimental • Six postes Pentium III 700Mhz 256Mo de RAM sous Windows 2000. • Reliés par un réseau Ethernet 100Mbits/s. • Un site est utilisé comme client et les cinq autres comme serveurs. • Plusieurs serveurs SDDS par machine pour simuler plusieurs serveurs (jusqu’à trois). • Un fichier peut ainsi s’étendre jusqu’à 15 serveurs.

  16. Expérimentations AMOS-SDDS • Fichier personne avec trois champs: (ssn, nom, ville). • De 20.000 à 300.000 enregistrements de 25 octets. • Distribution aléatoire. • Requête de jointure pour retrouver les couples de personnes habitant la même ville. • Requête 1 sur AMOS-II seul. • Requête 2 sur AMOS-SDDS avec Envoi de fonction. • Fonctions agrégats count et max. • Deux stratégies de traitement.

  17. Evaluation des requêtes • E-stratégie • Données sont stockées en dehors de AMOS-II »dans une case SDDS • Evaluation des requêtes par des fonctions externes • I-stratégie • Données sont importées dans une table AMOS-II • » Possibilité de création d’index local • »Tables temporaires vidées après traitement • » Pratique pour les jointures • Evaluation des requêtes par AMOS-II

  18. Nombre de Serveurs Nombre de Serveurs 1 1 2 2 3 3 4 5 4 5 Durée Requête (s) Sans Index 128 1.344 78 681 64 468 55 48 358 288 Temps par tuple (ms) 67,2 34 23,4 17,9 14,4 Avec Index 60 39 37 36 32 Expérimentations sur AMOS-SDDS Temps d’exécution deRequête 2sur un fichier 20.000 enregistrements Stratégie Fonction Externe Stratégie Importation Temps d’exécution de Requête 2 selon la stratégie

  19. Discussion • Les résultats montrent un net avantage de la stratégie d’importation sur la stratégie externe pour l’évaluation de la jointure. • Pour 5 serveurs, le taux d’amélioration est 6 fois plus important pour la boucle imbriquée, et 9 fois si un index est crée. • Ces résultats nous amènent à évaluer la stratégie d’importation sur un fichier de plus grande taille.

  20. Taille du fichier 20.000 60.000 100.000 160.000 200.000 240.000 300.000 # SDDS servers 1 3 5 8 10 12 15 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 Simulation de plusieurs serveurs Q1 = AMOS-SDDS; Q2 = AMOS-SDDS jointure avec count. Requête 2 : temps par enregistrement extrapolé pour AMOS-SDDS Temps d’exécution de la jointure en fonction de la taille du fichier et du nombre de serveurs

  21. Simulation de plusieurs serveurs • Résultats attendus en initialisant un seul serveur par machine. - obtenus en divisant les temps mesurés par le nombre de serveurs par machine • 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(2,94ms) quand la taille du fichier et le nombre de serveurs augmentent du même facteur. Extrapolation temps par tuple

  22. # serveurs 1 2 3 4 5 Stratégie-E (ms) 10 10 10 10 10 Stratégie-I (ms) 1.462 761 511 440 341 Fonction agrégat count Temps d’exécution de la fonction count sur un fichier de 100.000 enregistrements Fonction agrégat count surAMOS-SDDS count sur AMOS-II seul = 280ms Fonction agrégat count surAMOS-SDDS

  23. #serveurs 1 2 3 4 5 Stratégie-E (ms) 420 210 140 110 90 Stratégie-I (ms) 1..663 831 561 491 390 Fonction agrégat max Temps d’exécution de la fonction max sur un fichier de 100.000 enregistrements Fonction agrégat max surAMOS-SDDS max sur AMOS-II seul = 471ms Fonction agrégat max surAMOS-SDDS

  24. Discussion • Contrairement à la requête de jointure, la stratégie externe est gagnante pour l’évaluation des fonctions agrégats. • La fonction count est 34 fois plus rapide. • La fonction max est 4 fois plus rapide. • Ceci est du au temps d'importation des données et que les SDDS garde en mémoire le nombre d’enregistrements courant de chaque case. • Speed-up linéaire : le temps de traitement décroît en proportion de l’augmentation du nombre de serveurs. • L'utilisation des fonctions externes peut ainsi être très avantageuse pour certains types de requêtes.

  25. Expérimentations sur SD-AMOS Temps de création du fichier. La taille d’un enregistrement est de 100 octets. La taille maximale d'une case est de 750.000 enregistrements. Temps moyen d’insertion d’un enregistrement

  26. Expérimentations sur SD-AMOS Temps moyen de recherche d’un enregistrement. Temps moyen de recherche

  27. Discussion • 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é est de 0,12ms. - C’est 100 fois plus rapide que celui à un fichier traditionnel sur disque. • Scalabilité linéaire: Le temps d’insertion et le temps d’accès à un enregistrement sont indépendants de la taille du fichier.

  28. Expérimentations sur DB2-SDDS Temps d’accès aux données en fonction de leur lieu de stockage. Temps de traitement d'une requête à intervalle Temps par enregistrement

  29. Discussion • 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. • 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). Coût du couplage • Une application dispose : - d’accès direct rapide aux données - d’accès par le langage de requêtes du SGBD

  30. Conclusion • Nous avons prouvé expérimentalement la faisabilité de la liaison d’un gestionnaire SDDS avec AMOS-II, un SGBD en mémoire centrale et avec DB2, un SGBD supportant les fonctions externes. • Les résultats obtenus montrent une scalabilité du couplage pour le traitement de requêtes distribuées. • AMOS-SDDS et DB2-SDDS : utilisation d’un fichier SDDS par un SGBD et l’interprétation parallèle de requêtes sur les sites serveurs. • SD-AMOS : généralisation scalable d’un SGBD parallèle en mémoire centrale, où la répartition des données devient automatique.

  31. Futurs travaux • D’autres types de requêtes. • La décomposition dynamique des requêtes sur le client, en sous-requêtes appropriées au traitement parallèle. • L’optimisation de requêtes dans un environnement distribué dynamique.

  32. Fin Merci de votre attention CERIA Université Paris IX Dauphine Yakham.Ndiaye@dauphine.fr

More Related