structures de données distribuées et scalables

1

Structures de Données Distribuées et Scalables

Witold Litwinceria.dauphine.fr/witold.html

2


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

VLDB-05 par taillehttp://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


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


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


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


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 (multiordinateur reseau)» 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)

1 s

10 s

10 ms

RAM

RAM distant(Gb net)

disque local

100 s RAM distant(100Mb Ethernet)

1 m

10 m

2 h

8 j

Lune

500 s Flash 10 h

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)

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)

20

Dimensions de la scalabilité(vue client, spécifique SDDS)

Quantité de données

Multiordinateur & SDDS

Scale-up

Linéaire


RAM locale

Disques & Cache

Bandes, juke-box…

Cache & Disques

Temps d'opération

OrdinateurRAM locale

Ordinateur- cluster

Ordinateur- cluster = # fixe de serveurs

21

Dimensions de la scalabilité(vue client)

# serveurs

# opération / s

Speed-upLinéaire (idéal)


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 paires autonomes 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


Grid Computing– 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


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


Elastic Computing– Semble même chose que Cloud

28


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

Client Serveur Pair

« Spare »

32

Un multiordinateur

Client Serveur

Toujours disponible pour la connexion

etcontient les données

partagées

Initiateur des connectionsaux serveurs

pour l'accès auxdonnées partagées

Paire ?

33

Une SD classique

Calcul d'adresse

Clients

Fichier

SGF

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

38

Une SDDS

Clients

Croissance par des éclatements

Serveurs

39

Une SDDS

Clients


ServersServeurs

40

Une SDDS

Clients


ServersServeurs

41

Une SDDS

Clients


ServersServeurs

42

Une SDDS

Clients


ServersServeurs

43

Une SDDS

Clients

44

Une SDDS

Clients

45

Une SDDS

Clients

IAM

46

Une SDDS

Clients

47

Une SDDS

Clients

48

SDDSs Connues

DSClassics

49

SDDSs Connues

Hash

SDDS(1993)

LH* DDH

Breitbart & al

DSClassics

50

SDDSs Connues

Hash

SDDS(1993)

1-d tree LH* DDH

Breitbart & al RP* Kroll & Widmayer

DSClassics

51

SDDSs Connues

Hash

SDDS(1993)

1-d tree LH* DDH


m-d treesk-RP*

dPi-tree

DSClassics

52

SDDSs Connues

Hash

SDDS(1993)

1-d tree LH* DDH


m-d trees

DSClassics

Security LH*s

k-RP*dPi-tree

Nardelli-tree

LH*m, LH*g

H-Avail.

53

SDDSs Connues

Hash

SDDS(1993)

1-d tree LH* DDH

Breitbart & alRP*

Kroll & WidmayerBreitbart & VingralekBaton, CTH*, IH*..

m-d trees

DSClassics

H-Avail.

LH*m, LH*gSecurity LH*s

k-RP*dPi-tree, hQT*:

Nardelli-treeSD-Rtree…

s-availabilityLH*SA

LH*RS http://ceria.dauphine.fr/SDDS-bibliograhie.html

SDLSA

Disk

LH*P2PRS LH*RE

http://ceria.dauphine.fr/SDDS-bibliograhie.html

54

Références aux Travaux SDDS

55

Références aux Travaux SDDS

56

LH* Une SDDS basée sur Linear Hashing (LH)

– Litwin 1978, (VLDB-78).» Décrit dans plusieurs livres, Wikipedia, NIST Dict. of

Algos…» L'article original est réimprimé dans:

– Readings in Databases. M. Stonebraker (ed.). 2nd édition. Morgan-Kaufmann

» Utilisé dans de nombreux produits Postgres, MySQL, MS Inf. Server, SQL Server,

DbLibrary (Oracle), Nescape Suite, Frontpage, MsExchange

» Partie standard d’un curriculum en structures de données

57

LH* Proposée par Litwin, Neimat, Schneider (ACM-

Sigmod 1993), noté dans ce qui suit [LNS93] Présenté + en détail dans le journal ACM-

Transactions on Database Systems– ACM-TODS 96– Le principal journal de recherche en BDs

Nombreux variantes proposées depuis – Voir la biblio sur le site CERIA– Aussi ACM-TODS Oct. 06

Trois brevets US– 1 : HPL – 2 : IBM

58

Rappel sur LH 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 Le fichier consiste de cases de capacité b >> 1 Hachage par division hi : c -> c mod 2i N donne

l'adresse h (c) de la clé c. Eclatement de cases en remplaçant hi avec h i+1 ; i

= 0,1,.. En moyenne, b / 2 de clés s'en vont vers une

nouvelle case

59

Rappel sur LH

Un éclatement a lieu quand une case déborde On n'éclate pas la case qui déborde, mais celle

pointée par un pointer n. n évolue : 0, 0,1, 0,1,2, 0,1..,3, 0,..,7, 0,..,2i N, 0.. Ces principes évitent l'existence d'un index,

caractéristique d'autres algos de hachage extensible.

60

Evolution de fichier

351271524

h0 ; n = 0

N = 1b = 4i = 0h0 : c -> 20

0

61


351271524

h1 ; n = 0

N = 1b = 4i = 0h1 : c -> 21

0

62


1224

h1 ; n = 0

N = 1b = 4i = 1h1 : c -> 21

0

35715

1

63


32581224

N = 1b = 4i = 1h1 : c -> 21

0

211135715

1

h1 h1

64


321224

N = 1b = 4i = 1h2 : c -> 22

0

211135715

1

58

2

h2 h1 h2

65


321224

N = 1b = 4i = 1h2 : c -> 22

0

33211135715

1

58

2

h2 h1 h2

66


321224

N = 1b = 4i = 1h2 : c -> 22

0

3321

1

58

2

h2 h2 h2

1135715

3

h2

67


321224

N = 1b = 4i = 2h2 : c -> 22

0

3321

1

58

2

h2 h2 h2

1135715

3

h2

68


Et ainsi de suite– on introduit h3 puis h4 ...

Le fichier peut s'étendre autant qu'il faut, sans jamais avoir beaucoup de débordements.

69

Algorithme d'adressage

a <- h (i, c) si n = 0 alors exit sinon

si a < n alors a <- h (i+1, c) ;fin

70

LH* : Propriété Basique de LH

Une clé c est dans une case m adressée par une fonction hj ssi

hj (c) = m avec j = i ou j = i + 1

» Vérifiez par vous mêmes

71

LH* : Structure globale

Chaque case est sur un serveur diffèrent Pour toute clé c, son adresse est celle de

LH – C’est l’adresse correcte

Un site spécial gère les éclatements – Le coordinateur (super-pair)

72

LH* : Structure globale Le coordinateur est utile

– Adresses physiques– Haute dispo– Sécurité

Il est sollicité exceptionnellement– Pour ne pas être le point d’accumulation

» ang. hot spot Il n’est pas nécessaire

– Voir la version à jeton dans l’article ACM-TODS [LNS96]

73

LH* : Structure globale Quand il existe, il est le seul à

connaître (n, i)– Etat du fichier

» Ang. file state– Etendue du fichier

» Nombre de cases (serveurs)» Ang . extent

N = n + 2i

– La dernière case a pour l’adresse N -1

74

LH* : Structure globale Le coordinateur reçois tout message

d’une case qui déborde Il le seul à connaître et informer la

case n qu’elle doit éclater Une fois l’éclatement terminé, il met

à jour (n, i)– Selon LH– Comment alors ?

75

LH* : Adressage par clé

Chaque client a son image de l’état du fichier (i’, n’)

Initialement i’ = 0 et n’ = 0 Le client adresse toute requête à clé à la

case m m = LHi’, n’ (c)

76


L'en-tête de chaque case contient j courant– Déterminé par les éclatements– Egalement, par l’étendue du fichier N

Quand une clé c arrive de la part d'un client à une adresse, la case vérifie si elle est correcte – Par le test de la propriété de LH

Si OK, alors la case répond au client

77


Sinon – La case renvoie c vers une adresse peut-

être correcte– On parle d’un renvoi

» Ang. forwarding or hop La case réceptrice répète le schéma Etc Enfin, la case correcte répond au client

– Avec en plus un IAM

78

LH* : structure de fichier distribué

j = 4

0

j = 4

1

j = 3

2

j = 3

7

j = 4

8

j = 4

9

n = 2 ; i = 3

n' = 0, i' = 0 n' = 3, i' = 2 Coordinateur

Client Client

serveurs

79

LH* : éclatement

j = 4

0

j = 4

1

j = 3

2

j = 3

7

j = 4

8

j = 4

9

n = 2 ; i = 3

n' = 0, i' = 0 n' = 3, i' = 2 Site coordinateur

Client Client

serveurs

80

LH* : éclatement

j = 4

0

j = 4

1

j = 3

2

j = 3

7

j = 4

8

j = 4

9

n = 2 ; i = 3


Client Client

serveurs

81

LH* : éclatement

j = 4

0

j = 4

1

j = 3

2

j = 3

7

j = 4

8

j = 4

9

n = 2 ; i = 3


Client Client

serveurs

82

LH* : éclatement

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3


Client Client

serveurs

j = 4

10

83

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3

n' = 3, i' = 2 Site coordinateurClient

Client

serveurs

j = 4

10

15

n' = 0, i' = 0

N' = 1

84

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3n' = 0, i' = 0

n' = 3, i' = 2 Site coordinateurClient Client

serveurs

j = 4

10

15

N' = 1

85

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3

n' = 1, i' = 3 n' = 3, i' = 2 Site coordinateurClient

Client

serveurs

j = 4

10

15

j = 4, a = 0

N = 23 + 2N' = 23

86

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3


Client

serveurs

j = 4

10

9

n' = 0, i' = 0

N' = 1N = 23 + 2

87

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3n' = 0, i' = 0

n' = 3, i' = 2 Site coordinateurClient Client

serveurs

j = 4

10

9

N' = 1 N = 23 + 2

88

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3n' = 0, i' = 0


Client

serveurs

j = 4

10

9

N' = 1N = 23 + 2

89

LH* : adressage

j = 4

0

j = 4

1

j = 4

2

j = 3

7

j = 4

8

j = 4

9

n = 3 ; i = 3

n' = 2, i' = 3 n' = 3, i' = 2 Site coordinateurClient

Client

serveurs

j = 4

10

9

j = 4, a = 1

N' = 23 + 1N = 23 + 2

90

Adressage LH*

Le client – calcule l'adresse LH de la clé c dans son image, soit m, et

envoie c à la case m Serveur a recevant la clé c, a = m notamment, calcule :

a' := hj (c) ;si a' = a alors accepte c ;sinon a'' := hj - 1 (c) ;

si a'' > a et a'' < a' alors a' := a'' ; envoies c à la case a' ;

Vois [LNS93] pour la (longue) preuve de cet algo

Simple, n'est ce pas ?

91

Ajustement d'image du client Toute image d’un client SDDS doit être correcte

– Ne contenir que les adresses logiques qui sont dans le fichier

Une IAM fait converger une image vers l’état réel du fichier– Ajoute des adresses de serveurs inconnues du client– La convergence peut être +- rapide

Dans le cas de LH*– Image (i’,n’) est correcte ssi:

» i’ ≤ i et si i’ = i alors n’ ≤ n – Toute IAM doit diminuer la différence entre l’étendu réel

N et dans l’image N’ – Plusieurs algos possibles

92

Ajustement d'image du client Le message IAM consiste de l'adresse a de la

dernière case qui a renvoyé 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 ;

L'algo. garantit que tout image de client est contenue dans le fichier actuel [LNS93]– dans l'absence de contractions du fichier (merge)

Mais, peut-on faire mieux ?

Simple, n'est ce pas ?

93

Ajustement d'image du client La case correcte a renvoie dans IAM

– l’adresse de la dernière case traversée a’ et son j’– son propre j

Le client ajuste son image comme suit: i’ = j’ – 1

if j < j’ or a > 2i’ : a = a’ endifn’ = a + 1if n’ ≥ 2i’ : n’ = 0 ; i’ = i’ + 1 endif

94

Ajustement d'image du client

Analysez l’ajustement de l’image dans le cas

l’insertion de la clé 1 dans le fichier exemple

Par le 1er algorithme d’ajustement

Puis, par le 2ème

Conclusion ?

95

Résultat On peut construire un fichier distribué

grandissant à une taille quelconque (ex. tout Internet) et tel que :–Toute insertion et toute recherche à clé

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

96

Résultat Preuve dans [LNS 93] Récemment, on a démontré que si tout

site est pair, alors le cas le pire n’est qu’un seul message de renvoi.

Cette variante s’appèle LH*RSP2P

– C’est le meilleur résultat possible pour une SDDS (DHT, grille, nuage…)

Thèse de Y. Hanafi–En cours à Dauphine

97

Allocation de sites

Toute case a:–Une adresse logique

»a = 0, 1, 2..– Une adresse physique réseau,

»ex. s = 123.456.789– Son site (localisation…)

Les clients et les serveurs doivent connaître les adresses physiques

98

Allocation de sites Le coordinateur choisit le site pour

toute nouvelle case–Dans le pool de sites disponibles

»Ang. spare sites La case ayant besoin d’éclater demande

le site vide par multicast– LH*RS

Alternativement, tout serveur a ce pool dans une table fournit par le coord. – Statique ou dynamique

99

Propagation des adresses de sites

Le serveur de la case n reçoit dans la demande de l’éclatement du coordinateur les adresses qu’il pourrait ne pas connaitre – Jusqu’à la case N = n + 2i

Un serveur qui envoi une IAM y inclut les adresses de site que le client pourrait ne pas connaître

100

Propagation des adresses de sites Une manière de faire:

– Le client inclut dans la requête l’étendu N’ de son image

– Le 1er serveur qui a réacheminé la requête y inclut les adresses physiques de l’étendu de sa connaissance

N’…N’’ ≤ N -1– Le 2ème serveur qui soit envoie l’IAM, soit

réachemine encore la requête y unione les adresses physiques de l’étendu de sa connaissance

– Le résultat part dans l’IAM chez le client qui ajuste son image

101

Propagation des adresses de sites Alternativement: le client manquant

d’adresses de sites, les demande au coordinateur

Le coordinateur est davantage sollicité En contrepartie, le traitement est + simple Aussi, le client peut demander toute adresse

à sa guise–Par ex. pour se prémunir contre les

adresses périmées à la suite de pannes de cases»Reconstruits ailleurs

102

Table statique

une même table T sur tout client et serveur – contient tous les adresses

disponibles pour tous les fichiers

une fonction H de hachage :H : (F + a ) -> k

ex. k = (F + a) mod M T ( k ) contient s (a)

s1 s2 s3 sMT

5

H

103

Requêtes parallèles (Scans)

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 recevoir Q et une seule fois

Mode d'envoi:– multicast

» n'est pas toujours commode, voire possible– unicast

» le client ne connaît pas tous les serveurs

104

LH* Scans

Le client envoie Q à toute case a dans son image Le message avec Q contient le niveau de message

j' :– initialement j' = i' si n' aet ai' sinon j' = i' +

1– case a (de niveau j ) renvoie Q à tous ses enfants en

utilisant l'algo:while j' < j do

j' := j' + 1forward (Q, j' ) à case a + 2 j' - 1 ;

endwhile Preuve de cet algo ?

105

LH* Scans

Le client envoie Q à toute case a dans son image Toute case fait suivre Q à tous ces enfants, petits

enfants… selon son j et avec son j. Un descendant don le niveau est j aussi, fait

suivre à son descendant. Preuve de cet algo ? Différence pratique entre les deux ? Comment faire pour un client paire ?

– Le serveur de case 4 veut envoyer la requête parallèle

106

Terminaison d'un Scan(multicast ou unicast)

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

Stratégies possibles– Regroupement sur les cases connues du client

» Chaque serveur ayant reçu le scan par renvoi, renvoie la réponse au « père »

» Peut-être aussi son adresse en guise de IAM– Réponse directe au client – Réponse vers un fichier indiqué par le client

107

Terminaison d'un Scan(multicast ou unicast)

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

Solution déterministe (chère, mais 100 % sure)– C demande à chaque case de répondre

Solution probabiliste (en général moins chère, mais x < 100 % sure)– seules répondent les cases pertinentes à la requête– après chaque réponse C réinitialise un time-out T

108

Solution Déterministe

– Toute case envoie j, m et les enreg. éventuellement» m c'est l'adresse logique

– Le client termine quand il a reçu N réponses ;» N = 2 i + n avec

– i = min (j) et n = min (m) avec j = i

i+1 i i+1n

109

Exécution d'un Scan(TCP/IP)

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

Stratégie 2– Ceux refusés redemandent x fois la connexion après temps t, 2t, 4t…

Problèmes– Surcharge du LAN, nombreuses re-émissions de paquets

Stratégie 3– Le client rappelle pour la connexion les serveurs ayant répondu

» N serveurs simultanément ; N = 1 dans ce qui suit.

110

Exécution d'un Scan

0

1000

2000

3000

4000

5000

6000

1 10 20 30 40 50 60 70 80 90 100 120 140Nombre de serveurs

Tem

ps d

e ré

pons

e (m

s)

Scénario 1Scénario 2Scénario 3

Étude de MM. Tsangou & Samba (U. Dakar)

111

Performances d'accès d'une SDDS

Mesurées en nombre de messages sur le réseau– mesure indépendante des paramètres du réseau

Nombre moyen de messages / insertion– global– sur un client

Nombre moyen de messages / recherche– client nouveau (i' = 0, n' = 0)

Convergence de vue du nouveau client Performance d'un client peu actif

112

10,000 inserts

Global cost

Client's cost

115

Inserts by two clients

116

Travaux à Dauphine(CERIA)

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)

Application SD-AMOS (avec U. Uppsala)

117

SDDS-2000 : global architecture(SDDS-2007 actuellement)

Applications ApplicationsApplications etc

Data Data Data

SDDS-Server SDDS-Server SDDS- Server

SDDS- Client SDDS-Client SDDSClient SDDS-Client

Network

118

Send Request Receive Response Return Response Client Image process.

SDDS-2000 : Client Architecture

Interface : Applications - SDDS

send Request

Socket

Network

Response

Request

ReceiveResponse

file i n

..... .....

Client Image

Update

Server Address

ReceiveRequest

ReturnResponse

Id_Req Id_App ... .....

Queuing system

Request Response

Applications

Server

119

SDDS-2000 : Server Architecture Bucket SDDS

Insertion Search Update Delete

W.Thread 1 W.Thread 4…

Request Analysis

Queuing system

Listen Thread

Socket

Client

Network

client Request

Response

Response

Listen Thread Queuing system Work Thread Local process Forward Response

120

6 Pentium 700 Mhz 128 MB Ram

Ethernet 100 Mbit/s

SDDS-2000 Access Performance Experimental Analysis

UDP Protocol for inserts and searches TCP Protocol for splits

SDDS 2007 est sur 1Gbit/s et est 10 fois + rapide

121

File creation time

012345678

0 1 2 3 4 5 6Nombre de case

Tem

ps (s

)

Single client inserts 20 000 records with acks

Number of buckets

Tim

e (s

)

122

Insert Time

0

0,1

0,2

0,3

0,4

0,5

0 5000 10000 15000 20000Taille du fichier (enregistrements)

Tem

ps (m

s)

File size

Tim

e (m

s)

123

Search Time

0,1

0,2

0,3

0,4

0,5

0 5000 10000 15000 20000Taille du fichier (enregistrements)

Tem

ps (m

s)

image client actualisée image client non-actualisée

File size

Tim

e (m

s)

New client Client with exact image

124

Conclusion

Scalability as wished Access times 30 times faster than the disk access

time Splits do not cost much IAMs are efficient

125

Conclusion

MOs sont l'avenir SDDS sont une nouvelle classe de

structures de données à des performances impossibles auparavant

Des possibilités nouvelles pour nombreuses applications

126

FINMerci de votre attention

structures de données distribuées et scalables

Documents