La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP Results Panos Kalnis, Wee Siong Ng, Beng Chin Ooi,Dimitris.

Présentations similaires


Présentation au sujet: "DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP Results Panos Kalnis, Wee Siong Ng, Beng Chin Ooi,Dimitris."— Transcription de la présentation:

1 DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP Results Panos Kalnis, Wee Siong Ng, Beng Chin Ooi,Dimitris Papadias, Kian-Lee Tan 2002 ACM SIGMOD International conference on management of data Présenté par : Anis Krichen

2 DISIC : Metacomputing PeerOLAP 2 Plan Introduction Contexte Larchitecture du réseau PeerOLAP Présentation technique Le nœud PeerOLAP Les algorithmes doptimisation de requêtes Politique de cache Études expérimentales et résultats Conclusion - ouvertures

3 DISIC : Metacomputing PeerOLAP 3 Introduction Importance de la prise de décision rapide et efficace Multiplication des ERP (Enterprise Resource Planing) Data warehouses (Entrepôts de données): DW OLAP (On-Line Analytical Processing) Requêtes sur Data Warehouses Diminuer le coût des requêtes En essayant de regrouper les utilisateurs ayant les mêmes besoins

4 DISIC : Metacomputing PeerOLAP 4 Contexte Les DW traitent des vues multidimensionnelles de données (measures, dimensions, levels) O(2 d ) requêtes group-by possibles Avec d attributs de dimensions (formant le data cube) Search Lattice : graphe orienté Les nœuds représentent des requêtes group-by Data cube lattice. Dimensions : Product, Supplier and Costumer

5 DISIC : Metacomputing PeerOLAP 5 Contexte Une manière intéressante daccélérer OLAP Pré calculer quelques agrégats Les stocker comme étant des vues Recherches sur des algorithmes Concernant le problème du choix de la vue à pré calculer Algorithmes gourmands Approche statique approche dynamique inspirée du cache sémantique de données Au lieu de stocker des pages physiques ou des identifiants On stocke le résultat de requêtes précédentes avec leur description sémantique

6 DISIC : Metacomputing PeerOLAP 6 Contexte Un gestionnaire de cache sémantique : WATCHMAN Spécialement conçu pour OLAP Le système stocke dans le cache Le résultat de la requête La requête Résolution des requêtes suivantes si correspondances exactes entre requêtes

7 DISIC : Metacomputing PeerOLAP 7 Contexte Dynamat : un autre gestionnaire de cache OLAP Mémorise des fragments au lieu de résultat de requête Fragments : agrégats de résultats de requête granularité plus fine que les vues Sinon, même politique de cache que watchman

8 DISIC : Metacomputing PeerOLAP 8 Contexte Décomposition de lespace multidimensionnel en chunks Le plus petit morceau dinformation dans le cache Quand une requête est lancée Le système génère le jeu de chunks requis Le partage en 2 sous ensembles selon quils sont » Disponibles sur le cache » Non disponibles Le système demandera au DW les chunks manquants Algorithmes dadmission et de remplacement similaires à ceux de watchman.

9 DISIC : Metacomputing PeerOLAP 9 Contexte PeerOLAP utilise aussi des résultats sous forme de chunk Mise à part la granularité fine, 2 avantages: Uniformité des régions sémantiques » Permet combinaisons des chunks pour répondre aux nouvelles requêtes Bonne utilisation de lespace » Pas doverlapping des résultats dans le cache Les systèmes présentés jusquici Adoptent des architectures client-serveur traditionnelles Pas de coopération entre caches Pas de prise en compte du facteur réseau

10 DISIC : Metacomputing PeerOLAP 10 Contexte Proposition dune approche middleware cache des résultats OLAP fourni par un Web proxy-server Les proxys ne gèrent pas le cache de données dynamiques Applet pour gérer le dynamisme des données Inconvénient : proxy ne gère pas les données de 2 DW en même temps Extension de cette idée utilisant une infrastructure dédiée OCS (OLAP Cache Servers) Serveurs proxy optimisés pour les données OLAP Peut former un réseau et coopérer Granularité grossière (vue entière) Flou quand à la manière utilisée pour gérer plusieurs DW

11 DISIC : Metacomputing PeerOLAP 11 Contexte PeerOLAP diffère sur plusieurs aspects: Pas dinfrastructure mid-tier pour le cache de OLAP Le réseau PeerOLAP est dynamique ( OCS) Granularité plus fine de cache (permet réponses partielles de plusieurs nœuds) PeerOLAP peut cacher des données issues de plusieurs DW en même temps Les attentes du systèmes PeerOLAP correspondent bien aux caractéristiques offertes par la technologie P2P

12 DISIC : Metacomputing PeerOLAP 12 Contexte Piazza : premier système traitant des problèmes de gestion de base de données en environnement P2P Chaque nœud peut remplir les 4 rôles suivants: Data origin : fournit le contenu original Storage provider : stocke les vues Query evaluator : utilise sa ressource CPU pour évaluer une requête Query initiator : lance les nouvelles requêtes au système Piazza soccupe essentiellement du problème du placement des données Sphères de coopération Publicité : flooding des vues

13 DISIC : Metacomputing PeerOLAP 13 Contexte Pour PeerOLAP: Une granularité plus fine pose des problèmes de surcharge aux protocoles de publicité. PeerOLAP étant un système de cache, il ne peut réutiliser que les données qui ont déjà été demandées PeerOLAP adapte dynamiquement son comportement et sa structure de réseau pour saligner sur la charge de travail. Puisque PeerOLAP se concentre sur les requêtes OLAP » Possibilité de faire plusieurs optimisations qui ne seraient pas applicables sur dautres systèmes.

14 DISIC : Metacomputing PeerOLAP 14 Architecture du réseau PeerOLAP Le réseau PeerOLAP est constitué de nœuds Qui accèdent aux DW Et posent leurs requêtes Chaque nœud P i a un cache local et implémente des mécanismes Pour publier le contenu de son cache Pour mettre à disposition ses capacités de calcul Les autres nœuds peuvent se connecter à P i pour une requête P i peut répondre (localement) à la requête (ou une partie) Sinon il diffuse la requête à ses voisins

15 DISIC : Metacomputing PeerOLAP 15 Architecture du réseau PeerOLAP Dans les deux cas le résultats revient directement au nœud initiateur de la requête Le but de PeerOLAP est dagir comme un grand cache où tous les nœuds offrent la possibilité de réduire le coût des requêtes Un réseau PeerOLAP typique

16 DISIC : Metacomputing PeerOLAP 16 Architecture du réseau PeerOLAP Nombre max de hop : pour éviter le flooding Une requête au DW ne peut être initiée que par le nœud à lorigine de la requête Évite de surcharger le DW avec le même message P 2 ne sait pas combien de nœuds vont répondre Attends tous les chunks ou lexpiration dun timer Les chunks manquant seront demandés au DW (last option) P 2 décide ensuite quels chunks garder dans son cache Utilisation des location independant global name lookup (LIGLO) servers Maintient dune liste des nœuds (DW, location, speed..) contacte LIGLO pour avoir une liste de voisins potentiels

17 DISIC : Metacomputing PeerOLAP 17 Architecture du réseau PeerOLAP Les nœuds voisins initiaux ne sont pas optimaux Chaque nœud implémente un mécanisme de contrôle des voisins actuels Le but est dassurer les coûts les plus bas Les nœuds ayant des requêtes similaires devraient être voisins Paramètre système k : maximum de voisins Optimisation du problème des voisins par un cache de second niveau Suite : composants de larchitecture, traitement des requêtes, algorithmes de cache et de reconfiguraton de réseau

18 DISIC : Metacomputing PeerOLAP 18 Le nœud PeerOLAP 2 couches: Apllication Cache La couche application Connaît la structure du DW Et la sémantiques des données Dans cette implémentation cette couche Est construite comme un agent java envoyé par le DW Cet agent mobile se connecte ensuite à la couche du cache Et envoie à travers cette dernière toutes les requêtes de données

19 DISIC : Metacomputing PeerOLAP 19 Le nœud PeerOLAP PeerOLAP fournit un environnement où Plusieurs agents mobiles différents peuvent cohabiter Et effectuer leurs tâches sur le même nœud Cette polyvalence le rend très extensible et puissant Ceci dit, pas obligé davoir un agent mobile si lutilisateur est un habitué Application cliente constamment installée

20 DISIC : Metacomputing PeerOLAP 20 Le nœud PeerOLAP La couche cache: 3 modules Cache local : organisé comme un fichier de chunks Module de contrôle de cache : qui implémente les algorithmes dadmission et de remplacement dans le cache La plate-forme P2P : communication bas niveau, responsable de la reconfiguration du réseau

21 DISIC : Metacomputing PeerOLAP 21 Le nœud PeerOLAP Autres avantages de la séparation en deux couches En isolant le cache de la sémantique des données » Possibilité de stocker des données issues de plusieurs DW » Chaque chunk a un ID unique Responsabilité de la couche application De demander le jeu de chunks correct De définir lavantage quon a, à stocker un chunk Dans un cas extrême, le nœud pourrait servir uniquement de cache à ses voisins et nexécuter aucune application cliente

22 DISIC : Metacomputing PeerOLAP 22 Modèle de calcul de coût Chunk c avec une taille size(c) en tuples S(c,P) le coût de calcule de c dans le nœud P S(c,P) = a.size(c) (no aggregations of chunks) Le coût du réseau pour Transférer c de Q à P : Où: » Cn(PQ) : coût détablissement de la connexion » k : nombre de chunks envoyés » Tr(QP) : taux de transfert entre Q et P Le coût total de réponse à c au nœud P en passant par le nœud Q:

23 DISIC : Metacomputing PeerOLAP 23 Traitement des requêtes Ici on se concentre sur comment Localiser, accéder et cacher les chunks On considère que les DW sont accédés en lecture seule Si changement du contenu du DW Broadcast dun message précisant le problème survenu Timer pour chaque chunk calculé On va présenter ici deux méthodes de traitement de requêtes Eager Query Processing (EQP) Lazy Query Processing (LQP) Ils diffèrent au niveau de leffort fourni pour construire le plan dexécution

24 DISIC : Metacomputing PeerOLAP 24 Traitement des requêtes Eager Query Processing (EQP) Un utilisateur émet une requête q au nœud P, voici comment EQP la traite: » q est décomposée en chunks pour former le jeu C all » P regarde son cache local et en déduit C local : les chunks présents C miss : les chunks manquant » P envoie un message à ses voisins (Q 1 …Q k ) leur demandant C miss Si Q i possède un sous ensemble de C miss Il calcule le coût Ct(ci, QP) et renvoie lestimation à P Si un nœud ne possède aucun des chunks, il ne répond pas » Dans tous les cas Q i fait suivre la requête sur la totalité du C miss jusquà atteinte du nombre max de hop Étape 3

25 DISIC : Metacomputing PeerOLAP 25 Traitement des requêtes EQP (suite) » P reçoit les réponses pendant un temps t » C peer le sous ensembles de C miss trouvé dans PeerOLAP Sélection dun chunk c i et du nœud Q i qui peut le fournir avec le coût le plus bas Sélection dun chunk c j et du nœud Q j associé Si c j disponible sur Q i, on vérifie quel est le moins cher ­ T({c i,c j },Q i ) ou T(c i,Q i ) + T(c j, Q j ) On répète la même chose pour le reste des chunks de C peer » P initialise des connexion directes avec les nœuds choisis dans le plan dexécution, ces derniers renvoient les chunks qui nont pas été effacés entre temps, soit C evicted les chunks effacés » Le jeu C DW de chunks sera demandé directement au DW » C DW = C miss – (C peer – C evicted )

26 DISIC : Metacomputing PeerOLAP 26 Traitement des requêtes EQP (suite) » P construit la réponse et la renvoie à lutilisateur » Les nouveaux chunks sont envoyés au module de contrôle de cache » Reconfiguration du réseau si requise

27 DISIC : Metacomputing PeerOLAP 27 Traitement des requêtes Lazy Query Processing (LQP) Ici on essaie de réduire le nombre de nœuds visités LQP est similaire à EQP excepté pour létape 3 » P envoie la requête à tous ses voisins Q 1…k » Mais ces derniers ne diffusent linformation quà leurs voisins les plus avantageux » De plus si Q i peut répondre à une partie des chunks, il les retire du message diffusé » Le processus est répété jusquà h max hops Si k voisins » O(k.h max ) messages pour LQP » O(k hmax ) messages pour EQP

28 DISIC : Metacomputing PeerOLAP 28 Politique de cache Afin de définir la politique de contrôle de cache On définit une mesure B() du Benefit ou avantage » Et ce pour chaque chunk c au nœud P Cette valeur est fonction du coût du calcul dun résultat Ensuite on utilise une généralisation de LRU » ClockBenefit Ici on définit le benefit dun chunk comme suit: H(PQ) : nombre de sauts de P à Q (a:constante de overhead) Algorithme dadmission et de remplacement Least Benefit First (LBF) : LRU-like

29 DISIC : Metacomputing PeerOLAP 29 Politique de cache LBF

30 DISIC : Metacomputing PeerOLAP 30 Politique de cache Isolated Caching Policy (ICP) P met son cache à disposition Il utilise les algorithmes cités Il ne compte pas les requêtes venant des autres nœuds Il ne remet pas à sa valeur originale le poids dun chunk demandé par un voisin Même si ICP ne suit pas une logique de collaboration » Il colle assez bien à la philosophie des systèmes P2P (les nœuds nappartiennent pas forcément à même organisation) » Autonomie : choix des ressources que lon veut fournir

31 DISIC : Metacomputing PeerOLAP 31 Politique de cache Hit Aware Caching Policy (HACP) Contraire de ICP HACP prend en compte les demandes des voisins » Afin dassurer que les caches coopèrent » Dans le but de minimiser le coût total des requêtes HACP augmente le poids dun chunk demandé par un voisin » Plus de chances quil le garde » Et assure une disponibilité peu coûteuse à ses voisins

32 DISIC : Metacomputing PeerOLAP 32 Politique de cache Voluntary Caching Essaye dexploiter les ressources sous utilisées Empêche toute requête fournit par DW dêtre perdue Cette politique se greffe sur » ICP : vICP » HACP : vHACP

33 DISIC : Metacomputing PeerOLAP 33 Politique de cache Reconfiguration du réseau Création dun ensemble virtuel de nœuds voisins ayant les mêmes caractéristiques La logique est de fournir au nœud P un ensemble de voisins susceptibles avec une grande probabilité de lui fournir les chunks manquants. Évite un grand parcours du réseau Accéder à tous les nœuds serait coûteux Cas spécial de cache

34 DISIC : Metacomputing PeerOLAP 34 Etudes expérimentales 2 implémentations Utilisation dun prototype » Un DW dans une ville A » 10 nœuds dans une ville B Test des aspects fondamentaux et déduction de paramètres en conditions réelles Puis utilisation de ces paramètres dans un simulateur » Comportements de PeerOLAP dans différentes situations

35 DISIC : Metacomputing PeerOLAP 35 Etudes expérimentales La mesure utilisée pour comparer les résultats est Le Detailed Cost Saving Ratio (DCSR) wcost(qi) : coût total de la réponse à qi dans le pire cas cost(qi) : coût réalisé par le système (a) PeerOLAP (b)Client-Side-Cache (c) one large cache (d) Clients sans cache

36 DISIC : Metacomputing PeerOLAP 36 Etudes expérimentales PeerOLAP vs Client-Side-Cache architecture

37 DISIC : Metacomputing PeerOLAP 37 Etudes expérimentales Une configuration plus réaliste nc max = 4, h max = 3, cache size = 1%, groupes de 10 noeuds

38 DISIC : Metacomputing PeerOLAP 38 Etudes expérimentales Évaluation des stratégies doptimisation de requêtes

39 DISIC : Metacomputing PeerOLAP 39 Etudes expérimentales Évaluation des politiques de cache

40 DISIC : Metacomputing PeerOLAP 40 Etudes expérimentales Effets de la réorganisation du réseau

41 DISIC : Metacomputing PeerOLAP 41 Conclusion En général les clients se connectent sur un DW et collecte leur données dans un cache PeerOLAP propose de partager ces caches individuels, ce qui avantagerait tout le monde Système totalement distribué PeerOLAP fait ses preuves comparés au système C-S Techniques doptimisations de requêtes Politiques de cache (coopération, pas de réplication inutile) Mécanismes de reconfiguration

42 DISIC : Metacomputing PeerOLAP 42 Ouvertures Essayer de trouver une possibilité de considérer des chunks avec un niveau daggrégation différents de celui de la requête. Trouver un résultat sur le nœud en faisant plus daggrégation sur les chunks présents » Combinaisons possible augmente de façon exponentielle Algorithme plus sophistiqués pour la reconfiguration du réseau Trouver le parfait voisinage » On ne connaît pas tout le réseau » Connexion souvent volatiles


Télécharger ppt "DISIC : Metacomputing PeerOLAP 1 An Adaptive Peer-to-Peer Network for Distributed Caching of OLAP Results Panos Kalnis, Wee Siong Ng, Beng Chin Ooi,Dimitris."

Présentations similaires


Annonces Google