1 Structures de Données Distribuées et Scalables Witold Litwin

2 Structures de Données Distribuées et Scalables n Une nouvelle classe de structures de données pour des bases de données modernes –Scalables »Grandissant rapidement –Dune grande taille (GO – PO) »Avec des données multimedia, géographiques… –Hautement disponibles 24/7 –Permettant le calcul de prise de décision »Fonctions agrégat sur grande partie de la base

3 VLDB-98 par taille UPS contient aussi 6 GB d indexes

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

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

6 SDDSs : Ce que lon sait faire n Partitionnement scalable –Hachage –Ordonné –Multidimensionnel n Fichiers résidant en général en RAM distribuée »Accès dix à cent fois plus rapide quaux disques n Fichiers sur SANs – TOctets à POctets n Calcul parallèle –Nécessaire pour les calculs de décision n Disponibilité scalable –Plus le fichier est grands, plus il y a de serveurs à panne tolérée n Couplage à un SGBD –AMOS-2 n Prototype SDDS-2000 sous Windows 2000

7 PlanPlan n Pourquoi ? –Multiordinateurs & leur applications –Inadéquation de structures de données traditionnelles n Quoi ? –Axiomatique des SDDSs n Comment ? –SDDSs connues

8 Un multiordinateur n Une collection d'ordinateurs faiblement couplés –sans mémoire partagée –en général couplés par un bus de type LAN –et WAN, puis ATM

9 Un multiordinateur

10 Pourquoi des multiordinateurs ? n Bon marchés (souvent ils existent déjà) n Une configuration matérielle qui devienne dominante par son prix et utilité n 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 n Possibilité de bases en RAM distribuée –Une nécessité pour les bases modernes

11 Distance à l'info (ex. de Jim Gray) 100 ns 1 sec 10 msec RAM RAM distant (gigabit net) disque local 100 sec RAM distant (Ethernet)

12 Distance à l'info (ex. de Jim Gray) 100 ns 1 s 10 ms RAM RAM distant (gigabit net) disque local 100 s RAM distant (Ethernet) 1 m 10 m 2 h 8 j Lune

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

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

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

16 Applications potentielles de multiordinateur n SGBD n Calculs hautes performances –numérique –cryptographie n Haute disponibilité n Temps réel n Gestion en général n Multimédia n Cartographie n CAD/CAM n....

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

18 Un multiordinateur Client Serveur

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

20 Une SD classique Calcul d'adresse Clients Fichier SGF

21 Problèmes de transposition sur un MO n Calcul d'adresse unique centralisé deviendrait un point d'accumulation –limite sur les performances d'accès –vulnérabilité aux pannes n 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

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

23 Une SDDS: axiomes généraux n Un client peut faire des erreurs d'adressage par suite d'une image inadéquate de la structure de SDDS n Chaque serveur vérifie l'adresse de la requête et l'achemine vers un autre serveur si une erreur est détectée n Le serveur adéquat envoie alors un message correctif au client ayant fait l'erreur d'adressage: –Image Adjustment Message (IAM) n Le client ajuste son image pour ne plus faire la même erreur

24 ContraintesContraintes n Si une SDDS n'évolue plus, alors les IAM font converger toute image d'un client vers celle actuelle n L'ensemble des renvois à la suite d'une erreur d'adressage ne se fait qu'en quelques messages.

25 Une SDDS Clients Croissance par des éclatements Serveurs

26 Une SDDS Clients Croissance par des éclatements Servers Serveurs

27 Une SDDS Clients Croissance par des éclatements Servers Serveurs

28 Une SDDS Clients Croissance par des éclatements Servers Serveurs

29 Une SDDS Clients Croissance par des éclatements Servers Serveurs

30 Une SDDS Clients

31 Une SDDS Clients

32 Une SDDS Clients IAM

33 Une SDDS Clients

34 Une SDDS Clients

35 SDDSs Connues DS Classics

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

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

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

39 SDDSs Connues Hash SDDS (1993) 1-d tree LH* DDH Breitbart & al RP* Kroll & Widmayer m-d trees DS Classics Security LH*s k-RP* dPi-tree Nardelli-tree LH*m, LH*g H-Avail.

40 SDDSs Connues Hash SDDS (1993) 1-d tree LH* DDH Breitbart & al RP* Kroll & Widmayer Breitbart & Vingralek m-d trees DS Classics H-Avail. LH*m, LH*g Security LH*s k-RP* dPi-tree Nardelli-tree s-availability LH* SA LH* RS SDLSA Disk

41 LH*LH* n Une SDDS basée sur LH: –Linear Hashing (LH) : Litwin 1978, (VLDB-78). »Décrit dans plusieurs livres sur SGBDs. »L'article original est réimprimé dans: –Readings in Databases. M. Stonebraker (ed.). 2nd édition. Morgan-Kaufmann »Utilisé dans de nombreux produits Frontpage, MsExchange, MS Inf. Server, Nescape Suite… Frontpage, MsExchange, MS Inf. Server, Nescape Suite… n Proposée par Litwin, Neimat, Schneider (ACM- Sigmod 1993), noté dans ce qui suit [LNS93] n Plusieurs variantes proposées depuis –Voir la biblio sur le site CERIA

42 Rappel sur LH n Un algorithme d'hachage extensible –on étend l'espace d'adressage primaire pour éviter l'accumulation de débordements –et la détérioration progressive de performances d'accès n Le fichier consiste de cases de capacité b >> 1 n Hachage par division h i : c -> c mod 2 i N donne l'adresse h (c) de la clé c. n Eclatement de cases en remplaçant h i avec h i+1 ; i = 0,1,.. n En moyenne, b / 2 de clés s'en vont vers une nouvelle case

43 Rappel sur LH n Un éclatement a lieu quand une case déborde n On n'éclate pas la case qui déborde, mais celle pointée par un pointer n. n n évolue : 0, 0,1, 0,1,2, 0,1..,3, 0,..,7, 0,..,2 i N, 0.. n Ces principes évitent l'existence d'un index, caractéristique d'autres algos de hachage extensible.

44 Evolution de fichier h 0 ; n = 0 N = 1 b = 4 i = 0 h 0 : c -> 2 0 0

45 Evolution de fichier h 1 ; n = 0 N = 1 b = 4 i = 0 h 1 : c -> 2 1 0

46 Evolution de fichier h 1 ; n = 0 N = 1 b = 4 i = 1 h 1 : c ->

47 Evolution de fichier N = 1 b = 4 i = 1 h 1 : c -> h1h1h1h1 h1h1h1h1

48 Evolution de fichier N = 1 b = 4 i = 1 h 2 : c -> h2h2h2h2 h1h1h1h1 h2h2h2h2

49 Evolution de fichier N = 1 b = 4 i = 1 h 2 : c -> h2h2h2h2 h1h1h1h1 h2h2h2h2

50 Evolution de fichier N = 1 b = 4 i = 1 h 2 : c -> h2h2h2h2 h2h2h2h2 h2h2h2h h2h2h2h2

51 Evolution de fichier N = 1 b = 4 i = 2 h 2 : c -> h2h2h2h2 h2h2h2h2 h2h2h2h h2h2h2h2

52 Evolution de fichier n Et ainsi de suite –on introduit h 3 puis h 4... n Le fichier peut s'étendre autant qu'il faut, sans jamais avoir beaucoup de débordements.

53 Algorithme d'adressage a <- h (i, c) si n = 0 alors exit sinon si a < n alors a <- h (i+1, c) ; fin

54 LH*LH* n Propriété de LH : –Une clé c est dans une case m adressée par une fonction h j ssi h j (c) = m ; j = i ou j = i + 1 »Vérifiez par vous mêmes n Idée pour LH* : –mettre chaque case sur un serveur diffèrent –mettre j utilisé dans l'en-tête de la case –vérifier la propriété quand une clé arrive de la part d'un client

55 LH* : structure de fichier distribué j = j = j = n = 2 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs

56 LH* : éclatement j = j = j = n = 2 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs

57 LH* : éclatement j = j = j = n = 2 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs

58 LH* : éclatement j = j = j = n = 2 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs

59 LH* : éclatement j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j = 4 10

60 L'algo d'adressage LH* n Le client –calcule l'adresse LH de la clé c dans son image, soit m, et envoie c à la case m n Serveur a recevant la clé c, a = m notamment, calcule : a' := h j (c) ; si a' = a alors accepte c ; sinon a'' := h j - 1 (c) ; si a'' > a et a'' a et a'' < a' alors a' := a'' ; envoies c à la case a' ;

61 L'algo d'adressage LH* n Le client –calcule l'adresse LH de la clé c dans son image, soit m, et envoie c à la case m n Serveur a recevant la clé c, a = m notamment, calcule : a' := h j (c) ; si a' = a alors accepte c ; sinon a'' := h j - 1 (c) ; si a'' > a et a'' a et a'' < a' alors a' := a'' ; envoies c à la case a' ; n Vois [LNS93] pour la (longue) preuve de cet algo Simple, n'est ce pas ?

62 Ajustement d'image de client n Le message IAM consiste de l'adresse a ou le client a envoyé c et de j(a). –i' est la valeur présumée de i dans l'image du client. –n' est la position présumée de n –initialement, i' = n' = 0. si j > i' alors i' := j - 1, n' := a +1 ; si n' 2^i' alors n' = 0, i' := i' +1 ; si j > i' alors i' := j - 1, n' := a +1 ; si n' 2^i' alors n' = 0, i' := i' +1 ; n L'algo. garantit que tout image de client est contenue dans le fichier actuel [LNS93] –dans l'absence de contractions du fichier (merge)

63 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j =

64 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j =

65 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 3n' = 3, i' = 2 Site coordinateur Client serveurs j = a =7, j = 3

66 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j =

67 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j =

68 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 0, i' = 0n' = 3, i' = 2 Site coordinateur Client serveurs j =

69 LH* : adressage j = j = 3 7 j = n = 3 ; i = 3 n' = 1, i' = 3n' = 3, i' = 2 Site coordinateur Client serveurs j = a = 9, j = 4

70 RésultatRésultat n On peut construire un fichier distribué grandissant à une taille quelconque (ex. tout Internet) et tel que : –toute insertion et toute recherche peuvent être faites au plus en 4 messages au plus (IAM inclus) –en général une insertion est faite en un message et une recherche en deux messages –preuve dans [LNS 93]

71 Performances d'accès d'une SDDS n Mesurées en nombre de messages sur le réseau –mesure indépendante des paramètres du réseau n Nombre moyen de messages / insertion –global –sur un client n Nombre moyen de messages / recherche –client nouveau (i' = 0, n' = 0) n Convergence de vue du nouveau client n Performance d'un client peu actif

72 10,000 inserts Global cost Client's cost

73

74

75 Inserts by two clients

76 SDDS-2000 : global architecture Applications etc SDDS Data server SDDS Data server SDDS Data server SDDS-2000 Server SDDS-2000 Client Network

77 Send Request Receive Response Return Response Client Image process. SDDS-2000 : Client Architecture Interface : Applications - SDDS send Request Socket Network ResponseRequest Receive Response file i n Client Image Update Server Address Receive Request Return Response Id_Req Id_App Queuing system RequestResponse Applications Server

78 SDDS-2000 : Server Architecture Bucket SDDS InsertionSearchUpdateDelete W.Thread 1W.Thread 4 … Request Analyse Queuing system Listen Thread Socket Client Network client Request Response Listen Thread Queuing system Work Thread Local process Forward Response

MB Ram FC or FS Pentium 350 MhzPentium 90 Mhz 48 MB Ram SC or SS Ethernet 100 Mbit/s Performance measures : Configuration UDP Protocol for insertions and searches TCP Protocol for splits

80 Insert time into up to 3 buckets Configuration F.S J=2 S.S J=1 S.C 100 Mb/s S.S J=2 Bucket 0 Bucket 1 Bucket 2 UDP communication Batch 1,2,3, …

81 File creation time under 3 buckets Scalability Time for = 4 * Time for 5000

82 Insert Rate under 3 buckets With splits : includes 2 splits + forwards + IAM updates Without splits : the buckets already exist and the client image is up to date

83 Average search time in 3 Slow Servers : Configuration S.S J=2 S.S J=1 F.C 100 Mb/s S.S J=2 Bucket 0 Bucket 1 Bucket 2 UDP communication Batch 1,2,3, …

84 Search Rate Balanced load (charge) : 3 buckets are generated with the same number of records Unbalanced load : Bucket 1 has more records Conclusion : Good scalability

85 Best performances of a F.S : configuration F.S J=0 S.C (3) S.C (1) 100 Mb/s UDP communication Bucket 0 S.C (2)

86 Fast Server Insert Time 3 clients create lost messages

87 Fast Server Search Time Total search time / # of records searched More than 3 clients lost messages Bucket capacity does not influence the time (1000,5000, …, records),

88 Autres performances n Taux de remplissage : 70 % n Convergence d'image d'un nouveau client: –en O (log 2 N) IAM messages n Coût d'éclatement : un message (en théorie) n Temps d'accès (fichier RAM) : –< 1 ms sur Ethernet (pour articles de O) –30- s sur ATM ou un réseau 1 Gb/s »revisite l'ex. de Jim Gray n Tailles possibles d'un fichier RAM sur un LAN: – 100 GOctets aujourd'hui, > 500 GO demain

89 Taux de remplissage = m / (bN) est contrôlé par coordinateur en supposant l'image du fichier : On peut atteindre les taux moyens de l'ordre de %. Taux de remplissage = m / (bN) est contrôlé par coordinateur en supposant l'image du fichier : On peut atteindre les taux moyens de l'ordre de %. – % de plus que sans contrôle n Cette variante s'appelle à contrôlé d'éclatements Variantes de LH* Contrôlé d'éclatements Taux réel Taux supposé n N

90 Contrôle d'éclatements (détails) n Problème: –le coordinateur ne connaît pas m »m - nombre d'articles dans le fichier n Solution: –le coordinateur estime chaque fois qu'un message de débordement arrive –il ne déclanche l'éclatements que si t »t - taux de remplissage min voulu (threshold) –t [ ]

91 Contrôle d'éclatements Taux réel Taux supposé par le coordinateur n n La case s qui déborde envoie au coordinateur SC un message avec le nombre d'articles x dans s n SC execute l'algo suivant : d := x / b ; si s < n ou s 2 i alors d := 2 * d ; ' := (2 i * d ) / (2 i + n ) ; ' := (2 i * d ) / (2 i + n ) ; si ' > t alors evoie le message d'éclatement à la case n ; d x nn 2 i -n

92 Allocation de sites n Il faut appliquer pour toute case : –son adresse logique »a = 0, 1, 2.. – sur son adresse physique réseau, »ex. s = n Il faut une même correspondance sur chaque site n Solution: une table d'allocation T –statique –dynamique

93 Table statique n une même table T sur tout client et serveur –contient tous les adresses disponibles pour tous les fichiers n une fonction H de hachage : H : (F + a ) -> k ex. k = (F + a) mod M n T ( k ) contient s (a) s1s1 s2s2 s3s3 sMsM T 5 H

94 Table dynamique n Tout serveur n qui éclate choisit l'adresse s de la nouvelle case n' = n + 2 j - 1 n s est communiquée à SC n quand n' reçoit un forward de n, alors il inclut s dans l'IAM n Le client envoie un message au coordinateur avec i' et n' n Le coordinateur renvoie toutes les adresses manquantes au client (lesquelles alors ?) s1s1 s2s2 s3s3 s 20 T 3 s1s1 s2s2 s3s3 s 22 T s1s1 s2s2 s3s3 s 25 T SC S5S5 C 30

95 Table dynamique n Un serveur n'a que les adresses s de ses "enfants" n Un client a toutes les adresses s de son image n SC a toutes les adresses s n Ils existent d'autres algos pour gérer T –proposez un évitant le message de client à SC

96 Requêtes parallèles n Une requête Q à toutes les cases de F dont les exécutions locales sont indépendantes –en toute généralité : à certaines cases –toute case devrait recvoir Q et une seule fois n Mode d'envoi: –multicast »n'est pas toujours commode, voire possible –unicast »le client ne connaît pas tous les serveurs

97 LH* algorithme pour les requêtes parallèles n Le client envoie Q à toute case a dans son image n Le message avec Q contient le niveau de message j' : –initialement j' = i' si n' i' sinon j' = i' + 1 –case a (de niveau j ) renvoie Q à tous ses enfants en utilisant l'algo: while j' < j do j' := j' + 1 forward (Q, j' ) à case a + 2 j' - 1 ; endwhile n Preuve de cet algo ?

98 Terminaison d'une requête parallèle (multicast ou unicast) n Quand est-ce que le client C sait que la dernière réponse est arrivée ? –le nombre réel de cases est inconnu de C n Solution déterministe (chère, mais 100 sure) n Solution déterministe (chère, mais 100 % sure) –C demande à chaque case de répondre n Solution probabiliste (en géneral moins chère, mais x < 100 % sure) –seules repondent les cases pertinentes à la requête –après chaque réponse C réinitialise un time-out T

99 Solution Deterministe –Toute case envoie j, m et les enreg. eventuellement » m c'est l'adresse logique –Le client termine quand il a tout m tel que ; »m = 0,1..., 2 i + n avec – i = min (j) et n = min (m) avec j = i i+1i n

100 Exécution d'une requête parallèle (TCP/IP) n Stratégie 1 –Tous les sites serveurs se connectent dans la limite du "backlog" »Taille de la file d'attente de demandes simultanées de connections –5 sous Windows 2000 n Stratégie 2 –Ceux refusés redemandent x fois la connexion après temps t, 2t, 4t … n Problèmes –Surcharge du LAN, nombreuses re-émissions de paquets n Stratégie 3 –Le client rappelle pour la connexion les serveurs ayant répondu »N serveurs simultanément ; N = 1 dans ce qui suit.

101 Exécution d'une requête parallèle Étude de MM. Tsangou & Samba (U. Dakar)

102 LH* sans coordinateur n Un jeton J circule avec la valeur de i, à partir de n = 0. La case a qui a J estime (localement) La case a qui a J estime (localement) –comment ? ( il y a plusieurs stratégies ) Si > t alors a éclate et passe J à la case a +1 Si > t alors a éclate et passe J à la case a +1 n Il peut y avoir des cascades d'éclatements n Simulations de Julien Levy (Paris 9) montrent que les performances sont (un peu) meilleures que celles de LH* avec le coordinateur –De plus il n'y a aucun composant centralisé

103 Load factor for uncontrolled splitting

104 Load factor for different load control strategies and threshold t = 0.8

105

106 AutresAutres n Pré-éclatement n Accès concurrent n Plusieurs cases sur un même serveur –(Breitbart et Waikum, ACM-SIGMOD 94) n LH* LH (Transputer avec 128 PowerPCs) »avec J. Karlson & T. Risch, publié à EDBT-96 n LH* RS : »ACM-SIGMOD 2000

107 Opérations relationnelles n Projections, restrictions : –envoi d'une requête parallèle n Equijointures : –par bulk inserts dans le fichier LH* résultat »les clés égales ne peuvent finir que dans une même case »plusieurs méthodes existent –D. Schneider & al. COMAD 94 n On peut faire de très grandes jointures et on n'a pas besoin de connaître par avance la taille du résultat n Il est préferable de faire les projections et restrictions avant les jointure (comme pour les BDs centralisées)

108 Opérations relationnelles n Theta jointures –l'algo a définir en détails »la comparaison de deux clés C et C' autre que C =C' est peu performante par hachage »la comparaison de deux clés C et C' autre que C = C' est peu performante par hachage »RP* semble plus efficace n Fonctions agrégats (SUM, COUNT...) –req. parallèles

109 Vidéo sur demande n Chaque image (fixe) a une clé 0,1,2... n LH* répartit les images sur les sites n Le client qui doit faire jouer un film recherche les images en ordre de clés n Performances –on peut jouer plusieurs films à la fois –on peut jouer un film et charger d'autres simultanément –Pas besoin de serveur dédié (N-Cube chez Oracle)

110 Travaux à Dauphine (CERIA) n Implémentation des SDDS sous Windows NT –Système SDDS – 2000 »Financé par HPL, IBM-Almaden, MS-Research » LH* LH »LH* RS (U. Uppsala) »RP* –Client Java (U. Dakar) –Concurrence par dates de valeur (U. Dakar) n Application SD-AMOS (avec U. Uppsala)

111 ConclusionConclusion n MOs sont l'avenir n SDDS sont une nouvelle classe de structures de données à des performances impossibles auparavant n Des possibilités nouvelles pour nombreuses applications

112 FINFIN Merci de votre attention

113