Caches sémantiques coopératifs pour la gestion de

Caches sémantiques coopératifs pour la gestion de données sur grilles
Laurent d’Orazio, Fabrice Jouanot, Cyril Labbé, Claudia Roncancio
Laboratoire d’Informatique de Grenoble
681, rue de la Passerelle, BP. 72, 38402 Saint Martin d’Hères Cedex, France
Adresse électronique : {prénom.nom}@imag.fr
Résumé
Cet article présente une solution de caches sémantiques
coopératifs améliorant les coûts d’évaluation de requêtes
et de transferts de données dans les systèmes de gestion de
données réparties. Cette solution repose sur la séparation
des préoccupations. L’aspect sémantique est d’abord géré
indépendamment de l’aspect coopératif. Les données sont
ensuite gérées à l’aide de deux caches distincts, stockant
séparément les requêtes des objets. L’architecture alors obtenue offre une grande flexibilité, permettant une configuration adaptée à un environnement donné, notamment en
terme de coopération entre caches de requêtes et entre
caches d’objets. La solution est expérimentée dans un intergiciel de gestion de données réparties pour une application en bio-informatique.
Mots clés
Cache, sémantique, coopération, grille de données
1. Introduction
Le partage de données dans des systèmes à grande
échelle est devenu crucial. De nombreux efforts ont été
réalisés et sont menés pour la proposition d’intergiciels efficaces d’interrogation multi-sources largement réparties.
Les performances de tels intergiciels dépendent de nombreux facteurs et sont fortement influencées par les caractéristiques de l’infrastructure matérielle (architectures
de type grille, P2P, etc). Cet article porte sur des techniques de cache dans le contexte de déploiements sur grille
[16]. Nous considérons des grilles légères de type cluster de clusters qui offrent une facilité de déploiement, en
ne prenant par exemple pas en compte les aspects liés à la
sécurité.
Cet article propose une approche originale de caches
sémantiques coopératifs qui cherche à distribuer la
charge de travail et à diminuer les calculs et les transferts de données. Les caches sont déployés sur des
nœuds de la grille et peuvent coopérer entre eux pour
la résolution des défauts de cache. La coopération s’appuie sur une notion générale de proximité entre les caches.
Ainsi un cache peut demander la coopération d’un ou plusieurs caches ”proches” selon certains critères. La proximité peut refléter divers facteurs tels que des distances
géographiques, un éloignement lié à des caractéristiques
matérielles de l’infrastructure informatique (par ex. conditions du réseaux) ou des aspects plus sémantiques
concernant les centres d’intérêt des communautés travaillant sur les divers sites. La résolution coopérative
basée sur la proximité permet de fonctionner selon un regroupement pertinent, éventuellement dynamique, des
caches.
Le choix d’utiliser des caches sémantiques [22, 12] est
motivé par le fort potentiel de réutilisation des données
cachées. Le cache stocke des requêtes avec leur réponse
et permet la réutilisation totale ou partielle pour répondre
à d’autres requêtes. Nos propositions pour la coopération
sont générales et peuvent être intégrées à tout type de cache
sémantique. Nous avons ainsi appliqué nos propositions au
cache dual [14] qui combine un cache de requêtes et un
cache d’objets. La définition de la coopération peut se faire
à un niveau relativement fin en précisant une stratégie de
coopération pour le cache de requêtes et celui d’objets.
Nous avons réalisé des expériences sur une grille dans le
contexte de l’interrogation de sources de données biologiques. Les résultats sont prometteurs et confirment l’intérêt
de baser la coopération entre les caches sur une notion de
proximité qui peut être instantiée selon les besoins.
Cet article est organisé de la manière suivante. La section
2 dresse un aperçu des travaux connexes à notre proposition
de cache sémantique coopératif, qui est présentée dans les
sections suivantes, la section 3 présentant d’abord une vision globale de la solution, avant de détailler nos différentes
contributions : le concept de caches sémantiques coopératifs
(4), la proximité dans le processus de résolution (5) et le
cache dual coopératif (6). L’évaluation de notre proposi-
tion dans un intergiciel de gestion de données sur grille est
présentée dans la section 7. La section 8 conclut ce papier
et donne des perspectives de recherche.
2. Travaux connexes
La littérature en matière de caches est vaste. Il est
donc impossible de présenter ici un état de l’art exhaustif. Nous introduisons néanmoins les principaux travaux connexes au notre à savoir : les caches sémantiques,
les caches coopératifs et les solutions de caches sur grilles.
2.1. Caches sémantiques
Les caches sémantiques structurent leur contenu comme
un ensemble de régions sémantiques. Les accès aux
éléments cachés et leur remplacement s’effectuent au
grain de la région sémantique. Les régions sémantiques,
comme les pages, sont un moyen d’agréger l’information sur plusieurs objets. Contrairement aux pages,
la taille et la forme (dans l’espace sémantique) des
régions peuvent varier. Quand une requête R1 arrive à
un cache sémantique, elle est décomposée en deux parties : (1) une requête de consultation, qui récupère la
portion du résultat de R1 disponible dans le cache local et une requête restante1 , qui correspond à la partie absente du cache. Cette dernière peut être vue comme
le défaut de cache qui devra être résolu en s’adressant
au(x) serveur(s). On parle de succès exact si la requête recherchée est en cache et de succès étendu si des éléments
en cache contribuent à la réponse mais d’autres traitements sont nécessaires.
Il existent deux approches en terme de gestion des
entrées d’un cache sémantique : celle qui se base totalement sur les régions [22, 12, 28] et celle qui distingue les prédicats sémantiques et les objets réponse
[30, 22, 24, 14].
Caches de régions. Les régions [12] ou segments
sémantiques [28] sont des structures de données qui regroupent un ensemble d’objets2 . L’accès au cache est
comparable à celui des caches d’objets et de pages. Lorsqu’une requête est posée et qu’elle provoque un succès
de cache, cela signifie qu’une région sémantique correspond à cette demande. La requête est alors utilisée
comme une clé pour accéder à la région qui contient les objets résultats.
Caches de requêtes et d’objets. Ces solutions permettent
également un accès sémantique, mais utilisent une structure de données particulière [22]. La notion de région, n’est
1
2
Les termes consacrés en Anglais sont probe query et remainder query
N-uplet ou objet au sens large
F IG . 1. Cache dual
plus vraiment physique, mais logique. Le cache est géré en
deux niveaux, un niveau de prédicats qui représentent les
requêtes et un niveau d’objets. Lorsqu’une requête est posée
et qu’un succès de cache a lieu, le cache récupère à l’aide
d’un prédicat, la liste d’identifiants des objets réponse. Ces
objets se trouvent dans le cache et doivent être accédés ensuite. La présence des objets dans le cache est strictement
liée aux requêtes cachées. Notons que lorsqu’il s’agit d’un
cache de vues, comme dans [30], les objets eux mêmes ne
sont pas en cache.
Le cache dual, illustré par la figure 1, est une solution
de cache sémantique basée sur la coopération d’un cache de
requêtes et d’un cache d’objets. Le cache de requêtes fonctionne comme un cache de vues. Le cache d’objets garde
des objets qui peuvent être accédés via leur identifiant. Les
caches de requêtes et d’objets peuvent utiliser leurs propres
stratégies. Ainsi, la cohérence entre requêtes et objets peut
être relâchée, si chacun des caches utilise une politique de
remplacement ne prenant pas en compte les décisions prises
par l’autre. La possibilité de configuration indépendante des
deux caches est particulièrement intéressante pour la mise
en place d’une solution coopérative entre caches.
2.2. Caches coopératifs
Les caches coopératifs offrent une abstraction d’un ensemble de caches vus par les clients comme une seule entité. Ainsi, les clients bénéficient des capacités de stockage
et de traitement de caches présents sur plusieurs sites du
système. Ces approches ont été largement étudiées dans les
systèmes de fichiers [11], de bases de données [17] et Internet [10] dans un but de distribution de charge et limitation
des goulots d’étranglements au niveau des serveurs.
La coopération entre caches aide principalement à
résoudre les défauts de caches : au lieu de s’adresser systématiquement au(x) serveur(s), un cache peut
solliciter ses caches frères ou parents. Les protocoles de coopération entre caches peuvent se baser sur
une résolution verticale, une résolution horizontale ou hybride. La suite introduit ces protocoles ainsi que les caches
dits répartis.
Caches hiérarchiques et résolution verticale. Les caches
sont organisés selon une certaine hiérarchie [10]. Un cache
parent est utilisé pour résoudre les défauts d’objets ayant
eu lieu chez un fils. La demande d’un objet est propagée
récursivement de manière ascendante jusqu’à trouver l’objet ou atteindre les serveurs de données qui sont virtuellement la racine de la hiérarchie. Lorsque l’objet est trouvé, il
est transféré vers le bas de la hiérarchie jusqu’à atteindre le
demandeur. L’objet est ”caché” à chaque niveau.
Caches frères et résolution horizontale. Ici les caches
sont considérés de même niveau. La résolution d’un défaut
d’objet peut être demandée à des caches dits frères. Un
tel cache frère répond selon son contenu mais ne propage
pas la demande. L’envoie de la demande aux caches frères
peut être faite par inondation ou à l’aide d’un catalogue.
L’inondation [34, 33] envoie la demande à tous les frères.
La première réponse positive est prise en compte, les autres
étant ensuite ignorées. Dans une résolution avec catalogue,
celui-ci répertorie le contenu des caches frères. Le cache
demandeur consulte le catalogue pour connaı̂tre le ou les
caches frères à qui adresser la demande de l’objet recherché.
La gestion du catalogue peut être locale [15, 29] ou partagée
(voire même centralisée) [19, 26]. Dans tous les cas les serveurs sont contactés si l’objet n’est pas renvoyé par un cache
frère.
Caches réparties. Dans le cadre de ces travaux une demande issue d’un client sera recherchée sur un ensemble
de caches [23]. Différentes politiques existent pour le choix
du ou des caches à qui adresser la demande. La politique
peut être gérée localement par le client ou par une machine dédiée (par ex. une frontale sur un cluster de caches
Internet). La politique peut être simple, par exemple un
choix aléatoire ou basé sur un tourniquet. La charge est
alors équitablement divisée sur tous les caches. Une version
plus fine, appelée weighted round robin assigne à chaque
cache un poids qui représente sa charge. La distribution des
requêtes peut aussi être faite en fonction des clients. Cette
approche distingue des groupes de clients et leur associe
des caches vers lesquels sont redirigées leurs demandes. Enfin, la distribution peut être fonction des demandes ou d’une
fonction pré-établie : par exemple une fonction de hachage,
comme dans Cache Array Routing Protocol (CARP) [31]
ou Cache resolver [21]. Le protocole Locality Aware Request Distribution (LARD) [27] assigne un ensemble dyna-
mique de caches par fichier. Quand une requête arrive, le
système vérifie si un cache s’occupe déjà de ce document.
Dans le cas contraire, le serveur le moins chargé est alors
désigné.
2.3. Caches sur grilles
Afin de compléter les travaux connexes à nos propositions, nous abordons ici les caches proposés pour des
contextes grille. Comme nos propositions, les solutions
présentées s’intéressent à la coopération entre caches. Cependant elles ne considèrent pas les techniques de cache
sémantique. Dans des contextes présentant une forte localité sémantique, ces techniques sont pourtant très utiles et
permettent d’optimiser l’utilisation des ressources.
Dans [8] les auteurs proposent un protocole intéressant
de résolution de défauts de cache sur grilles. Les caches sont
organisés en groupes d’intérêt et placés sous un cache collectif de plus haut niveau correspondant à un catalogue
du contenu de ses descendants. Le cache collectif permet de localiser un cache de bas niveau répondant à
une requête posée. Cette proposition combine une approche hiérarchique et une résolution horizontale entre
caches frères.
Dans le cadre des intergiciels de gestion de données permettant d’accéder à des bases de données réparties, nous
pouvons citer les travaux orientés cluster [9] et orientés
grille [5]. L’évaluation de requêtes tire profit des caches associés aux bases de données. La réutilisation des données
cachées est possible en cas de succès exacts.
Des travaux au sein du CERN [18] propose une solution de caches disques pour grilles proposée afin d’optimiser la gestion des données issues de l’accélérateur de particules. Les caches répartis sont gérés de manière globale. La
répartition de la charge est gérée en transférant des données
d’un cache à un autre si nécessaire.
3. Vers des caches sémantiques coopératifs
Notre approche cherche à reprendre les concepts
de caches coopératifs et de caches sémantiques en les
généralisant de manière à définir une solution suffisamment flexible pour s’adapter à un environnement de grille
quelconque. La présence évidente de nombreux caches distribués sur différents nœuds d’une grille implique la mise en
place de stratégies de coopération entre eux. Le besoin d’interroger des masses de données, elles aussi réparties sur la
grille, nécessite le déploiement de caches sémantiques capables d’interpréter des requêtes de haut niveau pour
limiter les transferts de données et les calculs. L’idée qui dirige nos travaux est de trouver la meilleure combinaison de
ces deux techniques en fonction du contexte grille, de sa topologie et de son état à un instant donné. Dans cette op-
tique nous proposons trois contributions :
1.- Un cache sémantique coopératif combine les techniques de cache sémantique et celles des caches coopératifs.
Il repose sur le principe de la séparation des préoccupations.
Ainsi, la gestion de la sémantique au sein du cache est
indépendante de la coopération entre caches. Le principe
général consiste à exécuter le processus de traitement de
requêtes de manière séquentielle : coopération puis traitement sémantique pour les caches répartis, l’inverse pour
une coopération avec résolution horizontale ou verticale.
La combinaison de ces deux approches est particulièrement
pertinente dans des grilles de données, permettant le passage à l’échelle des systèmes d’interrogation, en optimisant
l’utilisation des ressources locales et globales.
2.- Le concept de proximité vise à optimiser la
coopération au sein d’une stratégie de résolution horizontale. Le calcul d’une valeur de proximité permet
d’évaluer une distance entre objets. Les objets considérés
ici sont des caches qui peuvent alors être regroupés en
sous-ensemble. Le but est de créer des groupes dans lesquels la coopération est intéressante et supprimer les coûts
liées à la gestion de coopérations peu pertinentes, pouvant être considérables dans des grilles où le nombre
de caches est potentiellement très grand. Ainsi, le processus de résolution ne concerne qu’un sous-ensemble
de caches. Le concept de proximité est générique, il
peut être adapté en fonction du contexte d’application, c’est-à-dire en fonction des propriétés de l’environnement ou des caches à considérer. Nous définissons toutefois
deux types de proximité au niveau le plus général : la proximité physique et la proximité sémantique.
3.- Le cache dual coopératif est un cache sémantique finement adaptable capable d’exploiter aux mieux différentes
stratégies de coopération. Les notions de cache dual et de
proximité sont combinées. Puisque le cache dual repose sur
un cache de requêtes et un cache d’objets ayant des objectifs
distincts, l’idée est d’associer à chaque type de cache une
stratégie de coopération éventuellement différente guidée
par une fonction de calcul de proximité spécifique. Ainsi,
des stratégies fines de coopération peuvent être proposées
pour optimiser les transferts de données et les évaluations
dans les systèmes d’interrogation grande échelle.
4. Caches sémantiques coopératifs
Dans cette section, nous proposons différents types de
coopérations appliquées aux caches sémantiques. Dans
la suite, l’expression ”cache sémantique” sera utilisée indifféremment pour le cache de régions, le cache de requêtes
et objets, le cache dual étant considéré d’un point de vue
global (la distinction entre cache de requêtes et cache d’objets sera étudiée dans la section 6). Bien qu’ils diffèrent
dans leur gestion du contenu, ils sont similaires en terme de
coopération. Quelque soit le type de coopération considéré,
le traitement sémantique des requêtes reste le même. Une
requête reçue par un cache est décomposée en deux parties disjointes, une requête de consultation, évaluées sur
le contenu du cache, et une requête restante, dont le traitement dépend par contre du type de coopération
considéré. La suite de cette section présente individuellement les différents caches sémantiques coopératifs : les
caches sémantiques répartis, les caches sémantiques utilisant une résolution verticale et finalement une résolution
horizontale. Le cas de la composition des coopérations sera
étudié en conclusion de cette section.
4.1. Caches sémantiques répartis
Le processus de traitement de requête par des caches
sémantiques répartis est illustré par la figure 2(a). Dans un
premier temps, le gestionnaire de répartition achemine la
requête vers un cache choisi en fonction d’une des stratégies
présentées précédemment. A la réception de la requête, le
cache élu procède à un traitement sémantique de celle-ci, la
requête restante étant envoyée aux serveurs. Le résultat final une fois obtenu est fourni à l’utilisateur ou à l’application.
4.2. Caches sémantiques et résolution verticale
La figure 2(b) présente l’évaluation de requête dans
un cache sémantique avec résolution verticale de défaut.
Comme dans un cache sémantique classique, la réception
d’une requête par un cache se traduit par un traitement sémantique de celle-ci. Contrairement à un cache
sémantique classique, un cache avec résolution verticale n’envoie pas directement la requête restante aux serveurs mais demande la résolution de celle-ci auprès d’un
cache parent.
Les caches parents peuvent être des caches sémantiques
avec résolution verticale, ou ne considérer uniquement que
l’un des deux aspects, voire aucun. Dans le cas où les deux
techniques sont prises en compte, le processus de résolution
au sein d’une hiérarchie de caches sémantiques conduit à
une propagation de requêtes de plus en plus précises, la
résolution se terminant si une requête restante nulle est obtenue à un niveau donné de la hiérarchie ou si les serveurs
sont contactés pour résoudre une requête restante non nulle.
4.3. Caches sémantiques et résolution horizontale
Le comportement d’un cache sémantique avec
résolution horizontale est illustré par la figure 2(c).
Un cache sémantique avec résolution horizontale propose un traitement sémantique d’une requête simi-
(a) Caches répartis
(b) Résolution verticale
(c) Résolution horizontale
F IG . 2. Caches sémantiques coopératifs
laire à un cache sémantique avec résolution verticale, la
seule différence provenant de l’envoi de la requête restante à des caches frères, n’initiant pas de résolution
en cas de défaut, et non à un cache parent, pour lequel la résolution est obligatoire. Le traitement des demandes par un cache frère peut ensuite suivre une approche
classique ou sémantique.
Alors qu’une résolution horizontale classique ne
considère que les succès exacts, une résolution horizontale sémantique prend également en compte les succès
étendus, autorisant l’obtention d’une réponse complète
en exécutant une évaluation sur les objets présents localement. Du point de vue du cache demandeur, ces approches sont cependant similaires, puisqu’il reçoit comme
résultat les objets en cas de succès ou une réponse nulle en
cas de défaut. Si la demande sur les frères n’a généré aucun succès (exact ou étendu), elle est alors résolue en
contactant les serveurs.
Avec une approche considérant des réponses partielles, un cache peut recevoir de ses frères des réponses
incomplètes. Le cache demandeur reçoit alors des parties du résultat associées à des prédicats. Il supprime
dans ce cas, si nécessaire, la duplication des objets au sein de la réponse (due aux éléments partagés
par plusieurs frères) et calcule la nouvelle requête restante. Si cette dernière n’est pas nulle une fois toutes les
réponses des frères reçues, elle est évaluée sur les serveurs.
Il faut noter que la prise de décision en cas de
considération des succès étendus et/ou partiels diffèrent
pour les protocoles par inondation et par catalogue. Alors
que pour le premier, le choix est fait par les caches inondés,
dans le second cette responsabilité est à la charge du cache
demandeur.
4.4. Composition de coopérations
Il est possible de combiner les coopérations entre
caches sémantiques présentées précédemment. Des caches
sémantiques répartis avec résolution horizontale et/ou verticale, ou encore des caches sémantiques avec résolutions horizontale et verticale peuvent alors être créés. Dans le cas
où toutes les coopérations sont utilisées, un gestionnaire
de distribution redirige la requête sur un cache en fonction de la stratégie de répartition employée. Le cache choisie procède à un traitement sémantique de la requête. La
requête restante est envoyée sur les caches frères. Si elle
n’est pas résolue, elle est alors envoyée à un cache parent. Le traitement de requête dans les autres combinaisons possibles peut facilement être dérivé de ce processus.
5. Résolution horizontale basée sur la proximité
Nos recherches se sont focalisées sur la coopération entre
caches via le processus de résolution horizontale. Ce type
de coopération permet en effet de prendre en compte un
très grand nombre de caches largement distribués. Dans ce
contexte les caches parents deviennent souvent des goulots d’étranglement et les caches répartis sont limités à une
géographie réduite.
Nous introduisons ici la notion de proximité, permettant de configurer finement le protocole de résolution. Nous
donnons d’abord une définition du concept de proximité.
La partie suivante présente l’application de la proximité au
sein des protocoles de résolution. Pour finir, nous étudions
la proximité au sein des caches sémantiques.
5.1. Définition de la proximité
Une problématique majeure dans la résolution horizontale consiste à regrouper de manière pertinente les caches.
Bien que ce regroupement ne soit pas nécessaire pour un
faible nombre de caches, il devient primordial si ces derniers sont très nombreux. En effet, le processus de synchronisation des catalogues ou d’inondation serait alors très
coûteux. Le concept de proximité résout ce problème par
une limitation de la résolution, en regroupant les caches en
fonction de certaines caractéristiques. La définition de la
proximité est la suivante :
Definition 1 Soit a et b deux espaces de stockage et de
traitement de données (des caches sémantiques ou des serveurs). On note prox(a, b) (proximité de a vers b) le coût
associé au traitement (évaluation et transfert) par b des
requêtes émises par a.
La fonction de proximité permet donc d’associer un coût
à une connexion entre deux entités données. Du point de vue
d’un cache, ces coûts permettent de choisir les éléments les
plus pertinents à contacter lors de la résolution d’un défaut.
De manière générale cette fonction n’est pas symétrique et
l’on a prox(a, b) 6= prox(b, a). La fonction prox(a, b) peut
être de nature très diverse. On peut différencier une proximité physique d’une proximité sémantique :
Definition 2 On note proxP hy(a, b) (proximité physique
de a vers b) la mesure de coût liée à des paramètres physiques associés au traitement par b des requêtes émises par
a.
Definition 3 On
note
proxSem(a, b)
(proximité
sémantique de a vers b) la mesure de coût liée à des paramètres sémantiques associés au traitement par b des
requêtes émises par a.
La proximité physique caractérise le coût d’accès aux
éléments. Dans un contexte grille, la proximité physique
peut par exemple grouper ensemble les nœuds d’un même
cluster, pour lesquels la distance géographique est faible et
le débit à l’intérieur du site très important. Accéder à un
cache frère devient alors très peu coûteux en terme de communication.
La proximité sémantique entre deux caches mesure la
similarité entre les demandes. Cette similarité peut par
exemple porter sur le type des données accédées. Dans le
cas d’un système d’interrogation, un paramètre intéressant
correspond aux centres d’intérêt. En effet, la proportion des
éléments partagés par deux utilisateurs sera d’autant plus
grande s’ils ont des intérêts communs, augmentant la probabilité de succès entre leur cache.
On peut donc définir la fonction de proximité comme une
fonction de différentes mesures de proximité :
Definition 4
prox(a, b) = f (proxP hy(a, b), proxSem(a, b))
La proximité est un concept générique, choisie en fonction du contexte applicatif. Deux niveaux d’adaptation sont
possibles. Dans un premier temps, il convient de définir
les paramètres à prendre en compte pour les proximités
sémantique (homogénéité des données, centres d’intérêt,
etc.) et physique (débit, processeur, etc.). Dans un second
temps, il est important de pondérer chaque proximité, en
choisissant la fonction f en conséquence. Ceci permet par
exemple, de ne prendre en compte qu’une seule des deux
caractéristiques, l’une ou l’autre, ou encore l’une et l’autre.
Cet article ne se focalise pas sur les mécanismes de calcul effectif des mesures de proximité proxP hy(a, b) et
proxSem(a, b), mais s’intéresse plutôt à l’utilisation de
ce concept pour la coopération entre caches. Des outils
comme par exemple Network Distance Service (NDS) [20],
qui permettent de prendre en compte les caractéristiques
des réseaux (bande passante, latence) et des hôtes (processeur, ressources de calcul ou encore mémoire disponible),
peuvent être utilisés pour le calcul de la proximité physique.
Il est important de noter que le calcul de la proximité a luimême un coût. Ce coût est important, notamment pour choisir le moment où le calcul de la proximité doit être effectué.
Celui-ci peut se faire à chaque résolution ou de temps en
temps. Dans notre proposition, nous avons évalué la proximité au moment du déploiement. En terme de proximité,
nous ne nous sommes intéressés qu’à des fonctions simples.
L’appartenance à un même cluster pour la proximité physique :
Definition 5 proxP hy(a, b) = proxP hy(b, a) = 0 si a et
b appartiennent au même cluster 1 sinon.
Les mêmes centres d’intérêt pour la proximité sémantique.
Definition 6 proxSem(a, b) = proxSem(b, a) = 1 − x si
les requêtes reçues par a et b ont x % de prédicats en commun.
La proximité choisie est utilisée pour créer des topologies logiques de caches pour un contexte applicatif
donné. Pour un cache donné, le calcul de la proximité caractérise les serveurs et les caches frères. La
comparaison des valeurs obtenues donne alors une estimation de l’intérêt de la coopération. Si l’accès par
un cache frère est plus intéressant que par les serveurs, celui-ci est ajouté à la liste des caches à considérer
lors du processus de résolution. Dans le cas où aucun cache frère n’est pas plus intéressant que les serveurs (cas de serveurs très performants), la liste est vide, la
résolution se faisant donc sans coopération. Ainsi, à titre
d’exemple, dans les expériences présentées dans la section 7 deux caches a et b sont frères si proxP hy(b, a) = 0
et/ou si proxSem(b, a) ≤ 0.4.
5.2. Proximité et protocoles de résolution
L’utilisation de la proximité est orthogonale au protocole
de résolution utilisé. Ainsi, la proximité peut être prise en
compte pour une approche par inondation ou pour une approche par catalogue.
Dans une approche par inondation, le processus de
résolution de défaut récupère, dans un premier temps, la
liste des caches frères à contacter, respectant la proximité choisie. Ensuite, la demande est envoyée à tous les
caches de cette liste. Le traitement de la résolution est ensuite le même que dans une approche classique : la
première réponse positive est prise en compte, les autres
sont ignorées et les serveurs sont contactés en dernier recours.
Dans une résolution par catalogue, la proximité est utilisée pour limiter la liste des caches dont le contenu doit
être considéré par le catalogue. Le type de catalogue est
indépendant de l’utilisation de la proximité, le catalogue
pouvant ainsi être partagé ou local à un cache. Les modifications de contenu des caches sont envoyées selon un protocole choisi (cohérence forte ou relâchée) aux catalogues
des caches respectant la proximité considérée.
5.3. Proximité et caches sémantiques
L’objectif de cette section est de décrire les applications du concept de proximité au sein des caches
sémantiques. Quatre types de coopération sont étudiés
en fonction de la proximité utilisée : proximité physique, proximité sémantique, et proximités physique et/ou
sémantique.
5.3.1. Proximité physique La proximité physique correspond à une instance de la fonction de proximité
pour laquelle la sémantique n’est pas prise en compte
(prox(a, b) = proxP hys(a, b)). La résolution de défaut
ne concerne alors que les caches proches physiquement du cache considéré.
Exemple 1 La figure 3(a) présente une coopération entre
caches basée sur une proximité physique. Ainsi dans le cas
d’une résolution de défaut pour le cache 1, les caches 2 et
3 sont contactés.
Une résolution horizontale basée sur une proximité physique vise à optimiser les transferts de données entre caches.
Ainsi un cache ne contactera que ses frères offrant des
accès rapide à leur contenu, notamment par des distances
géographiques relativement faibles ou des liens de communications très haut débit.
5.3.2. Proximité sémantique L’utilisation de la proximité
sémantique permet à des caches de clients partageant les
mêmes centres d’intérêt de coopérer lors du processus de
résolution. Avec cette stratégie, la proximité physique n’est
pas prise en compte (prox(a, b) = proxSem(a, b)).
Exemple 2 La figure 3(b) présente une coopération entre
caches basée sur une proximité sémantique. Ainsi dans le
cas d’une résolution de défaut pour le cache 1, les caches 3
et 4 sont contactés.
La proximité sémantique vise à minimiser les échanges
inutiles entre caches. L’objectif est d’autoriser uniquement
la résolution d’une requête par les frères pouvant fournir
le résultat correspondant avec une forte probabilité, par
exemple parce qu’ils ont les mêmes centres d’intérêts que
le cache demandeur.
5.3.3. Proximités physique et/ou sémantique Afin de tirer profit des avantages des proximités présentées
précédemment, il est possible de proposer des coopérations
prenant en compte à la fois les caractéristiques physiques et sémantiques. Deux combinaisons sont alors possibles, la coopération basée sur des proximités physique
et sémantique et la coopération reposant sur des proximités physique ou sémantique.
Exemple 3 La figure 3(c) présente une coopération entre
caches basée sur des proximités physique et sémantique.
Ainsi dans le cas d’une résolution de défaut pour le cache
1, seul le cache 3 est contacté.
Exemple 4 La figure 3(d) présente une coopération entre
caches basée sur des proximités physique ou sémantique.
Ainsi dans le cas d’une résolution de défaut pour le cache
1, les caches 2, 3 et 4 sont contactés.
Les proximités physique et sémantique permettent respectivement d’optimiser les transferts de données et
les évaluations de requêtes. Malheureusement, la prise
en compte de ces deux aspects au sein d’un cache
sémantique classique est difficile, un système combinant les deux approches étant trop ou insuffisamment
restrictif selon qu’elles soient considérées conjointement ou indépendamment. Une solution pour résoudre se
problème, consiste à utiliser le cache dual.
6. Cache dual et proximités
Dans cette section nous proposons une approche
coopérative pour le cache dual. Un cache dual utilise deux
(a) Proximité physique
(c) Proximité physique et sémantique
(b) Proximité sémantique
(d) Proximité physique ou sémantique
F IG . 3. Caches sémantiques avec résolution horizontale
caches distincts, un cache de requêtes et un cache d’objets visant à optimiser respectivement les temps de transfert
et de calcul. L’utilisation du cache dual offre des perspectives intéressantes en terme de coopération basée sur
la proximité. En effet, deux instances différentes peuvent
être appliquées au cache de requêtes et au cache d’objets.
6.1. Cache de requêtes et proximité sémantique
idObjList ← ReqCache.lookup(req)
if idList 6= null then {succès}
objList ← ObjCache.load(idObjList)
else {défaut}
if frères 6= ∅ then
idObjList ← frères.lookup(req)
if idObjList 6= null then {succès}
objList ← ObjCache.load(idObjList)
else {défaut}
(idObjList,objList) ← serveurs.load(req)
end if
else {résolution directe sur les serveurs}
(idObjList,objList) ← serveurs.load(req)
end if
ReqCache.add(req,idObjList)
end if
return objList
F IG . 4. Traitement des demandes par le cache
dual/cache de requêtes
L’algorithme de la figure 4 présente le traitement d’une
requête par le cache de requêtes dans le cas d’une résolution
basée sur le concept de proximité. Lorsque la requête posée
par un client doit être résolue ou si elle engendre une requête
restante non nulle, une résolution est initiée par le cache de
requêtes. Celui-ci envoie la demande aux caches frères de la
liste créée en fonction de la proximité choisie. Si un cache
possède la demande il transfert la liste des identifiants d’objets répondant à la requête. Le cache de requêtes contacte
alors son cache d’objets pour récupérer les éléments demandés. Si la liste des frères est vide ou si aucun frère ne
peut répondre, le cache contacte le serveur et récupère les
objets demandés, les ajoute dans son cache si besoin et les
transfert au client.
Les caches de requêtes sont utilisés afin de limiter les calculs. Dans le cas d’un cache dual, un calcul correspond à un ensemble d’identifiants. Par conséquent, la
réponse d’un cache de requêtes conserve une taille relativement petite même si le nombre d’identifiants est très
grand. Ainsi le temps de transfert entre caches reste très
faible, indépendamment de la distance entre les caches.
D’un autre côté la proximité sémantique dans un protocole de résolution assure une plus grande probabilité de trouver les objets demandés sur les caches frères.
Ces deux arguments nous incitent à utiliser une proximité sémantique pour les caches de requêtes.
6.2. Cache d’objets et proximité physique
Le traitement d’une liste d’identifiants d’objet par le
cache d’objets est illustré par l’algorithme de la figure
5. Lorsqu’un cache d’objets reçoit une liste d’identifiants
d’objets, il les recherche dans son espace de stockage créant
si besoin une liste des objets absents. Cette liste est alors
for each id in idObjList do
obj ← ObjCache.lookup(id)
if obj 6= null then {succès}
objList.add(obj)
else {défaut}
missIdObjList.add(id)
end if
end for
if missIdObjList 6= ∅ then
if frères 6= ∅ then
missObjList ← frères.lookup(missIdObjList)
if missObjList = null then {défaut}
missObjList ← serveurs.load(missIdObjList)
end if
ObjCache.add(missObjList)
else {résolution directe sur les serveurs}
missObjList ← serveurs.load(missIdObjList)
end if
end if
return objList
F IG . 5. Traitement des demandes par le cache
d’objets
envoyée aux caches frères considérés. Si un cache frère
possède les objets demandés il les transfert. Si la résolution
ne peut se faire par les frères (liste de frères vide ou aucun cache n’ayant la réponse), les serveurs sont contactés
pour récupérer les objets.
L’objectif principal du cache d’objets est de limiter les
transferts de données. Par conséquent, ces performances
sont fortement dépendantes des caractéristiques physiques
de l’environnement (distance géographique, débit, etc.).
C’est pourquoi il est pertinent d’utiliser une proximité physique pour la coopération entre caches d’objets.
6.3. Protocoles de résolution pour cache dual
Le cache dual est une solution flexible permettant en
plus de choisir une proximité différente pour les caches de
requêtes et les caches d’objets, d’activer ou non le processus de résolution horizontale. Ainsi, en fonction de l’environnement, et notamment des performances des accès navigationnels et associatifs, la résolution horizontale peut être
prise en compte pour le cache de requêtes, le cache d’objets,
les deux ou aucun d’eux. Ces stratégies sont capturées dans
les protocoles de résolution basique, physique, sémantique
et finalement physique et sémantique, illustrés par la figure
6.
Résolution basique Le protocole basique désactive la
coopération à la fois pour les caches de requêtes et les
F IG . 6. Protocoles de résolution au sein du
cache dual
caches d’objets. Ainsi en cas de défaut pour l’un de ces
deux caches, les demandes (requêtes ou listes d’identifiants) sont envoyées directement sur les serveurs.
Résolution physique Avec une résolution physique, la
coopération est prise en compte uniquement pour les
caches d’objets, en se basant sur une proximité physique. Ainsi un défaut pour une requête engendre une
résolution auprès des serveurs directement, alors que pour
une liste d’identifiants, les caches d’objets proches physiquement sont d’abord contactés, la récupération des
éléments sur les serveurs se faisant en dernier recours.
Résolution sémantique Un cache dual reposant sur
résolution sémantique considère une coopération entre les
caches de requêtes basée sur une proximité sémantique. En
cas de défaut une requête est alors transférée à des frères,
et évaluée sur les serveurs si nécessaire, alors que ces derniers sont contactés directement pour des demandes provenant du cache d’objets.
Résolution physique et sémantique Une résolution physique et sémantique correspond à une combinaison
des deux approches présentées précédemment. Autrement dit, les caches de requêtes coopèrent en fonction d’une résolution horizontale basée sur une proximité sémantique, et une proximité physique est employée
pour les caches d’objets.
7. Expérimentations
Cette section décrit une série d’expérimentations que
nous avons menée pour observer l’efficacité d’une architecture de caches coopératifs utilisant notre approche de proximité, qu’elle soit physique, sémantique ou une combinai-
son des deux. Nous poserons le contexte bio-informatique
de nos expérimentations ainsi que l’architecture où sont
déployés les caches. Les différentes métriques retenues pour
l’interprétation des résultats viendront valider l’évaluation
de performance de notre proposition.
7.1. Contexte applicatif d’expérimentation
Nous nous plaçons dans un contexte d’accès à des
masses d’information par des biologistes pour le traitement
de données génomiques. Ces opérations sont coûteuses
en temps de calcul et en transfert de données. L’utilisation de caches peut être particulièrement bénéfique pour
réduire les transferts et les nombreuses entrées/sorties
qu’impliquent ces traitements. L’utilisation d’une grille
prend également tout son sens pour distribuer les calculs et accéder aux données la plupart du temps déjà distribuées sur plusieurs sources. Une approche de cache
coopératif semble pertinente dans ce contexte. Si nous
considérons aussi les besoins des biologistes en terme de recherche d’information, qui accèdent au contenu de fichier
plat de très grande taille à l’aide de requêtes successives sémantiquement proches, des caches sémantiques
sont requis pour exploiter au mieux les données cachées.
Les expériences utilisent comme support la banque biologique de séquences de protéines Swissprot [1]. Cette
source d’information contient un grand nombre d’annotations sur chacune des séquences répertoriées. Elle est
massivement utilisée par les biologistes qui, après filtrage des séquences et/ou annotations pertinentes, l’utilisent comme données en entrée de nombreuses applications de traitements. Cette banque de données est un
fichier contenant 750Mo d’enregistrements. Un enregistrement se compose d’une séquence de protéines et de ses
annotations. Le modèle utilisé pour décrire les enregistrements est de type attribut / valeur, chaque ligne étant composée du nom de l’attribut et de la valeur associée (ou de
l’ensemble de valeurs associées). Ce fichier subit des modifications régulières, d’une part sous la forme de révision officielle (nouvelles séquences), d’autre part sous la forme
d’ajouts de nouvelles annotations par les différents biologistes (version ad-hoc de Swissprot). Chaque nouvelle
version donne lieu à un nouveau fichier, le contexte applicatif est donc principalement en lecture et se prête bien à
l’utilisation de caches.
7.2. Infrastructure pour l’expérimentation
Les caches coopératifs sont déployés au sein d’une architecture spécialisée et pilotée par un intergiciel de gestion
de données dédié aux grilles légères. Les paragraphes suivants résument les points importants de l’intergiciel et du
déploiement de celui-ci ainsi que des caches.
7.2.1. Aspect logiciel
Intergiciel Gedeon L’intergiciel de gestion de données sur
grilles Gedeon [2] est issu des résultats du projet de recherche du même nom sur la thématique masse de données
de l’ACI du ministère délégué à la recherche. L’objectif est
de définir un système de gestion de données hybride entre
le système de gestion de fichiers et le système de gestion de
bases de données. Un système de gestion de fichiers fournit un ensemble d’outils très efficaces pour accéder aux fichiers et à leur contenu, mais les données manipulables restent à gros grain, c’est-à-dire tout ou partie d’un fichier.
La sélection d’enregistrements en fonction des valeurs de
méta-données reste inaccessible sans le recours à une application ad-hoc, la sélection possible se limite donc aux fichiers en fonction d’attributs système. Un système de gestion de bases de données procure des moyens d’interrogation et de manipulation très évolués. Cependant en offrant
différents niveaux d’abstraction couplés à des langages de
définition et de manipulation de données, un SGBD requière
une structuration forte des données. Plus encore la complexité de déploiement d’un SGBD, et donc par extension
d’un SGBD distribué, nécessite l’intervention d’experts qui
doivent résoudre les problèmes de passage à l’échelle et de
configuration afin de conserver des performances correctes
lorsqu’il s’agit d’environnement de type grille.
L’intergiciel Gedeon propose donc d’étendre un système
de fichier à la notion d’enregistrements afin de pouvoir manipuler ceux-ci en fonction de leurs méta-données associées
et de les accéder à travers une grille. Gedeon repose sur une
indexation distribuée des données par un ensemble pertinents de méta-données. Dans l’exemple support décrit ciavant, les annotations d’un fichier Swissprot joue le rôle de
méta-données pour les données qui sont alors les séquences
de protéine. Un client qui pose une requête sur Gedeon
reçoit en réponse, après résolution, l’adresse de localisation des enregistrements pertinents. Une requête est une
conjonction de termes qui sont soit des prédicats simples,
soit des opérateurs de déférencement permettant de proposer des concepts de la logique du second ordre pour rechercher aussi les données référencées par certaines métadonnées cibles. Pour éviter l’aspect parfois monolithique
d’un SGBD, l’intergiciel est construit par un assemblage de
modules autour d’un noyau d’indexation de méta-données.
Les principaux modules se répartissent les tâches suivantes :
la distribution, l’interface utilisateur (extension shell, API,
XML, etc.), la transparence d’accès (catalogue, médiateur,
etc.), la gestion de cache. De nouveaux modules peuvent
ainsi être connectées et/ou remplacer d’autres modules.
Cache dual Le cache dual a été construit à l’aide d’une version Java et Fractal [7] du canevas de caches adaptables ACS
[14]. Les caches de requêtes et d’objets construits réutilisent
des composants fournis par la bibliothèque du canevas, no-
tamment une gestion des entrées du cache à l’aide de tables
de hachage et des politiques de remplacement LRU. La suite
de cette section s’intéresse plus particulièrement à la gestion de la sémantique au sein des caches, en terme d’analyse et d’évaluation des requêtes.
L’analyse de requêtes permet de confronter les requêtes
posées par les utilisateurs aux prédicats gardés en cache.
Afin que le processus de traitement en cache ne soit pas trop
coûteux, seuls des cas simples de succès étendus, liés à une
équivalence ou à l’inclusion d’une requête dans une entrée,
ont été pris en compte. L’équivalence autorise la détection
de requêtes contenant les mêmes termes dans des ordres
différents. L’inclusion quant à elle se base sur l’ajout de
termes supplémentaires (et par conséquent des demandes
plus restrictives). D’un point de vue développement, nous
avons eu recours à une transformation des requêtes en vecteur de bits. L’objectif de cette opération est de fournir un
processus de recherche au sein du cache plus efficace, la
confrontation de deux vecteurs de bits étant plus rapide que
la confrontation de requêtes dans leur forme standard (ici
des chaı̂nes de caractères). La solution repose sur une table
de correspondance entre un indice et un terme, les associations étant mises à jour avec les modifications du contenu du
cache (ajout d’un nouveau terme si besoin provoqué par une
nouvelle entrée et suppression si le terme d’un élément remplacé n’est utilisé par aucune autre entrée). Outre la comparaison plus rapide d’une requête posée avec le contenu du
cache, l’écriture de la requête de consultation (et lorsqu’elle
est considéré de la requête restante) est plus simple, en utilisant des opérateurs logiques sur les vecteurs de bits.
L’évaluation de requêtes autorise l’application de
prédicats sur l’ensemble du contenu du cache. Pour
le système d’interrogation de sources de données bioinformatiques, seules les sélections ont été prises en
compte. L’évaluation au sein du cache réutilise la brique
de traitement de requête fournie par l’intergiciel Gedeon, l’évaluateur employé par le cache étant essentiellement en charge d’assurer la liaison entre les couches logicielles. A noter que la bibliothèque Gedeon étant en C,
nous avons opté pour des appels systèmes pour gérer les interactions avec les caches.
7.2.2. Aspect matériel, déploiement sur grille L’intergiciel Gedeon a été déployé sur Grid5000, la plate-forme
française d’expérimentations sur grille. Des clusters sur
trois sites différents (Nancy, Rennes et Sophia-Antipolis)
ont été utilisés. Les caractéristiques des nœuds de chaque
site sont données par le tableau 1. Pour tous les clusters, l’interconnexion à l’intérieur d’un site correspond à de
l’ethernet 1Gbit/s. Les différentes sites sont connectés par
des réseaux longue distance (WAN) à 10Gbit/s.
Avec une architecture à serveur simple, la source de
données devient rapidement un goulot d’étrangement, puisqu’une seule machine est responsable de l’évaluation des
requêtes. L’architecture à union de serveurs vise à résoudre
ce problème en exécutant de manière parallèle le calcul sur la grille. Le principe consiste à découper la source
de données en N fichiers de taille équivalente (fragmentation horizontale), chaque fichier étant géré par un nœud
spécifique, appartenant ou non à un même site. Ainsi, lorsqu’une requête est posée, elle est transférée sur les
différents nœuds pour une évaluation en parallèle. Les
résultats sont ensuite agrégés au niveau du client pour
construire le résultat final. Des expériences ont montré que
les débits obtenus pour les serveurs sont quasiment proportionnels aux nombres de nœuds utilisés [32]. Dans le
cadre de nos expérimentations, la source de données Swissprot a été décomposé en trois fichiers de taille équivalente,
chacun géré par un nœud appartenant à un des trois clusters présentés précédemment.
7.3. Évaluation de performance
Cette section présente les outils pour l’évaluation de
performance. Premièrement, elle étudie la génération de
la charge de travail. Ensuite, elle présente les métriques
étudiées.
7.3.1. Génération de la charge de travail Les charges
de travail classiques utilisées dans les bancs d’essai (par exemple TPC [4], Wisconsin pour bases de
données [13] et proxy [6], ou encore Polygraph [3])
ne prennent pas en compte la localité sémantique,
alors qu’il s’agit d’une caractéristique majeure pour les
caches sémantiques. Nous avons utilisé la charge de travail Rx [25]. Les requêtes correspondent à des raffinements progressifs. La première requête est générale et les
suivantes sont de plus en plus précises et réduisent l’ensemble des éléments résultats. Dans une charge de travail Rx, x est le pourcentage de requêtes raffinées. Avec
R50 par exemple, la moitié des requêtes sont issues de raffinements de précédentes requêtes. Dans les expériences
suivantes, la charge de travail se constitue d’un ensemble de requêtes correspondant à un terme de sélection
ou à la conjonction de deux à quatre termes. Afin de simuler un contexte avec une localité sémantique, nous avons
choisi d’utiliser la charge de travail R40.
En plus de la localité sémantique, nous introduisons
la notion de communauté. Une communauté correspond
à un groupe d’utilisateurs partageant les mêmes centres
d’intérêt. Les requêtes des membres d’une communauté
tendent alors à se focaliser sur un sous-ensemble particulier d’enregistrements. Dans le cas particulier de Swissprot,
nous avons créé des groupes d’intérêt en nous inspirant
de l’arbre de vie. Chaque enregistrement appartient à l’un
des quatre groupes suivants : Eucaryotes, Archées, Virus
et Bactéries. Ainsi, pour chaque groupe, nous définissons
une communauté d’utilisateurs supposés particulièrement
Nancy
Rennes
Sophia-Antipolis
Machine
HP ProLiant DL145G2
Sun Fire V20z
Sun Fire X4100
Processeur
2x AMD Opteron 246 2.0GHz
2x AMD Opteron 248 2.2GHz
2x dual core AMD Opteron 275 2.2GHz
Mémoire
2GB
2GB
4GB
Disque
SATA
SCSI
SAS
TAB . 1. Caractéristiques des nœuds
intéressés par ce groupe. Dans les expériences suivantes,
60% des requêtes posées par les utilisateurs concernent des
enregistrements de leur communauté. Les 40% restants sont
distribués uniformément sur les autres enregistrements.
Q1 : OC ⊃ Bacteria ∧ OC ⊃ Proteobacteria
Q2 : OC ⊃ Bacteria ∧ OC ⊃ Proteobacteria ∧ OC ⊃ Gammaproteobacteria
Q3 : OC ⊃ Eukaryota ∧ OC ⊃ Mycetozoa
Q4 : OC ⊃ Eukaryota ∧ OC ⊃ Entamoebidae
Q5 : OC ⊃ Eukaryota ∧ OC ⊃ Entamoebidae ∧ OC ⊃ Entamoeba
Q6 : OC ⊃ Archaea ∧ OC ⊃ Nanoarchaeota
F IG . 7. Exemple de charge de travail
Exemple 5 La figure 7 présente un exemple de génération
de requêtes portant sur l’attribut OC (espèce), suivant une
charge R40, avec 60 % des requêtes posées concernant la
communauté du client (utilisateurs intéressés par les eucaryotes).
7.3.2. Métriques pour l’interprétation des résultats
L’une des métriques les plus importantes à étudier, pour
analyser des caches, est le temps de réponse, qui est fortement lié au taux de succès de cache. Cependant, d’autres
métriques peuvent être pertinentes. Ainsi, il peut être
intéressant de considérer la charge sur le serveur ou le volume de données transféré entre les clients et les serveurs, pour chiffrer l’apport d’un cache, puisque la gestion
de ces ressources est souvent cruciale dans les environnements largement distribués.
7.4. Résultats
Cette section présente les résultats que nous avons obtenus dans trois expérimentations distinctes. Les deux
premières permettent de mieux comprendre l’influence du
nombre de caches sur les résolutions basées sur le concept
de proximité. La dernière présente l’étude des différents
protocoles présentés dans la section 6.3 dans un contexte
grille. Pour toutes les expériences considérées, des caches
duaux de 325 Mo (correspondant à la moitié de Swissprot) sont déployés. Chaque cache est utilisé par un client
générant cinquante requêtes suivant la charge de travail R40 (appartenant ou non à une communauté selon
l’expérience considérée).
7.4.1. Influence du nombre de caches L’objectif de cette
section est d’étudier l’impact du nombre de caches sur les
coopérations basées sur la proximité. C’est pourquoi nous
avons étudié l’influence du nombre de caches de requêtes
sur la proximité sémantique et l’influence du nombre de
caches d’objets sur la proximité physique.
Nombre de caches d’objets et proximité physique Dans
une première expérience, nous étudions l’impact du nombre
de caches d’objets sur une coopération basée sur la proximité physique au sein du cache dual en terme de transfert et de calcul. Tous les caches déployés appartiennent
au site de Sophia-Antipolis et utilisent un caches d’objets
avec proximité physique. Ainsi, chaque fois qu’un cache
dual est ajouté sur un site, son cache d’objets devient un
frère pour les autres caches d’objets. A noter que les caches
appartiennent à des clients uniformément répartis dans les
différentes communautés présentées précédemment.
La figure 8(a) présente l’impact du nombre de caches
sur la résolution physique en terme de volume de données
transféré entre le cache et les serveurs. L’axe des abscisses
représente le nombre de caches, alors que l’axe des ordonnées représente le volume de données transféré en Giga
octets. Pour cette expérience, le nombre de caches varie de
un à cinq, avec un pas de un. Ce graphique permet d’observer qu’augmenter le nombre de caches permet de réduire
l’utilisation de la bande passante. Ainsi, passer de un à
quatre caches permet de réduire l’utilisation de la bande
passante de 50 %. Cependant, il est possible de noter que
le volume de données transféré devient relativement stable
lorsque le nombre de caches est supérieur à trois. En effet, l’espace physique total utilisé est suffisant pour stocker toutes les données pertinentes. Par conséquent ajouter des caches dans la coopération, n’apporte pas de gain
supplémentaire. Il faut cependant prendre en compte que
le nombre de caches est fonction de leur taille. En effet, les
mêmes résultats auraient pu être obtenus avec un plus grand
nombre de caches de plus petite taille.
La figure 8(b) présente l’impact du nombre de caches
sur la résolution physique en terme de taux de requêtes
par client évaluées sur les serveurs. L’axe des abscisses
représente toujours le nombre de caches, variant de un à
(a) Volume de données transféré
(b) Charge sur les serveurs
F IG . 8. Résolution basée sur la proximité physique
(a) Volume de données transféré
(b) Charge sur les serveurs
F IG . 9. Résolution basée sur la proximité sémantique
cinq par pas de un. Le cache des ordonnées représente cette
fois, le taux de requêtes, donné en pourcentage. Cette figure
permet de voir que le nombre de caches dans une résolution
physique n’a pas d’impact sur le taux de requêtes par client
évaluées sur le serveur. Celui-ci reste relativement constant
quelque soit le nombre de caches, avec une valeur aux environ de 37%. Il est possible de noter que la première mesure
est un peu supérieure aux autres. Cette différence n’est pas
la conséquence de la coopération entre les caches, celle-ci
ne concernant pas l’évaluation. Nous pensons, que la charge
utilisée dans ce cas précis est un peu moins représentative
que les autres, ce qui expliquerait ce léger décalage par rapport à la moyenne.
Nombre de caches de requêtes et proximité sémantique
L’expérience suivante se focalise sur l’influence du nombre
de caches de requêtes dans le cas de l’utilisation d’une
résolution basée sur la proximité sémantique pour le cache
dual, sur les transferts de données et les évaluations. Dans
cette expérience, les clients appartiennent à une des quatre
communautés considérées. Chaque client utilise un cache
dual avec une résolution coopérative basée sur la proximité sémantique pour le cache de requêtes. Les clients sont
répartis uniformément sur les trois sites concernés (Nancy,
Rennes et Sophia-Antipolis).
La figure 9(b) présente l’influence du nombre de
caches sur la résolution sémantique en terme de taux de
requêtes par client évaluées sur les serveurs. L’axe des abscisses représente le nombre de caches duaux, équivalent au
nombre de caches de requêtes. L’axe des ordonnées correspond au pourcentage de requêtes par client évaluées
sur les serveurs. Contrairement à la résolution physique, l’ajout de nouveaux caches est intéressant dans tous
les cas considérés. En effet, le nombre de requêtes possibles est relativement grand, rendant difficile leur stockage rapide dans un faible nombre de caches. On observe
ainsi que de quatre à vingt caches, le gain obtenu peut atteindre jusqu’à 45.3 %.
La figure 9(a) présente l’impact du nombre de caches sur
la résolution sémantique en terme de volume de données
transféré entre le cache et les serveurs. L’axe des abscisses
correspond au nombre de caches. L’axe des ordonnées permet de caractériser le volume de données en Giga octets.
Cette figure montre que le volume de données transféré
n’est pas sensible au nombre de caches. En effet, les variations du volume ne sont pas monotones avec une croissance du nombre de caches, les mesures oscillant entre 7.6
et 9.4 Giga octets.
7.4.2. Expérience grille La dernière expérience que nous
avons réalisée étudie les différents protocoles de résolution
proposés pour le cache dual dans un contexte grille. Le tableau 2 présente les résultats des différents protocoles, avec
vingt clients. Les lignes du tableau représentent les protocoles étudiés : basique, physique, sémantique et sémantique
physique. Les colonnes du tableau représentent les
métriques considérées : le temps moyen de réponse à
une requête en secondes, le taux de requêtes évaluées
sur les serveurs donné en pourcent et finalement le volume moyen de données transféré entre les serveurs et un
cache.
Globalement, le tableau montre qu’utiliser une
résolution coopérative permet de réduire le temps de
réponse, cette diminution étant de l’ordre de 50 %
dans le cas d’une combinaison des coopérations. Plus
généralement, toutes les coopération permettent une diminution (plus ou moins grande) du temps de réponse. Cette
diminution provient de différents facteurs : un gain en
terme de transfert de données et d’évaluations sur les serveurs.
La résolution physique est l’approche présentant le plus
faible gain. La coopération entre les caches d’objets n’a en
effet, aucun impact sur le taux de requêtes évaluées sur les
serveurs. De plus, le gain en terme de volume de données
transféré est assez faible (environ 200 Méga octets). Ce
faible gain peut s’expliquer par le fait que la plupart des
résolutions au sein du cache concerne le cache de requêtes.
Dans le cas d’une coopération physique, la résolution de
défaut pour le cache de requêtes se fait auprès du serveur, les
objets étant récupérés par ce même cache. Par conséquent,
les caches d’objets sont moins contactés que dans le cas
d’une double coopération.
L’utilisation d’une coopération entre cache de requêtes
basée sur la proximité sémantique permet de réduire le
nombre de requêtes à évaluer sur les serveurs. On observe effectivement, que le taux de requêtes évaluées sur
les serveurs est de 35 % sans coopération, alors qu’il est
diminué de moitié (17 %) lorsque celle-ci est activée. Il
est également possible de remarquer que la coopération
entre caches de requêtes permet de diminuer le volume de
données transféré, celui-ci passant de 9 à 7.9 Giga octets
lorsque la coopération est prise en compte. En effet, lorsque
les caches de requêtes coopèrent, les sources de données
sont plus souvent accédées à l’aide d’identifiants, évitant de
récupérer des objets déjà stockés.
La résolution sémantique physique représente le cas de la
double coopération. Les résultats montrent que le gain de la
coopération entre cache d’objets est bien plus significative
que précédemment, diminuant de 2.8 Giga octets entre la
résolution sémantique et la résolution sémantique physique.
A noter que le résultat en terme de taux d’évaluation reste
inchangé entre la résolution sémantique et la résolution physique. Ce résultat est logique, puisque l’accès au cache de
requêtes est le même dans les deux protocoles.
8. Conclusion
Cet article présente une solution de cache sémantique
coopérative. En utilisant le principe de séparation des
préoccupations, cette solution distingue d’abord clairement la gestion du cache du processus de résolution,
puis l’évaluation du transfert de données. Nous nous appuyons sur une notion de proximité pour optimiser les
stratégies de coopération en fonction des types de caches
considérés et de leurs environnements. Nous exploitons cette approche pour une solution de cache orientée
grille, nommée cache dual, qui introduit une collaboration entre un cache de requêtes et un cache d’objets. Une configuration fine de la stratégie du cache peut
alors être faite pour améliorer à la fois le transfert de
données en utilisant une coopération entre caches d’objets et l’évaluation de requêtes en utilisant une coopération
entre caches de requêtes. Des expériences ont montré la pertinence de cette solution dans un contexte grille utilisant un
intergiciel de gestion de données. Notre proposition permet d’optimiser le temps d’évaluation puisque elle maximise le partage de calculs entre caches et réduit le volume
de données transférées en limitant les communications externes, instaurant une coopération entre caches d’objets
d’une même organisation.
Plusieurs idées sont en cours d’exploration pour
améliorer à la fois les performances et l’autonomie d’une
solution de caches ”intelligents”. Nous considérons actuellement d’autres contextes applicatifs où déployer notre solution, en particulier les systèmes orientés entrepôts de
données qui posent des problèmes de cohérence relâchée.
Il est important de noter que nous n’avons pas abordé
les problèmes de synchronisation et qu’ils doivent par
conséquent être étudiés plus attentivement dans notre proposition. Dans l’idée d’obtenir des caches autonomes disposant à tout moment d’un fonctionnement adapté, nous
voulons étudier l’impact des politiques de remplacement et les changements de stratégies de coopération.
L’objectif à moyen terme est de disposer d’un canevas de caches auto-adaptables autonomes, sensibles au
contexte, pour fournir des solutions efficaces dans des environnements dynamiques.
Basique
Physique
Sémantique
Sémantique physique
Temps de réponse
44,1 s
43,7 s
28,4 s
23,4 s
Évaluations sur les serveurs
35 %
35 %
17 %
17 %
Données transférées
9.0 Go
8.8 Go
7.9 Go
5.1 Go
TAB . 2. Métriques de performance de protocoles coopératifs dans un contexte grille
Remerciements
Proc. 1st Symposium on Operating Systems Design and Implementation, pages 267–280, 1994.
Merci à l’équipe Hadas et celle du projet Gedeon pour
les discussions sur la gestion de données sur grille. Merci
également à l’ACI Masses de Données et à l’Institut National Polytechnique de Grenoble pour le support financier et
à l’ACI GRID qui a rendu possible nos expérimentations.
Références
[1] La
base
de
connaissances
http ://www.ebi.ac.uk/swissprot/.
swiss-prot.
[2] Le projet gedeon. http ://www-lsr.imag.fr/Gedeon/.
[3] Polygraph. http ://polygraph.ircache.net/.
[4] Transaction
processing
http ://www.tpc.org/.
performance
council.
[5] Mobin Uddin Ahmed, Raja Asad Zaheer, and M. Abdul Qadir. Intelligent cache management for data grid. In Proc. of
the Australian WS on Grid computing and e-research, pages
5–12, 2005.
[6] Jussara Almeida and Pei Cao. Measuring proxy performance
with the Wisconsin Proxy Benchmark. Computer Networks
and ISDN Systems, 30(22–23) :2179–2192, 1998.
[7] Eric Bruneton, Thierry Coupaye, Matthieu Leclerq, Vivien
Quéma, and Jean-Bernard Stefani. An Open Component model and its support in Java. In Proceedings of the international symposium in Component-based Software Engineering,
2004.
[8] Yonny Cardenas, Jean-Marc Pierson, and Lionel Brunie.
Uniform Distributed Cache Service for Grid Computing. In
2nd Int. WS on Grid and Peer-to-Peer Computing Impacts on
Large Scale Hereogeneous Distributed DB Systems., pages
351–355, 2005.
[9] Emmanuel Cecchet, Julie Marguerite, and Willy Zwaenepoel. C-jdbc : Flexible database clustering middleware.
In USENIX Annual Technical Conference, FREENIX Track,
pages 9–18, 2004.
[10] Anawat Chankhunthod, Peter B. Danzig, Chuck Neerdaels,
Michael F. Schwartz, and Kurt J. Worrell. A hierarchical
internet object cache. In USENIX Annual Technical Conf.,
pages 153–164, 1996.
[11] Michael Dahlin, Randolph Y. Wang, Thomas E. Anderson,
and David A. Patterson. Cooperative caching : Using remote client memory to improve file system performance. In
[12] Shaul Dar, Michael J. Franklin, Bjorn Thorn Jonsson, Divesh Srivastava, and Michael Tan. Semantic data caching
and replacement. In Proc. of the Int. Conf. on VLDB, pages
330–341, 1996.
[13] David J. DeWitt. The wisconsin benchmark : Past, present,
and future. In Jim Gray, editor, The Benchmark Handbook
for Database and Transaction Systems (2nd Edition). Morgan Kaufmann, 1993.
[14] Laurent d’Orazio, Olivier Valentin, Fabrice Jouanot, Yves
Denneulin, Cyril Labbé, and Claudia Roncancio. Services
de cache et intergiciel pour grilles de données. In 22ème
journées Bases de Données Avancées, 2006.
[15] Li Fan, Pei Cao, Jussara Almeida, and Andrei Z. Broder. Summary cache : a scalable wide-area web cache
sharing protocol. IEEE/ACM Transactions on Networking,
8(3) :281–293, 2000.
[16] I. Foster. What is the Grid ? A Three Point Checklist. Grid
Today, 1(6) :22, 2002.
[17] Michael J. Franklin, Michael J. Carey, and Miron Livny.
Global memory management in client-server database architectures. In Proc. of the Int. Conf. on VLDB, pages 596–609,
1992.
[18] Patrick Fuhrmann and Volker Gülzow. dcache, storage system for the future. In Euro-Par 2006, Parallel Processing,
12th International Euro-Par Conference, pages 1106–1113,
2006.
[19] S. Gadde, M. Rabinovich, and J. Chase. Reduce, reuse, recycle : An approach to building large internet caches. In
6th Workshop on Hot Topics in Operating Systems, page 93,
1997.
[20] Julien Gossa and Jean-Marc Pierson. End-to-end distance
computation in grid environment by nds, the network distance service. In Fourth European Conference on Universal
Multiservice Networks, 2007.
[21] David Karger, Alex Sherman, Andy Berkheimer, Bill Bogstad, Rizwan Dhanidina, Ken Iwamoto, Brian Kim, Luke
Matkins, and Yoav Yerushalmi. Web caching with consistent
hashing. Comput. Networks, 31(11-16) :1203–1213, 1999.
[22] Arthur M. Keller and Julie Basu. A predicate-based caching
scheme for client-server db architectures. The VLDB Journal, 5(1) :35–47, 1996.
[23] Adnan Khaleel and A. L. Narasimha Reddy. Evaluation of
data and request distribution policies in clustered servers. In
HiPC ’99 : Proceedings of the 6th International Conference
on High Performance Computing, pages 55–60, 1999.
[24] Dongwon Lee and Wesley W. Chu. Semantic caching via
query matching for web sources. In Proceedings of the
eighth international conference on Information and knowledge management, pages 77–85, 1999.
[25] Qiong Luo, Jeffrey F. Naughton, Rajasekar Krishnamurthy,
Pei Cao, and Yunrui Li. Active query caching for db web
servers. In 3rd Intl. WS on The WWW and DB, pages 92–
104, 2001.
[26] Jean-Marc Menaud, Valérie Issarny, and Michel Banâtre. A
new protocol for efficient cooperative transversal web caching. In Proceedings of the 12th International Symposium
on Distributed Computing, pages 288–302, 1998.
[27] Vivek S. Pai, Mohit Aron, Gaurov Banga, Michael Svendsen, Peter Druschel, Willy Zwaenepoel, and Erich Nahum.
Locality-aware request distribution in cluster-based network
servers. In ASPLOS-VIII : Proceedings of the eighth international conference on Architectural support for programming
languages and operating systems, pages 205–216, 1998.
[28] Qun Ren, Margaret H. Dunham, and Vijay Kumar. Semantic
caching and query processing. IEEE Transactions on Knowledge and Data Engineering, 15(1) :192–210, 2003.
[29] Alex Rousskov and Duane Wessels. Cache digests. Computer Networks and ISDN Systems, 30(22–23) :2155–2168,
1998.
[30] Nicholas Roussopoulos. An incremental access method for
viewcache : concept, algorithms, and cost analysis. ACM
Transactions on DB Systems, 16(3) :535–563, 1991.
[31] Vinod Valloppillil and Keith W. Ross. Cache array routing
protocol v1.0. Internet draft, 1998.
[32] Olivier Vanlentin, Fabrice Jouanot, Laurent d’Orazio, Yves
Denneulin, Claudia Roncancio, Cyril Labbé, Christophe
Blanchet, Pierre Sens, and Claude Bonnard. Gedeon, un intergiciel pour grille de données. In Conférence Française en
Système d’Exploitation, 2006.
[33] P. Vixie and D. Wessels.
(htcp/0.0), 2000.
Hyper text caching protocol
[34] Duane Wessels and K Claffy. ICP and the Squid Web
cache. IEEE Journal on Selected Areas in Communication,
16(3) :345–357, 1998.