1Interopé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 Présentation en vue de la Thèse

Yakham NDIAYEYakham NDIAYE

  13 Novembre 200113 Novembre 2001

2

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

ObjectifsObjectifs

3

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

PlanPlan

4

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

Les MultiordinateursLes Multiordinateurs

5

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.

Les SDDSLes SDDS

6

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)

SGBD AMOS-IISGBD AMOS-II

7

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

DB2 Universal Database  DB2 Universal Database 

8

Stratégies de Couplage avec AMOS

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

Réseau

Serveur AMOS-SDDS Client AMOS-SDDS

Client SDDS

Client AMOS II Serveur AMOS II Traiter-AMOS(requête)

Ship(requête) Résultats

Send-AMOS(requête) Send-AMOS(tampon)

Receive-AMOS(requête)

Serveur SDDS

Results(scan)

fonctions externes

Case SDDS

Send-SDDS(requête) Traiter-SDDS(requête)

Send-SDDS(tampon)

Receive-AMOS(tampon)

Receive-SDDS(tampon)

Receive-SDDS(requête)

Le Système AMOS-SDDSLe Système AMOS-SDDS

Traitement de requêtes sous AMOS-SDDS

10

Stratégies de Couplage avec AMOS

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-AMOSLe Système SD-AMOS

Traitement de requêtes dans SD-AMOS

Réseau

Serveur SD-AMOS Client SD-AMOS

Client SDDS

AMOS-II local AMOS-II local

Ship(requête) Résultats

Envoyer(requête)

Recevoir(tampon) Envoyer(tampon)

Recevoir(requête)

Serveur SDDS

Résultats (scan)

Données locales

Traiter(requête)

12

Couplage SDDS & DB2Couplage 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 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'

Réseau

Client SDDS

Serveur DB2

fonction UDF Résultats

Serveur SDDS

Case SDDS

Envoyer(requête SDDS) Traiter(requête SDDS)

Envoyer(tampon) Recevoir(tampon)

Recevoir(requête SDDS)

14

Couplage SDDS & DB2 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 transversalListe de tous les enregistrements du fichier SDDS.select * from table( scan(‘fichier’) ) as table_sdds(SSN, NAME,CITY)

- Requête à intervalleListe 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

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.

Environnement ExpérimentalEnvironnement Expérimental

16

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.

Expérimentations AMOS-SDDSExpérimentations AMOS-SDDS

17

Evaluation des requêtesEvaluation 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

Expérimentations sur AMOS-SDDS

Expérimentations sur AMOS-SDDS

Nombre de Serveurs

1 2 3 4 5

Durée Requête (s)

1.344

681 468 358 288

Temps par tuple (ms)

67,2

3423,4

17,9

14,4

Nombre de Serveurs

1 2 3 4 5

Sans Index128

7864

5548

Avec Index60 39

3736 32

Temps d’exécution de Requête 2 sur un fichier 20.000 enregistrements

Stratégie Fonction Externe Stratégie Importation

Temps d’exécution de Requête 2 selon la stratégie

0

20

40

60

80

1 2 3 4 5

Nombre de serveurs

Tem

ps

par

tup

le(e

n m

s)

Strategie-EStrategie-I sans indexStrategie-I avec index

19

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.

Discussion  Discussion  

20

Simulation de plusieurs serveursSimulation de plusieurs serveurs

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

02.0004.0006.0008.000

10.00012.000

20.000 60.000 100.000 160.000 200.000 240.000 300.000

1 3 5 8 10 12 15# enreg.# serveurs

Du

rée e

xecu

tion

(en

s)

AMOS-II AMOS-SDDS jointureAMOS-SDDS jointure & count

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

Q1 = AMOS-SDDS; Q2 = AMOS-SDDS jointure avec count.

21

Simulation de plusieurs serveursSimulation de plusieurs serveurs

Extrapolation temps par tuple

05

10152025303540

20.000 60.000 100.000 160.000 200.000 240.000 300.000

1 3 5 8 10 12 15

# enreg.# servers

Tem

ps

par

tuple

(e

n m

s)

AMOS-IIAMOS-SDDS jointureAMOS-SDDS jointure & count

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.

22

Fonction agrégat countFonction agrégat count

Fonction agrégat count sur AMOS-SDDS

0

500

1.000

1.500

2.000

1 2 3 4 5

Nombre de serveurs

Dur

ée e

xécu

tion

(ms)

0

2

4

6

8

10

12Count avecimportation(échelle gauche)

Count avec les fonctionsexternes(échelle droite)

Temps d’exécution de la fonction count sur un fichier de 100.000 enregistrements

# 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 sur AMOS-SDDS

count sur AMOS-II seul = 280ms

23

Fonction agrégat maxFonction agrégat max

Fonction agrégat max sur AMOS-SDDS

0

500

1.000

1.500

2.000

1 2 3 4 5

Nombre de serveurs

Dur

ée e

xécu

tion(

ms)

Max avec lesfonctions externesMax avecimportation

#serveurs 1 2 3 4 5

Stratégie-E (ms) 420210

140 110 90

Stratégie-I (ms) 1..663

831

561 491 390

Temps d’exécution de la fonction max sur un fichier de 100.000 enregistrements

Fonction agrégat max sur AMOS-SDDS

max sur AMOS-II seul = 471ms

24

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.

Discussion  Discussion  

25

Expérimentations sur SD-AMOSExpérimentations sur SD-AMOSTemps 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

0,000,200,400,600,801,001,20

1 1 1 1 1 1 1 2 2 2 2 2 2 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

# serveurs# tuples x 100K

Tem

ps

mo

yen (m

s)

M.G.M.C.

26

Expérimentations sur SD-AMOSExpérimentations sur SD-AMOSTemps moyen de recherche d’un enregistrement.

Temps moyen de recherche

0.00

0.05

0.10

0.15

0.20

1 2 3 4 5

#serveurs

Tem

ps p

ar tu

ple

(ms)

Requête parintervalle

Rchercheasynchrone

Recherchesynchrone

27

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.

Discussion  Discussion  

28

Expérimentations sur DB2-SDDSExpérimentations sur DB2-SDDS

0

2.000

4.000

6.000

8.000

10.000

20.000 40.000 60.000 80.000 100.000

Nombre d'enregistrements

Tem

ps d

e tr

aite

men

t (m

s)

DB2-SDDSDB2SDDS

0,000

0,020

0,040

0,060

0,080

0,100

20.000 40.000 60.000 80.000 100.000

Nombre d'enregistrements

Tem

ps

pa

r e

nre

g. (

ms)

DB2-SDDSDB2SDDS

Temps de traitement d'une requête à intervalle

Temps par enregistrement

Temps d’accès aux données en fonction de leur lieu de stockage.

29

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

Discussion  Discussion  

30

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.

ConclusionConclusion

31

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.

Futurs travauxFuturs travaux

32

FinFin

Merci de votre attentionMerci de votre attention

CERIA Université Paris IX Dauphine

Yakham.Ndiaye@dauphine.fr