WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

Mutualisation de requêtes XQuery sur des Flux RSS dans un environnement Pair-à-Pair

( Télécharger le fichier original )
par Mohammed Salah Benamira
Université de Versailles Saint Quentin en Yvelines - Master 2 Recherche 2007
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

CHAPITRE 1 : INTRODUCTION

1 Introduction

Les flux RSS basés sur les concepts XML du W3C constituent une nouvelle approche pour la publication d'informations. Du point de vue utilisateur, la consommation de ces données pose de nouveaux problèmes. En effet, l'utilisateur ne peut ou ne souhaite lire en temps réel l'ensemble des données provenant de ces flux. Un utilisateur peut être rapidement submergé par les données provenant de nombreux flux. Il doit pouvoir se faire aider par des outils qui lui synthétisent une information en tenant compte de la dimension temporelle. Un exemple de requête sur les flux est : «Quels sont les articles sur les jeux olympiques de pékin durant les trois derniers jours ?». Pour cela, il est nécessaire de conserver les flux sur une période de temps [1]. En outre, les requêtes sont fortement répétitives. A chaque nouvel item produit sur un flux RSS, il est nécessaire de recalculer les requêtes définies pour un utilisateur.

Un réseau P2P est utilisé pour les raisons suivantes :

- Répartition de la charge de traitement (si beaucoup de pairs veulent exécuter les mêmes requêtes)

- Fiabilité: ne plus dépendre d'un seul serveur.

- Collaboration : mise en commun de ressources (ex. Requête)

L'objectif du stage est d'étudier l'exécution de quelques requêtes XQuery temporelles bien définies sur plusieurs caches temporels distribués sur plusieurs machines. Un cache temporel permet d'aspirer un flux et de les conserver suivant une fenêtre temporelle. La conservation de ces données permet de faire des requêtes historiques, des requêtes d'agrégats (combien d'article parle des médaillées d'Or en natation).

Chaque cache peut également stocker les flux RSS provenant de plusieurs producteurs. Chaque cache est capable d'exécuter des requêtes XQuery (contient le SGBD eXist). L'utilisation de XQuery est justifiée par sa puissance et sa simplicité comme langage d'interrogation. Pour qu'il y ait une interopérabilité entre les différents caches répartis sur le réseau P2P, Chaque cache stocke également les clés permettant à d'autres utilisateurs d'atteindre les enregistrements pertinents qu'ils recherchent. Ces clés sont similaires aux clés des index traditionnelles (ex. BTree). Les clés indiquent où sont stockés les enregistrements.

Les clés sont calculées par une méthode d'indexation Pair-à-Pair (PàP) (c'est une sorte d'index distribué).

Pour l'exécution d'une requête XQuery temporelle, l'idée est d'utiliser l'index pour isoler les sites contenant les données pertinentes, et d'envoyer aux sites pertinents la requête XQuery. Vu la forte répétition des requêtes XQuery (à chaque arrivé d'un item dans un flux RSS, il faut recalculer le résultat), et pour éviter que tous les pairs exécutent la même requête (de nombreux utilisateurs peuvent s'intéresser aux mêmes sujets), l'idée est de mutualiser ces requêtes sur le réseau P2P. La mutualisation permets un meilleur équilibrage des charges et d'utiliser les ressources sur un réseau de manière plus optimum.

Ce rapport s'articulera donc autour de trois axes :

Tout d'abord, nous présenterons le contexte du stage, le sujet proposé ainsi que les problématiques posées, Ensuite, un état de l'art de quelques travaux qui nous ont inspiré dans la réalisation de ce stage sera décrit.

Enfin, le reste du rapport portera sur l'ensemble du travail effectué : les choix effectués, les résultats obtenus, leurs analyses et les perspectives envisageables.

1.1 Le contexte du stage

Le stage s'inscrit dans le cadre d'un projet ANR appelé ROSES.

Comme base de travail, j'ai utilisé une mini plateforme en pair à pair pour l'interrogation en historique des flux RSS, réalisée par les étudiants d'ISTY3 dans le cadre de leur projet annuel de troisième année. Pour ceci cette mini plateforme stocke de données RSS suivant le temps, pour pouvoir les interroger après [1].

Cependant, la réalisation du mini prototype n'intègre pas les fonctionnalités de mutualisation de requêtes sur le réseau distribué. Ceci est l'objet du présent stage.

L'architecture générale de cette plateforme est un réseau pair à pair avec réseau P2P au centre. Ce réseau est semi réparti. Il sera par la suite totalement réparti sur les pairs. La représentation des composants ci-dessous décrit le mini prototype

Figure 1 : Architecture du mini prototype

Selon la figure ci-dessous, les composants du réseau sont:

Ø les pairs : contiennent la base de données eXist, et aspirent périodiquement des flux RSS.

Ø le réseau P2P (Tour Eiffel) : le contenu des pairs (flux RSS) est publié dans le réseau, pour pouvoir les retrouver. Chaque pair possède une portion de code donnant vie au réseau figurant au centre. Cette portion de code assure les services comme le routage, le stockage de clés, etc.

Ø Le portail web : il permet de commander les pairs à distance. Il permet également de visualiser le comportement des pairs du réseau.

1.2 Fonctionnement du prototype

Si un pair P veut exécuter une requête XQuery Q sur une période T, P doit interroger le réseau P2P en lui fournissant comme paramètres quels : flux, mots clés et période T lui intéressent, le réseau P2P en retour donne à P les adresses IP des pairs pertinents.

Une fois ceci fait, P envoie la requête Q à chacun des pairs pertinents, et enfin le résultat serait l'union des réponses.

1.3 Faiblesses du mini prototype 

L'exécution des requêtes XQuery dans le modèle décrit ci-dessus, engendre plusieurs problèmes :

Ø Si toutes les réponses des pairs pertinents sont identiques (redondance), dans ce cas on augmente inutilement la charge du réseau, donc on risque de l'inonder.

Ø Si d'une manière ponctuelle (ex : Jeux Olympiques), il y a N pairs (N très grand) voulant exécuter la même requête Q, selon la logique de fonctionnement décrite ci-dessus, les N pairs devront faire les mêmes démarches, à savoir : interroger l'indexeur pour isoler les pairs pertinents, envoyer la requête Q à ces mêmes pairs, réaliser l'union des réponses reçues. Ainsi les pairs sources seront vite saturés.

Ø De plus, pour une requête identique issue de deux sites différents, compte tenu des temps de transmissions des données, du temps CPU pour le calcule, il peut s'avérer plus intéressants de calculer qu'une fois, puis de faire profiter du résultat à d'autres.

Il y a un vrai problème de répartition de la charge de traitement des requêtes sur l'ensemble des pairs.

1.4 L'objectif du stage

L'objectif de ce stage est la réalisation d'un prototype pour l'exécution des requêtes XQuery sur des flux RSS dans un réseau pair à pair tout en répartissant la charge de traitement de ces requêtes pour que le réseau s'adapte à la charge, en utilisant deux approches :

Ø Approche e-commerce (meilleures offres) pour résoudre le premier problème [3] (à savoir le choix parmi plusieurs sources possibles)

Ø Mutualisation des requêtes pour résoudre les derniers problèmes

Ces deux approches seront décrites dans le chapitre suivant.

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il existe une chose plus puissante que toutes les armées du monde, c'est une idée dont l'heure est venue"   Victor Hugo