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 SIGMODInternational conference on management of data
Présenté par : Anis Krichen
DISIC : Metacomputing PeerOLAP
2
Plan
Introduction Contexte L’architecture du réseau PeerOLAP Présentation technique
Le nœud PeerOLAP Les algorithmes d’optimisation de requêtes Politique de cache
Études expérimentales et résultats Conclusion - ouvertures
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
DISIC : Metacomputing PeerOLAP
4
Contexte
Les DW traitent des vues multidimensionnelles de données (measures, dimensions, levels)
O(2d) 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
DISIC : Metacomputing PeerOLAP
5
Contexte
Une manière intéressante d’accé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
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
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
DISIC : Metacomputing PeerOLAP
8
Contexte
Décomposition de l’espace multidimensionnel en chunks Le plus petit morceau d’information 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 qu’ils sont
» Disponibles sur le cache» Non disponibles
Le système demandera au DW les chunks manquants Algorithmes d’admission et de remplacement similaires à
ceux de watchman.
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 l’espace» Pas d’overlapping des résultats dans le cache
Les systèmes présentés jusqu’ici Adoptent des architectures client-serveur traditionnelles Pas de coopération entre caches Pas de prise en compte du facteur réseau
DISIC : Metacomputing PeerOLAP
10
Contexte
Proposition d’une 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
DISIC : Metacomputing PeerOLAP
11
Contexte
PeerOLAP diffère sur plusieurs aspects: Pas d’infrastructure 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
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 s’occupe essentiellement du problème du placement des données Sphères de coopération Publicité : flooding des vues
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 s’aligner 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 d’autres systèmes.
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 Pi 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 à Pi pour une requête Pi peut répondre (localement) à la requête (ou une partie)
Sinon il diffuse la requête à ses voisins
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 d’agir 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
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
à l’origine de la requête Évite de surcharger le DW avec le même message
P2 ne sait pas combien de nœuds vont répondre Attends tous les chunks ou l’expiration d’un timer Les chunks manquant seront demandés au DW (last option)
P2 décide ensuite quels chunks garder dans son cache Utilisation des location independant global name lookup
(LIGLO) servers Maintient d’une liste des nœuds (DW, location, speed..) contacte LIGLO pour avoir une liste de voisins potentiels
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 d’assurer 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 l’architecture, traitement des
requêtes, algorithmes de cache et de reconfiguraton de réseau
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
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é d’avoir un agent mobile si l’utilisateur
est un habitué Application cliente constamment installée
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
d’admission et de remplacement dans le cache La plate-forme P2P : communication bas niveau, responsable
de la reconfiguration du réseau
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 l’avantage qu’on a, à stocker un chunk
Dans un cas extrême, le nœud pourrait servir uniquement de cache à ses voisins et n’exécuter
aucune application cliente
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(P→Q) : coût d’établissement de la connexion» k : nombre de chunks envoyés» Tr(Q→P) : 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:
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 d’un 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 l’effort fourni pour construire le plan d’exécution
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 Call
» P regarde son cache local et en déduit• Clocal : les chunks présents
• Cmiss : les chunks manquant
» P envoie un message à ses voisins (Q1…Qk) leur demandant Cmiss
• Si Qi possède un sous ensemble de Cmiss
• Il calcule le coût Ct(ci, Q→P) et renvoie l’estimation à P• Si un nœud ne possède aucun des chunks, il ne répond pas
» Dans tous les cas Qi fait suivre la requête sur la totalité du Cmiss jusqu’à atteinte du nombre max de hop
Étape 3
DISIC : Metacomputing PeerOLAP
25
Traitement des requêtes
EQP (suite)» P reçoit les réponses pendant un temps t
» Cpeer le sous ensembles de Cmiss trouvé dans PeerOLAP
• Sélection d’un chunk ci et du nœud Qi qui peut le fournir avec le coût le plus bas
• Sélection d’un chunk cj et du nœud Qj associé
• Si cj disponible sur Qi, on vérifie quel est le moins cher
T({ci,cj},Qi) ou T(ci,Qi) + T(cj, Qj)
• On répète la même chose pour le reste des chunks de Cpeer
» P initialise des connexion directes avec les nœuds choisis dans le plan d’exécution, ces derniers renvoient les chunks qui n’ont pas été effacés entre temps, soit Cevicted les chunks effacés
» Le jeu CDW de chunks sera demandé directement au DW
» CDW = Cmiss – (Cpeer – Cevicted)
DISIC : Metacomputing PeerOLAP
26
Traitement des requêtes
EQP (suite)» P construit la réponse et la renvoie à l’utilisateur» Les nouveaux chunks sont envoyés au module de contrôle
de cache» Reconfiguration du réseau si requise
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 Q1…k
» Mais ces derniers ne diffusent l’information qu’à leurs voisins les plus ‘avantageux’
» De plus si Qi peut répondre à une partie des chunks, il les retire du message diffusé
» Le processus est répété jusqu’à hmax hops
Si k voisins
» O(k.hmax) messages pour LQP
» O(khmax) messages pour EQP
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 d’un résultat Ensuite on utilise une généralisation de LRU
» ClockBenefit Ici on définit le benefit d’un chunk comme suit:
H(PQ) : nombre de sauts de P à Q (a:constante de overhead)
Algorithme d’admission et de remplacement Least Benefit First (LBF) : LRU-like
DISIC : Metacomputing PeerOLAP
29
Politique de cache
LBF
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 d’un 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 n’appartiennent pas forcément à même organisation)
» Autonomie : choix des ressources que l’on veut fournir
DISIC : Metacomputing PeerOLAP
31
Politique de cache
Hit Aware Caching Policy (HACP) Contraire de ICP
HACP prend en compte les demandes des voisins» Afin d’assurer que les caches coopèrent» Dans le but de minimiser le coût total des requêtes
HACP augmente le poids d’un chunk demandé par un voisin» Plus de chances qu’il le garde» Et assure une disponibilité peu coûteuse à ses voisins
DISIC : Metacomputing PeerOLAP
32
Politique de cache
Voluntary Caching Essaye d’exploiter 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
DISIC : Metacomputing PeerOLAP
33
Politique de cache
Reconfiguration du réseau Création d’un 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
DISIC : Metacomputing PeerOLAP
34
Etudes expérimentales
2 implémentations Utilisation d’un 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
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
DISIC : Metacomputing PeerOLAP
36
Etudes expérimentales
PeerOLAP vs Client-Side-Cache architecture
DISIC : Metacomputing PeerOLAP
37
Etudes expérimentales
Une configuration plus réaliste ncmax = 4 , hmax = 3, cache size = 1%, groupes de 10 noeuds
DISIC : Metacomputing PeerOLAP
38
Etudes expérimentales
Évaluation des stratégies d’optimisation de requêtes
DISIC : Metacomputing PeerOLAP
39
Etudes expérimentales
Évaluation des politiques de cache
DISIC : Metacomputing PeerOLAP
40
Etudes expérimentales
Effets de la réorganisation du réseau
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 d’optimisations de requêtes Politiques de cache (coopération, pas de réplication inutile) Mécanismes de reconfiguration
DISIC : Metacomputing PeerOLAP
42
Ouvertures
Essayer de trouver une possibilité de considérer des chunks avec un niveau d’aggrégation différents de celui de la requête. Trouver un résultat sur le nœud en faisant plus
d’aggré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