Services de gestion de donn é es dans un environnement pair- à -pair

1. Ressources et Services P2P, Interrogation et Réplication Services de gestion de données dans un environnement pair-à-pair Stéphane Gançarski

2. RESPIRE : Ressources et Services P2P, Interrogation et Réplication • Projet ARA (Action Recherche Amont) Masses de données • Labélisé 15/12/2005. Kickoff le 24/02/2006. Durée 3 ans. • Partenaires : • BD LIP6 (S. Gançarski) • Département d'Informatique TMSP (ex-INT B. Defude) • PARIS – IRISA (G. Antoniu) • Atlas-GDD- LINA (E. Pacitti) • REGAL-INRIA (M. Shapiro) • Site Web : respire.lip6.fr

3. Objectifs • Partage d’information (documents, fichiers, BD, métadonnées) dans un réseau P2P • Indépendance au réseau P2P • Services de « type BD », au-delà du partage de fichiers et mots-clés • Application initiale : communautés d’intérêt • Infrastructure (facile à déployer) • Etudier les dépendances entre problèmes à différents niveaux • Projet BD et Système Répartis

4. Plan • Accès aux ressources distribuées • Aide au travail collaboratif • Aspects sémantiques • Déploiement, Simulation, Tests • Applications • Fonctionnement • Coopérations • actions • Focus : • Réplication optimiste et P2P • Bases de données et mémoire partagée répartie à grande échelle • Résultats quantitatifs et qualitatifs • Perspectives

5. Accès aux ressources distribuéesrequêtes et transactions • Médiation équitable : • allocation requêtes pour satisfaire consommateurs et producteurs, équilibrer la charge, inciter les utilisateurs • Requêtes Top-k : • Retrouver les k résultats les + pertinents au plus vite • Avec ou sans DHT, généralisation aux listes • Traitement des flots • Requêtes continues de jointure • Utiliser les pairs pour augmenter capacité mémoire • Réplication pessimiste et indexation • DHT répliquée : plusieurs fonctions de hachage, valeur la plus courante • Utilisation du service de partage transparent de données JuxMem : routage et contrôle de concurrence/fraîcheur, équilibrage de charge • Contrôle de concurrence optimiste/fraîcheur XML • Détection de conflits / code transactions, mesures : structure, texte,… • Services BD sur JuxMem • Vers un SGBD en mémoire réparti à grande échelle • Représentation des données relationnelles, index, transactions

6. P2P et Recherche d’InformationAspects sémantiques • Evaluation sémantique de requêtes • Indexation des concepts : contenu et requêtes • Aide au routage (concepts homogènes) : voisins sémantiquement proches, diffusion des index • Aide à l’interprétation (concepts hétérogènes) : ontologies différentes selon les pairs + mappings diffusés • Caractérisation des systèmes RI en P2P • Connaître les « bonnes » conditions d’utilisation d’un mécanisme P2P (routage, maintien de la cohérence) • Identifier les paramètres caractérisant une application • Simulations « exhaustives » : jeux de test appropriés

7. Aide au travail collaboratifRéplication optimiste P2P • Réplication optimiste : • Les différents participants proposent des actions (tentative) • Contraintes entre actions (conflit, atomicité, dép. causale) • Trouver un ordonnancement commun des actions respectant les contraintes (Icecube) • En P2P : • Protocole de validation asynchrone adapté au P2P vs.parallélisation d’Icecube • Réplication partielle • Solution basée sur transformées opérationnelle (XWiki)

8. Déploiement, simulation, tests • Outils génériques de déploiement • Adage : applications multi-middleware (ex. JXTA+Corba), description fonctionnelle et ressources • Cordage : gestion automatique des ressources • Systèmes P2P difficiles à simuler et à tester • Très grand nombre de pairs volatiles • Réseau difficile à modéliser, à contrôler • Simulation • Redéfinir protocoles PeerSim pour s’adapter à RI • Architecture générique + extensions pour RI • Tests • Test case = séquences d’actions • Contrôle de la volatilité et synchronisation des actions • Déploiement automatique et passage à l’échelle

9. Applications • Edition collaborative • Recherche d’information • Système de surveillance environnement • Systèmes de réservation en ligne • Communautés Web2.0

10. Fonctionnement • Organisation • Année 1: • réunions plénières et début des coopérations • Année 2 et 3 : • Poursuite des coopérations, réunions de travail • Réunions à thème (BD et DSM, sémantique, … ) • 4 workshops (invitations et sélection) • Personnel recruté (hors thèses) • Ingénieur (Paris, JuxMem) • PostDoc (LIP6, CC et XML. Regal, travail collaboratif)

11. Coopérations • Internes : • Réconciliation sémantique P2P (Régal, Atlas) • JXTA (Atlas-Paris : infrastructure, LIP6-Paris : JuxMem) • SGBD et DSM (LIP6, Paris) • Avec autres projets: • Réplication P2P (ARC Recall et Euro IST Grid4all) • Contrôle de concurrence XML (WebContent, AXML) • Service de partage de données JuxMem (projet GDS, ACI MD 2003-2006 )

12. Actions • JTE « réplication et cohérence des données sur réseaux p2p » • Conjointement avec ARC RECALL • Paris, 2007 • Workshop « Gestion de données en P2P » • Invités : A.M. Kermarrec, S. Abiteboul, P. Sens, J. Ferrié • Le Croisic, 2007 • Workshop DaMaP@EDBT • Data Management in P2P systems • 40 participants en 2008 • Nantes 2008, Saint-Pétersbourg 2009 • Workshop HPDGrid@Vecpar 2008 • Data Management in Grid and P2P Systems • Toulouse, Juin 2008

13. Focus 1 : P2P Semantic Reconciliation • Most existing P2P replication solutions are not concerned with the application and are single master approaches. • Why Semantic Reconciliation [Shapiro et. al 2001] ? • Multi-Master approach, necessary to scale up • Provides flexibility (application dependent) • Supports disconnections • Two Approaches • P2P-Reconciler (Lina/Atlas-Gdd) • Telex (Inria Rocquencourt/Regal)

14. P2P collaborative work • Share documents • Multiple masters • Different locations, times • Issues: • Disconnected operation • Detect & resolve conflicts shared document Ruby Marc Pierre

15. Introduction to Semantic Reconciliation • Action: application-specific operation • R(K, A, B): R relational table; K key attribute • Actions • a11: update R set A=a1 where K=k1 • a21: update R set A=a2 where K=k1 • a22: update R set B=b1 where K=k1 • Constraint: application invariant • Example: MutuallyExclusive(a11, a21) • Types: system-defined, user-defined • Cluster: set of actions related by constraints • C1 = {a11, a21}, C2 = {a22} • Schedule: list of ordered actions • S = [a11, a22]

16. P2P-Reconciler Approach • Problem definition • Given a set of updatable data objects that are shared by a virtual community through a P2P network, our goals are: • Assure eventual consistency among replicas in the presence of lazy multi-master replication • Provide a scalable and highly available replication solution with acceptable performance

17. Semantic Reconciliation in P2P Systems Updates must preceed deletes Application example: P2P text editing

18. P2P Reconciler • Reconciliation algorithm is distributed in 6 steps over a DHT • Reconciliation data distributed over 4 reconciliation objects (e.g action log) • Provider node : node assigned one RO based on its DHT identifier • Reconciler node: node involved in one or more reconciliation steps • Accessing and processing data held by providers • Executing reconciliation steps in parallel • Providers nodes are established by indexing reconciliation objects identifiers on the DHT • Important Optimizations for Improving Response Times • Limiting the number of reconcilers • Choice of the best Reconcilers nodes using a Cost Model • Choosing the nodes with best costs for accessing providers • Topology aware approach:choice of providers placement • Network latencies and bandwidths are taken into account • Optimizations are useful for any distributed algorithm for P2P collaborative applications

19. P2P-Reconciler at work Reconciler (Step 3) 13 Action Summary Schedule 12 15 Clusters Groups Action Log Node Allocation 9 1 Groups Groups Actions 8 Clusters 2 Clusters Set Reconciler (Step 2) 5 Reconciler (Step 3) • Some nodes are chosen to be Reconcilers for specific steps • Reconciler nodes work on independent data (e.g. independent groups) and may execute different steps • P2P liveness relies on the DHT fonctionalities

20. Contributions • Design of a replication service for APPA • Algorithm for distributed semantic reconciliation • Reconciliation protocol for P2P networks • Cost-based node allocation • Topology-aware reconciliation • Validation through simulation and prototyping in a cluster of 128 nodes • Others: UMS et KTS (P2P-LTR)

21. Experimental Results Wrt. the number of reconcilers As the workloadand the number of reconcilersincrease, the reconci-liation time remains stable P2P-reconciler-TA increases the performance of P2P-reconciler by a factor of 2

22. Telex semantic store forcollaborative applications • Separation of concerns: • Telex handles replication, conflicts, consistency • Developers focus on application logic • Conflict = app. invariant violated: • Action: reified operation • Constraint: reified invariant • Decentralised • Seamless integration in file system

23. How Telex works • Application stores document in FS: • Log = actions + constraints • Multilog = Directory + 1 log file / user • Consistency + locality • Conflict: Telex computes proposals • Conflict-free schedule • Local view • Decentralised commitment

24. Collaborative calendarMake appointment appt Shared Calendar Application +action(appt) Telex Semantic Store open("cal") append File system

25. Collaborative calendarReceive another appointment Shared Calendar Application getCstrt +cstrt(antg) Telex Semantic Store signal File system append

26. Collaborative calendarDetect & display conflict conflict Shared Calendar Application sched Telex Semantic Store File system

27. Focus 2 : bases de données et mémoire partagée répartie à grande échelle • Collaboration BD (LIP6) - PARIS (Irisa) • BD: expertise en bases de données • PARIS: systèmes de partage transparent de de données à grande échelle • Plate-forme JuxMem, basée sur la bibliothèque P2P JXTA de Sun Microsystems • Deux axes: • Partager les données via JuxMem • Partager les meta-données via JuxMem • Cadre de mise en œuvre de la collaboration • 2 stages de master de recherche • 1 thèse

28. JuxMem: un service de partage de donnéesà grande échelle basé sur des techniques P2P • But: partage transparent de données entre composants d'applications réparties à grande échelle, notamment sur des grilles • Echelle: 103-104 noeuds • Localisation et transfert transparents des données • Cohérence des données réparties • Tolérance aux fautes et à la volatilité Solution: approche hybride JuxMem = MVP + P2P • Plate-forme configurable : protocoles de cohérence et de réplication • Basée sur la bibliothèque JXTA de Sun Microsystems: http://www.jxta.org/ Composants de l’application Service de partage de données Mise à jour write read read Transfert Copie Service de partage des données http://juxmem.gforge.inria.fr/

29. Groupe auto-organisant Gestion de groupes Multicast atomique Consensus Détecteur de fautes JuxMem: une architecture en couches JuxMem API 3 Protocoles de cohérence 2 Protocoles de tolérance aux fautes JuxMem core (juk) Stockage en mémoire vive 1 Communication Découverte

30. Groupe auto-organisant Gestion de groupes Multicast atomique GDG Consensus Data group D Détecteur de fautes LDG LDG Client LDG Le groupe de données de JuxMem: un groupe auto-organisant, tolérant aux fautes • Chaque donnée est gérée par un groupe auto-organisant hiérarchique • Au niveau d’une grappe: Local Data Group (LDG) • Au niveau d’une fédération de grappes: Global Data Group (GDG) GDG : Global Data Group LDG : Local Data Group

31. Idée : utiliser JuxMem pour construireun SGBD réparti à grande échelle

32. GDG GDG Data group D1 Data group D2 LDG LDG LDG LDG Client Client LDG LDG Mise en œuvreRéprésentation d’une base de données

33. Un SGBD basé sur un service de partage transparent de données réparties: repères • Papier commun à HiPerGRID 2008 • Abdullah Almousa Almaksour, Gabriel Antoniu, Luc Bougé, Loïc Cudennec and Stéphane Gançarski. Building a DBMS on top of the JuxMem Grid Data-Sharing Service. In Proc. HiPerGRID Workshop, Brasov, Romania, September 2007. • Stages de master de recherche à l’Irisa (Rennes) • Abdullah Almaksour (été 2007) • SGBD sur JuxMem: prototype préliminaire • Marius Moldovan (été 2008) • Intégration de l’approche dans BerkeleyDB • Thèses en cours à l’Irisa (Rennes) • Bogdan Nicolae (2007-2010) • BlobSeer: support pour le partage transparent de données de très grande taille (fragmentation, accès à grain fin) • Diana Moise (2008-2011) • Utilisation de BlobSeer pour le support efficace des applications collaboratives à bases de données

34. Partager les méta-donnéesvia JuxMem (2ème axe) • Situation • Données massives : 10 000 SGBD relationnels • Réplication partielle des BD, accès parallèle aux BD répliquées • Charge transactionnelle intensive • 100 000 applications clientes  débit de 100 à 1000 TPS • Pas de transaction multi-bases • Toute transaction est traitée entièrement sur une BD • Router chaque transaction vers la BD la plus rapide • Exigence • Performance et disponibilité décentraliser le routage • Données obsolètes tolérées  mesurer la fraicheur d’une BD • Contrôler le routage • Connaître précisément quelles transactions modifient une donnée • Solution • Catalogue réparti pour router des transactions à large échelle

35. Méta-données : localise les répliques trace des transactions Shared Distributed Directory Architecture globale Applications Clientes A1 Am Transactions Catalogue réparti Routeurs de Transactions RT1 RTn CD1 CDk Transactions BD Répliquées B1 Bp

36. Catalogue réparti • Contenu : Placement et fraîcheur des répliques • Trace : pour chaque relation Ri et chaque copie Rij • Liste des transactions exécutées mais non validées partout • Listes des transactions à traiter ultérieurement • Catalogue fragmenté • Un fragment par relation Rj • Chaque fragment tient dans un bloc mémoire • Accès au catalogue • Opération unitaire : lecture/écriture d’un bloc mémoire • Cohérence du catalogue : contrôle par verrouillage offert par JuxMem • Grain d’un verrou = un bloc • Réduire le blocage : ne pas verrouiller trop longtemps • Verrouiller pendant le choix de Bi, avant de traiter T • Relâcher le verrou pendant l’exécution de T • Reprendre le verrou après la fin de T pour mettre à jour le catalogue

37. Routage basé sur le coût et la fraîcheur • Pour chaque base Bi telle que Bi contient toutes les Ri accédées par T • Estimer le coût de rafraichir Bi + coût de T en fonction de la charge de Bi • Trier les {Bi} par coût décroissant • Choisir B1  Assure l’équilibrage de charge

38. Routage d’une transactiontolérant aux pannes • Pannes dites ‘fail-stop’ • Pas de fautes byzantines • Il y a toujours au moins un routeur dispo • Nœuds concernés • Les nœuds applicatifs, les routeurs, les nœuds BD • la liste des nœuds disponibles est stockée dans le catalogue • Message suivi d'un acquittement Informe l'expéditeur avant expiration d’un timeout • Protocole de routage tolérant les pannes • Garanti qu’une transaction se termine • après plusieurs tentatives si nécessaire

39. Détection d’une panne • Détection adaptée au type de nœud • Application • sans impact sur l’intégrité des données • Routeur • Besoin de détecter rapidement une panne • Détection périodique par heart-beat • Notification immédiate aux autres RT  structurer les RT en anneau • BD • Limiter le surcoût de la détection • Détection après échec d’une demande de traitement • Limiter les fausses suspicions • distinguer une panne de communication d’une panne de BD

40. Efficacité du partagedes métadonnées via JuxMem • Objectifs • Mesurer l’impact du catalogue distribué • Latence d’accès : moins de 25ms • Volume des méta-données • ralentissement de 25% pour 100 répliques par BD • Mesurer le bénéfice pour des cas réalistes • Débit d’un routeur : 40 TPS • Scale-up : 120 TPS avec 3 routeurs • Mesurer l'impact de la gestion des pannes • Validation expérimentale • JuxMem-C + JXTA-C + proto (5000 lignes) • Machines du LIP6 • Un cluster de 20 PC et 20 desktop PC

41. Résultats(quantitatifs) • Plusieurs prototypes dont la plupart sont disponibles en ligne • Publications • 4 chapitres dans des ouvrages collectifs • 7 articles en revues internationales • 36 articles en conférences internationales • 6 articles en publications nationales • Thèses • 9 thèses (quasi) soutenues pendant le projet • 5 thèses en cours • 2 HDR (+1)

42. Résultats(qualitatif) • Objectifs atteints • Synergie Bases de données-Système répartis : vision globale des problèmes • Coopérations internes et externes • Visibilité nationale et internationale • Large spectre mais centré sur gestion de données P2P • Applications • Objectifs non ou partiellement traités • Services de base : existant suffisant • Intégration globale : trop prématuré, JXTA ? • Communautés virtuelles et regroupement des pairs : abandon thèse J. Tanguy

43. Perspectives • Fin des thèses en cours • DaMaP 2009 • Nouveaux projets connexes : • Acceptés • ANR DataRing (2009-2011) : services réseaux du futur • ANR Roses (2008-2010) : gestion de flux RSS • Soumission • ANR blanc sur aspects théoriques de la réplication • ANR systèmes embarqués et grandes infrastructures sur partage de données P2P avec préservation confidentialité

44. Questions ?

45. Vue globale Réseau P2P pertinent,frais/courant, complet équitable,rapide ? groupe groupe Màj,synchro? Indexation, routage, sémantique groupe Infrastructure, stockage, réplication, simulation, test, déploiement