1 / 126

Structures de Données Distribuées et Scalables

Structures de Données Distribuées et Scalables. Witold Litwin ceria.dauphine.fr/witold.html. Structures de Données Distribuées et Scalables. Une nouvelle classe de structures de données pour des bases de données modernes Scalables Grandissant rapidement D’une grande taille (TO – PO)

forest
Download Presentation

Structures de Données Distribuées et Scalables

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. Structures de Données Distribuées et Scalables Witold Litwin ceria.dauphine.fr/witold.html

  2. Structures de Données Distribuées et Scalables • Une nouvelle classe de structures de données pour des bases de données modernes • Scalables • Grandissant rapidement • D’une grande taille (TO – PO) • Avec des données multimedia, géographiques… • Hautement disponibles 24/7 • Permettant le calcul de prise de décision • Calcul rapide de fonctions diverses • Distribution et mémoires rapides

  3. VLDB-05 par taille http://www.wintercorp.com/VLDB/2005_TopTen_Survey/TopTenWinners_2005.asp

  4. VLDB-98 par taille UPS contient aussi 6 TB d ’indexes

  5. Même « VLDB Survey » en 1997 • Scalabilité : Base UPS a plus que quadruplé de volume en un an ! • Base TRW est la même que Experian

  6. Scalabilité de Grandes BDs • 3,2 TO en 97 • 17 TO en 98 • 223 TO en 2005 • La taille max connue d’une BD a augmenté de 70 fois en 8 ans !!!

  7. Structures de Données Distribuées et Scalables • Conçues spécifiquement pour les multiordinateurs • CPUs ou PCs interconnectés par un réseau local • Architecture à partage de rien • Shared Nothing Architecture • Introduites en 1993 • Plusieurs SDDSs découvertes depuis • Recommandées dans la nouvelle éd. 1999 de « Art of Computer Programming » de D. Knuth • Etudiées notamment à CERIA • Avec support de HP, IBM-Research & MS-Research • Cas unique pour les recherches en BDs en France

  8. Structures de Données Distribuées et Scalables

  9. SDDSs : Ce que l’on sait faire • Partitionnement scalable • Hachage • Ordonné • Multidimensionnel • Notamment SD-Rtrees • Fichiers résidant en général en RAM distribuée • Accès dix à cent fois plus rapide qu’aux disques • Fichiers sur SANs • TOctets à POctets • Calcul parallèle • Nécessaire pour les calculs de décision

  10. SDDSs : Ce que l’on sait faire • Disponibilité scalable • Plus le fichier est grands, plus il y a de serveurs à panne tolérée • Couplage à un SGBD • AMOS-2 • Prototype SDDS-200x sous Windows • Tables relationnelles scalables • SD-SQL Server

  11. SDDSs : Ce que l’on sait faire • Recherche de chaînes • Pattern matching • Confidentialité • Les deux, notamment en utilisant les signatures algébriques

  12. SDDSs : Ce que l’on ne sait pas faire • Beaucoup de choses • Fichiers plats • Concurrence • Transactions • Objets Symboliques • T-Cubes • ….

  13. Plan • Pourquoi ? • Multiordinateurs & leur applications • Inadéquation de structures de données traditionnelles • Quoi ? • Axiomatique des SDDSs • Comment ? • SDDSs connues

  14. Un multiordinateur • Une collection d'ordinateurs faiblement couplés • sans mémoire partagée • en général couplés • par un reseau de type LAN (multiordinateurreseau) • par un bus (ang.”switched” multiordinateur) • et WAN, puis ATM

  15. Un multiordinateur

  16. Pourquoi des multiordinateurs ? • Bon marchés (souvent ils existent déjà) • Une configuration matériel qui devienne dominante par son prix et utilité • Puissance théorique de ressources en calcul et mémoires impossible pour un ordinateur (traditionnel) 1400 WSs reliés à HPL avec le total de 100 GO de RAM et TOs de disques + que tout super-ordinateur existant • Possibilité de bases en RAM distribuée • Une nécessité pour les bases modernes

  17. Distance à l'info(ex. de Jim Gray, cours à UC Berkeley 1992, MAJ 2009) Lune 10 ms disque local 8 j 500 ms Flash 10 h RAM distant (100Mb Ethernet) 100 s 2 h RAM distant (Gb net) 10 s 10 m RAM 1 s 1 m

  18. Situation 2009 • Le prix d’une flash RAM est • 49 $ pour 32 GO (Déc. 08) • 139 $ pour 64 GO • Il est désormais sûr que: • Les disques devient le support d’archivage • Les données opérationnelles seront en général en RAM ou Flash distribuée • Voir l’article de J. Gray sur son site MS • Ou dans le matériel du cours

  19. Dimensions de la scalabilité(vue client) Scale-up Sous-linéaire (usuel) Temps d'opération(RAM distante) Linéaire (idéal) # opération / s Quantité de données# serveurs et # clients

  20. Dimensions de la scalabilité(vue client, spécifique SDDS) Bandes, juke-box… Sous-linéaire (usuel) Scale-up Temps d'opération Ordinateur- cluster Disques & Cache Cache & Disques Linéaire Multiordinateur & SDDS Ordinateur RAM locale RAM locale Quantité de données Ordinateur- cluster = # fixe de serveurs

  21. Dimensions de la scalabilité(vue client) Speed-up # opération / s Linéaire (idéal) Sous-linéaire (usuel) # serveurs

  22. Applications potentiellesde multiordinateur • Bases de Données • Réseaux Sociaux (Web 2…) • Réseaux Communautaires notamment • Calcul hautes performances • numérique • cryptographie • Haute disponibilité • Temps réel (flux de données…) • Gestion en général • Multimédia • Cartographie • ....

  23. Autres terminologies à la mode • Peer-to-Peer (P2P) Computing • Les pairesautonomes partageant les données • un paire est le client des autres • un paire est le serveur des autres • client seul = « free rider » • Les 1èrs P2P avait été non-structurés • toute requête provoquait un « flooding » • Un système P2P structuré évite le « flooding » • c’est en fait une SDDS

  24. Autres terminologies à la mode • GridComputing • calcul en grille • grilles de données • terminologie favorisée par IBM • projet Decrypthon en France et autres dans le monde. • Globus, Virtual Observatory, Meersman Primes… • Offre Industrielle naissante • DNS….

  25. Une Image Vaut Mille Mots

  26. Autres terminologies à la mode • Cloud Computing • Terminologie MS, IBM, HP… • Les services dispo à distance dans un « nuage » de serveurs (surtout sur le Web) • Semble un synonyme de grille (grid) • Storage Service • Amazon • Cas particulier de « Cloud »

  27. Autres terminologies à la mode • ElasticComputing • Semble même chose que Cloud

  28. Autres terminologies à la mode • SaaS • Software as a Service <-> Cloud • Voir Wikipedia… • Entreprise Data Fabric • Offert par Gemstone • Produit Gemfire • Même chose en principe que Storage Service • Mais c’est une RAM distribuée • Très proche de LH*

  29. GemFire http://www.gemstone.com/products/gemfire/edf.php

  30. Problèmes de conception • A part les réseaux : presque tout le logiciel système à (re)faire • Notamment les SGF pour : • mieux utiliser la RAM distribuée • offrir les fichiers scalaires sur la RAM distribuée (en dehors d'un ordinateur)

  31. Un multiordinateur Pair Serveur Client « Spare »

  32. Un multiordinateur Serveur Client Initiateur des connections aux serveurs pour l'accès aux données partagées Toujours disponible pour la connexion et contient les données partagées Paire ?

  33. Une SD classique Fichier SGF Calcul d'adresse Clients

  34. Problèmes de transposition sur un MO • Calcul d'adresse unique centralisé deviendrait un point d'accumulation • limite sur les performances d'accès • vulnérabilité aux pannes • Duplication du calcul d'adresse sur les clients exigerait des MAJ synchrones de clients en cas de changement de structure (éclatement d'une case, par exemple) • impossible pour un grand nombre de clients

  35. Une SDDS: axiomes généraux • Les données sont sur les (sites) serveurs • Il n'y a pas de répertoire central d'accès • Les MAJ de la structure d'une SDDS ne sont pas envoyées aux clients d'une manière synchrone

  36. Une SDDS: axiomes généraux • Un client peut faire des erreurs d'adressage par suite d'une image inadéquate de la structure de SDDS • 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 au client ayant fait l'erreur d'adressage: • Image Adjustment Message (IAM) • Le client ajuste son image pour ne plus faire la même erreur

  37. Une SDDS Croissance par des éclatements Serveurs Clients

  38. Une SDDS Croissance par des éclatements Servers Serveurs Clients

  39. Une SDDS Croissance par des éclatements Servers Serveurs Clients

  40. Une SDDS Croissance par des éclatements Servers Serveurs Clients

  41. Une SDDS Croissance par des éclatements Servers Serveurs Clients

  42. Une SDDS Clients

  43. Une SDDS Clients

  44. Une SDDS IAM Clients

  45. Une SDDS Clients

  46. Une SDDS Clients

  47. SDDSs Connues DS Classics

  48. SDDSs Connues DS SDDS (1993) Classics Hash LH* DDH Breitbart & al

  49. RP* Kroll & Widmayer SDDSs Connues DS SDDS (1993) Classics Hash 1-d tree LH* DDH Breitbart & al

  50. k-RP* dPi-tree RP* Kroll & Widmayer SDDSs Connues DS SDDS (1993) Classics m-d trees Hash 1-d tree LH* DDH Breitbart & al

More Related