Gestion de données dans les systèmes pair-à-pair - IA

Gestion de données dans les systèmes
pair-à-pair
Remerciements à Bruno DEFUDE (GET- Institut National des Télécommunications)
1
Plan
• Introduction
• Architectures des réseaux P2P
– P2P non structurés
– P2P structurés
– P2P hybrides (super-pairs)
• P2P sémantiques
• P2P et BD
• Synthèse et Conclusion
2
Introduction
• Limitations de l’architecture client/serveur dans le
cadre du Web
– Concentration des ressources individuelles sur un petit
nombre de nœuds
– Goulot d’étranglement
• Besoin de répartir la charge de traitement et de la
bande passante à travers tous les nœuds du système
d’information réparti
3
P2P
• Internet des débuts était un système P2P
– N’importe quel couple d’ordinateurs pouvait s’envoyer des
paquets :
• Pas de firewalls, pas de communications asymétriques
– Les machines sont indifféremment client ou serveurs
– Approche coopérative
• Les P2P sont une sorte de renaissance des principes
de base d’internet.
4
Définition
• Chaque nœud (peer) participant peut être client ou
serveur
• Chaque nœud « paye » sa participation en donnant
accès à une partie de ses ressources
• Propriétés :
–
–
–
–
–
–
–
Pas de coordination centralisée
Pas de BD centralisée
Aucun nœud n’a une vision globale du système
Le comportement global émerge à partir des interactions locales
Tous les services et données sont accessibles de n’importe quel nœud
Les nœuds sont autonomes
Les nœuds et les connections ne sont pas fiables
5
Différents types de systèmes P2P
• Systèmes de partage de fichiers
– Napster, Gnutella, Freenet
• Commerce électronique
– eBay, serveurs d’intégration B2B
• Bases de données réparties
– Mariposa [Stonebraker96]
• Réseaux
– Réseaux mobiles ad-hoc
L’approche P2P se trouve à tous niveaux du système : utilisateur,
application, gestion de l’information, réseau.
6
Approches comparables
• Systèmes basés sur les événements
– Les nœuds génèrent et reçoivent des messages
• « push » systems
– Les nœuds envoient des informations
• Agents mobiles
– Similarité dans la recherche et la navigation
• Bases de données réparties
– Les données sont réparties sur plusieurs nœuds
– Traitement efficace de requêtes complexes par décomposition
– Structures d’index adaptées au passage à l’échelle
Le problème majeur est de retrouver l’information.
7
Classes de systèmes P2P
• P2P centralisé (ex: Napster)
– Index centralisé (non tolérant aux fautes) géré de façon centralisée
– Échange d’information direct
• P2P décentralisé (ou « pur ») (ex: Freenet, Gnutella)
– Pas d’index global, pas de coordination centrale, le comportement global vient des
interactions locales, etc.
– Échange d’information direct (Gnutella) ou à travers une chaîne d’intermédiaires
(Freenet)
• P2P structurés (ex: CHORD, CAN, P-GRID)
– Répartition des ressources sur les différents nœuds
– Utilisation de tables de hachage distribuées
• P2P hiérarchiques ou « super peers » (ex: Kazaa)
– Introduction des super-peers
– Mélange de client/serveur et P2P
• P2P sémantiques (ex: SON, Routing Indices)
– P2P « pur » avec routage basé sur une information sémantique
8
Fonctionnalités d’un système P2P
•
•
•
•
•
Découverte de ressources
Gestion des mises à jour
Passage à l’échelle
Tolérance aux fautes
Sécurité
9
Critères de comparaison
• Recherche de ressources :
– Topologie du réseau : ouverte(gnutella) ou contrôlée (Chord)
– Placement des données et des méta-données : libre(Gnutella) ou dirigé
(Chord)
– Routage des messages : fonction de choix des successeurs
• Besoins applicatifs :
– Expressivité du langage de requêtes
– Qualité des réponses, complétude des résultats : une réponse, toutes les
réponses, les k meilleures réponses, …
– Autonomie des nœuds : choix des ressources à stocker, choix des
nœuds successeurs, etc.
– Efficacité : rapidité des requêtes, répartition de charge, …
– Tolérance aux pannes
10
P2P non structurés
Napster, Gnutella
11
Napster
4
Nœud j
a1.mp3
Nœud i
3
b2.mp3
2
1
1: enregistrement de i
recherche de a1.mp3
ajout des fichiers de i dans l’index
2: retour des noeuds possédant a1.mp3
Index
centralisé
3: demande directe de i à j pour télécharger a1.mp3
4: téléchargement de a1.mp3 et
ajout dans la base de ressources partagées
12
Bilan Napster
• Fonctionne bien à l’échelle d’Internet
• Accès en P2P, mais recherche centralisée
• Serveur doit être bien dimensionné et tolérant aux
fautes
• Sensible aux partitionnements du réseau (serveur
inatteignable) et aux attaques
13
Gnutella
• Chaque nœud propage la requête à ses voisins (en général 4)
• Le nombre de propagations est limité (en général à 7)
• Détection de cycles grâce à l’identificateur des paquets
Recherche a
Retour a
14
Types de messages
Types
Ping
Description
Pong
Annonce disponibilité et lance
recherche nouveaux pairs
Réponse à un ping
Query
Requête
QueryHit
Réponse à Query si on possède
la ressource
Push
Demande de téléchargement pour
pairs derrière un firewall
Information
vide
Adresse IP + N°port;
nombre et taille de fichiers
partagés
Bande passante minimum
demandée; critère de
recherche
Adresse IP + N°port et
bande passante; Nb de
réponses + descripteurs
Id. du pair; index du fichier
demandé; adresse IP et N°
port où envoyer le fichier
15
Gnutella (ajout d’un nœud)
• Pour participer, un nœud doit se connecter à un hôte Gnutella connu
(www.gnutella.com). Des serveurs spécialisés renvoient une liste des
nœuds connus (extérieur au protocole).
C
A
B
D
Ping de A
Pong de B
Pong de C
E
Pong de D
Pong de E
16
Gnutella (recherche)
Get X.mp3
X.mp3
X.mp3
C
A
B
D
Query de A
QueryHit de C
QueryHit de E
E
X.mp3
Transfert du fichier
17
Les principes sous-jacents
• Principes d’égalité entre les nœuds
– Même capacité (puissance, bande passante, …)
– Même comportement (également client et serveur) et bon
comportement (pas de « mensonge »)
• Principe de requêtes « populaires »
– Les ressources très demandées sont très répliquées
– Requêtes concernent principalement peu de ressources
• Principe de topologie du réseau
– Graphe minimisant le nombre de chemins entre deux nœuds
– Longueur de chemin minimum entre deux nœuds quelconques est
faible (5 à 8)
18
Quid des principes en réalité ?
• Principe d’égalité entre les nœuds
– [Sariou et al.01] montrent un écart de 1 à 3 dans la bande passante
disponible.
• Conséquence : risque de perturbation du réseau et de partitionnements
(trop forte charge demandée à des noeuds connectés via des modems par
exemple)
– [Adar, Hubermann 00] montrent que 70% des utilisateurs ne partagent
aucun fichier (ils n’en ont pas ou ils n’intéressent personne), et que
50% des résultats sont produits par 1% des nœuds.
• Conséquences : (1) ceux qui partagent n’y ont pas d’intérêt (pas de
réciprocité) et (2) le réseau est sensible aux fautes et aux attaques
– Les études montrent également que certains nœuds sous-évaluent leur
bande passante disponible pour éviter d’être choisis.
– Le free-riding est un problème social plutôt que technique. Il induit des
problèmes de performances et de vulnérabilité du système.
– Constat : beaucoup de pairs sont des « free-riders » et tous les domaines
19
sont concernés.
Quid des principes (2)
• Principe des requêtes « populaires »
– Les 100 requêtes les plus fréquentes sont distribuées uniformément
– Les autres suivent une distribution de type Zipf
– Les techniques de cache de résultats s’appliquent bien et peuvent
apporter une amélioration notable
• Principe de topologie du réseau
– Plusieurs études montrent que le graphe sous-jacent de Gnutella est de
type « small world » et que le degré des nœuds suit une distribution
« power law »
– Le principe de diffusion de Gnutella ne s’adapte pas à SW (beaucoup
de message redondants)
20
Observations sur la bande passante Gnutella
• Sur une période de 1 mois
– La taille d’une requête typique est de 560 bits (y compris
headers TCP/IP)
– Les requêtes occupent 25% du trafic, les ping 50% et le
reste 25%
– En moyenne, un pair est connecté activement à 3 autres
• Limite de la dégradation à 10 requêtes/seconde
– 10 req * 560bits*4 *3 connections = 67200 b/s
– Au dessus de la capacité des modems
• Gnutella ne passe pas à l’échelle (pour la bande
passante)
21
Bilan de Gnutella
•
•
•
•
•
Complètement décentralisé
Très tolérant aux fautes
S’adapte bien à la dynamique du réseau
Gros consommateur de bande passante
Pas de garantie de succès, ni d’estimation de la durée des
requêtes
• Pas de sécurité, ni de réputation (pas de notion de qualité des
pairs ni des données fournies)
• Problème du « free riding »
• Simple, robuste, passe l’échelle (pour le moment)
22
P2P « Structuré » (DHT)
Distributed Hash Table :
Chord, P-Grid
23
Chord [Stoica et al. 2001]
• Table de hachage distribuée
• Les nœuds sont répartis sur un anneau
• Les ressources sont réparties sur les différents nœuds de
l’anneau
• Structure dynamique
– Ajout/retrait de nœud
– Panne d’un nœud
• Peut être utilisée pour construire des applications au-dessus
(DNS, …)
24
Consistent Hashing
• Chord alloue les ressources aux nœuds en utilisant
une fonction de hachage
• Consistent Hashing garantit avec une probabilité
élevée
– Ressources sont distribuées uniformément sur l’ensemble
des nœuds
– L’ajout/retrait d’un Nème nœud n’oblige à déplacer que
O(1/N) ressources
25
Structure en anneau
N1
N8
Chaque nœud est
N56
alloué sur l’anneau en
fonction de hash(IP)
N51
Au plus 2m nœuds
N14
N48
N21
N42
N38
N32
26
Placement des ressources
N1
Hash(ressource)=k
K54
N8
k placé sur successeur(k) N56
successeur(k)=nœud
N51
immédiatement supérieur
N48
(ou égal) à k
K10
N14
N21
N42
N38
K38
N32 K30
K24
27
Recherche (naïve) d’une ressource
• Sur le nœud i on reçoit la requête : recherche(k)
• Si i possède k, il retourne k
• Sinon, il propage la requête à son successeur (chaque nœud
doit stocker l’identification de son successeur)
• Le résultat suit le chemin dans l’ordre inverse
• Recherche linéaire en nombre de nœuds
28
Exemple de recherche naïve
N1
K54
Recherche(K54)
N8
K10
N56
N14
N51
N48
N21
N42
N38
K38
N32 K30
K24
29
Amélioration de la recherche
• Avoir une table de routage plus complète
• Pour chaque nœud i :
– Succ[k]=premier nœud sur l’anneau qui vérifie
(i + 2k-1) mod 2m, 1<= k <= m
– Successeur=succ[1]
– m entrées dans la table
– Prédecesseur (utilisé pour la maintenance dynamique du réseau)
– Donne adresse IP et No de port du nœud
30
Exemple de recherche
N1
K54
Recherche(K54)
N8
K10
N56
N14
N51
N48
N21
N42
Table routage N8
N8+1
N14
N8+2
N14
N8+4
N14
N8+8
N21
N8+16
N32
N8+32
N42
N38
K38
N32 K30
K24
31
Algorithme de recherche
• Rechercher si la clé existe localement. Si oui on
renvoie la valeur associée sinon
• Rechercher dans la table routage un nœud avec plus
grande valeur inférieure ou égale à la clé cherchée
• Transmettre la requête au nœud sélectionné et
appliquer récursivement
• Nombre de sauts moyen : O(log2(N))
32
Ajout d’un nœud
• Repose sur la combinaison d’opérations élémentaires
– N.join(n’) : nœud n annonce au nœud n’ qu’il rentre dans le réseau
et lui demande de lui fournir son successeur
– N.stabilize() : lancé périodiquement, permet à n et à son successeur
de vérifier qu’ils forment un couple correct (il n’y a pas de
nouveaux nœuds entre les 2)
– N.majentrées() : lancé périodiquement, permet d’initialiser la table
de routage pour les nouveaux nœuds ou de la mettre à jour pour les
nœuds existants
– N.testpredecesseur() : lancé périodiquement, vérifie que le
prédécesseur est toujours là
33
Exemple d’ajout N26
N21
N21
Successeur(N21)
join
N26
N32
K24
N32
K24
K30
K30
N32
K24
N21
stabilize
N21
N26
K24
N26
K24
N32
K30
K30
34
Propriétés de l’algorithme d’ajout
• L’algorithme garantit que n’importe quelle séquence de join
entrelacée avec des stabilize converge vers un état stable (tous
les nœuds restent atteignables)
• Même en présence d’un ajout (limité) de nœud, le coût de la
recherche reste en O(log(N))
• Une recherche peut échouer si le réseau n’est pas
complètement stabilisé (il faut relancer la recherche un peu
plus tard)
35
Sensibilité aux fautes
• L’algorithme de recherche repose sur la notion de
successeur (sensible à la panne de celui-ci)
• Une solution consiste à gérer une liste de r
successeurs
36
Evaluation Chord
•
•
•
•
•
Type de recherche : égalité
Coût de la recherche : O(Log2(n))
Coût de la mise à jour : O(Log2(n))
Coût de l’ajout d’un nœud : O(Log2(n))
Pas d’autonomie de stockage et de routage
37
Bilan Chord
• Algorithme assez simple, avec de bonnes propriétés
démontrables
• Résultats expérimentaux confirment
• Problème de latence :
– Fonction de recherche minimise le nombre de sauts, mais tous les sauts
n’ont pas forcément le même prix (traversée transatlantique e.g)
– Besoin d’utiliser de l’information sur la distance entre les nœuds (on
choisira parmi les successeurs possibles celui à distance minimale) ->
Global Network Positionning
38
P-Grid [Aberer 01]
• Table de hachage distribuée
• Nœuds se répartissent les ressources selon une structure
d’arbre binaire de recherche
• Repose sur une fonction de hachage préservant les préfixes et
distribuant uniformément les ressources sur l’arbre binaire
• Structure auto-adaptative, avec réplication
• Permet les recherches basées sur les préfixes (pas seulement
égalité stricte)
39
Exemple d’un P-Grid
ABR
0
virtuel
Query(6, 100)
00
1
1: 3
01 : 2
6
1:5
01 : 2
Données Données
Préfixe 00 Préfixe 00
1
10
01 Query(5, 100)
2
1:4
00 : 6
3
0:2
11 : 5
11
Query(4, 100)
4
0:6
11 : 5
5
0:6
10 : 4
Données Données Données Données
Préfixe 01 Préfixe 10 Préfixe 10 Préfixe 11
Pairs
Table routage
Données
40
Bilan de P-Grid
• Structure assez simple, tolérante aux fautes, avec
passage à l’échelle
• Évite de structurer les nœuds selon une fonction de
hachage
• Peut intégrer facilement des optimisations sur la
latence (choix d’un pair)
• N’est pas restreint aux recherches basées sur l’égalité
stricte
41
Autres approches de DHT
• Freenet [Clarke 01]
• CAN [Ratsanamy 01] : espace à n-dimensions
• Pastry [Rowstron 01] : hypercube
42
P2P hybrides (super-pairs)
Client/serveur +P2P
43
Super-peers
• Eviter les problèmes dus à l’hétérogénéité de la bande
passante des nœuds
• Tous les nœuds ne sont plus égaux
– Les nœuds avec une bonne bande passante sont organisés en P2P : les
super-peers
– Les nœuds avec faible bande passante sont rattachés en mode
client/serveur à un super-peer (cluster)
– Les super-peers disposent d’un index de ressources de leur cluster
• Utilisé dans Kazaa
44
Exemple de super-peer
C/S
P2P
45
Super-peer redondant
• Le super-peer introduit de la sensibilité aux défaillances
• Amélioration possible, choisir k super-peers (partenaires) au
lieu d’un dans un cluster
• Chaque partenaire est connecté à chaque client et possède un
index de toutes leurs ressources
• Les clients envoient leurs requêtes aux partenaires selon un
principe de « round robin »
• Les voisins d’un partenaire distribuent également leurs
requêtes équitablement
• Fait baisser la charge du partenaire d’un facteur k
• Augmente le coût d’entrée d’un nouveau client d’un facteur k
• Augmente le nombre de connections ouvertes de k2
46
Exemple de super-peer redondant
C/S
P2P
47
Règles de conception d’un
super-peer [Yang 2003]
• R1 : augmenter la taille d’un cluster augmente la
charge individuelle (bande passante) mais diminue
la charge agrégée
– Peu de gros clusters : sensibilité aux défaillances, attaques, …
• R2 : la redondance de super-peer est favorable
– Amène la bonne charge agrégée des gros clusters avec une faible
charge individuelle et une bonne tolérance aux fautes
48
Règles de conception d’un super-peer
• R3 : maximiser le nombre de connexions des superpeers (diminue le nombre de sauts pour atteindre les
résultats). La stratégie doit être choisie pour tous les
pairs.
• R4 : minimiser le TTL (time-to-live)
49
Bilan des architectures
Non structuré
structuré
hybride
autonomie
Forte
Faible
Moyenne
efficacité
Faible
Forte
Forte
Qualité des
réponses
Faible
Forte
Forte
Expressivité
du langage
Tolérance aux
pannes
Forte
Faible
Forte
Forte
Forte
Faible
50
P2P sémantiques
Semantic Overlay Network (SON)
Routing Indices
51
P2P « sémantique »
• Ajouter de l’information aux tables de routage
• Généraliste vs spécifique (à une application)
• Information doit pouvoir être maintenue
dynamiquement
• Équilibre entre taille et précision
52
Quelle information ?
• Sur le contenu des nœuds (index)
– Suppose que les nœuds aient un contenu homogène (pas de placement
aléatoire)
– Routage par comparaison requête-index
– Même information partagée par tous, ou bien information construite
localement
– Exemples : SON, « routing indices »
• Sur le réseau (clustérisation)
– Regrouper logiquement les nœuds avec même « sémantique »
• Sur les requêtes
– Suppose qu’il y ait peu de requêtes différentes
– Routage par comparaison requête-requête
• Sur les utilisateurs
– Suppose que les utilisateurs aient toujours le même besoin
– Routage par comparaison utilisateur-utilisateur
53
Semantic Overlay Networks
• [Crespo, Garcia-Molina 03]
• Classifier l’ensemble des nœuds via une
classification « sémantique » (ex: genres de
musiques)
• Un même nœud peut se trouver dans plusieurs
classes
• Selon la requête, on sélectionne le ou les SON
susceptibles d’y répondre au mieux
54
Exemple de SON
Rock
A
C
Rap
Country
B
D
Jazz
F
E
H
G
Un nœud est logiquement relié à un autre, par un lien : (ni, nj, lk). Ex : (A, B, ‘Rock’)
55
Les nœuds ayant le même l forment un SON
Problématique des SON
• Un SON avec un seul label est un P2P classique
• Une fois le label choisi (en fonction de la requête), on
a un P2P classique
• Comment définir le SON ?
56
Processus de génération d’un SON
requête
Classification
requête
Hiérarchie
concepts
Définition SON
Distribution
Des données
SON
Classification
document
Nouveaux
noeuds
résultats
Classification
noeud
57
Exemple de classification
Music
Style
Jazz
Rock
Sous-style
Sous-style
Pop
Dance
Soft
New Orleans
Bop
Fusion
Un concept = un SON
58
Association des nœuds aux SON
• Repose sur un classifieur de documents
– Si un document du nœud correspond : favorise la
complétude, mais augmente le coût de la recherche
– Si k documents du nœud correspondent : diminue la
complétude, mais diminue le coût de la recherche
• Résolution d’une requête
– Cherche le(s) concept(s) correspondant à la requête
– Propage la requête dans le SON + ascendants +
descendants
59
Principe de recherche
SON i
requête
Nœud i
Classification
requête
SON k
60
Choix de la classification
• « bonne » hiérarchie de classification
– Classes dont les documents appartiennent à un petit nombre
de nœuds
– Les nœuds se trouvent dans peu de classes
– Classifieurs faciles à construire et les plus fiables possibles
61
Bilan SON
•
•
•
•
Repose sur la classification
Lié à un domaine précis
Favorise la précision, mais pas la complétude
Peut se paralléliser pour obtenir rapidement des
réponses (requête lancée dans chaque SON
sélectionné par le classifieur)
• Les résultats expérimentaux montrent une
amélioration notable en nombre de messages par
rapport à Gnutella.
62
« Routing Indices » [Crespo 02]
• Introduire de l’information sur le contenu des nœuds
(index)
• Analogue aux systèmes d’index répartis et
hiérarchisés pour moteurs de recherche sur Internet
• Trouver l’équilibre entre la taille de l’index et le gain
63
Exemple de « RI »
E
B
A
C
F
G
H
I
D
RI pour nœud A
Chemin
Nb
documents
BD
Réseaux
Théorie
langages
B
100
20
0
10
30
C
1000
0
300
0
50
D
200
10
0
0
100
150
J
64
Utilisation de l’index
• Soit Q une requête, conjonction de plusieurs termes de
recherche (tQ1, …tQk)
• Proximité(Q, chemin) =
Nbdedocuments X ∏i (RI(tQi)/Nbdedocuments)
•
•
•
•
•
Q émise sur A = (‘BD’, ‘langages’)
Proximité(Q, B) = 100 X 20/100 X 30/100 = 6
Proximité(Q, C) = 1000 X 0/1000 X 50/1000 = 0
Proximité(Q, D) = 200 X 100/200 X 150/200 = 75
Permet d’ordonner les nœuds successeurs
65
Exemple complet de RI
B
C
I
A
#
BD
R
T
L
I
50
25
0
15
50
D
1550
125
380
95
190
#
BD
R
T
L
J
50
15
0
25
25
D
1550
135
380
85
215
D
#
BD
R
T
L
A
300
30
80
0
10
B
100
20
0
10
30
C
1000
0
300
0
50
D
200
100
0
100
150
J
#
BD
R
T
L
D
100
60
0
60
75
A
1400
50
380
10
90
I
50
25
0
15
50
J
50
15
0
25
25
66
Algorithme de recherche
• Résoudre Q localement. Si suffisamment de résultats
OK, sinon
• Tant qu’il n’y a pas assez de résultats
– Évaluer proximité des successeurs
– Prendre le successeur S le plus proche (et non encore
exploré), si vide retour
– Recherche(Q, S)
67
Création d’un RI (ajout de AD)
B
C
I
A
#
BD
R
T
L
I
50
25
0
15
50
D
150
75
0
85
100
#
BD
R
T
L
J
50
15
0
25
25
D
150
85
0
85
125
D
#
BD
R
T
L
A
300
30
80
0
10
B
100
20
0
10
30
C
1000
0
300
0
50
1400, 50, 380, 10, 90
J
#
BD
R
T
L
D
100
60
0
60
75
I
50
25
0
15
50
J
50
15
0
25
25
200, 100, 0, 100, 150
68
Création d’un RI (2)
B
C
I
A
BD
R
T
L
A
300
30
80
0
10
B
100
20
0
10
30
C
1000
0
300
0
50
D
200
100
0
100
150
A Maj sur B et C
BD
R
T
L
I
50
25
0
15
50
D
150
75
0
85
100
1550, 125, 380, 95, 190
D
#
#
J
#
BD
R
T
L
J
50
15
0
25
25
D
150
85
0
85
125
1550, 135, 380, 85, 215
#
BD
R
T
L
D
100
60
0
60
75
A
1400
50
380
10
90
I
50
25
0
15
50
J
50
15
0
25
25
Somme de D sauf J
69
Maj d’un RI
• Analogue au processus de création
• Pour diminuer le coût, on peut accumuler les maj et
les traiter par lots
• Suppression d’un nœud suit le même principe
70
Bilan RI
• Structure d’indexation assez simple, mais maj génère beaucoup de
messages (mais diminue globalement le nb de msg par rapport à
Gnutella!)
• Exploration restreinte aux nœuds ayant la plus grande probabilité de
succès
• Fonctionne bien pour obtenir les meilleurs résultats, mais pas
forcément tous les résultats (plutôt orienté recherche des k meilleurs
résultats)
• Pas de garantie d’avoir tous les résultats
• Pour traiter des graphes généraux, il faut intégrer la gestion des cycles
(détection ou prévention)
• S’applique à des langages types mots-clés mais pas généralisable à des
langages plus complexes
• Classifier l’ensemble des nœuds via une classification « sémantique »
(e.g genres de musique)
• Pas d’information sur le nombre de sauts nécessaires (améliorations
possibles avec d’autres RI)
71
Une approche plus générale [Shen 04]
Autre
Super-peer
Super-peer
Global index
Group index
Local index
Local index
Local index
72
Hiérarchie de résumés
Global index
hp
Super-peer
level
hp
vs
Group index
hp
hp
vp
Peer
level
vp
Local index
hp
hp
hp
hp
vd
vd
vd
vd
document
document
document
Unit level
document
73
Construction des résumés
• Construction en deux étapes
– VSM (Vector Space Model): chaque document est
représenté par un vecteur (de grande dimension)
– LSI (Latent Semantic Indexing): utilisation de SVD
(Singular Value Decomposition), donne un point dans un
espace à k dimensions
• index
– Adaptation des VA files (Vector Approximation)
• Permet de calculer efficacement les K plus proches voisins
74
Exemple (1)
Id
Documents
d111
Monitoring XML Data on the Web
d211
Approximate XML joins
d321
Outlier Detection for High Dimensional Data
d421
High Dimensional Indexing using Sampling
d512
Document clustering with committes
d612
Document clustering with cluster refinement
d722
Title language model for information retrieval
d822
Document summarization in information retrieval
P1
P2
P3
P4
dinm : ième document du pair m du groupe n
75
Exemple (2)
d1
peer1
vp
Data,1,join,1 ,monitor,1,XML,2,web,1
10111
d2
SVD
01010
2d
2d
hp
Peer group 1
Data,2,detection,1,dimensional,2,high,2,index,1,join,1,monitor,1,outlier,1,sample,1,XML,2,web1
d3
Data,1,detection,1,dimensional,2,high,2,index,1,outlier,1,sample,1
2d
10000110021
…
SVD
d4
1111010
2d
peer2
11221001100
2d
SVD
0011101
2d
Peer group 2
76
Projet PADOUE
• Projet avec INRIA, LIP6, LIRMM, Cemagref
• Partage de données et de programmes entre chercheurs dans le
domaine de l’environnement
• Réseau à grande échelle, spécialisé, avec des utilisateurs
spécialisé : P2P sémantique
77
Médiation de données à large échelle
• Partage de données hétérogènes
– Outil de médiation
• Propriétés
– Intégration de données existantes
• Hypothèse
– Connaissances sur les sources
• Intérêt
– Traitement efficace des requêtes
• Distribution à large échelle
– Réseaux pair-à-pair
• Permet le passage à l’échelle et la dynamicité
78
Médiation et Pair-à-Pair
• Exploiter la complémentarité :
– Médiateur :
+ Langage de requêtes de haut niveau (SQL, XQuery,…)
- Sources connues (fixes)
- nombre limité de sources
– Pair-à-pair
+ Très grand nombre de sources
- Langage de requêtes pauvre (mots-clefs)
- Pb : comment localiser rapidement les données ?
79
Principes
• Mélanger différents niveaux d’informations
– Réseau global (contenu des nœuds): analogue à SON
– Utilisateurs : nœuds dont ils sont satisfaits
– Requêtes : utiliser les mêmes nœuds que ceux ayant traité
avec succès des requêtes analogues (même domaine)
• Utiliser le feedback
• Propager le feedback vers tous les nœuds par lesquels
la requête a transité
80
Informations sémantiques de Padoue
global
communauté
utilisateur
Type SON
{(cj, {(critèrei, {nj})})}
agrégé pour tous les
utilisateurs de la communauté
{(uk, {(critèrei, {nj})})}
81
Construction du réseau
• Ajout d’un nœud : s’adresser à un noeud connu du
réseau et récupérer l’information globale
• Mise à jour des informations de routage :
– Le feedback de l’utilisateur permet de mettre à jour
l’information utilisateur ET la communauté du nœud de
rattachement de l’utilisateur.
82
Bilan Padoue
• Utilisation conjointe de différents types d’information
• Informations statiques et dynamiques
• Besoin d’un minimum d’utilisation pour avoir de
bonnes tables de routage
• Suppose que les sites soient spécialisés et que les
utilisateurs posent des requêtes semblables
• Adapté à un domaine spécialisé
83
Comparatif sémantique
Type de
connaissance
statique
dynamique
apprentissage
SON
classification
domaine
oui
Non
classifieur
Routing
Indices
indexation
contenu
non
Oui
Comparaison
requête/indice
Padoue
classification
domaine +
utilisateurs +
requêtes
passées
oui
Oui
Requête
Feedback
utilisateur
84
P2P et BD
85
Gestion de données dans les P2P
Systèmes P2P
Dynamique
Placement aveugle
Passage à l’échelle
Autonomie
BD
Persistance
Cohérence des données
Propriétés transactionnelles
Schéma, intégration, médiation
Langage de requêtes, évaluation,
optimisation
indexation
86
Peer-to-Peer et bases de données
• BD dans les systèmes P2P
– Augmenter la puissance d’expression du langage de
requêtes (Huebsch 03, Villamil 04)
– Gestion de caches de résultats de requêtes (Sahin 04)
– Partage de données (http://gemo.futurs.inria.fr/projects/KadoP)
• P2P dans les SGBD
– Évaluation de requêtes réparties (Nejdl 03)
– Intégration de schémas (Tatarinov 03, Ooi 03)
– « intégration » de données (Arenas 03)
87
Projet PIER (Berkeley)
• Peer-to-peer Information Exchange and Retrieval
• Moteur de requêtes pour des environnements
distribués à très grande échelle (plusieurs milliers de
nœuds)
• Type d’applications visés : surveillance de l’Internet
• Relâchement de certaines contraintes BD (ex. ACID)
88
Architecture de PIER
App. 1
App. 2
Query
optimizer
Catalog
manager
Applications
Core
Relational
Execution
engine
PIER
Sur chaque
noeud
provider
Storage
manager
DHT
Overlay
routing
89
Composants PIER
• DHT : Bamboo, CAN, Chord
• Routing (propagation): leave, join, lookup(key),
locationMapChange()
• Storage manager (stockage temporaire en MC des
données de la DHT): store, retrieve, remove
• Provider (relie les 2 autres modules, et fait l’interface
avec les applications): get, put, renew, multicast,
lscan, newData
• Opérateurs relationnels au-dessus d’une DHT
(sélection, projection, jointure)
90
Bilan PIER
• Permet une évaluation de requêtes relationnelles sur
des DHT
• Passage à l’échelle
• Intégrer d’autres opérations (range queries, θjointure)
• Beaucoup de travail à faire sur l’optimisation
91
PinS : LSR-IMAG Grenoble
• Enregistrement et gestion de
données et de méta-données
– Méta-données : couples (attribut, valeur)
User Application
• Résolution de requête de
localisation
– Différentes stratégies
– Indexation
Insert()
Query()
PinS
Put()
Get()
DistributedStorageService
Lookup(), Join(), Leave()
DistributedLookupService
92
PinS : enregistrement d’un objet
• Enregistrement de l’objet dans le DSS
– Calcul de la clé de l’objet (Oid).
– Oid désigne un pair (pair de stockage) qui stocke l’objet et les
méta-données associées (Local Catalog).
• Enregistrement des méta-données dans le DSS
– Fragmentation
– Calcul d’une clé (Tid) pour chaque couple (attribut,valeur).
– Tid désigne un pair (pair de localisation) qui conserve la liste des
clés d’objets ayant cette valeur pour cet attribut
93
Exemple
P150
P600
Titre= Cent Ans de Solitude
Auteur=Gabriel Garcia Márquez
Année=1967
DSS.Put(123,Obj)
DSS. Put(201,123)
Données de localisation
P210
Titre= Cent Ans de Solitude
Auteur=Gabriel Garcia Márquez
Année=1967
TId
201
DSS. Put(401,123)
LstOId
{123}
Pair de localisation
P410
OId = (DSS.HashF(objet)) = 123
DSS. Put(510,123)
TId1 = (DSS.HashF(Année=1967)) = 510
TId
401
LstOId
{123}
TId2 = (DSS.HashF(Titre=CAS)) = 201
P550
TId3 = (DSS.HashF(Auteur=GGM)) = 401
Catalogue local (LC) sur le pair stockant l’objet
201, Titre, CAS, {123}
510, année, 1967, {123}
401, Auteur, GGM, {123}
TId
510
LstOId
{123}
94
PinS : Langage de requête
•
•
•
•
Query ::= Term [and/or Term]*
Term ::= EqTerm | IneqTerm | LikeTerm
EqTerm ::= AttributeName = value
IneqTerm ::= AttributeName op value
op is <, >, <= ou =>
• LikeTerm ::= AttributeName like [%lchar+[%]]
Exemple
Année<1988 and Title like «%One%» and auteur=GGM
95
Évaluation d’un EqTerm
stratégie générale
• Identification du pair de localisation :
– Calcule Tid du couple (attribut=valeur)
– Tid désigne le pair de localisation qui connaît toutes les
clés d’objets vérifiant ce terme.
• Conjonction, disjonction de EqTerm
– Intersection, union des réponses des pairs de
localisation.
• Couple (attribut,valeur) fréquent
– Pair de localisation surchargé (stockage, traitement)
96
Évaluation d’un EqTerm
stratégie locale
• Requête comportant plusieurs EqTerm :
– Pour les (Attribut, valeur) peu fréquents on utilise les pairs de
localisation pour connaître les clés d’objets candidats.
– Puis les autres termes sont évalués par le pair de stockage à l’aide du
LC (local strategy).
• Exemple :
P600
Titre= Cent Ans de Solitude
and/or
Année=1967
DLS.Lookup(123)
PinS.Evaluate(123,Query)
P150
P410
DSS.Get(510)
TId1 = (DSS.HashF(Année=1967)) = 510
TId2 = (DSS.HashF(Titre=CAS)) = 401
Titre= Cent Ans de Solitude
Auteur=Gabriel Garcia Márquez
Année=1967
IdTer
401
DSS.Get(401)
LstIdObj
{123}
P550
IdTer
510
LstIdObj
{123,750,...}
97
Évaluation d’un IneqTerm
• Évaluation coûteuse
• Solutions basées sur hash ordonnées
– Parcours des pairs susceptibles de contenir de l’information
de localisation
• Dans PinS
– Utilisation d’index
98
Évaluation d’un IneqTerm : Index
• Création d’index de localisation
–
–
–
–
une clé (Aid) est associée aux attributs indexés
Aid désigne le pair (pair attribut) qui stocke un index.
L’index mis à jour à l’enregistrement des objets.
Pour une valeur de l’attribut existant dans le système, le Tid
correspondant.
1969 197
1969 Valeur d’année
197 DSSHashF(Année=1969)
>= 1969
< 1969
1979 827 1987 773 1999 693
1963 285
1958 795 1959 691 1961489
1980773 1993 733
1963285 1967 319
1999 693 2003 668
…
99
Évaluation d’un IneqTerm : LC
• Quand une requête comporte d’autres termes
– Termes non indexés évalués par le pair de stockage à l’aide
du LC.
• Exemple :
P600
DLS.Lookup(123)
PinS.Evaluate(123,Query)
P150
DSS.Get(401)
Titre= Cent Ans de Solitude
Auteur=Gabriel Garcia Márquez
Année=1967
P410
IdTer
401
DSS.Get(795)
Titre= Cent Ans de Solitude
and/or
Année < 1963
TId1 = (DSS.HashF(Année) = 510
LstIdObj
{123}
DSS.Get(691)
DSS.Get(510)
Attribut Année
P550
TId2 = (DSS.HashF(Titre=CAS)) = 401
1969197
100
< 1969
>= 1969
Conclusions
• PinS est indépendant du système de DHT sous-jacent
– Architecture en trois couches : PinS, DSS et DLS
– Aucune hypothèse aux niveaux DSS et DLS
• Des stratégies d’évaluation pour une optimisation des requêtes
• Proposition pour améliorer l’accès aux données dans les
systèmes P2P, en adoptant une approche « BD » :
– fragmentation, duplication, cache de requêtes, index.
101
Projet Piazza (Washington Univ.)
• Système de médiation sans schéma global
• Chaque source dispose de son propre schéma et de
mappings vers d’autres sources
• Composition de mappings
• Résolution de requêtes : problème de reformulation
(approche mixte LAV et GAV)
102
Piazza (problèmes abordés)
•
•
•
•
Définition du langage d’expression des mappings
Étudier la composition de mappings
Étudier la reformulation de requêtes
Optimiser le processus d’évaluation (pipeline, précalculs)
• Dans un cadre relationnel et XML
103
Exemple de PDMS Piazza
Area(areaID, name, descr)
Project(projID, name, sponsor)
ProjArea(projID, areaID)
Pubs(pubID, projname, title, venue, year)
Author(pubID, author)
Member(projname, member)
DB-projects
U-Penn
data
Project(projID, name, descr)
Student(studID, name, status)
Faculty(facID, name, rank, office)
Advisor(facID, studID)
ProjMember(projID, memberID)
Paper(papID, title, forum, year)
Author(authorID, paperID)
Members(memID, Name)
Projects(projID, name, startDate)
ProjFaculty(projID, facID)
ProjStudents(projID, studID)
…
UW
data
Stanford
Area(areaID, name, descr)
data
Project(projID, areaID, name)
Pub(pubID, title, venue, year)
PubAuthor(pubID, authorID)
PubProj(pubID, projID)
Member(memID, projID, name, pos)
Alumni(name, year, thesis)
Direction(dirID, name)
Project(pID, dirID, name)
…
Berkeley
data
104
Définition des mappings (PPL)
• Description des sources (storage description)
– A : R = Q ou A : R ⊆ Q (A pair, R relation stockée par A, Q requête définie sur
le schéma de A)
– UPenn : students(sid, name, advisor) ⊆
UPenn : Student(sid, name, -), UPenn : Advisor(sid, fid), UPenn :
Faculty(fid, advisor, -, -)
• Médiation (peer mappings)
– Q1(A1) = Q2(A2) ou Q1(A1) ⊆ Q2(A2)
• Q1 et Q2 requêtes conjonctives de même arité
• A1 et A2 ensemble de pairs
– Egalité entre UW et DBProjects :
DBProjects:Member(pName, member) =
UW:Member(mid,pid,member), UW:Project(pid,pName)
– Definitional mappings
• Règles datalog portant sur les relations des pairs
105
Evaluation de requêtes
• Transformer Q en Q’ (exprimée sur des relations
stockées uniquement)
• Suppose que les mappings sont connus globalement!!
• Selon les mappings utilisés, doit mixer évaluation
GAV et LAV
106
Piazza (Mapping de schémas XML)
Schema S1 :
S1
people
faculty*
name
advisee*
student*
Schema S2 :
S2
people
faculty*
student*
name
advisor
* : une ou plusieurs occurrences
107
Requête posée sur S1
<result>{
For $faculty in document("S1.xml")/people/faculty,
$name in $faculty/name/text(),
$advisee in $faculty/advisee/text()
Where $name= "Ullmann"
Return <student>{$advisee}</student>
}
</result>
Etudiants conseillés par Ullmann
108
Mapping S1 vers S2
<S2>
for $people in /S1/people
return
<people>
for $name in
$people/faculty/name/text()
return
<faculty>{$name}</faculty>
for $student in $people/student/text()
return
<student>
<name>{$student}</name>
for $faculty in $people/faculty,
$name in $faculty/name/text(),
$advisee in
$faculty/advisee/text()
where $advisee=$student
return
<advisor>{$name}</advisor>
</student>
</people>
</S2>
Restriction de XQuery
Sémantique ensembliste
109
Piazza (bilan)
• Médiation sans schéma global
• Travail formel (mappings, composition mappings,
réécriture de requêtes, optimisation, …)
• Sur des données relationnelles et XML
• Certaines parties ne sont pas encore décentralisées
(évaluation de requêtes suppose connaissance globale
des mappings)
110
P2P et BD
• P2P est une voie prometteuse pour la gestion de
réseaux dynamiques et à grande échelle
• Domaine de recherche multi-disciplinaire (BD,
réseau, systèmes répartis, sciences sociales,…) très
actif (plusieurs workshops et conférences spécialisés)
• Pour l’instant, limité aux systèmes de partage de
fichiers, mais d’autres applications émergent
• Beaucoup de problèmes ouverts
111
Besoins applicatifs
Type
recherche
résultats
Garantie
Autonomie
stockage
Autonomie
routage
Gnutella
filtre
Tous?
Non
Oui
Oui
Chord
égalité
Un
oui
non
non
P-Grid
préfixe
Un
oui
Faible
non
Freenet
égalité
Un
Non
Oui
O/N
Super-peer
filtre
K
meilleurs
non
Oui
Oui pour SP,
non pour
autres
sémantique
filtre
K
meilleurs
non
Oui
oui
112
Problèmes ouverts
•
•
•
•
Sécurité
réputation
Contrôler le « free riding »
P2P sémantique
– On en est au début
– Mixer différents types de connaissances
– Connaissances dynamiques (apprentissage)
113
Sécurité
• Disponibilité (résistance aux attaques DoS)
• Authentification des ressources (si plusieurs réponses
différentes pour la même ressource)
– Plus vieille ressource
– Réputation (« experts »)
– Vote
• Anonymat
–
–
–
–
Auteur : quels utilisateurs ont créé quels documents?
Document : sur quels nœuds est stocké un document donné?
Lecteur : quels utilisateurs accèdent quels documents?
Serveur : quels documents sont stockés sur un nœud donné?
114
Bibliographie (générale)
•
•
•
•
•
•
•
•
•
•
•
K. Aberer, M. Hauswirth. Peer-to-Peer Information Systems: Concepts and Models, state-of-the-art,
and Future Systems, Tutorial IEEE ICDE, 2002
E. Adar, B. Huberman. Free Riding on Gnutella, Technical Report, Xerox PARC, septembre 2000
I. Clarke et al. Freenet: A Distributed Anonymous Information Storage and Retrieval System, LNCS
2009, Springer Verlag, 2001
L. Gong. JXTA: A Network Programming Environment, IEEE Internet Computing, 5(3), mai-juin
2001
Gnutella : http://www.gnutella.com
M.A. Jovanovic et al Scalability Issues in Large Peer-to-Peer Networks – A Case Study of Gnutella,
Research report, Univ. Cincinnati, 2001
J. Kleinberg. The Small-World Phenomenon: An Algorithmic Perspective, Technical Report 991776, Cornell Univ., 1999
J. Kubiatowicz et al. OceanStore: An Architecture for Global-Scale Persistent Storage, Proc.
ASPLOS, 2000
S. Saroiu, P. Gummadi, S. Gribble. A Measurement Study of Peer-to-Peer Sharing Systems, Proc.
Multimedia Computing and Networking, 2002
K. Sripanidkulchai. The Popularity of Gnutella Queries and its Implications on Scalability, février
2001
B. Yang, H. Garcia-Molina. Improving Search in Peer-to-Peer Systems, Proc. 28th Conf. On
Distributed Computing Systems, 2002
115
Bibliographie (DHT et super-pairs)
•
•
•
•
•
•
•
K. Aberer et al. Improving Data Access in P2P Systems, IEEE Internet
Computing, January 2002
K. Aberer. P-Grid: A Self-Organizing Access Structure for P2P Information
Systems, Proc. COOPIS, 2001
A. Rowstron, P. Dreschel. Pastry: Scalable, Distributed Object Location and
Routing for Large-Scale Peer-to-Peer Systems, Proc. IFIP/ACM Conf. On
Distributed Systems Platforms, 2001
I. Stoica et al. Chord: A Scalable Peer-to-Peer Lookup Service for Internet
Applications, Proc. ACM SIGCOMM 2001
S. Ratsanamy et al. A Scalable Content Addressable Network, Proc. ACM
SIGCOMM 2001
B. Yang, H. Garcia-Molina. Comparing Hybrid Peer-to-Peer Systems, Proc.
VLDB Conference, 2002
B. Yang, H. Garcia-Molina. Designing a Super-Peer Network, Proc. ICDE
Conf., 2003
116
Bibliographie (P2P sémantique)
• A. Crespo, H. Garcia-Molina. Routing Indices for
Peer-to-Peer Systems, Proc. ICDCS 2002
• P. Haase, R. Siebes. Peer Selection in Peer-to-Peer
Networks with Semantic Topologies, Proc. WWW
Conf., 2004
• H. T Shen, B. Yu. Efficient Semantic-Based Content
Search in P2P Network, IEEE TKDE 16(7), 2004
117
Bibliographie (médiation P2P)
•
•
•
•
•
•
•
•
K. Aberer, P. Cudré-Mauroux, M. Hauswirth. A Framework for Semantic Gossiping,
ACM SIGMOD Record 31(4), 2002
M. Arenas, V. Kantere, A. Kementsietsidis, I. Kiringa, R. Miller, J. Mylopoulos. The
Hyperion Project: From Data Integration to Data Coordination, ACM SIGMOD Recod
32(3), 2003
A. Halevy, Z. Ives, J. Madhavan, P. Mork, D. Suciu, I. Tatarinov. The Piazza peer data
management system. IEEE TDKE 16(7), 2004.
B.C Ooi, Y. Shu, K-L. Tan. Relational Data Sharing in Peer-based Data Management
Systems, ACM SIGMOD Record 32(3), 2003
J. Madhavan, A. Halevy. Composing Mappings Among Data Sources, Proc. VLDB
Conf., 2003
W. Nejdl, W. Siberski, M. Sintek. Design issues and challenges for RDF- and schemabased peer-to-peer systems. SIGMOD Record, 32(3), 2003.
W. Nejdel, B. Wolf, C. Qu, S. Decker, M. Sintek, A. Naeve, M. Nilsson, M. Palmer, T.
Rish. EDUTELLA: a P2P Networking Infrastructure based on RDF. Int. Conf. WWW,
2002.
I. Tatarinov, A. Halevy. Efficient Query Reformulation in Peer Data Management
System, Proc. ACM SIGMOD 2004
118
Bibliographie (requêtes complexes et DHT)
• J. Hellerstein. Architectures and Algorithms for Internet-Scale
(P2P) Data Management, tutorial VLDB 2004
• R. Huebsch, J. Hellerstein, N. Lanham, B.T Loo, S. Shenker, I.
Stoica. Querying the Internet with PIER, Proc. VLDB Conf.,
2003
• V. Papadimos, D. Maier. Mutant Query Plans, Information and
Software Technology, 44(4), 2002
• O.D Sahin, A. Gupta, D. Agrawal, A. EL Abbadi. A Peer-to-Peer
Framework for Caching Range Queries, Proc. ICDE 04 Conf.,
2004
• M. Villamil, C. Roncancio, C. Labbé. PinS: Peer-to-Peer
Interrogation and Indexing System, Proc. IEEE IDEAS
Conference, 2004
119