Caches adaptables et applications aux systèmes de gestion de données répartis à grande échelle

Transcription

1 Institut National Polytechnique de Grenoble N attribué par la bibliothèque THÈSE pour obtenir le grade de DOCTEUR DE L INP Grenoble Spécialité : «Informatique : Systèmes et Logiciels» préparée au laboratoire Laboratoire d Informatique de Grenoble (LIG) dans le cadre de l École Doctorale «Mathématiques, Sciences et Technologies de l Information, Informatique (MSTII)» présentée et soutenue publiquement par Laurent D ORAZIO Le 17 décembre 2007 Titre : Caches adaptables et applications aux systèmes de gestion de données répartis à grande échelle Directeurs de thèse : Mme. Claudia Roncancio et M. Cyril Labbé JURY M. Jean-Luc Koning, Président M. Guy Bernard, Rapporteur M. Abdelkader Hameurlain, Rapporteur Mme. Claudia Roncancio, Directeur de thèse M. Cyril Labbé, Co-directeur de thèse M. Fabio Hernandez, Examinateur

2

3 Remerciements Je tiens à remercier Monsieur Jean-Luc Koning, professeur à l Institut Polytechnique de Grenoble pour avoir accepté de présider mon jury de thèse, ainsi que Monsieur Fabio Hernandez, ingénieur de recherche à l Institut National de Physique Nucléaire et de Physique des Particules pour avoir bien voulu faire partie des membres de mon jury. Je remercie Messieurs Guy BERNARD, professeur à l Institut National des Télécommunications d Evry et Abdelkader HAMEURLAIN, professeur à l Université Paul Sabatier de Toulouse, qui ont accepté de lire ce manuscrit. Je remercie le laboratoire d Informatique de Grenoble et Madame Christine Collet responsable de l équipe Hadas pour m avoir accueilli et offert les moyens d effectuer mes travaux de recherches dans les meilleures conditions. Je remercie mes responsables, Claudia et Cyril, pour la direction qu ils ont sue faire prendre à cette thèse et pour les précieux conseils distillés durant ces années. J espère ne pas avoir été pénible au point de leur donner envie de penser à une reconversion. Je remercie les membres de l équipe Hadas : Alberto, Alexandre, Christophe, Diana, Fabrice, Genoveva, Gia-Hien, Levent, Marie-Christine, Maria, Michel, Mehdi, Naga, Pierre, Rémi, Sattisvar, Victor. Je tiens également à remercier les «anciens», Gennaro, Khalid, Luciano, Mourad, Patricia, Pilli, Quynh, Stéphane, Tanguy, Trinh. Je remercie particulièrement Talal El-Katib qui lors de son stage a été d une grande aide pour l avancement de nos travaux en particulier grâce aux outils qu il a proposés pour le déploiement d expérimentations multi-échelles de caches sur grilles. Merci également aux membres du projet Gedeon, Pierre, Claude, Christophe, Yves sans qui la plupart des résultats obtenus dans cette thèse n aurait pu voir le jour. Un merci plus particulier à Olivier pour les réalisations logicielles qu il a accomplies et qui ont permis d expérimenter nos propositions. J ai eu la chance durant cette thèse de pouvoir exercer des activités d enseignement, qui ont parfois influencé l orientation de nos travaux. Je tiens donc à remercier les membres des équipes pédagogique qui m ont confié des responsabilités d enseignement : Jean-François, Jean-Marie, Laurent, Marie-Christine, Pascal et Vania. Mes derniers remerciements iront à ma famille au sens large et mes amis qui ont toujours été à mes côtés. Merci de m avoir soutenu et supporté (j imagine que cela n a pas été facile, tant j ai pu être pénible parfois). Mes derniers remerciements iront à ma moitié. Merci pour ton aide et tout le bonheur que tu m as apporté, que tu m apportes et que tu m apporteras. iii

4 iv

5 Table des matières 1 Introduction Caches Interrogation de données à grande échelle Objectifs de la thèse Contributions de la thèse État de l art des techniques et services de caches ACS : un canevas de caches adaptables Cache dual : optimisations pour l interrogation de données Caches sémantiques coopératifs Mise en œuvre et expérimentations Organisation du document I État de l art sur les techniques de cache et les caches adaptables 7 2 Concepts et techniques de cache Notion de cache Déploiement d un cache Support physique d un cache Permissions d accès Place du cache Entrée du cache Fonctionnalités élémentaires d un cache Recherche au sein du cache Remplacement d entrées du cache Résolution d un défaut de cache Fonctionnalités optionnelles d un cache Préchargement Politique d admission Cache négatif Politique d allocation Fonctionnalités gérées par des services externes au cache Contrôle de concurrence Synchronisation Conclusion Caches sémantiques et caches coopératifs Caches sémantiques Principes v

6 TABLE DES MATIÈRES Gestion de la sémantique Gestion du contenu du cache Caches coopératifs Principes Résolution verticale Résolution horizontale de défaut de cache Caches répartis Coopération hybride Autres techniques de coopération Conclusion Caches adaptables et caches pour la gestion de données à grande échelle Services de caches adaptables Perseus CaLi Autres services de caches adaptables Caches pour l interrogation de données à grande échelle dcache Sequoia Gestion intelligente de caches Squid Service uniforme de caches distribués pour calcul sur grille Conclusion II Caches adaptables et techniques pour le passage à l échelle des applications 49 5 ACS, un canevas de caches adaptables Aperçu du canevas de caches adaptables ACS Architecture d ACS Cache élémentaire Cache augmenté Interactions avec d autres fonctionnalités ACS et caches sémantiques Résultats de requêtes Prédicats et objets ACS et caches coopératifs Résolution verticale Résolution horizontale Caches répartis Composition des coopérations et coopérations entre caches hétérogènes Adaptation contextuelle de cache Gestion de contexte Adaptation à base de règles actives Conclusion Cache dual Aperçu de la proposition Spécification du cache dual vi

7 TABLE DES MATIÈRES Cache de requêtes Cache d objets Traitement de requêtes par le cache dual Cache dual sémantique Analyse de requêtes sur le cache de requêtes Évaluation de requêtes sur le cache d objets Cache dual et autres techniques de cache sémantique Cache dual et adaptabilité Allocation des ressources aux requêtes et aux objets Configurations du cache de requêtes et du cache d objets Association cache de requêtes et caches d objets Conclusion Caches sémantiques coopératifs Aperçu de la proposition Caches sémantiques coopératifs Caches sémantiques répartis Caches sémantiques avec résolution verticale Caches sémantiques avec résolution horizontale Composition de coopérations Résolution horizontale basée sur la proximité Notion de proximité entre caches Proximité et protocoles de résolution Cache dual coopératif Coopérations entre caches de requêtes Coopérations entre cache d objets Conclusion III Mise en œuvre des propositions et validations Validations dans un intergiciel pour la gestion de données bio-informatiques Prototype d ACS Architecture du canevas Bibliothèque de composants Utilisation dans un logiciel de sécurité réseau Contexte d expérimentation Aspect logiciel, intergiciel Gedeon Aspect matériel, déploiement sur grille Validation d ACS Mise en œuvre de caches élémentaires Mise en œuvre de caches sémantiques Mise en œuvre de caches sémantiques coopératifs Outils pour l évaluation de performance Génération de la charge de travail Métriques pour l interprétation des résultats Validation du cache dual Influence de l environnement d exécution Expérience grille Validation du cache sémantique coopératif vii

8 TABLE DES MATIÈRES Influence du concept de proximité au sein du cache dual Analyse des protocoles de résolution pour le cache dual Conclusion Conclusions et perspectives Bilan des contributions et limitations État de l art Canevas pour la construction de caches adaptables Cache dual Caches sémantiques coopératifs Perspectives de recherche Caches et hétérogénéité Analyses et évaluations dans les caches sémantiques Accès efficaces à des volumes importants de données Caches et gestion de la concurrence et de la cohérence à grande échelle Caches adaptables dynamiques dans des environnements variables. 153 viii

9 Table des figures 2.1 Fonctionnement d un cache Fonctionnement d un cache sémantique Confrontation entre une requête et une entrée Recouvrements Cache sémantique de résultats de requêtes Cache sémantique de prédicats et objets Résolution verticale de défaut de cache Résolution horizontale de défaut de cache Caches répartis Architecture d ACS Ajout d un élément en cache Interactions entre les gestionnaires de contenu et de remplacement Interactions entre les gestionnaires de cache et de résolution dues à une résolution de défaut de cache Interactions entre le gestionnaire du cache et les sous-composants lors d un chargement Interactions entre le gestionnaire du cache et les sous-composants lors d une recherche Interactions entre le gestionnaire de cache et l analyseur de requêtes Interactions entre le gestionnaire de cache et l évaluateur de requêtes Interactions entre les gestionnaires de cache et d admission Interactions entre le gestionnaire de cache et le cache négatif Interactions lors d une résolution verticale Interactions lors d une résolution horizontale par inondation Interactions lors d une résolution horizontale à l aide d un catalogue Interactions lors d une demande sur des caches répartis Architecture du cache contextuel Concept source de données Concept interrogation de cache Exemple de règle active Exemple de règle active avec changement dynamique de composants Exemple de contenu d un cache dual Exemple d un enregistrement Swiss-Prot Exemple de cache dual avec une gestion fortement couplée Cache dual sémantique Cache dual et multiples caches d objets ix

10 TABLE DES FIGURES 7.1 Exemple de déploiement de caches pour un système d interrogation de données Caches sémantiques répartis Cache sémantique et résolution verticale Cache sémantique et résolution horizontale Caches sémantiques avec coopération hybride Cache dual et protocole de résolution sémantique Cache dual et protocole de résolution physique Création de lien et paramétrisation de composant Union de serveurs Création d un cache élémentaire pour Gedeon avec ACS Influence de la localité sémantique (sur un cache de 500 Mo) Influence de la localité sémantique sur le cache dual en terme de charge sur le serveur Influence de la taille du cache (pour une localité sémantique de 60 %) Influence de la taille d un cache dual en terme de charge sur le serveur Résolution basée sur la proximité physique Résolution basée sur la proximité sémantique x

11 Liste des tableaux 4.1 Caractéristiques des services de caches adaptables Caches pour les systèmes d interrogation de données à grande échelle Format de la table jour Caractéristiques des nœuds de Grid5000 utilisés pour les expérimentations Caractéristiques des protocoles de résolution pour cache dual Métriques de performances de caches sémantiques dans un contexte grille Métriques de performance de protocoles coopératifs dans un contexte grille 143 xi

12 xii LISTE DES TABLEAUX

13 Chapitre 1 Introduction Ce premier chapitre présente le contexte de notre travail (section 1.1), la problématique à laquelle nous nous sommes intéressés (section 1.2) les objectifs (section 1.3) et résultats (section 1.4) de nos recherches et pour finir l organisation du document (section 1.5). 1.1 Caches Les caches sont des espaces physiques limités permettant de stocker des copies d objets autorisant des accès plus rapides pour de futures utilisations. Le principe d un cache consiste à conserver des copies des objets demandés par des utilisateurs ou des applications, évitant ainsi de contacter les serveurs si ces objets sont de nouveaux référencés. L utilisation des caches a toujours été un choix important dans les systèmes informatiques (systèmes d exploitation, systèmes de gestion de bases de données, systèmes de gestion de fichiers, ou encore Internet) pour l amélioration des performances. Les caches doivent leur popularité et leur importance à différents facteurs. Ils sont avant tout utilisés pour améliorer les performances, notamment en réduisant les temps d attente perçus par les clients. Cette réduction provient généralement d un support physique permettant un accès plus efficace aux données, d un placement réduisant les coûts de communications, mais également d une réduction de la charge sur les serveurs et de la consommation de la bande passante, du fait du traitement d une partie des demandes localement. Les ressources stockées en cache offrent également une certaine disponibilité en cas de panne des sources de données. Les caches sémantiques permettent d exploiter les ressources en cache et la connaissance contenue dans les requêtes elles-mêmes. Par conséquent, ils autorisent un raisonnement efficace, une partie du processus de calcul est alors exécuté en cache, réduisant à la fois les transferts de données et la charge sur les serveurs. Quand une requête est posée, elle est décomposée en deux sous-requêtes, la première permettant de récupérer la portion de résultat disponible en cache, la seconde étant utilisée pour rapatrier la partie absente. En général, lorsque les objets demandés ne sont pas présents en cache, ils sont récupérés sur les serveurs. Les serveurs peuvent cependant devenir des goulots d étranglement. C est pourquoi, utiliser d autres caches pour récupérer les objets souhaités, en contactant les serveurs en dernier recours, peut réduire à la fois la charge sur les serveurs et le volume 1

14 Chapitre 1 : Introduction de données transférées sur certains liens de communication sensibles. 1.2 Interrogation de données à grande échelle L hétérogénéité des dispositifs, des architectures systèmes et des besoins des applications pour l accès aux données mènent à une grande diversité de caractéristiques à prendre en compte pour fournir un cache. Les caches peuvent ainsi différer en plusieurs aspects, telles que les informations manipulées, ou encore les politiques de remplacement ou de résolution employées. L amélioration des performances étant fortement liée à la configuration du cache en fonction de l environnement d exécution, les caches sont très souvent construits de bout en bout, rendant le développement coûteux (en temps et en argent). Ceci est plus particulièrement problématique dans les contextes grande échelle, comme les grilles, où de nombreux caches peuvent être nécessaires. Il faut, de plus, noter que les environnements applicatifs sont très souvent dynamiques. Ainsi, une configuration choisie pour un cache, à un instant donné, peut être remise en cause en fonction de certaines modifications de l environnement. L utilisation de caches est primordiale pour fournir des intergiciels efficaces d interrogation multiples sources largement réparties. Les performances de tels intergiciels dépendent de nombreux facteurs, notamment les capacités d évaluation sur les serveurs, mais également des débits proposés par les différents liens de communication. Les caches sémantiques augmentent le travail d évaluation en cache pour réduire le nombre de requêtes évaluées sur les serveurs, mais stockent également les objets correspondants pour limiter les transferts de données. Malheureusement, les propositions existantes ne permettent pas une distinction fine de ces deux aspects. Ainsi, il est impossible de conserver en cache des résultats de requêtes lorsque les objets correspondants sont trop importants pour être stockés. Par conséquent, ces approches limitent l amélioration des performances dans des contextes manipulant de grandes masses de données. Dans les applications à large échelle, où de nombreux clients manipulent de gros volumes de données répartis sur différents sites, le nombre de caches est souvent important, rendant pertinent l utilisation de coopérations entre caches. Néanmoins, toutes les coopérations ne sont pas nécessairement intéressantes. C est pourquoi, il est important de distinguer celles qui sont efficaces de celles qui pourraient dégrader les performances. Malheureusement, de nombreux paramètres, notamment physiques et sémantiques, peuvent être pris en compte. Par conséquent, la création de groupes de caches appropriés peut être difficile. 1.3 Objectifs de la thèse L un des objectifs de cette thèse est de fournir un service de caches adaptables statiquement et dynamiquement. Des caches finement configurés, et donc efficaces, pourront ainsi être fournis pour diverses applications. Les configurations pourront, de plus, être modifiées, si nécessaire, en fonction des variations du contexte, afin d assurer une bonne qualité de service. L utilisation d un service de caches adaptables est particulièrement pertinente pour faciliter l administration et améliorer les performances dans des systèmes variables à grande échelle, à l image des grilles. La facilité de développement des caches 2

15 1.4 Contributions de la thèse permet ainsi de tester divers placements et différentes configurations, mais également de proposer de nouvelles techniques. Cette thèse s intéresse également à l optimisation des performances dans les systèmes d interrogation largement distribués. Dans ce contexte, des techniques de cache sophistiquées peuvent être mises en place. Il est ainsi possible de tirer profit des ressources disponibles localement en offrant des capacités d évaluation au sein des caches. Il est aussi envisageable de profiter des caractéristiques matérielles ou applicatives pour mettre en œuvre des coopérations entre caches. Ces techniques doivent néanmoins être utilisées avec précaution pour ne pas dégrader les performances. C est pourquoi il est important de fournir des outils pour faciliter le travail de configuration. 1.4 Contributions de la thèse Cette thèse s intéresse premièrement à une analyse des travaux existants sur les caches et leurs applications dans des systèmes d interrogation de données largement distribués. Elle présente ensuite nos propositions pour fournir un service de caches adaptables, ainsi que de nouvelles approches de caches sémantiques et coopératifs. Ces différentes propositions sont ensuite mises en œuvre dans des contextes applicatifs différents État de l art des techniques et services de caches Il existe un très grand nombre de caches dans la littérature, pour différents systèmes informatiques. Les caches diffèrent en plusieurs aspects, tels que le placement du cache [Gla94, LA94, AKS98, ACPS96], les informations manipulées [DFMV90, DFJ + 96], les politiques de remplacement [Bel66, ASA + 96, CI97, CD98, LCK + 01, JZ03] ou de résolution employées [CDN + 96], ou encore la prise en compte de stratégies optionnelles, comme le préchargement [Smi82, GS95, CGFZ03] ou l admission [ASA + 95, SSV96]. Afin de fournir un service de caches adaptables, nous avons proposé une classification des caractéristiques pouvant intervenir. Ce document s intéresse notamment à deux types de cache particuliers : les caches sémantiques et les caches coopératifs. Les caches sémantiques [CKS99, KB96, DFJ + 96, GG97, ZL01, RDK03, ZZP + 03, HXW + 05] permettent de déléguer une partie du processus d évaluation au sein des caches, en tirant profit de la connaissance stockée. Les caches coopératifs [Smi82, FCL92, DHS93, BCC + 95, CDN + 96, PAB + 98, WVS + 99, BO00, FCAB00, Cec02, CYD04] autorisent un partage de ressources entre caches et donc une meilleure répartition de la charge d évaluation et des transferts de données. Différents travaux visent à proposer des services de caches adaptables [GB03, Zol04, mem, cac, joc, osc, ehc, jcs] ou des services de caches intégrant les techniques de cache sémantique [AZQ05] et coopératif [FG06, squ, CPB05] pour l interrogation de données dans des environnements à grande échelle. Néanmoins, comme nous le verrons, les propositions existantes peuvent être améliorées. 3

16 Chapitre 1 : Introduction ACS : un canevas de caches adaptables Notre première proposition, ACS (Adaptable Cache Service), vise à faciliter le développement de caches appropriés pour des applications ou des intergiciels présentant des caractéristiques spécifiques ou des besoins particuliers. ACS permet alors de se focaliser plus sur les problèmes de configuration ou de choix des stratégies employées que sur les difficultés d implantation de la solution. Le canevas ACS correspond à un cache générique réutilisable, représenté par un ensemble de classes abstraites, capturant les interactions entre les instances de ces dernières. Un cache créé avec ACS peut être reconfiguré dynamiquement, afin d offrir des performances optimales, même en cas d évolution de l environnement. Cette propriété est obtenue en utilisant les technologies orientées composants. Une caractéristique d un cache est alors modifiée en changeant les valeurs des paramètres des composants, ou les composants eux-mêmes. Les caches d ACS peuvent être construits pour des systèmes présentant différentes contraintes et caractéristiques, comme par exemple les systèmes pair-à-pair, ou encore les environnements mobiles. Nos travaux sont particulièrement portés sur l utilisation de caches dans un intergiciel pour l interrogation de sources de données sur grilles. Différents types de caches peuvent être utilisés, notamment des caches de données et des caches de requêtes. Ces derniers visent spécialement à optimiser l utilisation des ressources disponibles localement, en intégrant des techniques de cache sémantique. De nombreuses instances de ces différents types de cache peuvent être fournies, une instance pouvant être déployée sur chaque nœud de la grille. Cette quantité importante de caches offre alors des perspectives intéressantes de coopération, permettant de fournir un système hautement performant. L adaptation contextuelle des caches que nous envisageons au sein du canevas vise à intégrer les solutions proposées en informatique autonomique et en informatique contextuelle, afin de fournir des caches capables de s adapter aux modifications de leur contexte applicatif. Notre approche consiste à séparer les préoccupations, permettant une observation haut niveau de l environnement, tout en offrant la possibilité d une reconfiguration fine de l architecture pour modifier une configuration optimale à un instant donné qui ne le serait plus à cause, par exemple, de changements des séquences d accès aux données, de la disponibilité des ressources, ou encore des performances réseaux Cache dual : optimisations pour l interrogation de données Notre deuxième contribution, appelée cache dual, a pour but d améliorer les performances dans les systèmes d interrogation de données. Le cache dual se base sur la coopération entre deux caches distincts (et en général co-localisés). Le premier, utilisé pour conserver des résultats de requêtes sans stocker les objets correspondants, vise à minimiser la charge d évaluation sur les serveurs. Le second, dont le rôle est le stockage temporaire des objets, a pour objectif de réduire autant que faire ce peut les transferts de données avec les serveurs. La distinction de ces deux caches offre une flexibilité importante. Le cache proposé peut ainsi être finement configuré en fonction des objectifs fixés. Cette approche optimise de plus l utilisation de l espace physique. En effet, elle évite la duplication d objets partagés par différentes requêtes gardées en cache. Le cache dual 4

17 1.4 Contributions de la thèse est d autant plus prometteur dans les systèmes manipulant des masses de données importantes, puisqu il permet de relâcher la cohérence entre les deux caches, autorisant le stockage d évaluations, même si les objets correspondants sont trop volumineux pour être conservés. Le cache dual peut également intégrer des outils pour l analyse et l évaluation des requêtes, permettant alors de proposer une approche de cache sémantique. Un cache dual sémantique est orthogonal, et peut donc être utiliser conjointement, à d autres techniques d optimisation d évaluations de requêtes distribuées, à l image par exemple des agents mobiles [HM06] Caches sémantiques coopératifs Nous proposons également 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 exemple, les conditions du réseau) ou des aspects plus sémantiques concernant les centres d intérêt des communautés travaillant sur 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 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 pour les caches sémantiques. Nous les avons appliquées au cache dual. La définition de la coopération peut alors se faire à un niveau relativement fin en précisant une stratégie de coopération pour les caches de requêtes et les caches d objets Mise en œuvre et expérimentations Nous avons développé un prototype de notre canevas de caches adaptables ACS. Ce prototype a d abord permis de valider la facilité de conception de caches. Il est ensuite utilisé pour mettre en œuvre nos différentes propositions, le cache dual et la coopération entre caches sémantiques basée sur le concept de proximité. Il a alors été possible d évaluer les performances de ces approches dans un contexte de gestion de données largement distribuées. Nous avons utilisé l intergiciel Gedeon [VJd + 06]. Gedeon permet la gestion de fichiers sur grilles et offre des capacités d interrogation par requêtes déclaratives. Les résultats obtenus dans des expérimentations à l aide de données bio-informatiques montrent de bonnes performances. Nous avons également proposé des caches pour EX- TRA [ext] une application de surveillance du trafic réseau. A noter que le prototype d ACS, contenant des instances pour les contextes considérés du cache dual et de la coopération basée sur une proximité, est disponible et peut être utilisé pour le développement de nouvelles applications. 5

18 Chapitre 1 : Introduction 1.5 Organisation du document Le document est structuré en trois parties : «État de l art sur les techniques de cache et les caches adaptables», «Caches adaptables et techniques pour le passage à l échelle des applications»et «Mise en œuvre des propositions et validations». La première partie «État de l art sur les techniques de cache et les caches adaptables»identifie les problèmes liés à la proposition d un service de caches adaptables, notamment pour des systèmes de gestion de données largement distribués. Le chapitre 2 présente un état de l art sur les caractéristiques des caches. Le chapitre 3 s intéresse plus particulièrement aux techniques employées pour le passage à l échelle. Le chapitre 4 présente les services de caches adaptables et les caches utilisés pour la gestion de données largement distribuées. La deuxième partie «Caches adaptables et techniques pour le passage à l échelle des applications»présente les propositions de cette thèse. Le chapitre 5 présente ACS un canevas pour la construction de caches adaptables. Le chapitre 6 propose un cache sémantique pour les systèmes d interrogation de données à grande échelle. Le chapitre 7 introduit nos propositions de caches sémantiques coopératifs et une fonction générique pour définir la stratégie de coopération à utiliser. La dernière partie «Mise en œuvre des propositions et validations»présente les validations de nos résultats de recherche. Le chapitre 8 présente d abord un prototype du canevas ACS pour la construction de caches adaptables. Ce prototype est ensuite utilisé pour valider nos différentes propositions dans un intergiciel de gestion de données sur grilles, appliqué à la bio-informatique. Finalement, le chapitre 9 conclut cette thèse en dressant un bilan du travail réalisé, avant de fournir quelques perspectives de recherche. 6

19 Première partie État de l art sur les techniques de cache et les caches adaptables 7

20

21 Chapitre 2 Concepts et techniques de cache L objectif de ce chapitre est de définir la notion de cache et les concepts associés, avant de présenter les caractéristiques considérées au sein d un cache afin de mieux comprendre la difficulté de proposer un service de caches adaptables. Ce chapitre est organisé de la manière suivante. La section 2.1 présente le concept de cache tel qu il sera utilisé dans ce document. La section 2.2 s intéresse aux caractéristiques d un cache liées au déploiement. Les fonctionnalités élémentaires et optionnelles d un cache sont alors étudiées dans les sections 2.3 et 2.4. La section 2.5 s intéresse quant à elle aux fonctionnalités utilisées par un cache mais gérées par d autres services. Finalement, la section 2.6 conclut ce chapitre. 2.1 Notion de cache Définition 2.1. Cache Espace physique d accès rapide, généralement de taille limitée, utilisé pour stocker des copies des éléments les plus susceptibles d être référencés. L utilisation d un cache a toujours été importante dans les systèmes informatiques, afin de fournir une haute qualité de service et notamment une amélioration des temps de réponse perçus par les utilisateurs. En effet, un cache fournit un accès rapide aux données, pouvant tirer bénéfice de l utilisation d un support physique efficace, d un ensemble d éléments gérés plus petit autorisant des recherches plus rapides, ou encore d un placement évitant des communications réseaux. De plus, employer un cache réduit la charge sur les serveurs et éventuellement sur les liens de communication, la récupération des éléments étant alors plus rapide. Ainsi un cache améliore généralement les performances, en dépit des coûts de déploiement, d administration, de gestion et éventuellement des problèmes de cohérence qu il peut engendrer. Le fonctionnement classique d un cache est illustré par la figure 2.1. A la suite d une demande d un client (1), un cache vérifie la présence de l élément dans son espace de stockage. Si celui-ci est contenu en cache (succès de cache ou cache hit), il est fourni directement au client (2). Dans le cas contraire (défaut de cache ou cache miss), il est 9

22 Chapitre 2 : Concepts et techniques de cache Fig. 2.1 Fonctionnement d un cache nécessaire de contacter le serveur (2 ) afin de le récupérer (3 ). Le cache renvoie l élément (4 ) au client et le stocke pour une utilisation future. A noter qu en général, l utilisation du cache est transparente, le client n ayant pas conscience qu il accède aux données au travers d un cache. Cependant, la transparence est parfois levée, comme par exemple dans [BP94], permettant notamment à un client de contacter directement le serveur s il veut s assurer d obtenir la dernière version d un élément. Définition 2.2. Succès de cache Un succès de cache (cache hit) se produit, lorsque l élément demandé est présent en cache. Définition 2.3. Défaut de cache Un défaut de cache (cache miss) se produit, lorsque l élément demandé n est pas présent en cache. 2.2 Déploiement d un cache Cette section présente les caractéristiques liées au déploiement d un cache : le support physique, la taille, le droit de modification et la place d un cache Support physique d un cache Définition 2.4. Support physique de cache Le support physique correspond au matériel utilisé pour stocker les différents éléments placés en cache. Le concept de cache est souvent associé à la notion de mémoire. En effet, il s agit du premier support utilisé et de nos jours, un très grand nombre de caches reposent sur ce support physique, comme dans le système de fichiers Sprite [NWO88] par exemple. Néanmoins, il convient de noter que des caches disques sont proposés dans différentes applications, comme les systèmes de fichiers (notamment Andrew [MSC + 86, HKM + 87]), les systèmes de gestion de base de données client serveur [DR92] ou encore dans la plupart des caches Internet. Alors qu un cache mémoire offre un accès aux données plus rapide, un disque quant à lui fournit un espace de stockage plus important et surtout une persistance 10

23 2.2 Déploiement d un cache du contenu. Bien sûr, ces deux solutions peuvent être combinées, comme dans [FCL93], où un cache mémoire est utilisé en premier lieu, avec traitement de la demande par un cache disque si nécessaire Permissions d accès Les entrées d un cache peuvent être accédées en lecture ou en écriture. Les permissions d accès caractérisent les opérations autorisées sur les éléments stockés en cache. Elles peuvent être globales au cache, mais également liées aux éléments ou aux clients. Autoriser les modifications au sein d un cache engendre une synchronisation plus complexe des différentes copies que pour une approche lecture seule. Néanmoins, cette approche fournit une plus grande autonomie, évitant par exemple des communications coûteuses dans les environnements mobiles Place du cache Dans le cas des applications réparties, un cache peut être exécuté sur un client (cache client), sur un serveur (cache serveur) ou encore sur une machine intermédiaire (cache intermédiaire). Avec un cache client, chaque utilisateur ou application dispose de son propre cache. Ainsi, la charge sur les serveurs et l utilisation de la bande passante sont plus faibles puisque une partie des demandes est traîtée localement. En cas de panne des serveurs, ou d une déconnexion, un cache client fournit même une certaine disponibilité, les éléments ayant été chargés et stockés pouvant être utilisés. Cette approche est particulièrement intéressante pour le passage à l échelle, les ressources étant alors proportionnelles au nombre de clients. De plus, le cache n étant utilisé que par un unique client, il est possible d avoir une idée précise des éléments devant être conservés en cache. Contrairement à un cache client, un cache serveur peut être partagé entre différents utilisateurs ou différentes applications. Dans ce cas, une seule copie est stockée en cache, permettant d optimiser l utilisation de l espace physique global (contrairement à un cache client, où dans le pire des cas, le nombre de copies peut être égal au nombre de clients) et facilitant la gestion des mises à jour. Le partage du cache permet aussi de mieux caractériser les éléments les plus référencés globalement et éventuellement d anticiper leurs demandes. Avec un cache intermédiaire, le cache est associé à un serveur applicatif particulier, déployé sur une machine dédiée. Des caches intermédiaires ont ainsi été proposés dans les systèmes de médiations 1, tels que SIMS [AK94, AKS98] et HERMES [AS95, ACPS96], ou encore dans des serveurs mandataires pour Internet comme Relai (Relay) [Gla94] ou le serveur mandataire du Centre Européen de Recherches Nucléaires (CERN) [LA94]. A noter que le service applicatif est parfois uniquement consacré au cache. Bien que par leur caractère souvent organisationnel, les caches intermédiaires soient généralement déployés du côté des clients, ils arrivent qu ils soient placés à proximité des serveurs [TNNE02]. On parle dans ce cas de serveur mandataire inversé (reverse proxy). Un cache intermédiaire peut être vu comme un compromis intéressant entre un cache client et un cache serveur. Comme un cache client, il diminue la charge sur le serveur et, s il est placé proche des 1 Le cache est alors placé sur le médiateur [Wie92] 11

24 Chapitre 2 : Concepts et techniques de cache clients, réduit les communications et l utilisation de la bande passante. Comme un cache serveur, il partage son contenu pour différents clients, optimisant ainsi l espace physique disponible et permettant de déterminer les éléments les plus globalement utilisés, autorisant l intégration d algorithmes efficaces de prédiction. Contrairement à un cache serveur pour lequel les demandes peuvent diverger et ainsi dégrader les performances, un cache intermédiaire est souvent placé à un niveau institutionnel, les utilisateurs étant susceptibles d accéder à un même sous ensemble d éléments. Enfin, à l instar d un cache client, un cache intermédiaire offre une certaine disponibilité Entrée du cache Les entrées du cache correspondent aux éléments manipulés au sein du cache. Le type d une entrée dépend du contexte applicatif et en particulier de l architecture utilisée. Ainsi dans les systèmes de gestion de bases de données, les éléments en cache sont souvent des pages ou des objets (correspondant à des n-uplets). Dans les caches d objets [DFMV90], les entrées manipulées sont des objets (des n- uplets dans le cas des systèmes de gestion de bases de données). Un cache d objets est ainsi insensible au regroupement des données effectué du côté du serveur, puisque les accès se font en terme d objets et non en terme de groupes comme pour les caches de pages. Ceci permet notamment une utilisation de l espace physique plus efficace, puisque tous les objets présents en cache correspondent à des objets référencés par l utilisateur ou l application (sauf dans le cas d un chargement anticipé). Le fait de ne mettre en cache que des objets référencés optimise également la consommation de la bande passante. Enfin, la gestion de la concurrence est plus fine, puisque le verrouillage peut se faire au niveau des objets, évitant de bloquer l accès à des éléments non utilisés à un moment donné. Avec un cache de pages [DFMV90], les transferts depuis le serveur se font en terme de pages disque. Avec cette approche, le coût d accès des éléments en cache est réduit, une page représentant une agrégations d objets. Un regroupement efficace des objets permet de plus d anticiper de futures demandes des clients. En effet, si les pages rassemblent les objets qui ont une forte probabilité d être accédés dans un même intervalle de temps, alors la récupération de la page associée à un objet demandé permettra d éviter de contacter le serveur pour obtenir les autres objets qu elle contient. A noter que dans les systèmes de fichiers pour grille, le bloc [HN06], tout comme une page, représente une unité de transfert de taille fixe. Contrairement à une page qui regroupe différents objets, un bloc permet le découpage des fichiers dont la taille trop importante pourrait dégrader les performances de l application. Dans les systèmes d interrogation de données, les accès aux éléments du cache peuvent se faire en terme de résultats de requêtes, une entrée associant alors une requête aux objets réponses, rendant la recherche en cache ou la récupération de données sur le serveur moins coûteuses. Contrairement à une page, la taille des résultats de requêtes est variable. Ce mécanisme permet en particulier de ne pas garder des objets non référencés en cache et d optimiser l utilisation de la bande passante. Il est à noter que ce type d entrée est en particulier utilisé dans les caches sémantiques qui seront étudiés dans le chapitre 3. 12

25 2.3 Fonctionnalités élémentaires d un cache 2.3 Fonctionnalités élémentaires d un cache Le fonctionnement d un cache repose sur un ensemble de fonctionnalités dont certaines sont nécessaires pour fournir le service souhaité et d autres optionnelles pour améliorer les performances obtenues. Dans cette section, nous nous intéressons aux fonctionnalités élémentaires d un cache : la recherche, le remplacement et la résolution Recherche au sein du cache Lorsqu une demande est posée, l élément correspondant est recherché au sein du cache. Puisque la recherche d un élément est un évènement fréquent, le cache doit fournir des méthodes efficaces pour fournir cette stratégie. Cette fonctionnalité est capturée dans la politique de recherche du cache. La politique de recherche est fortement liée à la structure de données utilisée. Le choix d une structure de données dépend d un compromis entre la complexité de gestion des données et l efficacité des recherches. Ainsi en fonction du contexte applicatif, des structures simples nécessitant des parcours séquentiels, tels que des listes, des tableaux ou des structures plus complexes offrant des accès plus performants, à l instar des tables de hachage, peuvent être employées Remplacement d entrées du cache La taille des caches correspond en général à une variable, dont la valeur peut être choisie en fonction des objectifs fixés. Néanmoins elle est, dans la plupart des cas, limitée. C est pourquoi, un cache doit être capable de supprimer certaines de ses entrées pour pouvoir en accepter de nouvelles. Le but d une politique de remplacement est de maximiser l utilité du cache, en minimisant le nombre, ou encore le coût des défauts en remplaçant les entrées qui sont le moins à même d être utilisées dans un avenir proche. Dans [Bel66], la politique de remplacement est définie comme la procédure visant à déterminer les éléments à supprimer lorsque la taille globale des éléments présents en cache dépasse la taille de l espace physique. Ici, nous reprenons cette définition en relâchant la contrainte sur le moment du remplacement. Dans certains cas, il peut en effet être intéressant de ne pas attendre que le cache soit plein pour supprimer des entrées. Nous donnons donc la définition suivante pour la politique de remplacement. Définition 2.5. Politique de remplacement La politique de remplacement est utilisée pour déterminer les entrées du cache à remplacer, appelées victimes. Il n existe pas de politique de remplacement meilleure que les autres pour toutes les séquences d accès. C est pourquoi, de nombreuses solutions sont proposées dans la littérature. Le choix d une politique est fortement lié à l application et aux objectifs fixés par le développeur de la solution de cache. Les politiques de remplacement peuvent, en particulier, s appuyer sur le principe de localité pour le choix des éléments à supprimer, notamment sur la localité spatiale ou la localité temporelle dont les définitions sont 13

26 Chapitre 2 : Concepts et techniques de cache données ci-dessous. Définition 2.6. Localité spatiale [Lob00] La localité spatiale stipule que, plus un élément est proche d un autre qui vient d être référencé, plus il a de chance d être accédé à son tour. Définition 2.7. Localité temporelle [Lob00] Le principe de la localité temporelle stipule qu un élément récemment accédé a de grandes chances d être de nouveau référencé. La politique aléatoire (random) [Bel66] est une des stratégies les plus simples à développer. Avec cette stratégie, la victime est choisie au hasard. Bien que cette politique soit adaptée à des accès uniformes aux éléments du cache, elle n est pas vraiment optimale. En effet, elle peut conduire à la suppression d éléments populaires. Elle constitue néanmoins une référence pour juger d autres politiques. En effet, une stratégie peut être qualifiée d «efficace»si elle parvient à utiliser l information dont elle dispose (moment d accès, taille des entrées, etc.) de manière à engendrer moins de défauts que la politique aléatoire, qui n a besoin d aucune information, ni gestion supplémentaires. Différentes politiques de remplacement se basent sur le moment d entrée d un élément en cache. Ainsi les politiques FIFO (First In First Out) du premier entré premier sorti et LIFO (Last In First Out) du dernier entré premier sorti choisissent respectivement le premier et le dernier élément ajouté en cache comme victime du remplacement. Ces politiques engendrent peu de surcoût pour la gestion des entrées, puisque la seule information nécessaire est le moment d entrée. Malheureusement, des éléments populaires peuvent être choisis comme victime. De plus, ces politiques souffrent de l anomalie de Belady. Autrement dit, augmenter les ressources physiques allouées au cache peut accroître le nombre de défauts. Par exemple, avec la séquence d accès , un cache de trois éléments utilisant la politique FIFO produit neuf défauts, alors que ce nombre s élève à dix pour un cache de quatre éléments. Définition 2.8. Anomalie de Belady [BNS69] L anomalie de Belady caractérise un cache dont l augmentation de l espace physique ne produit pas une réduction du nombre de défauts. Certaines politiques de remplacement prennent en compte le moment d utilisation des entrées présentes en cache. Pour ce faire, le cache garde comme information le moment où un élément a été accédé pour la dernière fois. Il est, par conséquent, nécessaire de modifier cette information à chaque fois qu un élément est utilisé. Les politiques LRU (Least Recently Used) de l élément le moins récemment utilisé et MRU (Most Recently Used) de celui le plus récemment utilisé choisissent l élément, respectivement le moins et le plus récemment utilisé, comme victime. La première politique est utile pour une forte localité temporelle. La deuxième est plus particulièrement utile pour les séquences d accès cycliques, puisqu un élément qui vient d être accédé est sans doute celui qui sera le plus tardivement accédé à l avenir. 14

27 2.3 Fonctionnalités élémentaires d un cache Une autre approche possible consiste à remplacer les éléments en fonction de leur fréquence d utilisation. Le choix de la victime du remplacement se fait alors en fonction du nombre d accès à un élement depuis que celui-ci est présent en cache. Parmi ces politiques, nous pouvons citer NFU (Not Frequently Used), NRU (Not Recently Used) ou encore LFU (Least Frequenlty Used)). Il est à noter qu il est parfois nécessaire d utiliser un autre mécanisme pour différencier deux éléments ayant la même fréquence d utilisation. Ainsi, LFUPP Least Frequenlty Used with Periodicity and Priority [KCB04] est une variante de LFU, qui intègre une notion de priorité (réinitialisée périodiquement) pour distinguer les éléments de plus faible fréquence. La taille des entrées peut également être considérée lors du choix des victimes du remplacement. En effet, il est parfois intéressant de favoriser la suppression d éléments de grande taille, plutôt que de supprimer de nombreux éléments de petite taille pour libérer un espace équivalent. Ainsi, avec SIZE [ASA + 96], les éléments remplacés correspondent aux entrées du cache les plus volumineuses. Comme pour le remplacement sur la fréquence d utilisation, un autre mécanisme de décision doit être proposé pour des éléments de taille équivalente (par exemple, différencier les éléments en utilisant LRU). Certaines politiques de remplacement reposent sur un rapport coût/bénéfice pour déterminer les éléments à supprimer, comme suggéré dans [BH96]. Ce rapport peut être calculé de différentes manières. Le coût peut ainsi correspondre à la complexité de l évaluation, comme dans LNC-R (Least Normalized Cost Replacement) qui intègre dans le choix de la victime du remplacement le coût de calcul de l entrée, en plus de la taille et des moments d utilisation. Ceci permet notamment de privilégier un calcul d une jointure, plutôt que le résultat d une projection. Le coût peut aussi prendre en compte le temps de récupération des éléments, comme dans GDS (Greedy Dual Size) [CI97]. Le bénéfice peut, quant à lui, être exprimé en fonction du moment d utilisation d une entrée, les éléments les plus récemment utilisés pouvant être considérés comme les plus pertinents à conserver. A noter que parfois le bénéfice est également pris en compte pour les éléments absents du cache, comme dans LVCT Least Value Based on Caching Time [JZ03]. Cette valeur peut alors être utilisée par la politique d admission pour éviter qu une entrée ne soit ajoutée au détriment d éléments plus intéressants. Les différentes politiques de remplacement présentées jusqu à maintenant sont orthogonales. En conséquence, elles peuvent être combinées, de plusieurs façons, en vue de proposer d autres stratégies. Il est d abord possible de choisir la victime en fonction de plusieurs caractéristiques. Par exemple, certains caches Internet choisissent les victimes en considérant conjointement la fréquence et le moment d utilisation [PR94] [RP96], à l instar de LRFU (Least Recently/Frequently Used) [LCK + 01]. D autres approches consistent à distinguer différents groupes d entrées et à appliquer des stratégies différentes pour chacun d eux. Ceci est notamment le cas dans les systèmes de gestion de bases de données utilisant la politique de remplacement DBMIN [CD98], où les politiques MRU et LIFO sont utilisées respectivement pour les séquences cycliques et cycliques hiérarchiques, alors que la politique LRU est appliquée pour les séquences n appartenant à aucun groupe particulier Résolution d un défaut de cache Le protocole de résolution capture l ensemble des actions à effectuer afin de résoudre un défaut de cache. En particulier, elle détermine la source de données utilisée, notam- 15

28 Chapitre 2 : Concepts et techniques de cache ment si plusieurs serveurs sont disponibles ou s il est possible de contacter d autres caches (le cas des résolutions entre caches sera étudié en détail dans le chapitre 3). D autres considérations peuvent également être abordées, comme par exemple, la gestion des communications ou encore la gestion de connexion sécurisée (dans ce cas le protocole de résolution peut, par exemple, fournir un identifiant et un mot de passe). Définition 2.9. Protocole de résolution [CDN + 96] Le protocole de résolution définit la procédure exécutée pour récupérer des éléments lorsque des défauts de cache se produisent. 2.4 Fonctionnalités optionnelles d un cache Les fonctionnalités optionnelles d un cache regroupent des techniques tels que le préchargement, la politique d admission, la mise en cache négative ou encore l allocation des ressources. Ces fonctions engendrent des coûts supplémentaires à la gestion du cache et doivent par conséquent être intégrées avec prudence. Cependant, si elles sont judicieusement appliquées, la qualité du service de cache est améliorée Préchargement Définition Préchargement [Smi82] Les algorithmes de préchargement visent à récupérer des éléments non encore demandés mais susceptibles de l être dans un avenir proche. La plupart du temps, l ajout d un élément en cache se fait à la suite d une demande d un utilisateur ou d une application. Néanmoins, d autres évènements peuvent être à l origine de cette création. Dans un contexte sans fil, une unité mobile peut profiter d une connexion à un réseau pour récupérer un ensemble d éléments qu elle pourra éventuellement utiliser plus tard en mode déconnecté [CGFZ03]. Dans une hiérarchie de caches Internet, si le nombre de demandes d un élément dépasse un certain seuil sur un cache de haut niveau, il est possible de créer des copies sur des caches de niveau inférieur pour répartir la charge (on parle alors de push caching [GS95]). En plus du moment du préchargement, il est important de choisir les éléments à précharger. Différentes approches peuvent être envisagées. Les éléments peuvent, par exemple, être préchargés aléatoirement ou en fonction de statistiques sur les accès passés. Dans certains contextes, la structure des demandes ou des éléments requis peut être utilisée. Ainsi pour une page Internet, les liens hypertextes peuvent être utilisés pour télécharger les pages correspondantes. 16

29 2.4 Fonctionnalités optionnelles d un cache Politique d admission Définition Politique d admission [SSV96] Une politique d admission est utilisée pour prévenir la mise en cache d éléments qui pourraient dégrader les performances. Lorsque la mise en cache des éléments est optionnelle, une politique d admission est utilisée pour décider si une copie d un élément sera gardée ou non. Le but de cette stratégie est d assurer que l ajout en cache ne se fera pas au détriment des performances globales. Le mécanisme de décision peut prendre en compte différents aspects. Il arrive en effet dans certains cas, que la récupération d un élément sur un serveur soit plus performante que sur un cache. Ceci peut notamment être le cas dans des systèmes de médiation, où l évaluation répartie sur les différents serveurs est parfois plus intéressante que la manipulation en cache d une entrée de grande taille. La mise en cache peut également être interdite afin de ne pas remplacer des entrées du cache dont l absence dégraderait fortement les performances. Ainsi la politique LRU Thold [ASA + 95] évite de mettre en cache de trop gros éléments (leur taille dépasse un seuil donné), qui auraient pour conséquence d évincer un grand nombre d entrées de plus petite taille. En plus de la taille d un élément, il est également possible de prendre en compte son coût d évaluation. Par exemple, il peut être peu pertinent de mettre en cache le résultat d une projection au détriment d un résultat issu d une jointure. Ainsi, dans les entrepôts de données, la politique LNC-A (Least Normalized Cost Admission) [SSV96], vérifie si un élément doit être ajouté en cache ou non en fonction de son profit (prenant en compte notamment le coût de calcul et la taille). Un élément n est ajoutée en cache que si son profit est supérieur à celui d une entrée du cache. Parfois, un élément peut lui-même gérer son admissibilité. On parle alors d élément «cacheable»s il peut être stocké en cache, «non cacheable»(not cacheable) dans le cas contraire. Suivant ce principe, certaines pages Internet utilisent un entête particulier permettant d interdire leur mise en cache. L utilisation d un tel entête peut être motivée par des raisons statistiques (les accès aux éléments en cache n étant pas comptabilisés sur les serveurs), des accès payants, ou encore par la structure de l élément, notamment pour les pages dynamiques Cache négatif Définition Cache négatif Un cache négatif est un dispositif qui informe qu une demande ne peut temporairement pas être résolue. Le cache négatif [Moc87] marque temporairement certains éléments comme inaccessibles et ainsi empêche de contacter les serveurs pour les récupérer. Ceci évite alors de surcharger les liens de communication par des demandes envoyées à des serveurs en panne ou coupés du réseau. Dans ce cas, une demande peut malheureusement parfois ne pas être 17

30 Chapitre 2 : Concepts et techniques de cache résolue alors que le serveur est de nouveau accessible. C est pourquoi, il est important de bien configurer la période de validité des éléments du cache négatif Politique d allocation Définition Politique d allocation La politique d allocation est en charge de répartir les ressources de stockage proposées par le cache entre les différents utilisateurs de celui-ci. Une politique d allocation peut être mise en œuvre afin de distinguer les accès aux éléments du cache. La répartition autorise par exemple à favoriser certains utilisateurs prioritaires ou certaines applications critiques en leur allouant un espace physique plus important. Elle peut également être utilisée conjointement avec une stratégie de préchargement, les éléments préchargés étant alors distingués des éléments réellement accédés. En cas d accès par un client, un élément préchargé deviendra un élément accédé et sera alors déplacé dans l espace correspondant. Dans le cas de la politique de remplacement DB- MIN, les éléments du cache sont regroupés selon les séquences d accès et associés à la stratégie de remplacement correspondante. Ainsi un espace d accès peut par exemple être réservé pour les séquences d accès cyclique, le remplacement des entrées pour cet espace se faisant alors à l aide de la politique MRU. 2.5 Fonctionnalités gérées par des services externes au cache Dans cette section, nous présentons les fonctionnalités utilisées par un cache, mais pouvant être à la charge d un autre service. A la différence des caractéristiques présentées jusqu à maintenant, ces outils sont partagés entre le cache et d autres entités du système (des serveurs ou des miroirs par exemple). Deux fonctionnalités sont particulièrement pertinentes dans les applications (largement) réparties : le contrôle de concurrence et la gestion de la synchronisation Contrôle de concurrence Un contrôle de la concurrence est nécessaire si des accès à une même donnée par deux processus distincts peut entraîner des dysfonctionnements. Ce genre de situation peut se produire par exemple si une écriture est exécutée au même moment qu une lecture. Le contrôle de concurrence vise à garantir une exécution correcte, en planifiant les accès de manière à éviter les conflits. La notion la plus reconnue pour assurer l exécution concurrente des accès correspond à la sérialisabilité. Cette notion assure que l exécution de requêtes (éventuellement entrelacées) conduit au même résultat que ces requêtes exécutées de manière séquentielle, sans pour autant préciser un ordre. Les méthodes de contrôle de concurrence peuvent être rangées dans deux catégories : pessimiste et optimiste. Avec une approche pessimiste, un client doit d abord demander la permission d accéder à un élément, seuls les accès non conflictuels étant alors autorisés. Une approche optimiste, quant à elle, autorise les accès sans demande de permission, les conflits étant résolus au 18

31 2.5 Fonctionnalités gérées par des services externes au cache moment de la validation Synchronisation Un mécanisme de synchronisation a pour but d assurer le degré de cohérence souhaité entre les copies d un même élément. Ceci est nécessaire pour des caches ayant un droit de modification de leur contenu ou pour lesquels les éléments stockés peuvent être modifiés sur les serveurs. La synchronisation des copies peut être exécutée à différents moments. En reprenant la classification proposée dans [GN95], les synchronisations peuvent être regroupées selon les évènements qui engendrent le processus. La synchronisation temporelle peut exprimer une durée maximale attendue avant la propagation d une mise à jour, ou une périodicité spécifiant la fréquence de la synchronisation. La synchronisation sur la valeur peut spécifier un nombre de modifications pouvant être appliquées avant qu une copie ne soit mise à jour, ou encore pour les objets numériques, déclencher la synchronisation sur la différence de valeur entre les copies dépasse un certain seuil. Des évènements particuliers peuvent également être considérés comme, par exemple dans des environnements mobiles, la connexion d une station mobile sur un réseau filaire. L initiative de la synchronisation peut se faire de deux manières : les synchronisations de type pousser (push) et tirer (pull). Avec une synchronisation de type pousser, comme par exemple le mécanisme de callback du système de fichiers Andrew [HKM + 87], les mises à jour sont diffusées de la copie modifiée sur le serveur vers les copies stockées en cache. Dans un système basé sur une synchronisation de type tirer, à l instar du système de gestion de fichiers NFS [SGK + 85], chaque accès à un élément du cache engendre une consultation de la copie présente sur le serveur pour vérifier si cette dernière a été modifiée. La synchronisation peut alors dépendre de l âge des éléments du cache, comme dans le système de fichiers Alex [Cat92], ou reposer sur une durée de vie ou TTL (Time To Live), même si celle-ci est difficile à déterminer, son estimation pouvant ainsi être laissée à la charge du client lui-même [DP96]. La nature des mises à jour désigne le type d information échangée lors du processus de synchronisation. Deux approches peuvent être utilisées : les protocoles à diffusion des écritures et les protocoles à invalidation. Alors que le premier transfert des valeurs, des différences de valeurs ou la procédure exécutée, le second peut marquer à tout moment une copie comme non synchronisée. La synchronisation peut être exécutée selon différentes topographies, qui dépendent de la priorité de certains caches, ou encore de la topologie du réseau. Ainsi, sur un anneau, la mise en cohérence se fait entre deux copies, alors que sur une clique, une approche envisageable consiste à diffuser les mises à jour à toutes les copies. Il est également possible de diffuser à un sous-ensemble, notamment dans une approche hiérarchique, où la diffusion peut se faire uniquement sur les caches fils et non sur toute la descendance (chaque cache fils pouvant ensuite continuer la propagation). Finalement, la synchronisation doit considérer la capture des mises à jour. Un tel mécanisme peut être assuré à l aide d un support particulier, comme un journal (enregistrant les requêtes effectuées sur une copie) ou une copie ombre (copie de copie gardant une trace des valeurs d un élément avant certaines modifications). Il est également possible 19

32 Chapitre 2 : Concepts et techniques de cache pour capturer les mises à jour d avoir recours à des mécanismes déclencheurs, comme par exemple des appels de méthode, ou simplement en consultant la copie source. 2.6 Conclusion L utilisation de caches est fréquente dans de nombreuses applications informatiques. Cependant, la configuration d une solution, en fonction de son environnement d exécution, étant cruciale pour obtenir de meilleures performances, les techniques utilisées diffèrent d une application à une autre. C est pourquoi, il est intéressant de proposer un service de caches adaptables, notamment pour les contextes à grande échelle où de nombreux caches de types différents peuvent être nécessaires. Afin de proposer une telle solution, il est essentiel de ressortir les caractéristiques remarquables d un cache, pouvant être vues comme des points d adaptabilité, et pour chacune d elles établir un ensemble de valeurs possibles. Ce chapitre présente une proposition de la classification, qui est la suivante : déploiement du cache, fonctionnalités élémentaires, fonctionnalités optionnelles et fonctionnalités gérées par des services extérieurs. La liste (non exhaustive) des techniques présentées dans ce chapitre permet de s apercevoir que proposer une solution de cache adaptable est une tâche complexe devant prendre en compte un très grand nombre de paramètres. Dans les systèmes d interrogation de données à grande échelle, deux techniques de cache semblent particulièrement pertinentes : les caches sémantiques et les caches coopératifs. En effet, les premiers autorisent une meilleure utilisation des ressources disponibles en cache, alors que les seconds permettent d optimiser l utilisation des ressources globales en instaurant des coopérations entre caches. Le système global est alors plus robuste, les interactions avec les serveurs étant moins nombreuses. Le chapitre 3 propose un état de l art pour ces deux techniques de cache. 20

33 Chapitre 3 Caches sémantiques et caches coopératifs Le chapitre 2 a présenté les caractéristiques générales des caches. Ce chapitre a pour objectif de présenter plus en détails les caches sémantiques et les caches coopératifs, visant à optimiser respectivement l utilisation des ressources locales et globales. Ce chapitre est organisé de la manière suivante. La section 3.1 présente un état de l art des caches sémantiques. La section 3.2 s intéresse aux techniques de coopérations entre caches. La section 3.3 conclut ce chapitre. 3.1 Caches sémantiques Les machines utilisées par des utilisateurs sont de plus en plus puissantes, que ce soit en terme de calcul ou de stockage. C est pourquoi dans les systèmes d interrogation, une partie du processus d évaluation peut être déléguée au cache, on parle alors de cache sémantique. L objectif de cette section est d introduire le concept de cache sémantique, avant de dresser un état de l art des solutions existantes Principes Dans les systèmes de gestion de données répartis, deux types d architectures existent : les architectures par rapatriement de données (data shipping) et les architectures par rapatriement de requêtes (query shipping). Avec la première approche, les données sont récupérées en terme d objets ou de pages à l aide de leur identifiant. On parle alors d accès navigationnel, les opérations étant exécutées du côté des clients. La seconde approche repose sur un accès associatif, les requêtes étant transférées et calculées sur les serveurs. Les caches sémantiques visent à fusionner ces deux architectures en proposant un travail d évaluation local dans un système d accès associatif. L accès associatif évite de récupérer des données inutiles et le cache autorise un raisonnement fin sur son contenu, autorisant l évaluation de requêtes sur les entrées stockées. 21

34 Chapitre 3 : Caches sémantiques et caches coopératifs Définition 3.1. Cache sémantique Un cache sémantique est utilisé pour conserver des résultats de requêtes, maintenant une connaissance des données présentes, permettant des accès intelligents aux entrées stockées. Fig. 3.1 Fonctionnement d un cache sémantique Les caches sémantiques [KB96, DFJ + 96] (dont une définition est donnée ci-dessus) gèrent leur contenu (recherche, remplacement et résolution) en terme de résultats de requêtes. Dans la littérature, ces résultats sont appelés région sémantique ou segment sémantique [RDK03]. Le fonctionnement d un cache sémantique est illustré par la figure 3.1. Quand une requête est posée, elle est décomposée en deux parties disjointes : la requête de consultation (probe query), qui récupère la portion de résultat disponible dans en cache, la requête restante (remainder query) utilisée pour récupérer tous les objets absents. Si la requête restante (également qualifiée de requête promotionnelle ou discounted query [GG97]) n est pas nulle, autrement dit si celle-ci couvre une partie de l espace sémantique qui n est pas présent en cache, elle est envoyée au serveur pour être évaluée. Exemple 3.1. Soit un cache sémantique contenant l entrée de prédicat année = 2006 et une requête posée auteur = Blanchet. Alors la requête de consultation année = 2006 auteur = Blanchet est calculée en cache alors que la requête année = 2006 auteur = Blanchet est évaluée sur le serveur. Il est important de noter que deux types de succès de cache peuvent avoir lieu dans un cache sémantique : les succès de cache exacts et les succès de cache étendus. Nous donnons ci-dessous une définition de ces deux concepts. Définition 3.2. Succès de cache exact Un succès de cache exact se produit lorsqu une requête posée correspond exactement à une entrée du cache. 22

35 3.1 Caches sémantiques Définition 3.3. Succès de cache étendu Un succès de cache étendu se produit lorsque le résultat d une requête posée est obtenu en procédant à un calcul sur les entrées du cache. Exemple 3.2. Soit un cache sémantique contenant l entrée de prédicat année = 2006 et une requête posée année = 2006 auteur = Blanchet. Dans ce cas, un succès de cache étendu se produit. En effet, le résultat de année = 2006 auteur = Blanchet est inclus dans année = 2006 et peut être obtenu en appliquant une sélection sur les éléments de cette entrée. Un cache sémantique présente de nombreux avantages. Il permet d abord une meilleure répartition du processus d évaluation, une partie du travail étant traitée sur les machines clients, soulageant ainsi les serveurs (ceux-ci n étant parfois même pas contactés si la réponse complète est obtenue uniquement grâce au contenu du cache). L évaluation locale permet notamment de mieux caractériser les données à récupérer, réduisant ainsi la consommation de la bande passante. Le processus de calcul est également optimisé, en particulier pour des requêtes de plus en plus précises, pour lesquelles les évaluations seront exécutées sur des ensembles de données de plus en plus restreints. Un cache sémantique peut également améliorer l utilisation des ressources physiques, en évitant la prolifération de copies d un élément partagé par plusieurs requêtes. De plus, il offre une plus grande disponibilité qu un cache classique. En effet, en cas de déconnexion ou de panne des serveurs, il peut fournir des réponses, non seulement aux requêtes présentes en cache, mais également à celles dont le résultat peut être calculé à l aide d autres entrées. Cette disponibilité est d autant plus grande si le client accepte des résultats partiels. Néanmoins, le traitement d une demande par un cache sémantique peut être plus long que pour un cache classique, du fait des surcoûts liés aux éventuelles analyses sémantiques des entrées et aux évaluations de requêtes. C est pourquoi cette solution est généralement employée dans des contextes présentant une forte localité sémantique, où le gain obtenu compense les surcoûts. Définition 3.4. Localité sémantique [DFJ + 96] Le principe de la localité sémantique stipule que les éléments présentant une forte corrélation sémantique avec un élément récemment accédé ont de grandes chances d être référencés. Les caches sémantiques sont utilisés dans de nombreux contextes : les systèmes de gestions de bases de données distribués [DFJ + 96, KB96], les données étant éventuellement hétérogènes [GG97] et réparties sur une grappe (cluster) [ASC05] ; Internet [CB98, CB00, LC98, LC99, LNK + 01]; les environnements mobiles [ZL01, ZZP + 03, HXW + 05]; les annuaires LDAP [CKS99]. La suite de cette section présente un état de l art des techniques de cache sémantique. Les techniques sont classées en deux catégories : celles liées à la gestion de la sémantique et celles liées à la gestion du contenu du cache. 23

36 Chapitre 3 : Caches sémantiques et caches coopératifs Gestion de la sémantique La gestion de la sémantique regroupe les techniques utilisées par les caches sémantiques permettant de déléguer une partie du processus de calcul au sein du cache. Elle regroupe deux fonctionnalités : l analyse et l évaluation des requêtes. L objectif de cette section est de proposer un état de l art des possibilités offertes. Il convient cependant de noter que chaque solution est optionnelle et que sa prise en compte dépend du contexte applicatif Évaluation des requêtes L évaluation des requêtes correspond au processus responsable de l application d un prédicat sur un ensemble d éléments. Cette opération est nécessaire lorsque les entrées utilisées par les requêtes de consultation ne correspondent pas exactement au résultat attendu et qu un traitement supplémentaire doit être appliqué. Les premières solutions proposées dans la littérature concernaient les systèmes de gestion de base de données répartis. Ainsi, l évaluation de requêtes prenait en compte certaines opérations classiques des langages d interrogation : les sélections, les projections ou encore les jointures. Dans les environnements mobiles, il est parfois pertinent de gérer les requêtes dépendantes de la localité [ZL01], pour lesquelles le résultat peut être dépendant de la position du demandeur au moment de l interrogation (par exemple, «trouver les restaurants les plus proches de ma position actuelle»). Il faut noter que pour ce type de requête, le cache doit fournir des outils pour vérifier la validité de ses entrées en fonction de la position courante de l utilisateur [ZZP + 03] Analyse de requêtes (a) Equivalence (b) Requête incluse (c) Entrée incluse (d) Recouvrement (e) Disjonction Fig. 3.2 Confrontation entre une requête et une entrée L analyse de requêtes est le processus de comparaison entre prédicats permettant de vérifier si une entrée est utilisable pour répondre à une demande. Lors de la comparaison, 24

37 3.1 Caches sémantiques il est possible de distinguer cinq cas de figure [LC99] illustrés par la figure 3.2 : équivalence entre la requête et l entrée (3.2(a)) ; inclusion de la requête dans l entrée (3.2(b)) ; inclusion de l entrée dans la requête (3.2(c)) ; recouvrement de la requête et de l entrée sans aucune inclusion (3.2(d)) et disjonction entre la requête et l entrée (3.2(e)). Pour 3.2(a) et 3.2(b), la coïncidence est complète (complete match), le résultat pouvant être obtenu en utilisant uniquement l entrée considérée, contrairement à 3.2(c) et 3.2(d), où celle-ci est partielle (partial match). Dans le cas 3.2(e), l entrée n est pas utilisable pour construire le résultat. Exemple 3.3. Une entrée de prédicat année = 2006 et une requête année > 2005 année < 2007 sont équivalentes (3.2(a)). Exemple 3.4. Une requête année = 2006 auteur=blanchet est incluse dans une entrée de prédicat année = 2006 (3.2(b)). Exemple 3.5. Une entrée de prédicat année = 2006 auteur=blanchet est incluse dans une requête année = 2006 (3.2(c)). Exemple 3.6. Une requête année = 2006 espèce = virus recouvre partiellement une entrée de prédicat auteur = Blanchet espèce = virus (3.2(d)). Exemple 3.7. Une requête année > 2006 est disjointe d une entrée de prédicat année < 2004 (3.2(e)). (a) Vertical (b) Horizontal (c) Hybride Fig. 3.3 Recouvrements Le cas du recouvrement peut lui même être décomposé en sous catégories. Ainsi pour des sélections et des projections, le recouvrement entre la requête posée et la requête présente en cache peut être vertical, horizontal ou hybride [GG99] comme illustré par la figure 3.3. Avec un recouvrement vertical (3.3(a)), des n-uplets ne vérifient qu une seule des deux requêtes. Pour un recouvrement horizontal (3.3(b)), il existe des attributs qui ne sont présents que dans l une des deux requêtes. Le recouvrement hybride (3.3(c)) correspond à une combinaison de ces deux situations (des n-uplets et des attributs référencés uniquement dans une des deux requêtes). Exemple 3.8. Avec un cache sémantique contenant une entrée de prédicat σ annee=2006 (T), une requête σ auteur=blanchet (T) engendre un recouvrement vertical (3.3(a)). Le recouvrement caractérise les n-uplets vérifiant les prédicats année = 2006 et auteur = Blanchet. Exemple 3.9. Avec un cache sémantique contenant une entrée de prédicat π annee,auteur (T), une requête π annee,espece (T) engendre un recouvrement horizontal (3.3(b)). Le recouvrement caractérise l attribut année des n-uplets. Exemple Avec un cache sémantique contenant une entrée de prédicat π annee,auteur (σ annee=2006 (T)), une requête π annee,espece (σ auteur=blanchet (T)) engendre un recouvrement hybride (3.3(c)). Le recouvrement caractérise l attribut annee des n-uplets vérifiant les prédicats annee = 2006 et auteur = Blanchet. 25

38 Chapitre 3 : Caches sémantiques et caches coopératifs Lorsqu une requête est posée, il est parfois possible que plusieurs entrées du cache puissent être utilisées. Ces entrées peuvent correspondre à des situations de recouvrement différentes ou identiques. Bien que la première entrée utilisable puisse être choisie, il est souvent préférable de proposer une solution plus fine. Le cache doit alors fournir des mécanismes de décisions. Ces mécanismes sont utilisés dans un premier temps pour choisir le cas de coïncidence (par exemple privilégier l équivalence à un recouvrement partiel). Pour le cas considéré, ils doivent également élire une entrée si plusieurs éléments sont candidats (dans le cas d une requête incluse dans plusieurs entrées, une approche consiste à choisir l entrée de plus petite taille, qui minimisera le nombre d évaluations). Bien sûr, il est possible d utiliser plusieurs entrées pour répondre à une requête, si celles-ci sont complémentaires et permettent d augmenter la proportion du résultat produit en cache [RDK03]. Il est cependant important de noter que l optimisation de l utilisation de la bande passante obtenue en considérant un maximum d entrées se fait au détriment du processus d évaluation en cache, et que les requêtes traitées sur les serveurs sont alors en général plus complexes (puisqu elles peuvent contenir des négations et disjonctions de termes). Les caches sémantiques peuvent être confrontés au problème de vérifiabilité et de complétude [CRS99]. Une entrée est vérifiable si elle contient suffisamment d informations. Ainsi une entrée de prédicat π a,b ((T)) n est pas vérifiable puisqu elle ne permet pas de traîter la requête π a (σ c=12 (T)) (alors que le résultat correspond à un sous-ensemble de l entrée). Une réponse est complète, si elle contient tous les résultats et incomplète sinon. Le problème de la complétude se pose notamment pour les modèles de rang, où les serveurs ordonnent les résultats et retournent les k premières réponses. C est ainsi que les moteurs de recherche sur Internet retournent généralement des réponses incomplètes, sauf si le nombre de résultats est très faible. La comparaison de requêtes est, en général, un problème NP-complet. Ainsi les solutions mises en œuvre sont souvent proposées pour des langages spécifiques (comme XML [CRW02] ou XPath [MS05]) ou des ensembles restreints de requêtes (par exemple l utilisation de signatures pour gérer les requêtes constituées uniquement de conjonctions de termes [CB98, CB00]) Gestion du contenu du cache Les caches sémantiques offrent de nouvelles possibilités en terme de gestion du contenu, que ce soit au niveau des entrées, du remplacement ou encore du préchargement. De nouvelles techniques peuvent également être considérées : le partitionnement ou le regroupement d entrées Entrées Dans un cache sémantique, les données sont gérées comme des régions sémantiques. Il faut cependant noter que la gestion physique des régions peut se faire à différentes granularités. La granularité peut ainsi être assez spécifique, comme dans les bases de données multidimensionnelles où les transferts entre les caches et les serveurs se font en terme de morceaux (chunks) [DRSN98], un morceau étant issu de la division de la base en fonctions des différentes dimensions (elles-mêmes pouvant être découpées en intervalles). 26

39 3.1 Caches sémantiques Cependant nous nous intéressons ici à des granularités plus générales : résultats de requêtes ou prédicats et objets. Fig. 3.4 Cache sémantique de résultats de requêtes Dans un cache manipulant des résultats de requêtes [DFJ + 96], les entrées correspondent à des ensembles d objets, comme illustré par la figure 3.4. Le résultat d une requête est alors stocké dans une entrée, dont l identifiant est la requête et la valeur correspond à l ensemble des objets qui composent le résultat. Exemple Un exemple d entrée pour un cache de résultats de requêtes illustré par la figure 3.4 est (année = 2006,{obj1,obj2}), la requête année = 2006 correspondant à l identifiant de l entrée du cache, la valeur de cette entrée étant l ensemble des objets résultats {obj1, obj2}. Avec une telle approche, l accès aux éléments stockés est efficace, les données étant agrégées dans une entrée en fonction des requêtes posées. Le remplacement est de plus relativement simple, puisque l éviction d une victime n a pas d impact sur les autres éléments en cache. En effet, lorsqu un élément est référencé par plusieurs requêtes, le nombre de copies de cet élément est égal au nombre de requêtes qui le référencent. Malheureusement, dans ce cas la gestion des ressources physiques n est pas optimale du fait de la duplication (par exemple pour le cas illustré par la figure 3.4, les objets obj1 et obj4 sont dupliqués car référencés par des requêtes différentes). Une solution pour éviter la duplication consiste à vérifier qu à tout moment un élément est associé à une unique entrée. Néanmoins, dans ce cas la gestion du cache est plus complexe et contraignante, interdisant en particulier de garder deux requêtes populaires si elles ne sont pas disjointes (par exemple année = 2006 et espèce = virus sur le cas illustré par la figure 3.4). Fig. 3.5 Cache sémantique de prédicats et objets Les entrées d un cache sémantique peuvent également être des prédicats et des objets [KB96], les régions étant dans ce cas des structures logiques, comme l illustre la figure 3.5. Un index est alors utilisé pour associer à chaque requête une liste d identifiants permettant d accéder aux objets correspondants. Exemple Un exemple d entrée pour un cache de résultats de requêtes illustré par la figure 3.5 est (année = 2006,{obj1,obj2}), la requête année = 2006 correspondant 27

40 Chapitre 3 : Caches sémantiques et caches coopératifs à l identifiant de l entrée du cache, la valeur de cette entrée étant l ensemble des objets résultats {obj1, obj2}. L association entre l identifiant et la valeur est indirecte, nécessitant l utilisation d un index qui fait correspondre ici la requête année = 2006 aux identifiants des objets résultats obj1 et obj2, à savoir id1 et id2. Avec une telle approche, l utilisation des ressources physiques est optimale, une unique copie d un objet étant gardée en cache, même si celui-ci est partagé par plusieurs requêtes. Lorsqu une requête est victime du remplacement, la politique supprime alors les objets associés, uniquement s ils ne sont pas référencés par d autres résultats. Cette synchronisation forte peut néanmoins être problématique. En particulier, une requête peut être supprimée du cache sans libérer de ressources, si tous les objets correspondants sont référencés ailleurs ou si l ensemble des objets réponse est vide (comme illustré respectivement par les requêtes espèce = virus et année = 2010). Il faut également noter que l accès indirect aux objets peut être pénalisant, notamment pour de gros volumes de données. Il est à noter qu il existe également dans la littérature une variante des caches de prédicats et d objets proposée pour des systèmes centralisés, appelée cache de vues [Rou91]. Dans un cache de vue, le stockage des objets n est pas considéré. Autrement dit, le cache ne gère que des évaluations associant à une requête une liste d identifiants d objets, les objets étant ensuite récupérés directement sur les sources de données Remplacement Les caches sémantiques sont en général utilisés dans des contextes applicatifs présentant une forte localité sémantique, la localité sémantique pouvant alors être prise en compte lors du processus de choix des victimes du remplacement. Il existe ainsi certaines politiques prenant en compte la localité sémantique, comme par exemple les politiques Manhattan [DFJ + 96], LSR (Least Semantically Related) [CdSJ03] et LRU à deux niveaux (twolevel LRU) [RD99]. Il est important de noter que, contrairement à un cache classique, l implication d une région lors d un accès est variable. En effet, celle-ci peut être totalement ou partiellement utilisée pour fournir un résultat. C est pourquoi, il peut être pertinent de considérer lors du calcul de la nouvelle valeur de remplacement le pourcentage de l entrée utilisé afin de ne pas garder en cache des régions volumineuses dont seule une petite partie est fréquemment accédée. D autres aspects peuvent aussi être considérés, comme la vérifiabilité et la complétude, une requête complète et vérifiable étant plus pertinente qu une requête non vérifiable et/ou non complète. Pour les requêtes dépendantes de la localité, certains paramètres peuvent être particulièrement pertinents, comme la distance, la zone couverte par la requête [ZL01] ou encore la direction du déplacement comme dans la politique FAR (Furthest Away Replacement) [RD00]. Dans ce dernier cas, la politique de remplacement permet ainsi de favoriser l éviction d éléments dont la localisation est à l opposé de la trajectoire du client, et qui par conséquent ont de faible chance d être atteints par celui-ci. 28

41 3.1 Caches sémantiques Préchargement La gestion de la sémantique au sein du cache permet l utilisation d une technique particulière : l augmentation de requêtes (query augmentation) [KB96]. Cette solution consiste à réécrire la requête posée en relâchant certaines contraintes, afin de récupérer un ensemble de données plus grand et ainsi augmenter la réutilisation du résultat. Le processus de traitement de requêtes en cache doit alors comprendre une phase de réécriture de la requête, mais également une phase de filtrage pour fournir à l utilisateur uniquement les données souhaitées [LC98]. Cette technique doit néanmoins être employée prudemment, afin d éviter que l ajout d éléments préchargés peu utilisés ne se fasse au détriment d entrées qui le sont. Il est important de noter que les techniques de préchargement classiques peuvent également être considérées dans des caches sémantiques Regroupement et partition Dans les caches sémantiques, deux nouvelles techniques peuvent être intégrées à la gestion du cache : le regroupement et le partitionnement. Le regroupement consiste à fusionner plusieurs entrées en une seule, dont le prédicat est égal à l union des espaces couverts par chaque requête. Ainsi, une première approche ajoute en cache le résultat d une requête posée, plutôt que de garder séparément la requête de consultation et la requête restante. L approche peut être généralisée et ainsi être utilisée pour regrouper des requêtes complémentaires. Exemple Soit un cache sémantique contenant les entrées de prédicat A B et A B. Dans ce cas, ces deux entrées peuvent être regroupées en un seul élément identifié par la requête A. Le partitionnement consiste à découper une région lors d un cas de recouvrement d une requête posée avec une entrée du cache. Il est alors possible de distinguer les éléments contenus en cache utilisés pour construire le résultat de ceux qui ne le sont pas. Par conséquent, le partitionnement mène à une meilleure identification des fragments utilisés, permettant des évaluations en cache plus efficaces car portant sur des ensemble de données plus précis. Les performances d un cache sémantique sont souvent liées au compromis qui est fait entre le regroupement et le partitionnement. En effet, bien qu un regroupement important réduise le nombre d entrées et par conséquent facilite la recherche au sein de cache en engendrant moins d analyses de requêtes, il entraîne des évaluations sur des quantités de données plus importantes et donc plus coûteuses, les entrées du cache étant plus volumineuses. Le partitionnement, à l inverse, optimise les évaluations (les entrées étant plus petites) au détriment de l analyse des requêtes (les entrées étant plus nombreuses). A noter que pour limiter la prolifération d entrées de petites tailles, il est possible de considérer un seuil à partir duquel une entrée ne doit plus être partitionnée [LLS99]. Le partitionnement peut également être adapté en fonction des séquences d accès et ainsi fournir des régions de plus en plus précises pour une forte localité sémantique ou des régions grossières dans le cas contraire [HXW + 05]. 29

42 Chapitre 3 : Caches sémantiques et caches coopératifs 3.2 Caches coopératifs Les environnements applicatifs sont de plus en plus largement répartis, autorisant un déploiement massif de caches. Bien que les solutions individuelles soient pertinentes, la prise en compte de coopérations peut être cruciale pour le passage à l échelle du système considéré, en particulier dans des applications reposant sur des réseaux rapides, pour lesquelles l accès à des caches distants est parfois moins coûteux que d accéder à des données sur un disque local. Cette section introduit le concept de cache coopératif et dresse un état de l art des solutions existantes, basées sur la résolution, la répartition ou d autres aspects Principes Définition 3.5. Cache coopératif Un cache coopératif se joint à l effort d autres caches, en vue d améliorer les performances globales du système dans lequel ils sont intégrés. Les caches coopératifs (dont une définition est donnée ci-dessus) visent à fournir un système proche des mémoires virtuelles partagées [LH89], où un unique espace d adressage est partagé par plusieurs processeurs. Dans une coopération de caches, un client peut bénéficier de l ensemble des ressources proposées par les différents caches. La coopération est normalement transparente pour les utilisateurs, ces derniers n ayant la vision que d un unique point d entrée. Les requêtes sont posées aux caches coopératifs, l objet étant directement fourni à l utilisateur s il est présent dans un des caches. Dans le cas contraire, le serveur est contacté pour récupérer l objet demandé, qui est ensuite ajouté dans un (ou plusieurs) des caches puis transféré au client. Les caches coopératifs reposent en fait sur un niveau supplémentaire dans la hiérarchie classique de processus de résolution, la coopération s insère entre la demande d un client et une résolution sur le serveur. Les caches coopératifs autorisent une meilleure répartition de la charge sur le système et une plus grande disponibilité. L accès aux ressources de différents caches par les clients permet en effet de soulager les serveurs et, selon le placement des caches, de réduire la consommation de bande passante, limitant la sensibilité du système global à une déconnexion ou à une panne des serveurs. Le partage des ressources évite également de multiples transferts depuis les serveurs d un même élément, un utilisateur pouvant tirer profit des accès des autres clients. Ces nombreux avantages se traduisent en général par une réduction des temps d attente perçus par les utilisateurs. Il convient néanmoins de noter que des caches coopératifs engendrent des surcoûts par rapport à des caches classiques, liés à la localisation des données ou encore aux redirections des demandes sur les différents caches. Cependant ces surcoûts sont souvent négligeables par rapport au gain obtenu, surtout dans des contextes où les serveurs sont soumis à une forte charge. Les caches coopératifs sont utilisés dans des systèmes variés, comme les systèmes d exploitation, les systèmes de fichiers, les systèmes de gestion de bases de données, voire d entrepôts de données, ou encore Internet. Dans la suite de cette section nous proposons une classification des techniques utilisées dans ces différents contextes, en reprenant no- 30

43 3.2 Caches coopératifs tamment les classifications proposées dans la littérature [WVS + 99, BO00, CYD04]. Notre classification distingue ainsi la résolution verticale, la résolution horizontale et les caches répartis Résolution verticale Fig. 3.6 Résolution verticale de défaut de cache La résolution verticale, utilisée en particulier dans les caches système [Smi82] et Internet [DHS93, BCC + 95, CDN + 96], consiste à résoudre les défauts en contactant un cache parent, comme illustré par la figure 3.6. Ainsi, la réponse à une demande posée à un cache c1 (1) est récupérée à partir du cache parent cp (2), ce dernier initiant si besoin une résolution (3). La réponse est alors ajoutée dans les deux caches. Dans le cas d un nombre plus important de niveaux, la procédure est récursive, un cache recevant une demande d un fils pouvant demander la résolution à l aide de son père. Définition 3.6. Cache parent [CDN + 96] Un cache parent est un cache utilisé pour satisfaire les demandes provenant d autres caches, exécutant si nécessaire une résolution. L approche verticale est sans doute la coopération la plus facile à mettre en œuvre et à administrer. En effet, l information gérée par un cache pour la coopération est alors relativement simple, puisque seules les données permettant de communiquer avec un cache parent sont prises en compte. Cette solution est particulièrement adaptée dans les systèmes informatiques actuels, où les machines clientes contactent souvent l extérieur par des machines intermédiaires, des pares-feu pour Internet (comme par exemple Relai [Gla94]) ou encore des frontales sur une grille. Ainsi, un client peut tirer profit des accès des autres utilisateurs. Il faut cependant noter que l obtention de bonnes performances dépend de centres d intérêts communs entre les utilisateurs des différents caches [MH92]. Les caches parents peuvent néanmoins être amenés à supporter une grande charge et ainsi devenir des goulots d étranglement. Ceci est particulièrement problématique, si la charge provoque une défaillance, puisque les descendants seraient par conséquent isolés. Une solution consiste à créer des communautés virtuelles [BCS01, BPC02] d utilisateurs basées sur leurs centres d intérêt et de limiter le nombre de communautés gérées par un cache parent. 31

44 Chapitre 3 : Caches sémantiques et caches coopératifs Résolution horizontale de défaut de cache Fig. 3.7 Résolution horizontale de défaut de cache Alors qu une résolution verticale repose sur des caches parents, la résolution horizontale se base sur des caches frères. Le fonctionnement, illustré par la figure 3.7, est alors le suivant. Lorsqu une demande engendre un défaut (1), elle est transférée aux caches frères (2). Ces derniers fournissent l objet souhaité s il est présent dans leur espace physique, arrêtant par conséquent la résolution, ou informent par une réponse nulle qu ils ne peuvent fournir la réponse attendue. A noter que dans le cas d une réponse positive, celle-ci correspond en général à l objet demandé, mais peut parfois être une simple notification, le cache demandeur devant alors de nouveau contacter le cache fournisseur pour exécuter le transfert. Quelque soit l approche choisie, si aucun frère ne fournit les données attendues, la demande est transférée au serveur (3). Définition 3.7. Cache frère [CDN + 96] Un cache frère est un cache utilisé pour satisfaire les demandes provenant d autres caches, n exécutant pas de résolution si son contenu ne permet pas de fournir le résultat attendu. Dans une résolution horizontale, tous les caches ont alors un rôle équivalent. Cette caractéristique offre une propriété intéressante en terme de passage à l échelle, les ressources étant alors proportionnelles au nombre de caches. Elle permet également une meilleure répartition de la charge que pour une résolution verticale, où les caches parents représentent des goulots d étranglement. En particulier, le système global offre une plus grande disponibilité, l impact de la panne d un cache étant normalement limité à son seul client, contrairement à une défaillance d un cache parent isolant tous ses descendants. Cette approche pose néanmoins le problème de la localisation des données, notamment pour un nombre important de caches. Deux principales techniques sont proposées dans la littérature : l inondation et l utilisation d un catalogue Résolution par inondation Avec une inondation, un défaut engendre la diffusion de la demande à tous les frères. Ces derniers transmettent le document demandé s il est présent dans leur espace de stockage, ou envoie une réponse nulle dans le cas contraire. Le cache demandeur considère alors la première réponse positive. Si aucun frère ne peut satisfaire cette requête, la demande 32

45 3.2 Caches coopératifs est alors résolue par le serveur. Le document est ensuite ajouté en cache. L inondation est utilisée dans de nombreux contextes. Ainsi, cette solution est utilisée, par exemple dans Internet, avec des systèmes de coopération entre serveurs mandataires [MLB95] ou les protocoles ICP (Internet Cache Protocol) [WC98] et HTCP (Hyper Text Caching Protocol) [VW00], ou encore dans les architectures à mémoires distantes [LWY93]. Les avantages de l inondation sont les suivants. La mise en œuvre est relativement simple, puisque les seules informations à gérer par un cache sont celles permettant la connexion avec ses frères. Ainsi dans certains cas, une simple adresse multicast ou broadcast est suffisante. Cette technique permet également une bonne répartition de charge sur les différents caches en cas d une demande sur les frères en deux temps (notification et transfert). En effet, la notification considérée sera celle obtenue en premier, réduisant les chances d effectuer le transfert depuis un cache trop chargé. La simplicité de la mise en œuvre se fait néanmoins au détriment du passage à l échelle en terme de nombre de caches. Puisque un défaut engendre autant de communications que de frères, le nombre de messages envoyés augmente de manière quadratique avec le nombre de caches, posant des problèmes de charge sur ces derniers et de congestion sur les réseaux. Une solution à ce problème proposée pour des caches Internet consiste à utiliser différentes adresses multicast permettant de gérer des groupes d intérêt [TFW00]. Il faut également noter que les temps de réponse peuvent être assez longs, puisque si aucun frère ne possède l objet demandé, il faut attendre la dernière réponse (ou éventuellement la fin d un minuteur) pour qu une résolution auprès du serveur soit initiée Résolution à l aide d un catalogue Un catalogue est un ensemble de couples (e,c), où e est un élément et c la liste des caches qui le stockent. Lorsqu une demande engendre un défaut, elle est soumise au catalogue. Si celui-ci contient une entrée qui correspond, il fournit alors la liste des caches associés. Ces derniers sont alors contactés pour fournir la réponse. Si l élément n est pas présent dans le catalogue, alors la résolution se fait en contactant le serveur. Le cache ajoute ensuite la réponse dans son espace de stockage et informe le catalogue pour que celui-ci soit mis à jour. L utilisation du catalogue permet de réduire la charge globale sur le système. En effet, le nombre de caches concernés par une résolution est alors limité, réduisant à la fois la charge sur ces derniers, mais également sur les liens de communications. De plus, si le catalogue ne contient pas l élément souhaité, la résolution se fait directement auprès du serveur, économisant ainsi les temps de consultation des frères dépensés dans une approche par inondation. Il faut cependant noter que cette approche doit gérer la synchronisation du catalogue, celui-ci pouvant être partagé ou local à un cache. Catalogue partagé Un catalogue partagé facilite l administration et la gestion de la cohérence entre le catalogue et le contenu des caches. Cette approche est utilisée dans différents contextes. Dans des systèmes de gestion de bases de données [FCL92] ou des systèmes de gestion de fichiers [DMW + 94, DWAP94], le serveur possède une connaissance globale du contenu 33

46 Chapitre 3 : Caches sémantiques et caches coopératifs de tous les caches, étant ainsi capable de transférer les demandes. Dans Internet, le catalogue partagé est en général placé sur une machine spécifique, à l instar du serveur de correspondances (mapping server) du protocole CRISP [GRC97], du répertoire Relais [MPKD99] ou des caches distribués (distributed caching) [PH97]. Le partage peut néanmoins poser certains problèmes. En particulier, la charge à supporter par le catalogue peut être très importante notamment pour un grand nombre de caches. Les catalogues représentent de plus des points de défaillance, rendant impossible la localisation des objets en cas de panne. Des solutions ont été proposées pour résoudre ces problèmes, qui permettent de dupliquer ou répartir les catalogues. Une première approche, appelée répertoire réparti synchrone (Partitioned Synchronous Directory) [GCR98], consiste à distribuer un catalogue sur plusieurs machines, chacune étant responsable exclusivement d un ensemble de documents. Cette distribution peut également se faire directement sur les caches, comme dans l approche catalogue transversal [MIB98]. Une autre approche, le répertoire dupliqué asynchrone (Replicated Asynchronous Directory) [MIB98], consiste à dupliquer le catalogue de manière asynchrone. Les copies sont alors placées près de groupes de caches. Enfin, les catalogues partiels de duplicats (Replicated Partiel Directory) [MIB98] identifient un sous ensemble du contenu des caches qui est le plus à même de produire des succès. Seules ces entrées sont alors dupliquées sur chaque catalogue. Il est important de noter qu un cas particulier de catalogue partiel de duplicats introduit la notion de caches voisins (neighbor cache), pour laquelle les catalogues ne prennent en compte que les entrées des caches proches géographiquement. Catalogue local L approche catalogue local est particulièrement utilisée sur Internet, notamment avec les protocoles summary [FCAB98], [FCAB00] et digest [RW98]. Dans les contextes largement répartis, elle permet en effet de résoudre les problèmes de charge et de défaillance posés par un catalogue partagé (voire centralisé), la charge sur un catalogue étant limitée aux seules requêtes du cache correspondant, et une défaillance n ayant pas d impact sur les frères. Malheureusement, le processus de synchronisation des catalogues est parfois très coûteux, puisque l évolution du contenu d un cache (ajout, suppression, modification d une entrée) nécessite une notification sur tous les catalogues, pouvant engendrer un très grand nombre de messages et donc une charge importante sur les différents caches et sur les liens de communications. Une solution à ce problème consiste à limiter la gestion du catalogue à certains caches. Ainsi, un catalogue reposant sur l approche par voisinage (neighborhood) [RCG98] ne prend en compte que le contenu des frères proches du cache considéré, la proximité étant calculée en terme d une métrique de distance reflétant le coût de transfert des données (incluant le coût financier, la bande passante ou encore la latence). Le nombre de messages peut également être réduit en retardant les informations de synchronisation, ce qui permet de regrouper dans une même communication plusieurs mises à jour. Il faut cependant noter que dans ce cas, le catalogue n est pas forcément à jour, et peut transférer une demande sur un cache ayant récemment supprimé l objet souhaité. Néanmoins, il est parfois préférable de payer le coût d une communication n aboutissant pas à une résolution par des frères plutôt que celui associé à la gestion de la cohérence forte des catalogues [FCAB00]. 34

47 3.2 Caches coopératifs Fig. 3.8 Caches répartis Caches répartis Contrairement aux résolutions verticale et horizontale, la coopération au sein de caches répartis n est pas liée au processus de résolution, mais à un choix d un cache parmi un ensemble de caches disponibles, comme illustré par la figure 3.8. Lorsqu une demande est posée, elle est transférée à un cache particulier en fonction d une politique spécifique (1). A la réception de la demande, ce cache vérifie alors s il possède l élément correspondant et le fournit dans ce cas. Sinon, il initie une résolution de défaut auprès du serveur (2), puis stocke le document demandé. Les caches répartis sont notamment intégrés dans certaines solutions commerciales, comme les protocoles propriétaires CRP Content Routing Protocols de Cisco [cis], et plus particulièrement le protocole WCCP (Web Cache Control Protocol). De manière générale, un mécanisme de décision doit être proposé, pour pouvoir associer à chaque demande un cache à contacter. Ce choix peut être fait localement ou alors en contactant une machine dédiée, comme par exemple une frontale dans le cas des grappes de caches Internet. Le choix est même parfois pris par les caches eux-mêmes comme dans la politique PPBL(Parallel Pull-Based LRU) [Cec01, Cec02]. Différentes stratégies peuvent être utilisées pour distribuer les demandes [KR99]. Il est possible d utiliser une répartition aléatoire, comme c est notamment le cas pour des caches mandataires pour Internet dans [MLB95]. Si la fonction aléatoire est efficace, cette approche autorise alors une bonne répartition des demandes. Afin d obtenir une distribution optimale, une répartition à l aide d un tourniquet (round robin) peut être employée, comme dans [BC95] pour des caches mandataires pour Internet. Une version légèrement modifiée, appelée tourniquet pondéré (weighted round robin), peut même être mise en œuvre, afin de considérer également la charge des différents caches et par conséquent éviter de transférer des demandes vers des caches surchargés. Si l objectif de la distribution consiste à optimiser les succès de cache, ces stratégies sont néanmoins limitées. Il est alors préférable d utiliser une répartition en fonction des clients ou une répartition en fonction des demandes. Avec une répartition des demandes en fonction des clients, l espace des utilisateurs est décomposé et chaque cache doit servir les requêtes d une partition, comme c est par exemple le cas dans un DNS (Domain Name System)[Moc87]. Avec une répartition en fonction des demandes, l espace des fichiers est découpé et chaque cache est en charge des requêtes d un ensemble. Cette approche est utilisée dans différents contextes, notamment dans des systèmes de fichiers [DWAP94] ou encore Internet [AT04], avec le protocole CARP (Cache Array Routing Protocol) [VR98] et cache resolver [KSB + 99] pour lequel la répartition se fait en fonction du hachage 35

48 Chapitre 3 : Caches sémantiques et caches coopératifs cohérent consistent hashing [KLL + 97]. Avec ces deux approches, les clients ont ainsi de fortes chances d obtenir des succès de cache s il demande de nouveau des éléments qu ils ont déjà référencé. Contrairement à une répartition en fonction des clients, la répartition en fonction des demandes permet de plus de tirer profit des demandes des autres utilisateurs, un client pouvant utiliser les éléments récupérés par d autres utilisateurs. Il convient cependant de noter qu une répartition en fonction des demandes peut conduire à une répartition de charge hétérogène, les caches responsables des documents populaires pouvant alors être surchargés. La stratégie LARD (Locality Aware Request Distribution) [PAB + 98] offre une solution à ce problème, en considérant, en plus de la distribution en fonction des demandes, la charge sur les différents caches. Quand une requête est posée, le gestionnaire de distribution vérifie si un cache est responsable de l élément demandé. Si ce n est pas le cas, le cache le moins chargé est alors désigné pour résoudre cette demande Coopération hybride La résolution verticale, la résolution horizontale et les caches répartis sont des approches orthogonales et peuvent, par conséquent, être combinées. Une résolution verticale peut ainsi utiliser des caches répartis, comme dans [DWAP94], où un défaut sur un cache est résolu par des caches répartis de plus haut niveau. Une autre approche possible consiste à combiner une résolution horizontale et une résolution verticale [BA92, CDN + 96, TDVK99, RSB01]. Dans les caches hiérarchiques [CDN + 96] par exemple, une résolution horizontale par inondation peut être suivie en cas d échec d une résolution verticale Autres techniques de coopération Dans la section précédente, nous nous sommes focalisés sur la coopération entre caches en terme de traitement de demandes. Dans cette section nous présentons d autres types de coopération : les coopérations liées à l admission et au remplacement, la création dynamique de caches et pour finir la coopération entre caches hétérogènes Admission et remplacement Choisir des politiques d admission et de remplacement efficaces est primordial pour fournir de bonnes performances. Les caches coopératifs offrent des perspectives particulières pour ces deux politiques. Un cache peut notamment prendre en compte les décisions prises par les autres caches lors de ses propres décisions. Dans le cas d une stratégie isolationniste [LWY93], un cache ne considère que ses propres décisions. Chaque cache ajoute et supprime simplement les éléments qui lui permettent d augmenter ses propres succès. Cette stratégie permet d accéder aux documents les plus pertinents avec un coût minimal, l accès étant local et non au travers d un autre cache. Cependant, elle peut entraîner une duplication non négligeable, puisque des éléments populaires peuvent être gardés dans de nombreux caches, interdisant par conséquent le stockage d autres entrées moins importantes, mais néanmoins utilisées. Pour augmenter les performances globales, éventuellement au détriment des perfor- 36

49 3.2 Caches coopératifs mances locales, il est possible d utiliser des stratégies prenant en compte les décisions des autres caches. L objectif est de privilégier l ajout d entrées qui ne sont pas très présentes sur l ensemble des caches ou, au contraire, favoriser le remplacement d éléments contenus dans un grand nombre de caches, l accès pouvant toujours se faire à l aide de l un d entre eux. Au contraire, la dernière copie d un objet est précieuse, puisque sa disparition nécessiterait une résolution via un serveur. De cette façon, un cache peut être amené à garder un élément relativement peu important, puisqu il compte sur d autres caches pour garder les éléments plus importants. L admission et le remplacement pour une optimisation globale peuvent se faire de manière centralisée [LWY93], éventuellement en conservant pour chaque cache des ressources gérées par des stratégies locales [DWAP94]. D autres stratégies sont employées pour une prise de décision locale afin d améliorer les performances pour l ensemble du système. Le protocole PICS (Platform for Internet Content Selection) [YM98], issu d Internet, permet de diffuser dans une hiérarchie de caches les informations sur les contenus des caches parents. Ces informations peuvent alors être utilisées dans la stratégie d admission des caches pour éviter de stocker des éléments présents dans d autres caches, et ainsi ne pas remplacer certaines entrées rares ou utiliser les ressources pour conserver de nouveaux éléments. Une stratégie simple pouvant être mise en place consiste par exemple à ne pas conserver un élément déjà stocké dans un cache de plus haut niveau. D autres algorithmes, également proposés pour Internet, peuvent être employés dans des caches hiérarchiques tels que Prob, LCD (Leave Copy Down) et MCD (Move Copy Down) [LSS04]. Avec une approche Prob, la décision de conserver ou non un élément en cache est prise de manière probabiliste. L avantage de cette stratégie est que la décision est totalement prise localement. Avec l algorithme LCD, un élément demandé est uniquement stocké au niveau directement inférieur du niveau sur lequel s est produit le succès (ce niveau pouvant être un cache ou un serveur). MCD est similaire à LCD, à la différence que l élément se déplace sur le cache de niveau inférieur. Autrement dit, si le succès a lieu sur un cache parent, la copie du cache parent est détruite, pour n être conservée que par le cache fils. Enfin, dans les entrepôts de données, la politique HACP (Hit Aware Caching Policy) [KNO + 02] permet de prendre en compte les accès des entrées d un cache par d autres caches pour calculer le bénéfice des éléments stockés. Cette approche permet alors au moment de l admission ou du remplacement à l aide de la politique LBF (Least Benefit First) [KNO + 02] de conserver les entrées les plus utiles pour le système global. Une autre approche, proposée dans les systèmes de gestion de fichiers [DWAP94], les bases de données orientées objets [LCD97] ou multidimensionnelles [KNO + 02], liée au remplacement et à l admission consiste à utiliser les autres caches comme espace de stockage supplémentaire. Lorsqu un cache est plein et qu il doit stocker de nouvelles entrées, les victimes du remplacement sont alors transférées à d autres caches Multiplication dynamique de caches La multiplication dynamique de caches, proposée dans des systèmes de gestion de vidéos sur Internet [Cob05], vise à ajuster le nombre de caches utilisés, activant des caches pendant les périodes de forte charge, et les plaçant dans un état d hibernation ou d arrêt complet pendant les périodes de faible activité. Cette approche permet ainsi de augmenter ou de réduire les capacités de stockage ou de calculs en fonction de l évolution de l environnement. 37

50 Chapitre 3 : Caches sémantiques et caches coopératifs Coopération de caches hétérogènes Les approches étudiées jusqu à présent se sont intéressées aux coopérations entre caches homogènes. Néanmoins, les systèmes informatiques deviennent de plus en plus complexes. En particulier, il n est pas rare de répartir le travail sur différents sites. Les résultats d un site sont alors utilisés à d autres endroits afin de continuer le traitement, et ainsi de suite jusqu à obtenir le résultat final. Cette distribution rend alors possibles des coopérations entre caches hétérogènes. Sur Internet, des serveurs fournissent un accès à un grand nombre de pages dont le contenu est extrait dynamiquement de bases de données relationnelles. Lors d une demande, un tel serveur génère différents formats de résultat : les n-uplets réponses aux requêtes SQL, qui sont ensuite empaquetés dans des fragments XML, ces derniers étant alors utilisés par un programme XSLT pour générer les pages HTML finales. L utilisation de caches trois tiers configurables est alors pertinente [YFIV00], trois types de cache autorisant la gestion de documents HTML, XML et/ou des résultats de requêtes sur la base de données. Lorsque tous les caches sont utilisés, une demande est d abord envoyée au cache HTML, qui en cas de défaut contacte le cache XML faisant lui même appel au cache de données si besoin. Des caches coopératifs hétérogènes sont également déployés pour optimiser les performances dans des environnements de bioinformatique, comme dans [TZ05]. Cette application sert à calculer des alignements de séquences. Les caches coopératifs sont utilisés lors du processus de calcul. Ce dernier est composé de deux phases, la première calculant les alignements par paire, la seconde produisant les alignements multiples à l aide des alignements par paire. Les caches proposés permettent de stocker ces différents résultats, les entrées du cache d alignements par paire étant utilisées par le cache d alignements multiples. A noter que dans cette solution, les stratégies de caches sont indépendantes. C est ainsi que le cache d alignements par paire utilise une politique de remplacement LRU, alors que le cache d alignements multiples emploie la stratégie GDS [CI97]. Une autre solution de caches coopératifs hétérogènes est proposée dans des systèmes pair-à-pair [GEvS05]. Dans cette approche deux types de caches sont déployés : les caches de supers pairs et les caches de fichiers. Les premiers sont utilisés par les pairs classiques et contiennent les identifiants des super pairs qui se sont révélés utiles par le passé. Les caches de fichiers quant à eux, sont accédés par les supers pairs afin de conserver la liste des fichiers stockés par les pairs classiques, qui ont récemment été référencés. Le traitement d une requête est alors le suivant. Une requête posée par un pair classique est envoyée aux supers pairs présents dans son cache. Si le fichier demandé n est pas présent dans le cache de fichiers des supers pairs, une recherche est initiée sur le réseau des supers pairs. Dans le cas contraire, l identifiant d un pair classique contenant le fichier est retourné. Le pair demandeur peut alors récupérer le fichier sur le pair qui le stocke. 3.3 Conclusion Ce chapitre a dressé un état de l art des caches sémantiques et des caches coopératifs. Les caches sémantiques intègrent des capacités d analyses et d évaluations de requêtes, permettant ainsi d optimiser l utilisation des ressources locales. Les expériences que nous avons réalisées, qui seront présentées dans la partie validation de ce document, ont montré qu une 38

51 3.3 Conclusion partie importante des évaluations de requêtes peut être déléguée aux caches, réduisant ainsi la charge de travail sur les serveurs et les transferts de données entre les serveurs et les caches. Les résultats expérimentaux ont également mis en avant le fait que les caches coopératifs permettent de répartir la charge sur les différents caches. Un cache peut alors tirer profit des résultats présents dans d autres caches et ainsi réduire le travail d évaluation sur les sources de données, en déchargeant par la même occasion certains liens de communication privilégiés. Dans les environnements informatiques actuels, notamment sur les grilles, les clients disposent de ressources de calculs et de stockage importantes, rendant pertinent l utilisation de caches sémantiques pour des systèmes d interrogation. De plus, le nombre de clients présents est généralement très important, permettant d envisager l intégration de techniques de cache coopératif. Il est néanmoins important de noter que les caches sémantiques et les caches coopératifs existants présentent certaines limites pour l interrogation de données à grande échelle. Les caches sémantiques ne distinguent pas clairement la gestion du cache de la gestion de la sémantique (analyse et évaluation de requêtes), rendant plus complexe le déploiement d un cache sémantique. De plus, les types d entrées proposés ne permettent pas de fixer précisément les objectifs à atteindre, à savoir l économie d évaluations et/ou de transferts de données. Ainsi, les différentes propositions n autorisent pas la mise en cache d évaluations sans les objets associés, leur stockage pouvant être difficile pour des grandes masses de données alors que les transferts sont facilités par des réseaux très haut débit permettant de tirer profit d une indexation (accès par identifiants d objet) plus efficace que l évaluation des données (accès par requêtes). En ce qui concerne les caches coopératifs, la localisation des données reste un problème crucial, en particulier pour un très grand nombre de caches. Bien que certaines techniques soient proposées comme solutions à cette problématique, elles restent trop spécifiques en ne considérant qu un protocole de résolution particulier (inondation ou catalogue) et sur une caractéristique précise (distance géographique ou centres d intérêt). Dans le prochain chapitre, nous étudierons les services de caches adaptables, ainsi que les caches utilisés dans les systèmes d interrogation de données à grande échelle existants, en se focalisant en particulier sur les techniques de cache sémantique coopératif. 39

52 Chapitre 3 : Caches sémantiques et caches coopératifs 40

53 Chapitre 4 Caches adaptables et caches pour la gestion de données à grande échelle Dans les chapitres 2 et 3 nous avons étudié les caches, d un point de vue général d abord en présentant les concepts et les caractéristiques des caches, puis en étudiant les caches sémantiques et coopératifs. L objectif de ce chapitre est de dresser un état de l art des services de caches adaptables, ainsi que des caches utilisés dans les systèmes de gestion de données à grande échelle. Ce chapitre est organisé de la manière suivante. La section 4.1 dresse un état de l art des services de caches adaptables. La section 4.2 s intéresse aux caches proposés dans des systèmes d interrogations de données à grande échelle. Enfin, la section 4.3 conclut ce chapitre en présentant un bilan des apports des différentes caches, mais surtout de leurs limites qui motivent notre travail de thèse. 4.1 Services de caches adaptables Les caches sont utilisés dans de nombreuses applications. C est pourquoi, afin de limiter le travail des développeurs, il existe différentes propositions de services de caches génériques pouvant être configurés afin de s adapter à un environnement applicatif particulier. Certaines propositions sont issues de travaux de recherches universitaires comme CaLi et Perseus, d autres correspondent à des logiciels libres accessibles sur Internet Perseus Perseus [GBDC03, GB03, per] est un canevas logiciel pour la construction de gestionnaires d objets persistants. Ces derniers reposent sur différentes fonctionnalités, permettant de prendre en compte le stockage bien sûr, mais également la concurrence des accès, la journalisation et l utilisation d un cache. Chacune de ces fonctionnalités peut être vue comme un «sous-canevas», le cache pouvant ainsi être facilement isolé. 41

54 Chapitre 4 : Caches adaptables et caches pour la gestion de données à grande échelle Le canevas de cache de Perseus repose sur deux composants : le CacheManager et le ReplacementManager, basés tous les deux sur le concept de CacheEntry. Une CacheEntry correspond à une entrée du cache et peut être de différents types, en fonction de l application ciblée. Le CacheManager est en charge de la gestion du contenu du cache. Il capture ainsi de nombreuses caractéristiques : le support physique, la structure de données et la stratégie de recherche. Le ReplacementManager implante, quant à lui, la politique de remplacement utilisée. Perseus offre de nombreuses avantages. Les caches créés peuvent être déployés sur différentes machines (client, serveur et machine intermédiaire), les entrées manipulées peuvent être de différents types, gardées en mémoire ou sur disque, et accédées en lecture seule ou en lecture-écriture. Le canevas capture de plus deux des trois fonctionnalités élémentaires d un cache, à savoir la recherche et le remplacement. Il faut aussi remarquer que l implantation à l aide de l approche à composants Fractal [BCL + 04, fra] autorise la création de caches adaptables dynamiquement. Ce canevas présente néanmoins quelques limites. Le contexte applicatif visé étant la persistance des données, le patron d accès général des données ne considère que les interactions entre un cache et un support de stockage. Ainsi, le protocole de résolution de défaut n est pas capturé spécifiquement, n autorisant pas l intégration de techniques de coopération entre caches. Bien que la création de caches sémantiques soit possible, le canevas n intègre pas explicitement les techniques associées. En particulier, aucun élément n est proposé pour assurer la gestion de la sémantique, que ce soit pour l analyse ou l évaluation des requêtes. D un point de vue plus général, seules les fonctionnalités élémentaires d un cache sont considérées, à l exception du contrôle de concurrence capturé dans le ConcurrencyManager. Enfin, bien que des outils soient fournis pour autoriser la reconfiguration dynamique des caches, les problématiques de capture du contexte et des décisions d adaptation ne sont pas considérées CaLi CaLi [Cal, Zol04] est un canevas C++ pour la création de caches qui peuvent être locaux ou répartis. Suivant les paradigmes de la programmation générique, la bibliothèque fournit un ensemble de modules pour autoriser le déploiement de systèmes de caches flexibles et efficaces. La structure de CaLi repose sur trois concepts : CacheEntry, InsertPolicy et ReplacementPolicy. Le concept de CacheEntry décrit un objet stocké en cache et fournit les informations de base utiles pour les politiques du cache. Le concept est générique et permet de gérer différents types d éléments. Les deux autres concepts permettent de capturer respectivement les politiques d admission et de remplacement. Le cœur du canevas, reposant sur ces différents concepts, est le CacheManager, qui gère les insertions, suppressions et localisations des éléments en cache. En plus de solutions locales, CaLi considère la création de caches distribués en se basant sur le concept DistributedEntry, une extension de CacheEntry. CaLi présente de nombreux avantages. Pour commencer, la bibliothèque permet d adapter toutes les caractéristiques liées au déploiement : le support physique, la place, le droit de modification et le type des éléments manipulés. CaLi capture également la plupart des fonctionnalités de base d un cache : le remplacement, la recherche (selon une structure de 42

55 4.1 Services de caches adaptables données choisie) et même d autres aspects, tels que l admission des éléments ou encore la gestion de la cohérence. Le canevas autorise aussi la création de caches coopératifs grâce au concept de DistributedEntry, considérant des solutions, comme la résolution horizontale par catalogue ou les caches répartis en fonction des documents (à l aide d une fonction de hachage). Ce canevas souffre cependant de quelques manques. Le plus important est, sans doute, l absence d outils pour la création de caches sémantiques, ne prenant ainsi pas en compte les problèmes d analyse et d évaluation de requêtes. Il faut aussi remarquer que la coopération entre caches n est que partiellement abordée, la résolution verticale n étant pas intégrée. De plus, à l exception de la politique d admission, les fonctionnalités optionnelles d un cache ne sont pas considérées. Ceci est particulièrement dommage pour le préchargement, alors que le concept CacheStatistics génère différents types de statistiques. Finalement, l adaptabilité de la solution est limitée au moment du déploiement, une reconfiguration dynamique des différents modules étant impossible Autres services de caches adaptables D autres services de caches adaptables, pour la plupart issus de la communauté du logiciel libre, sont disponibles sur Internet. Memcached [mem] est un système de cache d objets génériques, visant notamment à être utilisé pour améliorer les performances d applications Internet dynamiques. Ce service, développé en C, est en particulier intégré dans les canevas Django et Zend, des canevas de serveur Internet (écrits respectivement en Python et PHP). Bien que le cache soit générique, il reste cependant limité en terme de configuration, les stratégies ne pouvant pas être adaptées, à l instar du remplacement pour lequel seule la politique LRU est disponible. Cache4j [cac], ShiftOne Java Object Cache [joc], OSCache d OpenSymphony [osc], Ehcache [ehc] et Java Caching System [jcs] sont des services de caches, développés en Java, composés d un ensemble de classes permettant de fournir un cache générique d objets. Les caches créés à l aide de ces services peuvent être configurés, pour être déployés sur des clients, des serveurs ou des machines intermédiaires, autorisant des accès en lecture seule ou en lecture-écriture. Il est à noter que OSCache, Ehcache et Java Caching System permettent de créer, en plus des caches mémoires, des caches persistants sur disque (les deux autres services étant dévolus uniquement à la construction de caches mémoires). Tous ces services fournissent différentes politiques de remplacement (LRU, LFU et FIFO pour la plupart). Enfin, la plupart de ces propositions offre la possibilité de créer de nouvelles instances de cache en respectant l interface proposée, laissant la possibilité aux développeurs de choisir d autres structures de données ou stratégies de recherche. Ces services de caches offrent donc un certain degré de flexibilité, notamment en terme de déploiement ou de fonctionnalités de base d un cache. Néanmoins, il est important de noter qu aucun de ces services ne prend en compte les fonctionnalités optionnelles telles que le préchargement, la mise en cache négative ou encore l admission. Il n existe pas non plus de proposition intégrant les techniques de cache sémantique, ni même les techniques de coopération entre caches. Enfin, bien que ces services de caches soient adaptables statiquement, aucun d eux ne prend en compte les problèmes de reconfiguration dynamique. 43

56 Chapitre 4 : Caches adaptables et caches pour la gestion de données à grande échelle 4.2 Caches pour l interrogation de données à grande échelle Le volume de données augmentant plus vite que les capacités matérielles de stockage, les architectures nouvelles sont distribuées, souvent à grande échelle. On parle alors de grilles de données. Celles-ci sont majoritairement utilisées dans les communautés effectuant de gros calculs qui manipulent des volumes de données très importants, telles que la biologie (génomique), l astronomie ou la météorologie. L utilisation de caches est alors cruciale pour fournir une bonne qualité de service. Dans cette section, nous présentons un état de l art des caches intégrés à des systèmes de gestion de données à grande échelle dcache dcache [FG06] est un cache pour grille, utilisé pour la gestion des données enregistrées par l accélérateur de particules du CERN. L objectif de dcache est de fournir un système pour stocker et manipuler de gros volumes de données distribués sur de nombreux serveurs hétérogènes, sous un unique système de fichiers virtuel à l aide de méthodes d accès standards. Afin de fournir ce service, dcache propose des méthodes pour répartir la charge et assurer un certain degré de tolérance aux fautes. dcache est particulièrement intéressant en terme de passage à l échelle, notamment en nombre de clients ou en volume de données manipulées. Néanmoins, dcache reste une solution globale à la grille, rendant difficile son déploiement, du fait de l utilisation d autres couches logicielles spécifiques à la grille, telles que SRM (Storage Resource Manager) pour le stockage et la répartition des ressources. Il faut également noter que la manipulation des données se fait à un grain relativement grossier, les fichiers, n autorisant pas des interrogations sur les données. Par conséquent, les techniques de cache sémantique ne sont pas intégrées Sequoia Sequoia, anciennement C-JDBC (Cluster-JDBC) [Cec04] [CMZ04], est un intergiciel pour la gestion de bases de données sur grappe. Alors que les utilisateurs ont une vision d une unique base de données virtuelle, les données sont en réalité gérées sur plusieurs nœuds d une grappe, offrant alors une certaine tolérance aux fautes, ainsi qu une meilleure répartition de charge et une plus grande disponibilité que pour les systèmes de gestion de base de données répartis classiques. Il est important de noter que Sequoia repose également sur l utilisation de caches pour améliorer les performances. Néanmoins, les caches proposés sont relativement simples, stockant des résultats de requêtes sans pour autant considérer les techniques de cache sémantique (analyses et évaluations de requêtes au sein du cache) ou encore les coopérations entre caches Gestion intelligente de caches La gestion intelligente de caches ou ICM (Intelligent Cache Management) [AZQ05] est utilisée pour optimiser l interrogation de bases de données réparties sur grilles. Un 44

57 4.2 Caches pour l interrogation de données à grande échelle schéma unique de la base de données est alors partagé par tous les sites concernés. Le plan d exécution d une requête devant être évaluée distingue la sous-requête à évaluer sur les bases de données locales des sous-requêtes à soumettre aux bases de données distantes, puis construit le réponse finale en fusionnant les résultats des sous-requêtes. Afin d optimiser les performances, notamment les problèmes de latence réseau, un cache sémantique est utilisé pour stocker les résultats des sous-requêtes distantes. L utilisation de cache permet également aux clients de consulter des réponses partielles en attendant l évaluation des sous-requêtes sur les sources de données distantes. Il est à noter qu en dépit du nombre important de caches pouvant être présents dans le système d interrogation, les coopérations entre caches ne sont pas considérées. Ainsi, une requête distante est directement envoyée sur les bases de données concernées, même quand le résultat est présent dans d autres caches du système. Il faut aussi remarquer que le passage à l échelle d ICM est limitée, la présence d un schéma unique partagé étant une contrainte très (voire trop) forte, notamment pour les grilles, où une administration centralisée est difficile, voire impossible Squid Squid [squ] est un logiciel libre, issu des recherches menées au cours du projet Harvest [CDN + 96] (à l instar de la version commerciale NetCache) permettant de déployer des caches mandataires pour Internet, qui utilisent différents protocoles, tels que FTP, HTTP, Gopher, et HTTPS. Squid intègre la plupart des techniques de coopérations entre caches, à savoir les résolutions verticale, horizontale par inondation (ICP ou HTCP) ou à l aide de catalogue digest, et les caches répartis en fonction des demandes via une fonction de hachage (CARP). Bien qu à l origine Squid fut proposé pour Internet, il est également utilisé pour la gestion du cache dans le système de gestion de bases de données sur grille FroNtier [fro]. Bien que Squid ait été intégré dans un système d interrogation de bases de données sur grille, il n existe pas de prise en compte des techniques de cache sémantique, seuls les succès exacts étant considérés. Il est intéressant de remarquer que de récents travaux sont en cours pour proposer l adaptabilité dynamique des caches Squid [SDML + 06]. Néanmoins, ces propositions portent surtout sur l évolution des caches, en permettant d ajouter de nouvelles fonctionnalités, telles que la correction de trous de sécurité ou encore d une politique de préchargement, à l aide d une technologie par aspects. Malheureusement, les problèmes de reconfiguration dynamique ne sont pas vraiment étudiés Service uniforme de caches distribués pour calcul sur grille Le service uniforme de caches distribués pour calcul sur grille (Uniform Distributed Cache Service for Grid Computing) [CPB05] est utilisé dans des systèmes d interrogation haut niveau de données sur grilles. Ce service vise à optimiser l utilisation des données disponibles sur la grille et à fournir des accès performants, en proposant des caches coopératifs. La coopération correspond à une résolution horizontale à l aide d un catalogue, la gestion de celui-ci étant facilitée par une approche hiérarchique. Il est intéressant de noter que le prototype proposé autorise également l adaptabilité dynamique de la politique de remplacement. 45

58 Chapitre 4 : Caches adaptables et caches pour la gestion de données à grande échelle Bien que ce service se focalise sur l interrogation de données, les solutions de caches sémantiques ne sont malheureusement pas considérées. Ceci est particulièrement dommage, puisque l approche tend à proposer un système d interrogation particulièrement pertinent autorisant l accès aux données à l aide des méta-données associées. 4.3 Conclusion En s appuyant sur les caractéristiques des caches présentées dans le chapitre 2 et l état de l art sur les caches sémantiques et les caches coopératifs développé dans le chapitre 3, ce chapitre a étudié les services de caches adaptables et les caches utilisés dans les systèmes d interrogation largement distribués afin de placer le contexte de nos travaux de recherche. Perseus CaLi MemC OSC JOC C4j EhC JCS Support Oui Oui Non Oui Non Non Oui Oui Modification Oui Oui Oui Oui Oui Oui Oui Oui Place Oui Oui Oui Oui Oui Oui Oui Oui Entrée Oui Oui Oui Oui Oui Oui Oui Oui Remplacement Oui Oui Non Oui Oui Oui Oui Oui Recherche Oui Oui Non Non Oui Oui Oui Oui Résolution Non Oui Non Non Non Non Non Non Sémantique Non Non Non Non Non Non Non Non Préchargement Non Non Non Non Non Non Non Non Admission Non Oui Non Non Non Non Non Non Allocation Non Non Non Non Non Non Non Oui Cache négatif Non Non Non Non Non Non Non Non Adaptation statique Adaptation dynamique Tab. 4.1 Caractéristiques des services de caches adaptables Le tableau 4.1 présente une synthèse des caractéristiques détaillées dans le chapitre 3 couvertes par les services de caches adaptables. Ce tableau permet d observer que les services existants sont relativement complets en terme de déploiement et de fonctionnalités élémentaires. Seule la politique de résolution (et par conséquent les coopérations entre caches) n étant que très rarement considérée. Ces services de caches adaptables présentent néanmoins certaines limites, puisque les fonctionnalités optionnelles ne sont pas ou très peu capturées. En particulier, aucun des caches étudiés ne considère la construction de caches sémantiques. Ces techniques sont pourtant, selon nous, particulièrement pertinentes pour le passage à l échelle des systèmes d interrogations, puisqu elles permettent de maximiser l utilisation des ressources disponibles en cache, celles-ci étant de plus en plus importantes, pour ainsi réduire la charge sur les serveurs et sur les liens de communications devant gérer un nombre toujours plus important de clients. Du point de vue de l adaptabilité, la plupart des services offre la possibilité de configurer les caches statiquement. Néanmoins, il convient de noter que seul Perseus rend possible l adaptation dynamique d un cache en terme de composants. Il faut cependant remarquer 46

59 4.3 Conclusion que Perseus offre simplement la propriété d adaptabilité dynamique, mais ne considère pas vraiment cette problématique. En effet, les problèmes d observation de l environnement et d auto-adaptation ne sont pas abordés. Sémantique Coopération dcache Non Oui Sequoia Non Non ICM Oui Non Squid/FroNtier Non Oui Service uniforme Non Oui Tab. 4.2 Caches pour les systèmes d interrogation de données à grande échelle Le tableau 4.2 présente un récapitulatif des caches utilisés dans les systèmes d interrogation de données à grande échelle, en fonction des techniques présentées dans le chapitre 3. Il permet de s apercevoir qu il n existe pas de cache prenant en compte à la fois les techniques de cache sémantique et les coopérations entre caches. En fait, la plupart des caches se focalise sur la coopération, seule ICM considérant la sémantique au sein du cache. 47

60 Chapitre 4 : Caches adaptables et caches pour la gestion de données à grande échelle 48

61 Deuxième partie Caches adaptables et techniques pour le passage à l échelle des applications 49

62

63 Préambule L utilisation de caches est cruciale dans de nombreux systèmes informatiques. Néanmoins, un cache n est efficace que s il est correctement configuré en fonction de son environnement d exécution et de l application. C est pourquoi, lorsqu un cache est nécessaire, il est très souvent construit de bout en bout, ce qui est coûteux en temps (et en argent). Ceci est d autant plus vrai dans des environnements grande échelle, comme les grilles, pour lesquels, de nombreux caches parfois hétérogènes sont nécessaires. De plus, les systèmes informatiques actuels étant en général dynamiques, il est important de pouvoir reconfigurer les caches proposés afin de les adapter en fonction des modifications de l environnement. Malheureusement, les services de caches adaptables existants sont, de notre point de vue, incomplets, car certaines caractéristiques des caches, ainsi que les problèmes d adaptation dynamique, ne sont pas pris en compte. L un des objectifs de cette thèse est d apporter une solution à ces problèmes, en fournissant un service de caches adaptables, visant à faciliter la création de caches sophistiqués afin d offrir une haute qualité de service. Nos travaux de recherche se sont particulièrement intéressés à l utilisation de caches dans les systèmes d interrogation de données largement distribués, en reprenant des techniques de cache avancées pour les intégrer au sein d un environnement dynamique et dirigé par des problèmes de passage à l échelle. Nous nous sommes notamment focalisés sur les techniques de cache sémantique, qui optimisent l utilisation des ressources disponibles en cache, et les techniques de cache coopératif et favorisent les interactions entre caches afin de limiter les communications avec les serveurs (réduisant ainsi la charge sur les serveurs, ainsi que la consommation de bande passante). La facilité de création de caches à l aide de notre service de caches adaptables nous a permis de tester différentes configurations pour un système donné. Ainsi, l utilisation de ce service a donné naissance à de nouvelles techniques de cache sémantique et coopératif. Les caches sémantiques permettent d optimiser les performances des systèmes d interrogation dans lesquels ils sont intégrés en réduisant à la fois les transferts de données et la charge d évaluation sur les serveurs. Néanmoins, les différents caches proposés dans la littérature ne semblent pas adaptés à une utilisation grande échelle. Premièrement, le déploiement de tels caches sémantiques est rendu difficile, car la gestion du contenu du cache et la gestion de la sémantique ne sont pas clairement distinguées. De plus, la gestion du contenu du cache ne permet pas de fixer de manière précise les objectifs à atteindre, la réduction de la charge sur les serveurs et/ou les transferts de données. C est ainsi que les caches sémantiques proposés interdisent la mise en cache de résultats d évaluations sans que les objets correspondants ne soient stockés. Ceci est particulièrement dommage dans des environnements manipulant de grands volumes de données, permettant de profiter d accès efficaces par rapatriement de données sur les serveurs. 51

64 L utilisation de caches sémantiques est une première étape pour optimiser les performances dans les systèmes d interrogation largement distribués. Néanmoins, bien que le travail local soit réduit, une partie des évaluations reste à la charge des serveurs, ce qui nécessitent des capacités de traitement, mais également de transfert des données. Ceci peut devenir particulièrement problématique pour de multiples clients. C est pourquoi, il est intéressant de considérer les techniques de cache coopératif, pour que les ressources d un cache puisse être utiles à d autres caches. Bien que les caches sémantiques et les caches coopératifs soient des techniques orthogonales, il n existe pas, à notre connaissance, de proposition de cache intégrant conjointement ces deux aspects, alors qu une telle combinaison semble particulièrement pertinente pour les systèmes d interrogation à grande échelle. Au cours de nos travaux, nous avons étudié différentes stratégies de coopération entre caches sémantiques. Nous nous sommes notamment focalisés sur la résolution horizontale de défaut de cache, permettant des coopérations entre caches largement distribués.pour un tel contexte, il est néanmoins nécessaire de traiter le problème de la localisation des données en cache, afin de proposer des coopérations fines entre les différents caches. Dans la suite de ce document, nous présenterons nos propositions. Le chapitre 5 présentera ACS un canevas de caches adaptables. Le chapitre 6 présentera le cache dual une approche novatrice de cache sémantique pour l interrogation de données largement réparties. Enfin, le chapitre 7 introduira les caches sémantiques coopératifs. 52

65 Chapitre 5 ACS, un canevas de caches adaptables Le chapitre 4 nous a montré que les solutions de caches adaptables existantes ne capturent pas certaines techniques de coopération entre caches, ni les principes des caches sémantiques. L objectif de ce chapitre est de présenter le canevas de cache adaptable ACS (Adaptable Cache Service), permettant de construire des caches pour divers contextes applicatifs. Les caches ainsi créés peuvent notamment faciliter le passage à l échelle des applications. Ce chapitre est organisé de la manière suivante. La section 5.1 fournit un aperçu de notre proposition de canevas de caches adaptables ACS. La section 5.2 présente l architecture du canevas. Les sections 5.3 et 5.4 s intéressent à l utilisation d ACS pour la construction de caches sémantiques et coopératifs. La section 5.5 étudie l adaptation contextuelle des caches. La section 5.6 conclut ce chapitre. 5.1 Aperçu du canevas de caches adaptables ACS Le chapitre 4 a montré que les caches adaptables existants restent limités en terme de passage à l échelle pour la gestion de données. En effet, les techniques de cache sémantique et coopératif ne sont pas, ou très peu, considérées, laissant à la charge des serveurs une grande partie du travail d évaluation. De plus, la plupart du temps, l adaptabilité dynamique des caches n est pas prise en compte. Le travail présenté dans ce chapitre vise à fournir une réponse à ces problèmes, en proposant un cache adaptable statiquement et dynamiquement prenant en compte la création de caches sémantiques et coopératifs. Notre approche cherche à reprendre les caractéristiques des caches et les techniques permettant le passage à l échelle des applications en les généralisant de manière à définir un cache suffisamment flexible pour s adapter à un environnement quelconque et en particulier pour permettre la gestion de données largement distribuées. Dans cette optique, nous proposons trois contributions : La première contribution, ACS, est un canevas pour la construction de caches adaptables. L adaptabilité repose sur le principe de la séparation des préoccupations. Ainsi, les 53

66 Chapitre 5 : ACS, un canevas de caches adaptables caractéristiques sont gérées de manière relativement indépendantes permettant d ajouter, supprimer, remplacer les fonctionnalités de manière statique ou dynamique. Le principe général consiste à caractériser les besoins de l environnement et à choisir les stratégies correspondantes. Ainsi, en fonction de la configuration désirée, les composants du cache sont choisis au sein de la bibliothèque de composants proposés. Les composants peuvent également être développés pour des besoins spécifiques, si nécessaire. Le canevas offre ainsi une capacité d évolution pour le service de caches. Une fois l assemblage des composants terminé, le cache peut être exécuté sur les machines souhaitées. La deuxième contribution cherche à compléter la bibliothèque de composants proposée afin d intégrer des techniques de cache sémantique. Les composants proposés autorisent la manipulation de régions sémantiques en terme de résultats de requêtes ou en terme d objets, ainsi que l intégration de politiques de remplacement et de préchargement spécifiques, et enfin la prise en compte des techniques de partitionnement et regroupement de requêtes. La troisième contribution regroupe les solutions autorisant les différentes techniques de coopération entre caches. L idée est de fournir les composants de base permettant de proposer les stratégies étudiées dans le chapitre 3 : les résolutions verticale et horizontale, les caches répartis ou encore la coopération entre caches hétérogènes. A noter que la modularité d ACS permet alors de combiner facilement les différentes approches. La quatrième contribution vise à fournir une adaptation contextuelle pour les caches créés à l aide d ACS, afin de les adapter aux variations de leur contexte applicatif, à l aide d une modification de leur configuration, en les paramétrant de manière différente, ou par un ajout, une suppression ou un changement d un ou plusieurs de leurs composants. Pour ce faire, l adaptation contextuelle repose d une part sur un gestionnaire de contexte offrant une vision du contexte applicatif, et d autre part sur des règles actives permettant d adapter la configuration du cache proposé. Illustrations Notre proposition sera illustrée au fur et à mesure de ce chapitre dans deux contextes applicatifs différents : un système d interrogation de sources de données sur grille et une application de sécurité pour la surveillance du trafic réseau. Ces deux contextes présentent la particularité de mettre en œuvre différents types de cache. Le système d interrogation est considéré pour une application de bio-informatique. La gestion de données se fait à la granularité des enregistrements. Un enregistrement représente des séquences de protéines annotées. Il contient la séquence d une protéine, ainsi que des informations permettant, par exemple, de dater la création ou les modifications, ou de donner des noms des personnes ayant travaillé avec. Deux sources de données sont considérées : Swiss-Prot et TrEMBL [swi]. La première correspond à une base de références, la seconde gère les enregistrements non encore intégrés dans la première. Outre la différence sémantique, il convient de noter que ces bases diffèrent surtout par leur taille, le fichier Swiss-Prot est ainsi inférieur à 1Go, alors que TrEMBL fait plus de 2Go. EXTRA (EXternal TRaffic Analyzer) [ext] est un outil de surveillance réseau basé sur l analyse de la journalisation de routeur d une institution. Cet outil récupère le trafic réseau qui est stocké dans des bases de données gérées à l aide du système MySQL. Les n-uplets enregistrés contiennent des informations relatives aux communications, comme les 54

67 5.2 Architecture d ACS adresses internes ou les ports internes et externes à l institution. Les données sauvegardées sont alors analysées pour détecter les situations anormales, comme une intrusion dans le système. Afin d illustrer différents aspects de l adaptation contextuelle, nous considérons un environnement multi-sources et multi-clients. Les sources sont présentes de manière permanente dans le système, mais peuvent parfois être indisponibles (défaillance du serveur, arrêt pour une mise à jour). Les clients peuvent apparaître et disparaître de la grille, à l instar d un système pair-à-pair. 5.2 Architecture d ACS Fig. 5.1 Architecture d ACS ACS est un service de caches adaptables et évolutifs. L adaptabilité repose sur les technologies à composants, permettant des adaptations statiques et dynamiques des caches construits. L utilisation d un canevas logiciel [Joh97] permet, quant à elle, de capturer les interactions entre les différents composants. Les canevas logiciels offrent, de plus, des capacités d évolution intéressantes, autorisant l intégration de nouvelles techniques. Cet aspect est particulièrement pertinent pour les caches, où de nouvelles stratégies sont fréquemment proposées (politiques de remplacement, protocoles de résolution, etc.). Cette section présente l architecture du canevas de caches adaptables ACS, illustrée par la figure 5.1, capturant les fonctionnalités d un cache et leurs interactions. Le canevas est décomposé en trois groupes distincts, mais complémentaires, de composants. Le premier correspond au cache élémentaire, alors que le deuxième est associé au cache augmenté. Le troisième groupe, quant à lui, traite des interactions avec des services extérieurs Cache élémentaire Un cache élémentaire est un cache pour lequel seules les fonctionnalités élémentaires sont prises en compte. Dans cette section, nous présentons chaque fonctionnalité avant de conclure en présentant les compositions du point de vue du cache. Mais avant d aborder 55

68 Chapitre 5 : ACS, un canevas de caches adaptables ces différents thèmes, il est nécessaire d introduire le concept fondamental d un cache : la notion d entrée Entrée du cache Le fonctionnement d un cache s articule autour du concept d entrée du cache. Une entrée correspond à un couple (id, objet), représentant un élément du cache accédé à l aide de son identifiant id et dont la valeur est objet. En plus de ces informations utiles à l application, une entrée du cache maintient d autres informations pouvant être utilisées en interne, comme par exemple les informations de remplacement. Ainsi, il est possible de maintenir l âge d une entrée, le moment de la dernière utilisation, ou encore la fréquence d utilisation. Exemple 5.1. Soit creqgri, un cache de requêtes pour le système d interrogation de sources de données sur grille, contenant l entrée (espèce = Eucaryotes,{e 1,e 2,...,e n }). Dans ce cas, l identifiant est le prédicat espèce = Eucaryotes et la valeur est l ensemble {e 1,e 2,...,e n }. Exemple 5.2. Soit cobjgri, un cache d objets pour le système d interrogation de sources de données bio-informatiques, contenant l entrée (ACHYT,e 1 ). Dans ce cas, l identifiant et la valeur sont respectivement l identifiant de l enregistrement ACHYT et l enregistrement lui-même e 1. Exemple 5.3. Soit creqextra, un cache de requêtes pour le système de surveillance réseau EXTRA, contenant l entrée (select * from ,{t 1,t 2,...,t n }). Dans ce cas, l identifiant et la valeur sont respectivement la requête SQL select * from et les n-uplets t 1,t 2,...,t m correspondants Maintient du contenu du cache Un cache doit fournir les opérations de base pour ajouter, modifier, supprimer et rechercher des éléments. Toutes ces opérations sont capturées par le gestionnaire de contenu ou ContentManager. Les caractéristiques d un cache considérées à ce niveau sont : la structure de données, la stratégie de recherche en cache et le support physique sur lequel sont enregistrées les entrées. La recherche au sein du cache est nécessaire à chaque fois qu un élément est accédé. Puisqu il s agit d un évènement fréquent, le gestionnaire du contenu doit prendre en compte la performance de cette opération, tout en considérant les coûts associés aux autres méthodes (ajout, suppression, modification). C est pourquoi, le contenu du cache, représenté par une structure de données (vecteur, arbre, table de hachage, etc.) nommée content, doit être choisi en fonction du contexte applicatif. L implantation des méthodes de maintien du contenu du cache est directement liée à ce choix. Il faut noter que la méthode de recherche offre un degré d adaptabilité, prenant en compte l algorithme souhaité. Il est également important de remarquer que le choix du support physique est capturé au sein du gestionnaire de contenu. Ainsi, la bibliothèque du canevas ACS propose différents composants gestionnaire de contenu, certains pour construire des caches mémoires, d autres pour fournir des caches disques. 56

69 5.2 Architecture d ACS Exemple 5.4. Supposons un utilisateur intéressé par la source de données Swiss-Port. Dans ce cas, l entrée de taille maximale pouvant être stockée en mémoire, il est possible d utiliser un cache mémoire cmem. Une entrée de cmem correspond à un couple (prédicat, ensemble des enregistrements vérifiant le prédicat), par exemple (espèce = Eucaryotes, {e 1,e 2,...,e n }). Exemple 5.5. Supposons un utilisateur intéressé par la source de données TrEMBL. Dans ce cas, l entrée de taille maximale ne pouvant être stockée en mémoire, il est intéressant d utiliser un cache disque cdisque. Une entrée de cdisque correspond dans ce cas à un couple (prédicat, nom de fichier), le fichier associé étant utilisé pour garder l ensemble des enregistrements vérifiant le prédicat. Par exemple pour l entrée (espèce = Eucaryotes, euc.txt), le fichier euc.txt stocké sur le disque contient l ensemble d enregistrements {e 1,e 2,...,e n }. Fig. 5.2 Ajout d un élément en cache Le gestionnaire de contenu permet de vérifier et récupérer un élément au sein du cache à l aide de la méthode chercher (lookup). Le résultat d un appel à cette méthode est alors l élément correspondant s il est présent, la réponse nulle sinon. Une fois récupéré, un objet peut être ajouté en cache en utilisant la méthode ajouter (bind), comme illustré par la figure 5.2. La suppression d un élément par la politique de remplacement (voir la section sur le remplacement ) est assurée par la méthode supprimer (unbind). En cas de besoin, la modification des entrées du cache peut être fournie à l aide d une méthode explicite modifier (modify), mais également être considérée uniquement en terme de suppression des anciennes valeurs et d ajout des nouvelles Remplacement d entrées du cache La politique de remplacement détermine l ensemble des entrées devant être évincées du cache. Elle choisit par exemple, lorsque l espace disponible alloué au cache est faible, des éléments à supprimer pour en ajouter de nouveaux. Le choix de cette politique est capturé au sein du composant gestionnaire de remplacement (ReplacementManager). Puisque l ajout et le moment d accès à un élément du cache sont souvent considérés par la politique de remplacement, il est important de capturer les interactions entre le gestionnaire de contenu et le gestionnaire de résolution (présenté dans la section suivante) pour ces deux évènements. L ajout d un élément en cache est un évènement important pour les politiques basées sur le moment d entrée ou encore le moment d utilisation (la création étant considérée alors comme la première utilisation). C est pourquoi cette situation doit être capturée par les 57

70 Chapitre 5 : ACS, un canevas de caches adaptables (a) Notification d ajout d un élément (b) Notification d accès à un élément (c) Notification de remplacement Fig. 5.3 Interactions entre les gestionnaires de contenu et de remplacement interactions entre le gestionnaire de contenu et le gestionnaire de remplacement comme illustrée par la figure 5.3(a). L insertion d un élément provoque la séquence d actions suivante. L élément est d abord ajouté en cache par un appel à la méthode ajouter. Le gestionnaire de contenu notifie alors l insertion au gestionnaire de remplacement en invoquant la méthode ajouterpourremplacement (addforreplacement). A ce moment, l objet est ajouté dans la structure de données gérant les éléments éligibles lors d un remplacement. Le gestionnaire de remplacement réalise également un ensemble d actions pour mettre à jour les informations utilisées par la politique de remplacement. Ces informations peuvent varier en fonction de la politique de remplacement utilisée. Par exemple, une politique basée sur la fréquence d accès prendra en compte le nombre d accès à un objet, alors qu une politique basée sur le moment d entrée en cache se focalisera sur l instant d ajout de l objet en cache. Le diagramme de séquences de la figure 5.3(b) illustre les interactions entre le gestionnaire de cache et le gestionnaire de remplacement lors de l utilisation d une entrée du cache. A chaque accès, le gestionnaire de contenu invoque l opération ajusterpourremplacement (adjustforreplacement) du gestionnaire de remplacement qui provoque éventuellement la mise à jour des informations pour le remplacement. Si la politique prend en compte la fréquence ou le moment d accès, alors un appel à cette méthode provoquera une modification de ces informations. Par contre, si la stratégie ne considère que le moment d entrée, alors l appel à cette méthode n a aucune incidence, puisque seul l instant de création est pris en compte. Évidemment, ces appels sont inutiles dans ce cas. Néanmoins, en cas de changement de la politique de remplacement, ces appels peuvent de nouveau être pertinents. Ainsi, capturer cette interaction quelle que soit la politique de remplacement évite de remplacer le gestionnaire de contenu en cas de modification du gestionnaire de remplacement. La spécification du gestionnaire de contenu prend en compte la gestion d évènements de remplacement. Ces évènements peuvent alors être utilisés par d autres composants. Cette fonctionnalité peut en particulier être utilisée pour mettre à jour les catalogues dans une résolution horizontale (voir section 5.4). La figure 5.3(c) présente les interactions entre le gestionnaire de contenu et le gestionnaire de remplacement dues à une notification de remplacement. Au moment du choix des victimes, le gestionnaire de 58

71 5.2 Architecture d ACS remplacement notifie le gestionnaire de contenu de sa décision en utilisant la méthode HandleEviction (prise en compte de l éviction). Cette notification est alors propagée à tous les abonnés de l évènement. Exemple 5.6. Soit cobjgri, un cache d objets pour le système d interrogation sur grille permettant de garder les objets les plus souvent utilisés. Une politique de remplacement LRU est efficace pour des accès aux éléments suivant une localité temporelle (un élément accédé à de fortes chances de l être de nouveau dans un futur proche). La mise en œuvre dans un gestionnaire de remplacement LRU se fait en associant à chaque objet une horloge logique indiquant le moment de sa dernière utilisation. Exemple 5.7. Soit creqgri, un cache de requêtes pour le système d interrogation sur grille gérant des objets associés à des requêtes posées. Supposons que les tailles des réponses soient très variables. Alors une politique de remplacement basée sur la taille des entrées, telle que SIZE [ASA + 96] est efficace si elle favorise le stockage de nombreuses entrées utiles au détriment d éléments plus volumineux. Ainsi, un gestionnaire de remplacement basé sur la taille peut être mis en œuvre en ordonnant les entrées sur leur taille (un autre critère étant utilisé pour départager deux éléments de même taille, par exemple, le dernier moment d accès). La mise en œuvre de politique de remplacement basée sur plusieurs stratégie à l instar de DBMIN [CD98] est réalisable à l aide d ACS. Alors qu une approche intuitive serait de créer un gestionnaire de remplacement prenant en compte les différentes séquences d accès, une autre approche consiste à créer autant de gestionnaire de contenu que de patrons considérés et d appliquer à chacun la politique choisie. Dans ce cas, les autres composants sont partagés. Par exemple, un seul gestionnaire de résolution est utilisé quelle que soit la séquence d accès. Cette solution permet de séparer les préoccupations. La gestion du contenu du cache et du remplacement est prise en compte par les gestionnaires correspondants, alors que la répartition est considérée à un niveau supérieur (voir la gestion du cache) Résolution d un défaut de cache Le gestionnaire de résolution (ResolutionManager) capture le processus à exécuter en cas de défaut de cache pour récupérer un objet demandé. Deux caractéristiques du cache sont considérées à ce niveau : le mode de communication avec le serveur mais également les coopérations entre caches par résolutions horizontale ou verticale. Exemple 5.8. Soit cobjgri, un cache d objets pour le système d interrogation de sources de données bio-informatiques. Dans ce cas, le gestionnaire de résolution récupère les objets sur les serveurs à l aide de leur identifiant. Le gestionnaire peut prendre en compte des résultats sous forme de flux de données. Exemple 5.9. Soit creqextra, un cache de requêtes utilisé pour le système de surveillance réseau EXTRA. Dans ce cas, le gestionnaire de résolution assure la communication avec le système de gestion de bases de données MySQL, fournissant notamment la localisation de la base ainsi que les informations de connexion. Dans le cas d une version java du canevas, le composant peut également procéder à une transformation du résultat pour extraire du resultset JDBC des objets éventuellement typés. 59

72 Chapitre 5 : ACS, un canevas de caches adaptables Du point de vue d un cache, le gestionnaire de résolution est vu comme un serveur, fournissant les objets demandés. Il est utilisé par invocation de la méthode charger (load), lorsqu un objet doit être récupéré. Le diagramme de séquences de la figure 5.4 présente les interactions entre le gestionnaire de contenu et le gestionnaire de résolution au sein d ACS. Dans le cadre d une résolution horizontale ou verticale, d autres interactions entre le gestionnaire de résolution et un cache peuvent être ajoutées. L étude de ces interactions sera détaillée dans la section 5.4. Fig. 5.4 Interactions entre les gestionnaires de cache et de résolution dues à une résolution de défaut de cache Compositions Il est important de proposer une interface standard permettant d accéder aux méthodes des sous-composants utilisées par les clients d un cache (un utilisateur, une application ou un autre cache). Cette interface est proposée par le gestionnaire de cache (CacheManager) servant de glue pour la composition interne des composants d un cache, mais également pour la composition externe avec d autres caches. Cette dernière composition est réalisée à l aide des méthodes chercher et charger fournies par le gestionnaire de cache. Fig. 5.5 Interactions entre le gestionnaire du cache et les sous-composants lors d un chargement La figure 5.5 présente les interactions entre un client et un cache lors du traitement d une demande sur le cache à l aide de la méthode charger (load). Cette méthode sert de point d entrée pour les applications ou les caches de niveaux inférieurs pour lesquels l objet demandé doit être fourni. A la réception d une demande, le gestionnaire du cache exécute une recherche de l élément au sein du cache via la méthode chercher (lookup) du gestionnaire de contenu. En cas de défaut, l élément est récupéré en invoquant la méthode charger du gestionnaire de résolution. Une fois reçu, l élément est ajouté en 60

73 5.2 Architecture d ACS cache par le gestionnaire de cache en utilisant la méthode ajouter du gestionnaire de contenu. Fig. 5.6 Interactions entre le gestionnaire du cache et les sous-composants lors d une recherche Contrairement à une demande classique, la demande d un objet provenant d un cache frère ne doit pas provoquer de résolution si un défaut se produit, une réponse nulle doit être retournée dans ce cas là. Dans ce cas, la résolution n est pas activée, comme illustré par le diagramme de séquences de la figure Cache augmenté En plus d autoriser la création de caches élémentaires, ACS permet de prendre en compte des fonctionnalités optionnelles d un cache et ainsi proposer des caches augmentés. L objectif de cette section est de présenter la gestion de ces différentes fonctionnalités au sein du canevas : la gestion de la sémantique, le préchargement, l admission, le cache négatif et l allocation Gestion de la sémantique Les caches sémantiques doivent proposer des outils permettant d utiliser des connaissances supplémentaires sur les données présentes en cache. Deux fonctionnalités distinctes, mais néanmoins coopératives, peuvent être isolées : l analyse et l évaluation de requêtes. Un gestionnaire de cache particulier doit ensuite être utilisé pour prendre en compte la sémantique au sein du cache Analyse des requêtes L analyseur de requ^etes (QueryAnalyser) se préoccupe du processus de comparaison sémantique entre les requêtes posées et le contenu du cache dans le but de détecter des situations de recouvrement sémantique. Ce composant peut ainsi permettre, selon les cas de figure considérés, l équivalence entre une requête et une entrée du cache, l inclusion d une requête dans une entrée, l inclusion d une entrée dans une requête, ou encore un recouvrement partiel. La détection de ces différents cas de figure repose sur les travaux issus de la communauté de recherche sur le recouvrement (query containement). Il est important de noter que ces travaux n ayant pas fait l objet d une étude poussée durant nos recherche, ils ne seront pas développés dans ce document. L analyse sémantique est considérée uniquement si la requête posée n est pas déjà présente comme identifiant d une entrée du cache. Lors de l analyse, le gestionnaire de cache parcourt les entrées du cache en les comparant à la requête posée en fonction des 61

74 Chapitre 5 : ACS, un canevas de caches adaptables situations considérées. Une fois une entrée choisie, le gestionnaire de cache décompose la demande de l utilisateur en une requête de consultation et une requête restante. Fig. 5.7 Interactions entre le gestionnaire de cache et l analyseur de requêtes Les interactions entre le gestionnaire de cache et l analyseur de requ^etes sont illustrées par le diagramme de séquences de la figure 5.7. Le résultat d un appel à la méthode analyse portant sur une requête q et une entrée du cache e correspond à la situation de recouvrement correspondante (équivalence, inclusion de q dans e ou de e dans q, recouvrement partiel ou disjonction). L analyse de requêtes peut être un processus complexe et par conséquent relativement coûteux. C est pourquoi il est important d être capable de juger les situations de recouvrement à considérer et celles devant être ignorées. Ainsi, même si un analyseur de requ^etes autorise la détection de tous les cas de figure, seuls certains d entre eux peuvent être étudiés par le gestionnaire de cache. Il est également important de noter que l analyse de requêtes dépend du langage d interrogation employé. Exemple Soit creqgri, un cache de requêtes pour le système d interrogation de données bio-informatiques. Supposons que les accès par les utilisateurs correspondent à des raffinements de requêtes de sélection. Dans ce cas, un gestionnaire de cache peut utiliser un analyseur de requ^etes permettant de détecter les inclusions d une requête posée dans une entrée du cache, pour le langage utilisée (il s agit ici d un langage de requêtes particulier, utilisé au sein de l intergiciel de gestion de sources de données). L inclusion entre deux requêtes est, dans ce cas, détectée si l une des requêtes est obtenue en appliquant une contrainte supplémentaire à la seconde. Exemple Soit creqextra, un cache de requêtes pour le système de surveillance réseau EXTRA. Supposons que les accès par les utilisateurs correspondent à des raffinements de requêtes de sélection ou à des changement de présentation des résultats. Dans ce cas, un gestionnaire de cache peut utiliser un analyseur de requ^etes pour un langage de type SQL permettant de détecter les inclusions d une requête posée dans une entrée du cache (ajout de conditions supplémentaires dans la clause WHERE) ou les équivalences entre une requête et une entrée (changement de la clause ORDER BY pour modifier le classement des résultats Évaluation de requêtes L évaluateur de requ^etes (QueryEvaluator) fournit des opérateurs (sélection, projection, ordonnancement, agrégation, etc.) pour évaluer localement des requêtes sur le contenu du cache. Il permet d évaluer certaines requêtes sur une entrée du cache afin 62

75 5.2 Architecture d ACS d obtenir le résultat demandé. L évaluateur de requ^etes est ainsi utilisé pour les cas d inclusions d une requête dans une entrée ou de recouvrements partiels. Fig. 5.8 Interactions entre le gestionnaire de cache et l évaluateur de requêtes Les interactions entre le gestionnaire de cache et l évaluateur de requ^etes sont illustrées par le diagramme de séquences de la figure 5.8. Lorsqu une entrée ne correspond pas intégralement à une requête posée, le gestionnaire de cache invoque l évaluateur de requ^etes à l aide de la méthode évaluer (evaluate) pour extraire de l entrée considérée les résultats de la demande de l utilisateur. L instanciation de l évaluateur de requ^etes peut reposer sur des travaux sur l évaluation de requêtes [VC04]. A l instar de l analyse de requêtes, l évaluation peut être assez coûteuse. C est pourquoi, même si toutes les opérations sont prises en compte dans l évaluateur de requ^etes, il est possible de limiter les traitements exécutés au sein d un cache, en intégrant ces choix dans le gestionnaire de cache. Ce dernier peut par exemple ne prendre en compte que les équivalences et les inclusions d une requête dans une entrée du cache. Exemple Soit creqextra, un cache de requêtes pour le système de surveillance réseau EXTRA. Supposons que les accès par les utilisateurs correspondent à des raffinements de requêtes de sélection. Dans ce cas, un gestionnaire de cache peut utiliser un évaluateur de requ^etes permettant de sélectionner un ensemble d objets en fonction d un prédicat donné Préchargement d éléments en cache Nos travaux ne se sont pas focalisés sur les techniques de préchargement. Ainsi la bibliothèque du canevas ne fournit pas de composants permettant la mise en œuvre de ces techniques. Néanmoins, nous envisageons de proposer un composant dédié, appelé gestionnaire de préchargement (PrefetchManager), qui serait en charge de la stratégie de préchargement utilisée pour anticiper les demandes. Les instances d un tel composant permettrait de capturer la politique de choix des éléments à précharger et également de déterminer le moment du préchargement Politique d admission d une entrée en cache Le gestionnaire d admission capture la politique d admission utilisée par un cache. Après une résolution de défaut, ce composant est utilisé pour décider si une entrée doit être ajoutée en cache ou non. 63

76 Chapitre 5 : ACS, un canevas de caches adaptables Fig. 5.9 Interactions entre les gestionnaires de cache et d admission La figure 5.9 présente les interactions entre le gestionnaire de cache et le gestionnaire d admission. Lorsqu un défaut est résolu, le gestionnaire de cache fait appel au gestionnaire d admission à l aide de la méthode peut^etreplacéencache (iscacheable) pour savoir si l entrée correspondante peut être stockée ou non en fonction de la politique d admission considérée. En cas de réponse positive, l élément est ajouté en cache à l aide de la méthode ajouter du gestionnaire de contenu et pourra être utilisé pour d autres demandes. Si l admission est interdite, le document est fourni à l application sans être stocké. Par conséquent, s il est de nouveau demandé, il sera une nouvelle fois nécessaire d exécuter une résolution de défaut. Exemple Supposons un utilisateur intéressé par la source de données TrEMBL. La taille de la source de données étant très importante, il est possible d utiliser une politique d admission pour le cache disque cdisque, limitant la taille des entrées du cache, afin d éviter le stockage des entrées dont la taille est supérieure à 1Go. Il est à noter qu ACS propose un composant particulier pouvant coopérer avec la politique d admission, le gestionnaire de liste noire. La liste noire correspond dans ce cas à des éléments qu il est interdit de stocker, par exemple parce que leur ajout en cache présente un gain très faible. Ce composant offre toutes les méthodes nécessaires à la maintenance de cette liste (recherche, ajout, suppression). Il est à noter que la politique peut être étendue, pour considérer en plus des éléments dont la présence en cache est interdite, ceux qu il est déconseillé d ajouter en cache, mais qui peuvent néanmoins être gardés, notamment si des ressources de stockage sont disponibles Mise en cache négative La mise en cache négative permet de gérer une liste d éléments inaccessibles à un moment donné. L utilité de cette fonctionnalité est d éviter de saturer les liens de communication en envoyant des messages vers des serveurs qui ne répondent pas ou qui ne peuvent être interrogés. ACS visant à faciliter le déploiement de caches, cette solution permet aisément de fournir un cache simple stockant les identifiants des éléments non accessibles. Chacun d eux doit être associé à un minuteur, afin d éviter qu un élément n ayant pu être accédé à un instant donné ne puisse plus l être à jamais. Ainsi une fois le délai écoulé, l identifiant 64

77 5.2 Architecture d ACS de l élément est supprimé du cache négatif. Il est à noter que pour un cache négatif, aucun gestionnaire de résolution n est utilisé, puisqu un ajout en cache ne se fait pas à la suite d une demande, mais à la suite d un échec de résolution. (a) Ajout d une entrée (b) Consultation Fig Interactions entre le gestionnaire de cache et le cache négatif Les interactions entre le gestionnaire de cache et le cache négatif sont illustrées par les figures 5.10(a) et 5.10(b). Avant une résolution de défaut, le gestionnaire de cache vérifie, avec la méthode chercher (lookup), que l identifiant correspondant n est pas déjà présent en cache négatif. En cas de réponse nulle (identifiant absent du cache négatif, donc a priori accessible), la résolution est initiée. Dans le cas contraire, l application est notifiée que l élément est temporairement inaccessible. Si la résolution initiée échoue (message d erreur, échéance d un minuteur, etc.), l identifiant de l élément correspondant est ajouté dans le cache négatif. Exemple Dans le cas d une interrogation de sources de données bio-informatiques, il est intéressant pour les caches cobjgri et creqgri d utiliser un cache négatif. En effet, dans un environnement largement distribué, il est fréquent que les sources soient temporairement indisponibles, suite à une déconnexion réseau ou encore à des opérations de maintenance Allocation des ressources L allocation a pour objectif d assurer la répartition des ressources allouées au cache. Elle permet par exemple de réserver un espace physique spécifique pour stocker des données préchargées, afin de ne pas perturber les éléments gardés en cache à la suite de demandes de clients. L allocation des ressources du cache n est pas directement capturée au sein d ACS. Néanmoins, il est possible de la prendre en compte en tirant profit de la facilité de création de caches avec le canevas. Pour ce faire, un nombre de gestionnaires 65

78 Chapitre 5 : ACS, un canevas de caches adaptables de contenu (chacun utilisant son propre gestionnaire de remplacement) équivalent au nombre de groupes partageant les ressources doit être créé. Ainsi chaque communauté utilisera son propre cache. Le gestionnaire de cache sera alors responsable de répartir les accès sur les différentes structures de données. A noter que le gestionnaire de résolution peut être partagé entre les différents caches (il en va de même pour les fonctionnalités optionnelles, comme par exemple la politique d admission). Exemple Soit creqgri, un cache de requêtes pour le système d interrogation de données bio-informatiques. Dans ce cas, il est possible d utiliser un gestionnaire de préchargement basé sur les requêtes les plus populaires et des demandes périodiques toutes les heures. Afin de gérer finement les ressources allouées au préchargement, il est possible de créer deux gestionnaires de contenu distincts. Dans ce cas de figure, il convient de noter qu un élément préchargé, une fois accédé, est transféré dans l espace de stockage réservé aux éléments référencés Interactions avec d autres fonctionnalités ACS capture les fonctionnalités devant être gérées par un service de cache. Le chapitre 2 a cependant souligné qu un cache pouvait être amené à coopérer avec d autres fonctionnalités qui ne sont pas propres au cache, fournies par d autres services, en particulier le contrôle de concurrence et la gestion de la synchronisation. Le contrôle de concurrence doit permettre de gérer les situations d accès conflictuelles à la fois au sein du cache, mais également entre des éléments du cache et des éléments présents sur les serveurs de données. La gestion de la synchronisation assure, quant à elle, un degré souhaité de cohérence. Il existe dans la littérature des services traitant ces problématiques. Ainsi, Perseus propose un canevas de gestionnaire de concurrence, alors que RS2.7 propose un canevas de gestion de duplication. Néanmoins, nos recherches ne se sont pas focalisées sur la coopération entre ces services. Ce travail fait partie de nos perspectives. 5.3 ACS et caches sémantiques Cette section présente l utilisation d ACS pour la construction de caches sémantiques. Nous avons vu précédemment que la gestion de la sémantique était capturée dans l analyseur de requ^etes et l évaluateur de requ^etes, et que ces composants étaient contactés par un gestionnaire de cache considérant les recouvrements sémantiques. Dans cette section, nous nous intéressons aux caches sémantiques en terme de gestion du contenu du cache, avant d évoquer les autres techniques considérées dans les caches sémantiques. ACS autorise la création de caches sémantiques manipulant les résultats des requêtes à différentes granularités. Deux types de cache peuvent ainsi être proposés à l aide des composants fournis par la bibliothèque du canevas : les caches de résultats de requêtes et les caches de prédicats et d objets Résultats de requêtes La création de caches sémantiques manipulant des résultats de requêtes est relativement simple à l aide d ACS. En effet, la gestion de résultats de requêtes au sein du cache peut se 66

79 5.4 ACS et caches coopératifs faire à l aide de composants génériques proposés, notamment pour les gestions du contenu et de la résolution qui sont similaires à celles d un cache classique. Néanmoins, il est possible de considérer des politiques de remplacement adaptées. En particulier, la valeur de remplacement d une entrée peut dépendre de son utilité. C est pourquoi un gestionnaire de remplacement spécifique peut être employé, calculant par exemple l utilité d une entrée en fonction de son pourcentage d utilisation Prédicats et objets Contrairement aux résultats de requêtes, la manipulation de prédicats et d objets par des caches d ACS repose sur des composants spécifiques. Ces derniers prennent en compte les deux niveaux pour l accès aux résultats des requêtes : le niveau des prédicats, associant une requête à la liste des identifiants d objets correspondants, et le niveau des objets, permettant l accès aux objets via leur identifiant. Il convient néanmoins de noter que les composants spécifiques ne sont utilisés que pour la gestion du contenu et la politique de remplacement, les autres fonctionnalités pouvant être traitées à l aide des composants génériques. Le gestionnaire de contenu offre un accès aux éléments du cache en terme de prédicat, alors que le stockage au sein du cache se fait à la granularité des objets. Par exemple, la méthode chercher prend en entrée une requête, qui est associée à une liste d identifiants. Cette liste est ensuite parcourue pour récupérer les objets. De la même façon, le remplacement se fait en terme d objets, alors que le choix des victimes est influencé par les prédicats. Par exemple, le prédicat le moins récemment référencé est choisi par une politique de type LRU. Les objets correspondants sont ensuite supprimés, s ils ne sont pas associés à d autres requêtes stockées en cache. 5.4 ACS et caches coopératifs ACS offre la possibilité de créer des caches coopératifs. L objectif de cette section est d expliquer la mise en œuvre des différentes coopérations à l aide du canevas. La première partie se focalise sur la résolution verticale, alors que la deuxième s intéresse à la résolution horizontale. Les caches répartis sont introduits ensuite. Puis, les cas des compositions de coopérations et des coopérations entre caches hétérogènes sont discutés Résolution verticale La construction de caches hiérarchiques à l aide d ACS se concentre autour de la configuration du gestionnaire de résolution. Lorsqu un défaut se produit sur un cache utilisant une résolution verticale, l objet demandé est récupéré à l aide d un cache parent. Ce protocole de résolution est capturé dans ACS au sein du gestionnaire de résolution verticale ou ParentResolutionManager. La figure 5.11 illustre les interactions entre un cache fils et un cache parent au moment d une résolution. La demande de résolution de défaut par le cache fils se traduit par un appel à la méthode charger sur le gestionnaire de résolution associé. Celui-ci étant un gestionnaire de résolution verticale, l objet est demandé au cache parent. 67

80 Chapitre 5 : ACS, un canevas de caches adaptables Fig Interactions lors d une résolution verticale Le cache parent étant dans l obligation de retourner l objet demandé, la méthode du gestionnaire de cache utilisée est charger. Le cache parent fournit l objet demandé, en exécutant si besoin une demande de résolution à l aide de son propre gestionnaire de résolution. Il est à noter qu un cache parent utilise son gestionnaire de résolution, pouvant être simple ou également coopératif. Ainsi, il est possible de fournir des hiérarchies à plusieurs niveaux de caches, les caches des différents niveaux utilisant un gestionnaire de résolution verticale, à l exception du niveau le plus élevé pour lequel les caches ont recours à une résolution auprès des serveurs. ACS offre également la possibilité de déployer des caches hiérarchiques pour lesquels un cache peut avoir plusieurs parents. Dans ce cas, un gestionnaire de résolution verticale spécifique prenant notamment en compte le problème de localisation des parents à contacter. Ensuite d une manière similaire à un processus d inondation, la demande est envoyée aux parents, la première réponse positive étant prise en compte et les autres ignorées Résolution horizontale Comme pour les caches hiérarchiques, la coopération entre caches frères est prise en compte au niveau du gestionnaire de résolution. Lorsqu un défaut se produit, les caches frères sont contactés pour récupérer le document correspondant. Si ce dernier ne peut être obtenu ainsi, il est chargé depuis le serveur. Le gestionnaire de résolution horizontale proposé par ACS doit donc, en plus de gérer la coopération avec les frères, intégrer un autre gestionnaire de résolution permettant de récupérer les éléments en cas d échec sur les frères. L utilisation de deux gestionnaires de résolution permet de séparer les préoccupations, en traitant distinctement les interactions avec les caches frères et les interactions avec les sources de données. La localisation des caches dans ACS est à la charge du gestionnaire de topologie (TopologyManager). La topologie représente les caches frères (et éventuellement les pères) d un cache donné. Le gestionnaire de topologie fournit la liste des informations utiles sur les caches frères (et pères) à contacter à l aide de la méthode récupérerfrères (getsiblings) (et de la méthode récupérerparents ou getparents). La topologie peut être modifiée afin de prendre en compte l ajout ou la suppression de caches. ACS propose deux gestionnaires de résolution horizontale correspondants aux approches présentées dans le chapitre 3 : la résolution basée sur inondation et la résolution à l aide d un catalogue. 68

81 5.4 ACS et caches coopératifs Inondation Dans une approche par inondation, une demande est transférée à tous les caches frères. En cas de réponses positives multiples, la première arrivée est considérée, les autres étant ensuite ignorées. Ce protocole est capturé dans ACS par le gestionnaire de résolution par inondation (FloodingResolutionManager). Pour prendre en compte l inondation, ce composant doit permettre la localisation des caches frères. Fig Interactions lors d une résolution horizontale par inondation La figure 5.12 présente les interactions lors d une résolution horizontale par inondation. Au moment d une résolution, le gestionnaire de résolution par inondation transfert la demande à tous les caches frères, à l aide de la méthode chercher de leur gestionnaire de cache (évitant ainsi une résolution en cas de défaut). En cas d échec, l élément est récupéré auprès des serveurs à l aide de la méthode charger du gestionnaire de résolution Catalogue Dans une approche basée sur un catalogue, celui-ci est consulté lors d une résolution. Ce protocole est capturé dans ACS par le gestionnaire de résolution par catalogue CatalogueResolutionManager. Il est à noter que ce composant doit également gérer le cas où l élément désiré est dupliqué sur plusieurs frères. Plusieurs façons de faire peuvent alors être proposées, par exemple contacter tous les frères concernés et gérer les réponses multiples comme dans une approche par inondation, ou encore les contacter de manière séquentielle jusqu à l obtention de l objet demandé. Fig Interactions lors d une résolution horizontale à l aide d un catalogue La figure 5.13 illustre les interactions au moment d une résolution basée sur un catalogue. Lorsqu une résolution est initiée, le gestionnaire de résolution par catalogue consulte le catalogue à l aide de la méthode chercher (lookup) pour savoir si l élément 69

82 Chapitre 5 : ACS, un canevas de caches adaptables souhaité est stocké par un ou plusieurs caches frères. Dans ce cas, le catalogue fournit les informations permettant de contacter les caches frères en question. Pour simplifier le diagramme, nous ne considérons qu un seul cache contenant l élément désiré. Ce dernier est alors contacté à l aide de la méthode chercher de son gestionnaire de cache. Il est à noter que ces interactions sont valables quel que soit le catalogue choisi (partagé ou local). La différence entre les divers catalogues ayant seulement un impact sur les évènements liés aux changements (ajouts, suppressions, modifications) du contenu des caches Caches répartis Contrairement aux coopérations présentées précédemment, la gestion des caches répartis dans ACS ne concerne pas le gestionnaire de résolution. En fait, pour prendre en compte ce type de caches coopératifs, nous avons introduit le gestionnaire de distribution (DistributionManager). Ce dernier capture la politique de répartition des demandes (aléatoire, tourniquet, etc.) sur les caches considérés, chacun d eux utilisant ses propres stratégies (remplacement, recherche, etc.). Dans le but d offrir la transparence à l application ou à l utilisateur, un gestionnaire de cache particulier est utilisé, servant uniquement de relai avec le gestionnaire de distribution. Fig Interactions lors d une demande sur des caches répartis Les interactions pour des caches répartis sont illustrées par le diagramme de séquences de la figure Lorsqu un client soumet une demande au gestionnaire de cache, celleci est transférée au gestionnaire de distribution à l aide de la méthode charger (load). Le gestionnaire de distribution applique alors la politique de distribution sur la demande, permettant de choisir un cache, qui est contacté à l aide de la méthode charger de son gestionnaire de cache. Un processus classique de traitement en cache est alors exécuté. Tout comme pour une résolution horizontale, un gestionnaire de topologie est utilisé pour gérer la liste des caches coopérants. Un cache peut apparaître et disparaître à tout moment. La politique de répartition utilisée par le gestionnaire de distribution doit donc prendre en compte cet environnement dynamique. Bien sûr, le problème ne se pose pas pour certaines politiques, comme par exemple pour une distribution aléatoire. Par contre, dans le cas d une distribution en fonction des demandes, notamment lorsqu un élément est associé à un cache à l aide d une fonction de hachage, il est important de s adapter à l évolution des caches présents. Dans ce cas, l utilisation d une politique de type hachage cohérent (consistent hashing) [KLL + 97] permet de prendre en considération la variabilité de l environnement. 70

83 5.5 Adaptation contextuelle de cache Composition des coopérations et coopérations entre caches hétérogènes ACS offre la possibilité de combiner les coopérations présentées précédemment. Il est ainsi possible de créer des caches répartis avec résolutions horizontale et verticale. Dans ce cas, le processus de traitement consiste à utiliser un gestionnaire de distribution et un gestionnaire de résolution horizontale s appuyant sur un gestionnaire de résolution verticale. La composition peut se limiter à deux types de coopération, par exemple les résolutions horizontales et verticales, qui sont souvent utilisées conjointement, notamment pour des caches Internet. Bien que nous ne nous soyons pas focalisés sur cet aspect, les coopérations entre caches hétérogènes peuvent être mises en œuvre à l aide d ACS. Ces types de coopération sont alors capturés dans des gestionnaires de résolution particuliers. Ainsi, si un cache souhaite utiliser des éléments d un autre cache, alors le gestionnaire de résolution du premier peut les récupérer à l aide de la méthode load du gestionnaire de cache du second, puis leur appliquer un processus permettant d obtenir le bon type d objet pour le cache considéré. 5.5 Adaptation contextuelle de cache L adaptation contextuelle vise à offrir les meilleures performances possibles en proposant la configuration la plus adéquate, statiquement au moment du déploiement, mais aussi dynamiquement afin que l efficacité d un cache ne soit pas affectée par les évolutions de l environnement applicatif. La représentation de l environnement contextuel pertinent pour un cache peut prendre en compte de nombreux paramètres liés à l application, comme les séquences d accès, ou l environnement physique, par exemple la disponibilité des serveurs ou les ressources pouvant être allouées aux caches. Il est à noter que dans les environnements à grande échelle, il semble très difficile de demander aux administrateurs d intervenir sur tous les caches présents dans le système. C est pourquoi, il est important de fournir des outils permettant à un cache de s adapter à son environnement sans aucune intervention humaine. L objectif de cette section est de présenter les mécanismes pour assurer l adaptation dynamique et automatique des caches construits à l aide du canevas ACS. L architecture globale de notre proposition de cache auto-adaptable en fonction du contexte applicatif est illustrée par la figure L auto-adaptabilité des caches se base sur l expertise de notre équipe de recherche dans la gestion du contexte et les règles actives Gestion de contexte L adaptation contextuelle est un sujet de recherche en plein essor, comme en témoigne notamment les travaux menés en informatique mobile et ubiquitaire [CDS04] ou encore en interaction homme-machine [CCD + 06]. Dans ce document, nous nous intéressons à un canevas de gestion de contexte [BJ05] proposé au sein de notre équipe de recherche. L utilisation d un canevas est particulièrement intéressante, puisqu elle autorise une instanciation fine par rapport à l environnement étudié pour les caches déployés. Si le gestionnaire de contexte est lui-même adaptable et évolutif, il est alors possible de 71

84 Chapitre 5 : ACS, un canevas de caches adaptables Fig Architecture du cache contextuel changer ses caractéristiques, en particulier considérer des situations qui ne l étaient pas jusqu à présent. L objectif ici n est pas de présenter en détail l architecture du canevas de gestion de contexte, mais plutôt d en donner un aperçu et discuter des possibilités d intégration dans un cache adaptable à son contexte d exécution Modélisation du contexte La modélisation du contexte autorise une représentation plus ou moins complexe de l environnement d exécution. Elle vise à limiter l environnement réel à un ensemble de paramètres pertinents à considérer. Le modèle est alors constitué d un ensemble de concepts nécessaires et suffisants du contexte applicatif. Ces concepts peuvent alors être utilisés pour comparer l état de l environnement à une situation pertinente. Fig Concept source de données Exemple La figure 5.16 donne un exemple de concept concernant l état d une source de données. Le concept Source est ici composé de trois sous-concepts : le sous-concept Adresse, une chaîne de caractères, qui représente une adresse IP; le sous-concept Port, un entier correspondant au port utilisé; le sous-concept État appartenant à l ensemble de valeur {disponible, indisponible} caractérisant la disponibilité de la source. Exemple La figure 5.17 donne un exemple de concept, concernant les caractéristiques de l interrogation d un cache. Le concept interrogation cache est ici composé de deux sous-concepts : le sous-concept charge, un entier, qui représente le nombre de requêtes posées par seconde ; le sous-concept localité sémantique, un entier, représentant un pourcentage pour caractériser une corrélation sémantique entre les requêtes posées. 72

85 5.5 Adaptation contextuelle de cache Fig Concept interrogation de cache Capture du contexte La capture du contexte permet de modéliser l état de l environnement considéré à un instant donné. Afin de parvenir à cette modélisation, le gestionnaire de contexte doit intégrer un processus permettant de capturer, agréger et interpréter des mesures, tout en vérifiant la cohérence des données. Les prises de mesures reposent sur un ensemble de capteurs matériels et/ou logiciels. Les capteurs sont utilisés pour évaluer l état actuel du contexte considéré. Les données des capteurs de l environnement sont ensuite transférées au gestionnaire de contexte, afin qu elles soient modélisées. Exemple Pour vérifier la disponibilité d une source, le gestionnaire de contexte peut envoyer périodiquement des requêtes de type ping. L absence de réponse (la configuration du nombre d absence étant à définir en fonction de l environnement) fait passer le sous-concept État du concept Source de la valeur disponible à la valeur indisponible, alors qu une réponse transforme une source indisponible en une source disponible. Exemple Lorsqu une demande d un client échoue, suite à l arrivée à échéance d un minuteur, il est possible d affecter la valeur indisponible au sous-concept etat du concept source. Exemple La valeur du sous-concept localité sémantique du concept interrogation cache peut être mise à jour en utilisant le composant analyseur de requ^etes. Ce dernier peut en effet réévaluer le pourcentage de requêtes liées sémantiquement à chaque comparaison de requêtes. L agrégation des mesures consiste à regrouper un ensemble d informations contextuelles afin d en créer de nouvelles. L agrégation se déroule en plusieurs étapes. La première consiste à recevoir les informations contextuelles (qui peuvent parfois être stockées). La réception des informations correspond à une gestion de transactions, afin d obtenir toutes les informations nécessaires, à moins d avoir une fonction précisant l utilisation de valeurs précédentes. Lorsque toutes les informations sont obtenues, elles sont traitées pour créer une nouvelle information contextuelle. Exemple Dans le cas du système d interrogation de sources de données, l agrégation du concept capacité de service et du concept nombre de requ^etes par seconde correspond au concept charge. A la différence de l agrégation, l interprétation des mesures ne prend en compte qu un seul concept. Lorsque des données sont reçues, elles sont interprétées afin de fournir une nouvelle information contextuelle. 73

86 Chapitre 5 : ACS, un canevas de caches adaptables Exemple Dans le cas du système d interrogation de source de données, une charge dont la valeur est supérieure à 1 peut être interprétée comme une surcharge sur le serveur. La modélisation du contexte se décompose en plusieurs étapes. En particulier, la propagation de l état contexte à tous les concepts n est pas instantanée, les concepts pouvant à un instant donné ne pas représenter la même situation. La vérification de la cohérence des mesures permet d attendre que tous les concepts concernés soient synchronisés avant de considérer le contexte mesuré. Après obtention d un contexte cohérent, il est possible de le comparer avec les situations considérées. La vérification de la cohérence des mesures se fait de la manière suivante. Lorsqu une demande de vérification de cohérence est traitée, les capteurs sont bloqués (verrouillage) pour qu aucune nouvelle mesure ne soit considérée. En effet, seules les valeurs mesurées au moment de la demande représentent le contexte à cet instant. Ensuite, une boucle de vérification est initiée, jusqu à obtenir une stabilité des concepts. Finalement, l information est remontée au demandeur. Bien sûr, la cohérence peut être relâchée en fonction de l environnement ciblé, notamment si l évaluation du contexte prend du temps Gestion des situations pertinentes La gestion des situations pertinentes permet de représenter les états du contexte attendus. Les informations à ce niveau sont donc les mêmes que celles gérées par le niveau de prises de mesures. Cependant, alors que les prises de mesures modélisent l environnement à un instant donné et par conséquent varient au cours du temps, les «situations pertinentes»modélisent des états attendus de l environnement et contiennent des contraintes pour un état du contexte considéré. Ces contraintes peuvent être représentées sous forme d un ensemble de valeurs ou encore d intervalles. Exemple La situation pertinente correspondant à la valeur chargée pour le concept source et disponible pour le concept cache parent permet de caractériser un état du contexte où il est intéressant d adapter un cache afin d utiliser une résolution verticale. Exemple La situation pertinente correspondant à un nombre de caches frères présents dans le système appartenant à l intervalle [2,25] permet de caractériser un état du contexte où il est intéressant d adapter un cache afin d utiliser une résolution horizontale par inondation. Pour un nombre supérieure à 25, il est préférable d avoir recours à un catalogue Adaptation à base de règles actives Une fois l environnement d exécution capturé, il est alors nécessaire de réagir en fonction du contexte, en associant un ensemble d actions en fonction des situations de l environnement. L objectif, ici, est d adapter dynamiquement la configuration du cache par rapport à son l environnement. La réactivité, c est-à-dire l habilité d exécuter certaines opérations en réponse à des situations particulières sans intervention extérieure, est une caractéristique clé pour obtenir un cache auto-adaptable. Notre approche se base sur l expertise des travaux réalisées au sein de notre équipe dans le domaine de l informatique autonomique [CNCR07] et notamment des mécanismes actifs utilisés dans les systèmes de gestion de bases de données actifs [CHR96]. Ces derniers étendent les systèmes de gestion 74

87 5.5 Adaptation contextuelle de cache de bases de données en considérant des mécanismes pour surveiller la gestion des données et exécuter dynamiquement des actions prédéfinies en réponse à la détection de certains évènements. La sémantique informelle d une règle ECA (Évènement Condition Action) est : «Quand un évènement de type E se produit, si la condition C est satisfaite, alors exécuter l action A». Un aspect actif peut être décrit comme un modèle de règles et un modèle d exécution. Le modèle de règle spécifie les définitions des règles. Le modèle d exécution spécifie la manière dont les règles doivent être exécutées. Les règles actives sont considérées par le gestionnaire d adaptation, dont la responsabilité est d assurer la reconfiguration dynamique du cache, en fonction des modifications du contexte applicatif Modèle de règles Le modèle de règles spécifie la forme des règles. Il décrit les évènements, les conditions et les actions composant les règles. La figure 5.18 donne un exemple d une règle active associée à un capteur vérifiant la disponibilité d une source. L objectif de la règle est d adapter un cache à une défaillance de la source utilisée pour la résolution des défauts. règle règlesource encasde défaillance s1 faire si s2 disponible alors ResolutionManager.serveur.adresse s2.adresse ResolutionManager.serveur.port s2.port finsi finencasde Fig Exemple de règle active Les évènements considérés par le gestionnaire d adaptation sont ceux produits par le gestionnaire de contexte, à la suite de modifications de l environnement (les modifications étant elles-mêmes caractérisées à l aide d évènements). Un évènement correspond à un fait particulier à un instant donné. Il est caractérisé par un type et un ensemble de paramètres. Un type d un évènement est une expression décrivant une classe d occurrences d intérêts significatifs ; il peut être primitif ou composite. Les évènements de type primitif sont associés à des opérations élémentaires. Par exemple, un appel de méthode sur une interface, ou le dépassement d un seuil sur une jauge de consommation de la mémoire. Les évènements composites sont définis comme des combinaisons d autres évènements primitifs ou composites, en utilisant des opérations sur les évènements, par exemple des opérateurs logiques comme la conjonction, la disjonction ou encore la négation. Exemple Sur l exemple considéré dans la figure 5.18, l évènement primitif correspond à défaillance s1, notifiant l indisponibilité de la source de données s1. Cet évènement est un évènement applicatif produit par le gestionnaire de contexte lorsque le sous-concept état du concept source prend la valeur indisponible pour s1 (ce changement de valeur pouvant provenir d un évènement matériel). Les conditions sont optionnelles et expriment des contraintes supplémentaires sur l état du système qui doivent être satisfaites pour que la partie action soit exécutée. Les expressions simples de condition sont construites à l aide d opérateurs logiques, donnant naissance 75

88 Chapitre 5 : ACS, un canevas de caches adaptables à une valeur booléenne (par exemple, pour vérifier si la valeur d un attribut est plus grande qu une valeur donnée ou non). D autres expressions de conditions plus complexes peuvent être construites à l aide de requêtes sur la structure, ou encore sur des caractéristiques de système. Exemple Sur l exemple considéré dans la figure 5.18, la condition s2 disponible consiste à vérifier que la source s2 permet toujours d évaluer des requêtes. Les transformations pouvant être appliquées à un cache sont exprimées dans la partie action de la règle. Les opérations de l action peuvent varier d une simple paramétrisation des attributs d un composant, par exemple en augmentant la taille d un cache, à des reconfigurations structurelles plus complexes, pouvant inclure l addition, la suppression, le remplacement d un ou plusieurs composants. Les différentes opérations des actions peuvent être exprimées dans des scripts ADL (Architecture Description Languages) dynamiques. Exemple Sur l exemple considéré dans la figure 5.18, l action correspond aux instructions de paramétrisation permettant de modifier les valeurs de l adresse et du numéro de port utilisées dans le gestionnaire de résolution afin de contacter la source s2 lors de résolutions de défauts pour le cache considéré. règle règlesémantique couplage différé encasde cachesémantique faire cache.unbind(basiccachemanager) cache.bind(semanticcachemanager) cache.bind(queryanalyser) cache.bind(queryevaluator) finencasde Fig Exemple de règle active avec changement dynamique de composants Exemple Supposons que la défaillance de la source de données s1 entraîne une surcharge sur le serveur gérant la source s2. De plus considérons une forte localité sémantique pour les requêtes. Dans ce cas, le gestionnaire de contexte peut demander au cache de prendre en compte la gestion de la sémantique. Il est alors pertinent de remplacer le gestionnaire de cache classique par un gestionnaire de cache considérant la gestion de la sémantique, et d ajouter un analyseur de requ^etes et un évaluateur de requ^etes. Cette adaptation contextuelle est représentée par la règle active de la figure Modèle d exécution La sémantique des règles d exécution décrit la manière dont un système actif se comporte une fois un ensemble de règles défini. Elle est spécifiée dans le modèle de règle d exécution et se caractérise par plusieurs dimensions. Il y a trois phases concernées par l évaluation d une règle. Premièrement, la phase de déclenchement se réfère à la détection et à la notification de l occurrence d un type d évènement. Ensuite, la phase d évaluation où les expressions de condition de la règle déclenchée sont évaluées, et enfin, la phase d exécution où les actions correspondantes sont exécutées. 76

89 5.5 Adaptation contextuelle de cache Exemple Dans l exemple considéré dans la figure 5.18, la phase de déclenchement correspond à l instruction on défaillance s1, la phase d évaluation à disponible et la phase d exécution aux instructions ResolutionManager.s.adresse s2.adresse et ResolutionManager.s.port s2.port. La phase d évaluation n a pas besoin de suivre immédiatement la phase de déclenchement. De la même manière, si des conditions sont évaluées comme vraies, la phase d exécution n est pas nécessairement exécutée tout de suite après la phase d évaluation. Les relations entre les différentes phases sont spécifiées dans les modes de couplage. Le mode de couplage évènement-condition détermine quand la condition doit être évaluée en fonction de l évènement qui déclenche la règle. Le mode de couplage condition-action indique quand une action doit être exécutée en fonction de l évaluation de la condition, par exemple immédiatement (mode de couplage par défaut) ou de manière différée. Exemple La règle active de la figure 5.18 est un exemple de règle sur le changement de source de données en cas de défaillance avec un mode de couplage immédiat (couplage par défaut), permettant une réaction rapide à une panne de la source s1. Exemple La règle active de la figure 5.19 est un exemple de règle sur la transformation d un cache simple en un cache sémantique, avec un mode de couplage différé. Le couplage différé est utilisé pour assurer une continuité de service pour les utilisateurs. Ainsi, en cas de traitement d une demande d un client par le cache au moment de la décision d adaptation, l adaptation n est effectivement réalisée qu une fois la demande traitée, c està-dire une fois la réponse envoyée au client. Si au même moment, d autres demandes sont posées aux caches, alors elles sont mises en attente et ne seront prises en compte qu une fois l adaptation réalisée. Quelques dimensions concernent la façon dont les évènements sont traités et consommés par une règle au moment de son exécution. Une règle peut traiter un seul évènement à un instant donné ou un ensemble d évènements. Ceci est spécifié dans le mode de traitement de l évènement, avec une sémantique orientée instance pour le premier et une sémantique orientée ensemble pour le second. Le mode de consommation d évènement détermine la façon dont l évènement déclenché est géré. Il peut être consommé et ignoré dans la suite de l exécution de la règle ou au contraire être préservé et considéré pour une autre exécution. Quand des règles multiples sont déclenchées au même moment, le plan d exécution local détermine leur stratégie de traitement. Une option simple consiste à choisir une des règles déclenchées et d ignorer les autres. D autres stratégies plus communes sont : (1) une exécution séquentielle des règles déclenchées sur des priorités prédéterminées ou fixées dynamiquement; ou (2) une exécution séquentielle des règles de manière aléatoire, (3) une exécution parallèle des règles déclenchées, (4) une stratégie hybride combinant les exécutions parallèles et séquentielles. Par exemple, dans un traitement séquentiel quand plusieurs règles sont associées à la même valeur de priorité, elles peuvent être exécutées en parallèle. A noter qu une règle peut engendrer des évènements déclenchant d autres règles, on parle alors de cascade de règles. Dans le cas d un cache, il est possible à un moment donné que la règle pour passer d un cache non coopératif à un cache coopératif et celle pour passer d un cache simple à un cache sémantique soient déclenchées au même moment, notamment en cas de surcharge des sources de données. Une approche possible ici consiste à utiliser une exécution séquentielle des règles de manière aléatoire, l ordre des modifications n étant pas crucial. 77

90 Chapitre 5 : ACS, un canevas de caches adaptables 5.6 Conclusion Ce chapitre a présenté ACS, un canevas pour la construction de caches adaptables, et son utilisation pour créer des caches sémantiques et coopératifs. L architecture globale du canevas repose sur le principe de la séparation des préoccupations afin de favoriser l adaptabilité statique et dynamique d une solution de cache. Pour une plus grande flexibilité, le principe est appliqué à différents niveaux. Le premier distingue les fonctionnalités de base des fonctionnalités optionnelles et pouvant être gérées par des services extérieurs. Le deuxième niveau sépare chaque fonctionnalité dans les différentes catégories (par exemple, gestion du contenu, du remplacement, et de la résolution pour la catégorie fonctionnalité de base). L adaptation de la solution se fait alors par une paramétrisation, un ajout, une suppression ou un remplacement de chaque composant correspondant. ACS est particulièrement pertinent pour la gestion de la sémantique au sein d un cache. A notre connaissance, il est le seul service de caches adaptables intégrant les techniques de cache sémantique. L architecture permet en effet de prendre en considération la complexité de certaines requêtes, les ressources allouées au cache sémantique, la charge sur le serveur, les liens de communications et bien sûr l objectif du cache considéré. Toute cette connaissance doit être prise en compte pour choisir le niveau approprié de fonctionnalité pour la gestion de la sémantique. Ainsi, si le but final est d économiser les ressources sur le serveur, alors un analyseur de requ^etes et un évaluateur de requ^etes sophistiqués doivent être utilisés. Le canevas permet également la mise en place de différents types de coopération. Ainsi, il est possible d implanter des caches répartis, utilisant des résolutions verticale ou horizontale, des combinaisons entre ces différentes approches, ou encore des coopérations entre caches hétérogènes. Ceci autorise la mise en place de coopérations fines entre caches (éventuellement hétérogènes), particulièrement pertinentes pour les applications à grande échelle. Le chapitre 8 montrera notamment l utilisation d ACS, sur grilles de données, pour la mise en œuvre de caches coopératifs basés sur des topologies physiques et logiques. ACS considère également la gestion de caches dans des environnements variables. Ainsi, les caches développés à l aide d ACS offrent une adaptation contextuelle permettant de fournir à tout moment de bonnes performances. L adaptation contextuelle se base sur l utilisation d une gestionnaire de contexte et de règles actives. Il est ainsi possible de modéliser les situations pertinentes pour les caches, tout en offrant les outils nécessaires pour modifier leur configuration en fonction des variations de leur environnement d exécution. La facilité de création de caches permet de tester différentes configurations pour un système donné. Ainsi l utilisation de ce canevas a donné naissance à de nouvelles techniques de cache sémantique et coopératif. Dans le prochain chapitre, nous présentons le cache dual, une solution de cache sémantique particulièrement intéressante pour le passage à l échelle. 78

91 Chapitre 6 Cache dual Le canevas ACS facilite la création de caches pour différents contextes applicatifs. Il permet en particulier de proposer des caches sémantiques pour les systèmes d interrogation de données. L utilisation du canevas nous a permis de mettre en œuvre différents types de caches sémantiques, mais également de proposer une nouvelle approche. L objectif de ce chapitre est d introduire cette nouvelle approche appelée cache dual. Ce chapitre est organisé de la manière suivante. La section 6.1 donne un aperçu de notre proposition. La section 6.2 présente la spécification du cache dual. La section 6.3 introduit ensuite le concept de cache dual sémantique. Puis, la section 6.4 présente les possibilités offertes par le cache dual en terme d adaptabilité. Enfin, la section 6.5 conclut ce chapitre. 6.1 Aperçu de la proposition Un cache sémantique vise à réduire les transferts de données et la charge d évaluation de requêtes sur les serveurs. Néanmoins, les caches proposés dans la littérature (les caches de résultats de requêtes et les caches de prédicats et objets) ne permettent pas de distinguer clairement ces deux objectifs. De plus, les caches sémantiques existants présentent un inconvénient majeur concernant la mise en cache de grandes masses de données. En effet, dans les environnements à grande échelle, il est parfois impossible de stocker les objets résultats d une requête, même s il est pertinent de garder une trace des évaluations sans les éléments correspondants. Notre objectif est de proposer des caches pour les systèmes d interrogation de données, notamment dans des contextes à grande échelle (environnement largement distribué, manipulation de gros volumes de données, gestion d un nombre important de clients). Notre proposition se base sur trois contributions : Premièrement, le cache dual, qui repose sur la coopération flexible entre un cache de requêtes et un cache d objets. Alors que le premier cache permet de mémoriser des évaluations de requêtes afin de réduire la charge de calculs sur les serveurs, le second, en charge du stockage des objets, a pour objectif de minimiser les transferts de données. Le principe général consiste à contacter le cache de requêtes, pour obtenir des résultats d évaluation. Les éléments correspondants sont ensuite récupérés à l aide du cache d objets. 79

92 Chapitre 6 : Cache dual La deuxième contribution, le cache dual sémantique, cherche à compléter le cache dual en prenant en compte les techniques utilisées dans les caches sémantiques. L approche proposée offre une grande flexibilité, à la fois en terme d analyse et d évaluation de requêtes, mais également en terme de gestion du cache, où des techniques spécifiques peuvent être considérées (remplacement, préchargement ou encore partitionnement et regroupement). Outre la gestion de la sémantique, la flexibilité du cache dual est un atout majeur pour qu il soit finement adapté à l application considérée et qu il contribue à son passage à l échelle. L adaptation peut être prise en compte au niveau de l allocation des ressources aux différents caches, des politiques spécifiques pour chaque cache ou encore des possibilités de répartition en terme de caches d objets. Afin d illustrer notre proposition tout au long de l avancement de ce chapitre, nous reprenons le système d interrogation de sources de données bio-informatiques sur grille présenté dans le chapitre 5. Les sources de données stockent des enregistrements correspondants à des séquences de protéines annotées, qui peuvent être accédés à l aide de requêtes, mais également via leur identifiant. 6.2 Spécification du cache dual Dans cette section, nous présentons notre proposition de cache pour les systèmes d interrogation de données, appelée cache dual, reposant sur la combinaison d un cache de requêtes et d un cache d objets. Fig. 6.1 Exemple de contenu d un cache dual Cache de requêtes Le cache de requêtes s inspire de la notion de vue des systèmes de gestion de bases de données. Il est utilisé pour stocker des évaluations (requêtes pré-calculées), sous la forme de couples (q,objidlist), afin de minimiser la charge d évaluation sur les serveurs. L identifiant q, associé à une requête (q peut par exemple être la requête elle-même sous forme d une chaîne de caractères), permet d accéder à objidlist la liste des identifiants 80

93 6.2 Spécification du cache dual des objets répondant à cette requête. Comme les caches de vues [Rou91], les objets euxmêmes ne sont pas stockés dans le cache de requêtes. Exemple 6.1. La figure 6.1 présente le contenu d un cache de requêtes pour le système d interrogation de données considéré. Dans ce contexte, les identifiants sont des chaînes de caractères alpha-numériques. La première entrée correspond à l évaluation d une requête permettant de sélectionner les objets dont l attribut année a pour valeur Le prédicat utilisé pour identifier l entrée dans le cache est année = Pour cette évaluation, les objets identifiés par P15711 et Q43495 sont les seules réponses. Exemple 6.2. Sur le même exemple de contenu, il est également possible de remarquer que la réponse à la requête année = 2010, permettant de sélectionner les éléments créés ou modifiés en 2010 est vide, autrement dit qu aucun n objet ne répond à ce critère Cache d objets Dans un cache de vues, l accès aux objets se fait directement en accédant aux sources de données. En effet, cette solution a été proposée pour des systèmes centralisés, pour lesquels le coût d accès aux objets était faible par rapport au coût d évaluation. Le cache dual vise à être utilisé dans des applications (largement) réparties, pour lesquelles l accès aux données directement sur les sources est coûteux. C est pourquoi, au sein du cache dual, l accès aux éléments se fait par un cache d objets dont les entrées sont des couples (idobj, obj), où idobj est l identifiant d objet et obj sa valeur. ID 104K_THEPA STANDARD; PRT; 924 AA. AC P15711; DT 01-APR-1990 (Rel. 14, Created) DT 01-APR-1990 (Rel. 14, Last sequence update) DT 10-MAY-2005 (Rel. 47, Last annotation update) DE 104 kda microneme-rhoptry antigen. OS Theileria parva. OC Eukaryota; Alveolata; Apicomplexa; Piroplasmida; Theileriidae; OC Theileria. OX NCBI_TaxID=5875; RN [1] RP NUCLEOTIDE SEQUENCE. RC STRAIN=Muguga; RX MEDLINE= ; PubMed= ; DOI= / (90) ; RA Iams K.P., Young J.R., Nene V., Desai J., Webster P., Ole-Moiyoi O.K., RA Musoke A.J.; RT "Characterisation of the gene encoding a 104-kilodalton microneme- RT rhoptry protein of Theileria parva."; RL Mol. Biochem. Parasitol. 39:47-60(1990). CC -!- SUBCELLULAR LOCATION: In microneme/rhoptry complexes. CC -!- DEVELOPMENTAL STAGE: Sporozoite antigen. DR EMBL; M29954; AAA ; -; Unassigned_DNA. DR PIR; A44945; A DR InterPro; IPR007480; DUF529. DR Pfam; PF04385; FAINT; 4. KW Antigen; Repeat; Sporozoite. FT REGION 1 19 Hydrophobic. FT REGION Hydrophobic. SH SEQUENCE 924 AA; MW; 289B4B554A61870E CRC64; SQ MKFLILLFNILCLFPVLAADNHGVGPQGASGVDPITFDINSNQTGPAFLTAVEMAGVKYLQVQHGSNVNIHRLVEGNVVIWENASTPLYTGA IVTNNDGPYMAYVEVLGDPNLQFFIKSGDAWVTLSEHEYLAKLQEIRQAVHIESVFSLNMAFQLENNKYEVETHAKNGANMVTFIPRNGHICKMVYHKNV Fig. 6.2 Exemple d un enregistrement Swiss-Prot Exemple 6.3. Un exemple de contenu du cache d objets est illustré par la figure 6.1. Dans le contexte applicatif considéré, l identifiant d une entrée correspond à une chaîne de caractères alpha-numériques et sa valeur correspond à une chaîne de caractères structurée et formée d un ensemble d attributs et de valeurs représentant les données et méta-données des séquences de protéines. La figure 6.2 présente un exemple d enregistrement pour la source de données Swiss-Prot. Afin de simplifier la représentation, les enregistrements 81

94 Chapitre 6 : Cache dual stockés dans le cache d objets ne sont pas détaillés, mais simplement représentés sous forme d une chaîne de caractères enr-id Traitement de requêtes par le cache dual Cette section présente le traitement d une requête par le cache dual. Le processus d évaluation se décompose en deux étapes, le traitement par le cache de requêtes, puis celui par le cache d objets. Dans cette section, seule la résolution classique de défaut est considérée. Autrement dit, le cache dual étudié ne prend pas en compte les coopérations entre caches de requêtes et celles entre caches d objets (ces coopérations seront étudiées dans le chapitre 7). Ainsi, en cas de défaut (de requêtes ou d objets), la résolution se fait en contactant directement les serveurs. Afin d illustrer le processus de traitement, nous considérons un cache dual, comme illustré par la figure Traitement d une requête par le cache de requêtes Algorithme 1 Traitement d une requête par un cache de requêtes : ReqCache.charger(req) Entrées : req : requête Sorties : objlist : liste d objets {Recherche de la requête dans le cache} idobjlist ReqCache.GCont.chercher(req) si idobjlist null alors {succès} si idobjlist alors {Récupération des objets sur le cache d objets à l aide de la liste d identifiants} objlist ObjCache.charger(idObjList) sinon objlist finsi sinon {défaut} {Résolution de la requête} (idobjlist,objlist) ReqCache.GRés.charger(req) {Ajout de l évaluation de la requête dans le cache de requêtes} ReqCache.GCont.ajouter(req,idObjList) si objlist alors {Ajout des objets dans le cache d objets} ObjCache.ajouter(objList) finsi finsi retourner objlist Lorsqu une requête est posée sur le cache dual, elle est dans un premier temps transférée au cache de requêtes. L algorithme 1 présente le traitement d une requête req par le cache de requêtes. La première étape consiste à vérifier la présence de la requête dans le cache. La requête peut alors provoquer un succès (idobjlist non nulle) ou un défaut (idobjlist nulle). Le terme succès correspond ici à un succès exact, le cas des succès étendus sera étudié pour le cache dual sémantique dans la section

95 6.2 Spécification du cache dual En cas de succès, une liste d identifiants idobjlist est récupérée. Si cette liste n est pas vide, elle est utilisée pour charger la liste des objets objlist correspondant à l aide du cache d objets. La procédure de traitement de cette liste par le cache d objets est détaillée dans la section Exemple 6.4. Soit le cache illustré par la figure 6.1 et la requête année = 2006 posée. Dans cette situation, un succès se produit et la liste {P15711, Q43495} est soumise au cache d objets pour récupérer les éléments correspondants. En cas de défaut d objet, le processus de résolution récupère les objets réponses à la requête. La résolution classique consiste à contacter les serveurs appropriés. Dans ce cas, l appel ReqCache.GRés.charger(req) correspond simplement à l instruction serveurs.charger(req). Néanmoins, une résolution à l aide de caches frères ou parents peut également être mise en place. Le cas de la résolution horizontale sera étudié dans le chapitre 7, où nous présenterons l algorithme ReqCache.GRés.charger associé. Exemple 6.5. Soit le contenu du cache illustré par la figure 6.1 et la requête année = 2004 posée. Un défaut se produit et la requête année = 2004 est soumise aux serveurs pour être évaluée. Quel que soit le moyen de récupération des objets (cache d objets ou résolution de la requête), le cache de requêtes obtient l ensemble des objets souhaités objlist et le fournit à l utilisateur ou à l application Traitement d une liste d identifiants par le cache d objets Le cache dual peut être finement configuré, le cache d objets et le cache de requêtes utilisant leurs propres stratégies. En particulier, les politiques de remplacement et d admission de chaque cache sont indépendantes. Ainsi, il est possible d avoir une gestion fortement couplée ou au contraire une gestion très lâche. Il est important de noter que dans le cas d une gestion découplée, les sources de données doivent permettre, en plus d accéder aux données à l aide de requêtes, de pouvoir récupérer des objets via une liste d identifiants. Dans les deux cas, les réponses correspondent à des ensembles d objets. L algorithme 2 présente le traitement d une liste d identifiants d objets dans le cas le plus général. Les stratégies de remplacement et d allocation sont indépendantes pour le cache de requêtes et pour le cache d objets. Une fois reçue, une liste d identifiants est parcourue pour récupérer les objets associés. A ce niveau, trois cas de figure peuvent apparaître : (1) tous les objets de la liste sont présents dans le cache ; (2) certains objets sont absents ; (3) aucun objet n est stocké. Le premier cas est le plus favorable, car aucune résolution n est nécessaire. Dans le deuxième cas de figure, les objets absents sont récupérés. En général, la résolution est exécutée auprès des serveurs. L appel de méthode ObjCache.GRés.charger(absIdObjList) correspond alors à l instruction serveurs.charger(absidobjlist). Il convient de noter qu il est également possible de contacter d autres caches. Nous étudierons, par exemple, le cas de la résolution horizontale dans le chapitre 7, qui présentera alors l algorithme ObjCache.GRés.charger correspondant. Une fois reçus, les objets demandés sont ajoutés en cache, puis fusionnés avec ceux qui étaient déjà présents, construisant ainsi le résultat complet. 83

96 Chapitre 6 : Cache dual Algorithme 2 Traitement d une liste d identifiants par un cache d objets avec une gestion découplée : ObjCache.charger(idObjList) Entrées : idobjlist : liste d identifiants d objet Sorties : objlist : liste d objets {Initialisation} objlist absidobjlist {Parcours de la liste des identifiants} pour chaque id de idobjlist faire {Recherche dans le cache d objets} obj ObjCache.GCont.chercher(id) si obj null alors {succès} {Ajout de l objet considéré dans la liste des objets résultat} objlist.ajouter(obj) sinon {défaut} {Ajout de l identifiant considéré dans la liste des objets absents} absidobjlist.ajouter(id) finsi fin pour si absidobjlist alors {Récupération des objets absents} absobjlist ObjCache.GRés.charger(absIdObjList) {Ajout des objets récupérés dans le cache d objets} ObjCache.GCont.ajouter(absObjList) {Construction de la liste finale des identifiants des objets demandés} objlist objlist absobjlist finsi retourner objlist Exemple 6.6. Soit le contenu du cache d objets illustré par la figure 6.1 et la liste d objets {P15711, P13813} posée (correspondant à la requête espèce = virus). Dans cette situation, un succès se produit et enr-p15711 est récupéré à l aide du contenu du cache, alors qu un défaut est provoqué, nécessitant le chargement de enr-p13813 depuis les serveurs. A la réception de ce dernier, l ensemble {enr-p15711, enr-p13813} est fourni au cache de requêtes. Le troisième cas de figure, où aucun des objets recherchés n est présent dans le cache, est bien sûr le moins favorable, puisqu il engendrera potentiellement le plus gros volume de données à récupérer, entraînant une plus grande consommation de bande passante et une charge plus importante sur les serveurs ou sur les caches contactés. Cependant, même dans ce cas de figure, le cache dual présente un gain, puisqu il permet d utiliser un précalcul et d éviter une évaluation, totale ou partielle, sur les serveurs. Cette possibilité est une des grandes forces du cache dual, autorisant le stockage de calculs même si les objets correspondants sont trop volumineux pour être gardés. Exemple 6.7. Soit le cache illustré par la figure 6.1 et la liste d objets {P13813, P19084} posée (correspondant à la requête auteur = Blanchet). Dans cette situation, tous les éléments engendrent un défaut qui devra être résolu. 84

97 6.2 Spécification du cache dual Il est important de noter que le cache dual offre un niveau de flexibilité plus important que les caches sémantiques classiques. En effet, en cas de défaut sur le cache d objets, il est possible de récupérer les éléments correspondants à l aide de leur identifiant, mais également en transmettant la requête posée. Dans ce dernier cas, le cache d objets gère les problèmes de duplication des objets qui étaient déjà stockés. L utilisation de résolutions à l aide de listes d identifiants, plutôt que de résolutions avec les requêtes correspondantes dépend de l efficacité des mécanismes d indexation proposés par les serveurs, mais également du nombre d objets absents, puisque le coût de la résolution à l aide d une liste est proportionnel au nombre d éléments de la liste. Il faut également remarquer que l algorithme de traitement d une liste d identifiants par le cache d objets présentant une gestion découplée du cache de requêtes ne fournit la réponse à un client que si celle-ci est complète. Cependant, nous avons également proposé une autre approche permettant de fournir au client la portion de résultat disponible en cache, sans attendre la résolution de défauts d objets auprès des serveurs. Le client peut ainsi prendre en compte les objets à sa disposition, pendant la récupération en parallèle des objets absents. Il convient cependant de noter que cette approche engendre des coûts supplémentaires liés à la gestion des deux processus (contre un pour une approche fournissant uniquement un résultat complet). Algorithme 3 Traitement d une liste d identifiants par le cache d objets avec une gestion fortement couplée : ObjCache.charger(idObjList) Entrées : idobjlist : liste d identifiants d objet Sorties : objlist : liste d objets {Parcours de la liste des identifiants} pour chaque id de idobjlist faire {Recherche dans le cache d objets} obj ObjCache.GCont.chercher(id) {Ajout de l objet considéré dans la liste des objets résultat} objlist.ajouter(obj) fin pour retourner objlist L algorithme 3 présente le traitement d une liste d identifiants d objets dans le cas d une gestion fortement couplée entre le cache de requêtes et le cache d objets. Avec une gestion fortement couplée, tous les objets dont les identifiants appartiennent à une entrée du cache de requêtes sont présents dans le cache d objets associé. Ainsi, le processus de traitement de requêtes pour un cache dual avec une gestion fortement couplée est obtenu à l aide de l algorithme général en ne prenant plus en compte le cas d objets absents (et donc de résolution de défauts) puisque une gestion fortement couplée assure que les objets référencés par leur identifiant dans le cache de requêtes sont présents dans le cache d objets. Il est important de noter qu avec cette approche, le cache dual est relativement proche d un cache sémantique manipulant des prédicats et des objets, les politiques de remplacement des caches devant assurer une synchronisation entre les requêtes et les objets. Exemple 6.8. Soit le contenu du cache illustré par la figure 6.3 et la requête année = 2006 posée. Dans cette situation, un succès se produit sur le cache de requêtes et les objets {P15711, Q43495} sont dans le cache d objets. 85

98 Chapitre 6 : Cache dual Fig. 6.3 Exemple de cache dual avec une gestion fortement couplée 6.3 Cache dual sémantique Le cache dual vise à optimiser les performances dans les systèmes d interrogation de données. Dans ce contexte, il est alors possible d utiliser des outils d analyse et d évaluation permettant de proposer un cache dual sémantique Analyse de requêtes sur le cache de requêtes Fig. 6.4 Cache dual sémantique L analyse de requêtes permet de comparer une requête posée à une entrée du cache. Puisque l analyse est réalisée sur les prédicats, ce processus est pris en compte au sein du cache dual par le cache de requêtes. Pour ce faire, le cache de requêtes utilise les outils de détection de recouvrement de requêtes proposés par l analyseur de requêtes, comme illustré par la figure 6.4. Lors du traitement d une demande, le cache de requêtes peut ainsi considérer différents cas de figure : l équivalence ou le recouvrement partiel entre une requête posée et une entrée du cache, l inclusion d une requête dans une entrée du cache ou l inclusion d une entrée du cache dans une requête. L algorithme 4 présente le traitement d une requête req par le cache de requêtes d un cache dual sémantique. Le début de l algorithme, correspondant aux instructions réalisées en cas de succès de cache exact, est identique au fonctionnement d un cache dual classique. La différence entre les deux caches intervient dans le cas où aucun succès exact ne se produit. Dans ce cas, le cache dual sémantique, à l aide de la méthode traitsémantique, récupère la portion de résultat disponible en cache, correspondant au résultat de la requête de consultation, et écrit la requête restante, permettant de récupérer sur les serveurs les objets absents. Le résultat de la requête restante, obtenu après résolution, viendra compléter la réponse fournie au client. L algorithme 5 exécuté par la méthode traitsémantique, permet d appliquer un trai- 86

99 6.3 Cache dual sémantique Algorithme 4 Traitement d une requête par un cache dual sémantique : Req- Cache.charger(req) Entrées : req : requête Sorties : objlist : liste d objets {Recherche de la requête dans le cache} idobjlist ReqCache.GCont.chercher(req) si idobjlist null alors {succès exact} si idobjlist alors {Récupération des objets sur le cache d objets à l aide de la liste d identifiants} objlist ObjCache.charger(idObjList) sinon objlist finsi sinon {pas de succès exact} {Traitement sémantique} (considobjlist,consobjlist,reqrest) traitsémantique(req) si reqrest null alors {requête restante non nulle} {Résolution de la requête restante} (restidobjlist,restobjlist) ReqCache.GRés.charger(reqRest) {Ajout des objets de la requête restante dans le cache d objets} ObjCache.ajouter(restObjList) finsi {Construction de la liste finale des identifiants des objets demandés} idobjlist considobjlist restidobjlist ReqCache.GCont.ajouter(req,idObjLIst) objlist consobjlist restobjlist finsi retourner objlist tement en fonction des cas de recouvrement considérés. Dans un premier temps, l algorithme sélectionne l entrée du cache la plus intéressante, respectant les cas de recouvrement pris en compte, pour répondre à la requête posée, à l aide de la méthode meilleureentrée. Cette méthode retourne une entrée, ainsi que le cas de recouvrement avec la requête posée correspondante. A noter que si tous les cas de recouvrement sont considérés, l algorithme tentera de privilégier celui minimisant les évaluations au sein du cache et sur les serveurs. C est pourquoi, les cas de recouvrement classés par ordre de pertinence sont l équivalence, l inclusion d une requête dans une entrée du cache, l inclusion d une entrée du cache dans une requête et finalement le recouvrement partiel. Chaque cas de recouvrement est associé à un processus de traitement spécifique, capturé dans une méthode particulière. Ainsi, une fois que le meilleur cas de recouvrement est obtenu, la méthode associée est exécutée pour calculer la requête restante et le résultat de la requête de consultation (sous forme d une liste d identifiants et d une liste d objets). Il est à noter que si aucune entrée ne peut être utilisée, la requête restante correspond à la requête posée, engendrant une résolution de défaut de cache «classique». L interaction entre le cache de requêtes et l analyse des requêtes est capturée au niveau de l algorithme meilleureentrée, par des appels à la méthode analyse du gestionnaire d analyse, qui dépend du langage de requêtes utilisé. Il est important de noter que nous ne nous sommes pas focalisés sur la manière de détecter les recouvrements des requêtes (query 87

100 Chapitre 6 : Cache dual Algorithme 5 Traitement sémantique d une requête par un cache de requêtes : traitsémantique(req) Entrées : req : requête Sorties : considobjlist : liste d identifiants d objet, consobjlist : liste d objets, reqrest : requête {Sélection d une entrée} (cas,entrée) meilleureentrée(req) si cas = équivalence alors {Traitement du cas d équivalence} (considobjlist,consobjlist,reqrest) traitéquivalence(req,entrée) sinon si cas = inclus alors {Traitement du cas d inclusion de la requête posée dans une entrée du cache} (considobjlist,consobjlist,reqrest) traitinclus(req,entrée) sinon si cas = incluant alors {Traitement du cas d inclusion d une entrée du cache dans la requête posée} (considobjlist,consobjlist,reqrest) traitincluant(req,entrée) sinon si cas = partiel alors {Traitement du cas de recouvrement partiel} (considobjlist,consobjlist,reqrest) traitpartiel(req,entrée) sinon si cas = null alors {Aucun recouvrement} {Le résultat de la requête de consultation est vide} considobjlist consobjlist {La requête restante est la requête posée} reqrest req finsi retourner (considobjlist,consobjlist,reqrest) containement). C est pourquoi, nous ne nous attarderons pas sur cet aspect. Néanmoins, notre approche par séparation des préoccupations nous laisse penser que les résultats obtenus dans cette communauté de recherche (tels que les travaux réalisés pour les requêtes XML [CRW02] ou XPath [MS05]) peuvent être intégrés dans nos travaux. Les algorithmes 6 et 7 illustrent la méthode meilleureentrée. L algorithme 6 correspond à un traitement ne prenant en compte que les équivalences. L algorithme 7 correspond à un traitement ne considérant que les inclusions de la requête posée dans une entrée du cache. Il est possible de remarquer, que le processus du parcours du cache est différent pour les deux algorithmes. Alors que, pour l équivalence, l entrée choisie est en général la première respectant la propriété considérée, afin de minimiser le coût des analyses, pour l inclusion d une requête dans une entrée, la décision peut se faire selon différentes approches, en fonction du contexte applicatif. Bien sûr, le parcours du contenu du cache peut être arrêté le plus tôt possible, afin de réduire le coût des analyses. Il est néanmoins envisageable de terminer ce parcours, afin de choisir ensuite l entrée sur d autres critères en cas de réponses positives multiples. Par exemple, l approche utilisée par l algorithme 7 consiste à choisir l entrée dont le nombre d éléments est le plus faible, puisque cela évite des traitements inutiles. Il est important de noter que dans le cas d une entrée incluse dans une requête posée ou dans le cas d un recouvrement partiel, il est possible d utiliser plusieurs entrées du cache. 88

101 6.3 Cache dual sémantique Algorithme 6 Sélection d une entrée avec considération uniquement des équivalences : meilleureentrée(req) Entrées : req : requête Sorties : cas : chaîne de caractères, entrée : entrée du cache de requêtes {Parcours du contenu du cache} entrée ReqCacheCont.suivant tantque entrée null faire {Comparaison par l analyseur de requêtes de la requête avec l entrée du cache} cas ReqCache.analyseur.analyse(req,entrée.id) si cas = équivalence alors {Arrêt du parcours} retourner (cas,entrée) finsi fintantque retourner (null,null) Dans ce cas, le calcul de la requête restante se fait en fonction de toutes les entrées utilisées. Un mécanisme est alors utilisé lors de l évaluation de la requête de consultation pour gérer la duplication des éléments, si certains d entre eux appartiennent à plusieurs entrées considérées. Ce mode de fonctionnement permet alors de réduire le volume de données transférées entre les serveurs et le cache. Néanmoins, le coût d évaluation en cache et sur les serveurs est dans ce cas plus important. Nous avons choisi, dans un premier temps, de ne pas imposer une charge d évaluation trop importante au cache. C est pourquoi, les différents algorithmes proposés dans ce document ne s intéressent qu à la prise en compte d une seule entrée du cache. Les algorithmes prenant en compte plusieurs entrées feront l objet de futurs travaux. La suite de cette section présente les algorithmes associés aux différents cas de recouvrement, appelés par la méthode traitsémantique : l équivalence, l inclusion de la requête posée dans une entrée du cache, l inclusion d une entrée du cache dans la requête posée et finalement le cas d un recouvrement partiel Équivalence entre une requête posée et une entrée L algorithme 8 présente le traitement d une requête req par un cache dual sémantique prenant en compte l équivalence entre une entrée et une requête posée. Dans ce cas, le résultat entre l entrée du cache et la requête posée est identique. Par conséquent, aucune évaluation n est nécessaire. Le résultat de la requête de consultation est alors obtenu du cache d objets à l aide de la liste des identifiants d objets de l entrée utilisée. A noter que dans ce cas, la requête restante est nulle, l intégralité du résultat pouvant être obtenue avec les informations disponibles en cache. Exemple 6.9. Soit le contenu du cache de requêtes illustré par la figure 6.1 et une requête année > 2005 année < 2007 posée. Cette requête est équivalente au prédicat année = Ainsi la réponse peut être obtenue en récupérant les éléments identifiés par P15711 et Q43495 à l aide du cache d objets. 89

102 Chapitre 6 : Cache dual Algorithme 7 Sélection d une entrée avec considération uniquement des inclusions de requêtes dans une entrée du cache : meilleureentrée(req) Entrées : req : requête Sorties : cas : chaîne de caractères, entrée : entrée du cache de requêtes {Initialisation} cas null entrée null {Parcours du contenu du cache} entréecour ReqCacheCont.suivant tantque entréecour null faire {Comparaison par l analyseur de requêtes de la requête avec l entrée du cache} castemp ReqCache.analyseur.analyse(req,entréeCour.id) si castemp = inclus alors si entrée = null alors {Cas de la première entrée incluant la requête posée} entrée entréecour cas inclus sinon {Cas d une autre requête incluant la requête posée} {Sélection de l entrée avec le moins d identifiants} si entréecour.valeur.taille < entrée.valeur.taille alors entrée entréecour finsi finsi finsi fintantque retourner (cas,entrée) Inclusion d une requête posée dans une entrée L algorithme 9 illustre le traitement d une requête req par un cache dual sémantique prenant en compte l inclusion d une requête posée dans une entrée du cache. Dans le cas d un tel recouvrement, une évaluation de la requête sur les objets correspondants est exécutée. Puisque les objets ne sont pas présents dans le cache de requêtes, cette évaluation est déléguée au cache d objets à l aide de la méthode ChargerEtÉvaluer. Cette méthode permet d évaluer la requête sur les objets concernés (voir section 6.3.2), et de retourner les objets pertinents. Le cache de requêtes peut alors fournir le résultat au client. A noter qu à l instar d une équivalence, ce cas de recouvrement ne nécessite aucune évaluation sur les serveurs, puisque l intégralité des objets demandés est présente en cache. Ainsi, la requête restante est nulle. Exemple Soit le contenu du cache de requêtes illustré par la figure 6.1 et une requête année = 2006 espèce = bactéries posée. Cette requête est incluse dans le prédicat année = 2006, ainsi la réponse peut être calculée l aide d une évaluation sur les éléments identifiés par P15711 et Q Inclusion d une entrée dans une requête posée Le traitement de l inclusion d une entrée dans une requête est illustré par l algorithme 10. Dans ce cas, les objets associés à l entrée sont récupérés à l aide du cache 90

103 6.3 Cache dual sémantique Algorithme 8 Traitement du cas d équivalence par un cache de requêtes : traitéquivalence(req,entrée) Entrées : req : requête, entrée : entrée du cache de requêtes Sorties : considobjlist : liste d identifiants d objet, consobjlist : liste d objets, reqrest : requête {Mise à jour de la liste des identifiants} considobjlist entrée.valeur {Récupération des objets sur le cache d objets à l aide de la liste d identifiants} consobjlist ObjCache.charger(consIdObjList) retourner (considobjlist,consobjlist,null) Algorithme 9 Traitement du cas d inclusion d une requête dans une entrée par un cache de requêtes : traitinclus(req,entrée) Entrées : req : requête, entrée : entrée du cache de requêtes Sorties : considobjlist : liste d identifiants d objet, consobjlist : liste d objets, reqrest : requête entréeidlist entrée.valeur si entréeidlist alors {Évaluation de la requête de consultation} (considobjlist,consobjlist) ObjCache.chargerEtÉvaluer(req,entréeIdList) sinon {liste vide} considobjlist consobjlist finsi retourner (considobjlist,consobjlist,null) d objets et constituent le résultat de la requête de consultation. La requête restante, req entrée.id, est calculée, puis sera envoyée aux serveurs. Exemple Soit le contenu du cache de requêtes illustré par la figure 6.1 et une requête année > 2005 posée. L entrée de prédicat année = 2006 est incluse dans la réponse à cette requête, ainsi la réponse contient les éléments identifiés par P15711 et Q Néanmoins, si des éléments ont été modifiés depuis 2005, sans que la modification ait eu lieu en 2006, ils doivent être récupérés sur les serveurs. Dans ce cas, la requête restante est année > 2005 année = 2006) Recouvrement partiel entre une requête posée et une entrée L algorithme 11 illustre le dernier cas de recouvrement, l intersection entre une requête et une entrée, sans inclusion. Ce cas est le plus complexe en terme d évaluation, puisqu il nécessite du calcul à la fois pour la requête de consultation et pour la requête restante. Le résultat de la requête de consultation est obtenu en évaluant la requête posée sur les objets associés à l entrée considérée (à l aide de la méthode chargeretévaluer du cache d objets). La requête restante est, quant à elle, calculée en fonction de la requête de l entrée utilisée et sera ensuite soumise aux serveurs. Exemple Soit la requête année = 2006 auteur = Blanchet et un cache de requêtes contenant une unique entrée, de prédicat année = 2006 espèce = virus et 91

104 Chapitre 6 : Cache dual Algorithme 10 Traitement du cas d inclusion d une entrée dans une requête par un cache de requêtes : traitincluant(req,entrée) Entrées : req : requête, entrée : entrée du cache de requêtes Sorties : considobjlist : liste d identifiants d objet, consobjlist : liste d objets, reqrest : requête {Calcul de la requête restante} reqcons entrée.id reqrest req ( reqcons) considlist entré.valeur si considlist alors {liste non vide} {Récupération des objets sur le cache d objets à l aide de la liste d identifiants} consobjlist ObjCache.charger(consIdList) sinon {liste vide} consobjlist finsi retourner (considobjlist,consobjlist,reqrest) de valeur {P15711, Q43495}. Dans ce cas, une partie de la réponse peut être obtenue à l aide d une évaluation sur les enregistrements identifiés par P15711 et Q Par contre, les enregistrements créés par Blanchet en 2006 qui ne sont pas des virus doivent être récupérés sur les serveurs à l aide de la requête restante année = 2006 auteur = Blanchet (espèce = virus) (qui correspond à une simplification de la requête année = 2006 auteur = Blanchet (année = 2006 espèce = virus)) Évaluation de requêtes sur le cache d objets Comme vu précédemment, certaines requêtes seront évaluées sur le cache d objets. Ainsi, l évaluation de la requête peut être distribuée, une partie du processus étant exécutée sur les serveurs, alors que la partie restante est exécutée en cache à l aide de l évaluateur de requ^etes, comme illustré par la figure 6.4. L algorithme 12 présente le traitement d une d évaluation de requêtes par le cache d objets (ObjCache) à l aide de la méthode chargeretévaluer, dans le cas d une gestion découplée. Cette méthode prend en paramètre la liste des identifiants d objets sur lesquels porte l évaluation ainsi que la requête à exécuter. La liste est alors parcourue pour récupérer les objets stockés et construire la liste des identifiants des objets absents, afin que ces derniers soient récupérés (auprès des serveurs ou d autres caches en fonction du protocole de résolution utilisé). La requête est évaluée sur ces deux ensembles distincts. Cette séparation permet de ne pas stocker des objets ne faisant pas partie de la réponse à la requête posée (objets de l entrée du cache utilisée, mais ne vérifiant pas la requête évaluée). Cette séparation est également utile pour fournir pour un cache dual parallélisant l évaluation. Ainsi, il est possible de fournir la partie du résultat disponible en cache, sans attendre que les objets absents aient été récupérés sur les serveurs, puis soumis à l évaluation de la requête en cache. Cependant, cette parallélisation a un coût lié à la gestion des processus. Dans le cas d une gestion fortement couplée, l algorithme utilisé est plus simple, puisqu il ne considère pas la récupération des éléments absents, comme illustré par l algo- 92

105 6.3 Cache dual sémantique Algorithme 11 Traitement du cas de recouvrement partiel par un cache de requêtes : traitpartiel(req,entrée) Entrées : req : requête, entrée : entrée du cache de requêtes Sorties : considobjlist : liste d identifiants d objet, consobjlist : liste d objets, reqrest : requête {Calcul de la requête restante} reqcons entrée.id reqrest req ( reqcons) entréeidlist entrée.valeur si entréeidlist alors {liste non vide} {Évaluation de la requête de consultation} (considobjlist,consobjlist) ObjCache.chargerEtÉvaluer(req,entréeIdList) sinon {liste vide} considobjlist consobjlist finsi {Transfert du résultat} retourner (considobjlist,consobjlist,reqrest) rithme 13. Quel que soit le degré de cohérence fixé, le processus d évaluation est capturé dans la méthode évaluer, prenant en entrée une requête et la liste des objets sur lesquels elle doit être appliquée. Dans la suite, nous nous intéressons à la prise en compte des différentes opérations (sélection, projection, tri, etc.) au sein du cache dual, notamment par rapport au critère de vérifiabilité. Les gestions orthogonales des requêtes et des objets nécessitent une prise en compte particulière de la vérifiabilité. L objectif de cette partie n est pas de présenter une étude exhaustive de la vérifiabilité au sein du cache dual, mais une solution relativement simple permettant de prendre en compte de nombreuses opérations pour un cache dual sémantique. Notre approche consiste à récupérer et à stocker des objets complets dans le cache d objets. Ainsi, le cache dual réécrit les requêtes afin d enlever si nécessaire les projections. L évaluation des requêtes est alors distribuée, la projection étant exécutée au niveau du cache. Cette précaution évite notamment qu un objet récupéré par une projection sur un nombre très faible d attributs empêche une sélection sur des attributs non gardés. Bien sûr en cas de succès de cache pour une requête de projection, il sera de nouveau nécessaire d appliquer la projection correspondante pour ne récupérer que les attributs souhaités. Des sélections et des tris peuvent être réalisés au sein du cache dual. Les sélections sont exécutées en cas d inclusion d une requête dans une entrée ou en cas d intersection entre une requête et une entrée. Elles permettent alors de récupérer l ensemble des objets de l entrée faisant partie de la réponse à la requête. L opération de tri est, quant à elle, utilisée pour ordonner les résultats d une requête en fonction d un attribut donné. A notre connaissance, aucun cache sémantique ne considère cette opération. Pourtant, cette opération peut néanmoins être utile dans certains contextes, où un important travail est effectué sur la présentation des résultats. Le tri est exécuté au sein du cache dual en cas d équivalence d une requête posée avec une entrée du cache. Il est à noter que la considération de tris au sein d un cache dual nécessite des précautions particulières. En général, le cache dual ne prend pas en compte l ordre des objets réponses à une requête, afin de fournir un résultat partiel, qui correspond aux objets déjà présents en cache. Dans 93

106 Chapitre 6 : Cache dual Algorithme 12 Evaluation d une requête sur une liste d identifiants par un cache d objets avec une gestion découplée : ObjCache.chargerEtÉvaluer(req,entréeIdList) Entrées : req : requête, entréeidlist : liste d identifiants d objet Sorties : idobjlist : liste d identifiants d objet, objlist : liste d objets {Initialisation} présobjlistéval absidobjlist {Parcours de la liste des identifiants} pour chaque id de entréeidlist faire obj ObjCache.GCont.chercher(id) si obj null alors {succès} {Construction de la liste des objets présents en cache} présobjlistéval.ajouter(obj) sinon {défaut} {Construction de la liste des objets absents du cache} absidobjlist.ajouter(id) finsi fin pour si présobjlistéval alors {Évaluation de la requête de consultation sur les objets présents en cache} (présidobjlist,présobjlist) ObjCache.évaluateur.évaluer(req,présObjListÉval) finsi si absidobjlist alors {Récupération des objets absents} absobjlistéval ObjCache.GRés.charger(absIdObjList) {Évaluation de la requête de consultation sur les objets récupérés} (absidobjlist,absobjlist) ObjCache.évaluateur.évaluer(req,absObjListÉval) {Ajout des objets récupérés et vérifiant la requête dans le cache d objets} ObjCache.GCont.ajouter(absObjList) finsi {Construction du résultat final} idobjlist présidobjlist absidobjlist objlist présobjlist absobjlist retourner (idobjlist,objlist) le cas d un tri, il est nécessaire d attendre la récupération des objets à partir des serveurs pour construire l ensemble complet des objets demandés. Une fois tous les objets obtenus, ils peuvent être ordonnés en fonction des critères donnés par le client. D autres opérateurs peuvent être considérés par un cache sémantique, notamment les jointures, les fonctions d agrégation (maximum, minimum, moyenne, etc.) ou encore les requêtes de localisation. L étude de ces opérateurs constitue une perspective de recherche importante. Les algorithmes que nous avons présentés cherchent à réduire autant que possible la charge de calcul sur les serveurs. Ainsi, l évaluation en cache est à chaque fois privilégiée par rapport à une évaluation sur les serveurs. Ce choix est pertinent dans des contextes où les ressources de calculs des caches sont importantes et/ou les serveurs sont très chargés. Ce choix peut cependant être nuancé. Il est alors important de savoir quand évaluer une requête sur le contenu du cache et quand poser la requête sur les serveurs. Contrairement aux caches sémantiques classiques, il faut également prendre en compte le cas d objets 94

107 6.3 Cache dual sémantique Algorithme 13 Evaluation d une requête sur une liste d identifiants par un cache d objets avec une gestion fortement couplée : ObjCache.chargerEtÉvaluer(req,entréeIdList) Entrées : req : requête, entréeidlist : liste d identifiants d objet Sorties : idobjlist : liste d identifiants d objet, objlist : liste d objets {Initialisation} objlistéval {Parcours de la liste des identifiants} pour chaque id de entréeidlist faire obj ObjCache.GCont.chercher(id) {Construction de la liste des objets} objlistéval.ajouter(obj) fin pour {Évaluation de la requête de consultation sur les objets} (idobjlost,objlist) ObjCache.évaluateur.évaluer(req,objListÉval) {Transfert du résultat} retourner (idobjlist,objlist) absents. La problématique d évaluation doit alors considérer l absence de certains éléments du cache d objets. Ceci nécessite alors de les récupérer dans un premier temps, lors de la décision d exécuter la requête sur les serveurs ou localement. Si la plupart des objets sont absents, il est parfois préférable de déléguer le calcul aux serveurs, surtout pour un grand nombre d objets et si le résultat ne concerne au final qu une infime partie d entre eux. Il est donc intéressant de proposer au sein d un cache dual (ou de tout autre cache sémantique) un mécanisme permettant de choisir entre une évaluation en cache et une évaluation sur les serveurs. Selon les contextes, ce mécanisme pourra mettre en œuvre une adaptation dynamique, notamment pour s adapter à la charge sur les serveurs Cache dual et autres techniques de cache sémantique Cette section s intéresse aux techniques de cache sémantique appliquées au cache dual. La première partie présente le remplacement. La deuxième traite du préchargement. Enfin, la dernière partie se focalise sur le partitionnement et le regroupement Remplacement Le cache dual autorise l utilisation de politiques de remplacement sémantiques. Il peut, en particulier, utiliser une politique de remplacement basée sur l utilité, à la fois des résultats de requêtes, mais également, des objets. D autres stratégies peuvent également être considérées. Par exemple, la politique LRU à deux niveaux peut être appliquée au cache de requêtes. Les entrées sont alors réparties dans différents groupes sémantiques. Les groupes peuvent, par exemple, correspondre aux espèces, permettant de distinguer les entrées portant sur les virus de celles portant sur les bactéries. Lorsqu une entrée doit être supprimée, elle est choisie à l aide d une stratégie LRU au sein d un groupe, lui-même étant le moins récemment référencé. 95

108 Chapitre 6 : Cache dual Préchargement Le cache dual autorise le préchargement basé sur la sémantique des demandes, à l aide de l approche par augmentation de requêtes [KB96]. Dans ce cas, la résolution de défaut par le cache de requêtes ne se fait pas sur le prédicat posé, mais sur une requête plus large, pour obtenir un résultat plus intéressant pour de futures demandes. La requête est donc réécrite au moment de la résolution, afin d être moins contraignante (en enlevant, par exemple, des conditions de sélections), puis soumise aux serveurs. Le résultat une fois reçu est filtré de manière à fournir à l utilisateur ou l application uniquement les données demandées. Le cache de requêtes peut alors stocker le résultat de la requête augmentée, et éventuellement de la requête posée. Le cache d objets, quant à lui, peut considérer différemment les objets préchargés de ceux fournis au client. La gestion des projections au sein du cache dual est un exemple de préchargement par augmentation de requêtes, la requête posée étant réécrite pour exécuter la projection en cache et non sur les serveurs. Il est important de noter que le cache dual, en plus de prendre en compte le préchargement par augmentation de requêtes, peut également considérer d autres stratégies de préchargement. Il est notamment possible d anticiper les demandes à l aide de statistiques, que ce soit pour le cache de requêtes ou pour le cache d objets Partitionnement et regroupement Le partitionnement consiste à distinguer lors d un recouvrement d une entrée et d une requête, la portion d une entrée utilisée pour construire le résultat. En distinguant les requêtes des objets, le cache dual n engendre pas de duplication au sein du cache. En effet, à un instant donné, une unique instance d un élément est stockée dans le cache d objets, même s il est partagé par différents prédicats gardés dans le cache de requêtes. Ainsi, le partitionnement au sein d un cache dual permet de conserver au sein du cache de requêtes à la fois l entrée utilisée, mais également le résultat de la requête posée. Le partitionnement permet alors d économiser des calculs, notamment dans le cas de successions de requêtes de plus en plus précises, en travaillant sur des ensembles d objets de plus en plus petits. Il est à noter que le partitionnement peut néanmoins être limité, afin d éviter de gérer un trop grand nombre d entrées, pour ainsi réduire le coût d une recherche en cache. Une limitation possible est, par exemple, un seuil de partitionnement basé sur la taille des entrées [LLS99]. Bien sûr, si le cache de requêtes ne peut stocker qu un nombre très limité d entrées (ce qui est rare, puisque la taille d une liste d identifiants est très souvent petite) ou si le processus de recherche en cache est très coûteux alors que l évaluation est performante, il est possible de minimiser le partitionnement, en ne gardant pas les résultats de requêtes pouvant être obtenus à l aide d entrées du cache (ainsi le cache tendra à ne conserver que des entrées de grande taille pouvant donc être réutilisées par de nombreuses requêtes). Le cache dual considère également le regroupement, qui vise à limiter le nombre de requêtes gérées au sein du cache. Tout comme pour le partitionnement, le regroupement ne concerne que le cache de requêtes. Deux types de regroupements peuvent être considérés. Le premier permet de fusionner le résultat pour une requête posée de la requête de consultation avec le résultat de la requête restante. Ce regroupement est intégré par défaut dans un cache dual, puisqu il facilitera la réutilisation du résultat de la requête, en évitant de manipuler plusieurs entrées. Le deuxième niveau de regroupement repose sur une gestion sémantique autorisant la création de nouvelles entrées dans le cache de requêtes. Ainsi si 96

109 6.4 Cache dual et adaptabilité deux requêtes sont complémentaires, elles peuvent engendrer un nouveau prédicat correspondant à l union de leur résultat. Dans ce cas là, il peut être décidé de garder ou non les sous-requêtes. Il s agit alors d un compromis entre le coût de calcul et le coût de recherche. Alors que la conservation des sous-requêtes permet de réduire le coût des évaluations en travaillant sur des ensembles de plus petite taille, la suppression des sous-requêtes diminue le nombre de comparaisons au moment de l analyse. Il est important de noter que ce deuxième niveau de regroupement peut être considéré à tout moment, et pas uniquement lorsque les requêtes sont posées. Ainsi, il peut notamment être appliqué lorsque l utilisation des ressources de calcul du cache est faible. 6.4 Cache dual et adaptabilité Dans cette section, nous présentons la flexibilité du cache dual dans l optique d une application dans des environnements grande échelle, le volume des données manipulées pouvant être très important, pour de nombreux clients et sources de données largement distribués. La première partie traite de l allocation des ressources pour les requêtes et pour les objets. La deuxième partie présente les configurations indépendantes du cache de requêtes et du cache d objets. La troisième partie s intéresse aux stratégies de déploiement pour un cache dual Allocation des ressources aux requêtes et aux objets Puisque le cache dual est composé d un cache de requêtes et d un cache d objets, l espace physique alloué doit être réparti en fonction de ces deux caches distincts. Les entrées du cache de requêtes sont généralement plus petites que celles du cache d objets. En effet, les tailles d une requête et d un identifiant d objet sont, la plupart du temps, de plusieurs ordres de grandeur inférieures à la taille des objets. C est pourquoi, le pourcentage de ressources alloué au cache de requêtes est en général petit par rapport à celui réservé au cache d objets. Par exemple, pour les expérimentations que nous avons réalisées pour un intergiciel de gestion de données sur grilles, sur 500 Méga octets alloués au cache dual, seuls 10 Méga octets sont réservés au cache de requêtes. Il convient, néanmoins, de noter que l efficacité du cache proposé dépend de la pertinence de cette distribution qui a un impact direct sur les objectifs fixés. Privilégier le cache de requêtes est intéressant si l évaluation d une requête est plus coûteuse que la récupération des objets correspondants à l aide de leur identifiant. Favoriser le cache de requêtes est donc préférable si les serveurs disposent de mécanismes d indexation efficaces et si les liens de communications sont performants. Dans les cas extrêmes, la totalité des ressources peut être allouée au cache de requêtes. Le cache dual est alors équivalent à un cache de vues. Un tel cache dual peut, par exemple, être utilisé si les objets manipulés sont trop volumineux pour être conservés en cache. Ceci est notamment le cas de certaines applications d imagerie médicale manipulant des vidéos. Allouer un maximum de ressources au cache d objets vise à réduire les transferts de données. Ainsi, le cache de requêtes peut être utilisé pour garder un nombre limité de requêtes. Dans ce cas, il est en général pertinent de garder les requêtes répondant à un maximum de demandes, autrement dit, les moins précises. Ceci permet d augmenter le 97

110 Chapitre 6 : Cache dual potentiel de réutilisation des données en cache. Il est cependant primordial de noter que l intégralité des ressources ne peut être attribuée au cache d objets, puisque son utilisation dépend d un succès sur le cache de requêtes correspondant Configurations du cache de requêtes et du cache d objets Configurer le cache dual revient à choisir des configurations, pouvant être différentes, pour le cache de requêtes et le cache d objets. Le processus de création d un cache dual est alors plus complexe que pour un cache classique. Néanmoins, le cache dual est alors plus flexible. Cette flexibilité permet ainsi une adaptation très fine en fonction de l environnement applicatif, afin d offrir une meilleure qualité de service. Par exemple, il est possible d utiliser des protocoles de résolution spécifiques à chacun des caches. Le cache de requêtes et le cache d objets peuvent alors contacter des serveurs différents. Ceci peut être intéressant, notamment si certains serveurs sont très efficaces pour des rapatriements de requêtes, alors que d autres sont plus performants pour des rapatriements de données. L utilisation de stratégies de résolution orthogonales est d autant plus intéressante pour les coopérations entre caches. La coopération peut être considérée pour le cache de requêtes et/ou le cache d objets, et pour chacun d eux un protocole de résolution particulier peut être utilisé. Le cas du cache dual coopératif sera étudié en détail dans le chapitre 7. Par ailleurs, les fonctionnalités optionnelles peuvent être considérées pour le cache de requêtes, le cache d objets, les deux ou aucun des deux. Il est, par exemple, envisageable d adopter une stratégie de préchargement uniquement pour le cache d objets Association cache de requêtes et caches d objets Fig. 6.5 Cache dual et multiples caches d objets Le cache dual offre une flexibilité de déploiement permettant d associer un cache de requêtes à plusieurs caches d objets, comme illustré par la figure 6.5. Ainsi en cas de résolution, les éléments récupérés sont stockés sur ces différents caches, en fonction d une stratégie spécifique, pouvant s inspirer des politiques employées dans les caches répartis. L utilisation de plusieurs cache d objets autorise le stockage de grandes masses de données, difficilement réalisable sur une unique machine, tout en gardant une centralisation de la connaissance sémantique, permettant une réutilisation importante des éléments gardés. Cette approche permet également de répartir la charge, le processus de recherche 98

111 6.5 Conclusion des éléments tirant alors profit de la parallélisation du travail sur les différents caches d objets. 6.5 Conclusion Ce chapitre a présenté le cache dual pouvant être utilisé dans les systèmes d interrogation. Après avoir introduit la spécification du cache dual, nous nous sommes intéressés à son extension sémantique, avant d étudier son adaptabilité. Le cache dual offre de nombreux avantages. Il optimise l utilisation de l espace physique, les éléments étant gardés au sein du cache d objets, des résultats non disjoints peuvent être gardés conjointement dans le cache de requêtes, sans que de multiples copies des éléments partagés ne soient stockées. Il est ainsi possible de gérer un plus grand nombre d éléments, à la fois pour les requêtes et pour les objets, permettant des taux de succès plus importants. Le cache dual offre également la particularité de pouvoir stocker des requêtes sans les objets associés, ce qui peut être particulièrement pertinent dans des contextes où les masses de données manipulées sont très grandes. Le cache dual sémantique est une étape supplémentaire pour répartir la charge, en optimisant l utilisation des ressources locales, et ainsi rendre le système global plus robuste. Cette contribution offre une grande flexibilité en terme de gestion de la sémantique. L approche modulaire proposée, distinguant l analyse et l évaluation de la gestion du contenu du cache permet une adaptation précise en fonction de l environnement d exécution. Il est alors possible d ajouter, supprimer ou modifier les cas de recouvrement et les opérations pris en compte au sein du cache dual lors du processus de traitement de requêtes. D autres caractéristiques du cache dual sont particulièrement utiles pour la gestion de données à grande échelle. L allocation précise des ressources permet un compromis intéressant sur les objectifs fixés. L optimisation des ressources en cache augmente la charge locale et réduit le nombre de requêtes évaluées sur les serveurs et la consommation de bande passante. Le cache dual permet, de plus, une configuration très souple, à la fois en terme de fonctionnalités des différents caches, mais également en terme de déploiement, permettant notamment d utiliser plusieurs caches d objets pour des contextes manipulant de gros volumes de données. Le cache dual se présente donc comme un cache efficace pour les systèmes d interrogation de données, pouvant être utilisé comme cache client, mais également comme un cache mandataire, partagé par plusieurs clients. Il autorise notamment la gestion de la sémantique, afin d optimiser l utilisation des ressources locales. Les expérimentations réalisées dans un système d interrogation de sources de données sur grilles (voir le chapitre 8) montrent que le cache dual réduit fortement le nombre d évaluations sur les serveurs et les transferts de données, conduisant à une réduction du temps d attente perçu par les utilisateurs de l ordre de 35 % par rapport à d autres caches sémantiques. Le chapitre 7 étudiera l apport des coopérations dans les caches sémantiques et s intéressera notamment aux nouvelles perspectives offertes par le cache dual. 99

112 100 Chapitre 6 : Cache dual

113 Chapitre 7 Caches sémantiques coopératifs Le chapitre précédent a présenté une nouvelle approche appelée cache dual. Cette approche a vu le jour grâce à la facilité de création de caches sémantiques pour les systèmes d interrogation à l aide du canevas ACS. Le canevas, en plus d aider à la construction de caches sémantiques, permet aisément de mettre en œuvre des caches coopératifs. L objectif de ce chapitre est de présenter notre proposition, appelée cache sémantique coopératif, inspirée par les perspectives offertes par ACS. Ce chapitre est organisé de la manière suivante. La section 7.1 donne un aperçu de notre proposition. La section 7.2 présente nos spécifications de caches sémantiques coopératifs. La section 7.3 introduit notre définition du concept de proximité pour la résolution horizontale de défaut. La section 7.4 étudie l intégration de ce concept au sein du cache dual. Enfin, la section 7.5 conclut ce chapitre. 7.1 Aperçu de la proposition L utilisation de caches coopératifs est particulièrement pertinente dans les environnements largement distribués. En effet, ils permettent d améliorer les performances en déchargeant les serveurs et les liens de communications. Néanmoins, à notre connaissance, il n existe pas de cache coopératif intégrant également les techniques de cache sémantique, alors que leur utilisation pourrait améliorer la qualité de service dans les systèmes d interrogation à grande échelle. Il convient également de noter que l aspect grande échelle rend nécessaire la mise en place de coopérations pertinentes entre les caches, certaines coopérations pouvant être nuisibles au bon fonctionnement du système, du fait de coûts de communication élevés ou encore d une faible probabilité d obtenir une réponse à une demande posée. Ce chapitre décrit notre proposition visant à apporter une solution à ces problèmes, permettant ainsi de fournir des caches sémantiques coopératifs performants pour des environnements à grande échelle, en instaurant des stratégies fines de coopération entre les caches. Notre proposition se décompose en trois contributions : Premièrement, le cache sémantique coopératif, qui combine les techniques de cache sémantique et de cache coopératif. Le cache sémantique coopératif repose sur le principe de la séparation des préoccupations. Ainsi, la gestion de la sémantique au sein du cache 101

114 Chapitre 7 : Caches sémantiques coopératifs est indépendante de la coopération entre caches. Le principe général consiste à exécuter le traitement de requêtes de manière séquentielle : soit coopération entre caches, puis traitement sémantique pour les caches répartis, soit traitement sémantique, puis résolution à l aide d autres caches pour une coopération avec résolution horizontale ou verticale. La deuxième contribution cherche à optimiser la coopération au sein d une stratégie de résolution horizontale en introduisant le concept de proximité entre caches. Le but est de créer des groupes dans lesquels la coopération est intéressante et supprimer les coûts liés à la gestion de coopérations peu pertinentes. Ainsi, le processus de résolution ne concerne qu un sous-ensemble de caches. Le concept de proximité est générique et 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. La troisième contribution, le cache dual coopératif, est un cache sémantique finement adaptable capable d exploiter au 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, guidée par une 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 le système. Pour illustrer notre proposition, nous considérons un système d interrogation de données sur grille, similaire à celui présenté dans les chapitres 5 et 6. Dans cette application, des bio-informaticiens peuvent accéder à des enregistrements stockés dans la source de données Swiss-Prot, correspondant à des séquences de protéines annotées. Il faut remarquer que la source autorise des accès à l aide de requêtes et aussi via des identifiants d enregistrements. Fig. 7.1 Exemple de déploiement de caches pour un système d interrogation de données Dans ce contexte, nous prenons en compte plusieurs clients répartis sur la grille, comme illustré par la figure 7.1. Ainsi, les clients pris en compte sont cl1, cl2 et cl3 à Grenoble, et cl4 et cl5 à Rennes. Outre le regroupement physique des clients (Grenoble et Rennes), nous introduisons un regroupement sémantique en caractérisant deux communautés d utilisateurs : ceux intéressés par les séquences de protéines d Eucaryotes, et ceux intéressés par celles d Archées. 102

115 7.2 Caches sémantiques coopératifs 7.2 Caches sémantiques coopératifs Dans cette section, nous proposons différents types de coopérations appliquées aux caches sémantiques. Les caches sémantiques coopératifs visent à combiner les avantages des caches sémantiques et des caches coopératifs. Les techniques de cache sémantique optimisent l utilisation des ressources locales, en raisonnant finement sur le contenu d un cache. Les caches coopératifs, quant à eux, permettent une meilleure utilisation des ressources globales, en tirant profit notamment des ressources offertes par les autres caches. Dans la suite de cette section, l expression «cache sémantique»sera utilisée indifféremment pour le cache de résultats de requêtes, le cache de prédicats et d 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 7.4). Bien que ces trois caches diffèrent dans leur gestion du contenu, ils sont similaires en terme de coopération. Par souci de clarté, la suite de cette section présente individuellement les différents caches sémantiques coopératifs : les caches sémantiques répartis 7.2.1, 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ée en conclusion de cette section (7.2.4) Caches sémantiques répartis Fig. 7.2 Caches sémantiques répartis Les caches sémantiques répartis, à l instar des caches répartis classiques, offrent une très bonne répartition de charge (à condition de choisir une fonction de répartition adéquate). La gestion de la sémantique est, quant à elle, peu coûteuse, puisqu un traitement sémantique n est exécuté que sur un unique cache. Le processus de traitement de requêtes par des caches sémantiques répartis est illustré par la figure 7.2. 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 dans le chapitre 3 (aléatoire, tourniquet, en fonction des clients, en fonction des demandes, etc.). A la réception de la requête, le cache élu procède comme un cache sémantique classique, décomposant la requête en deux requêtes disjointes : une requête de consultation et une restante. La requête de consultation est évaluée localement, alors que la requête restante est envoyée aux serveurs. Le résultat final est fourni au client par le cache. 103

116 Chapitre 7 : Caches sémantiques coopératifs Exemple 7.1. Supposons une répartition sur les caches c1, c2 et c3 basée sur les demandes. A la réception d une requête année = 2006, cette dernière est transférée par le gestionnaire de répartition au cache c2 responsable de cette requête, dont le contenu est [auteur = Blanchet]. Le traitement de la requête par c2 engendre l exécution locale de la requête de consultation année = 2006 auteur = Blanchet et la résolution par les serveurs de la requête restante année = 2006 auteur = Blanchet Caches sémantiques avec résolution verticale Fig. 7.3 Cache sémantique et résolution verticale Les caches sémantiques avec résolution verticale sont les plus faciles à mettre en œuvre, puisque comme dans une résolution verticale classique, seules les informations pour contacter un cache père sont nécessaires pour mettre en place la coopération. La figure 7.3 présente l évaluation de requêtes dans un cache sémantique avec résolution verticale. Comme dans un cache sémantique classique, la réception d une requête par un cache se traduit par la décomposition de la requête en une requête de consultation et une requête restante, la requête de consultation étant évaluée localement. 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. Le processus peut être récursif d un point de vue sémantique et coopératif. Ainsi, si les caches parents sont également des caches sémantiques avec résolution verticale, ils décomposent les requêtes reçues en une requête de consultation et une requête restante ; chaque résolution se fait en propageant la requête au niveau supérieur (un cache parent ou des serveurs). Ainsi, 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. Bien sûr, le processus de résolution est alors relativement coûteux, puisqu un traitement sémantique peut être considéré à chaque niveau de la hiérarchie. Pour simplifier la résolution, il est alors possible pour un cache parent de ne pas être un cache sémantique, ou encore de ne pas considérer la résolution verticale. Cependant, considérer les deux aspects est intéressant dans des contextes où la charge sur les serveurs est importante, notamment si le client accepte des résultats partiels. 104

117 7.2 Caches sémantiques coopératifs Exemple 7.2. Considérons une hiérarchie de caches sémantiques avec résolution verticale c1, cp1 et cpp1 telle que cp1 et cpp1 soient respectivement parents de c1 et cp1. Soient [année > 2005], [année > 2004] et [année > 2003] les entrées respectives de c1, cp1 et cpp1. Le processus de traitement de la requête année > 2000 engendre alors les couples (requête de consultation, requête restante) suivants : (année > 2005, année > 2000 année 2005) sur c1, (année > 2004, année > 2000 année 2004) sur cp1 et (année > 2003, année > 2000 année 2003) sur cpp1. Ce dernier étant situé au niveau le plus élevé de la hiérarchie, sa requête restante est envoyée aux serveurs Caches sémantiques avec résolution horizontale Fig. 7.4 Cache sémantique et résolution horizontale Le comportement d un cache sémantique avec résolution horizontale est illustré par la figure 7.4. Une requête posée par un client est décomposée en une requête de consultation et une requête restante qui est transférée à un ensemble de caches frères. Ces derniers n ont pas d obligation de résolution en cas de défaut, le résultat retourné pouvant être nul. Le traitement des demandes par un cache frère peut suivre une approche classique ou sémantique. Alors que l approche classique ne considère que les succès exacts, l approche 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. Exemple 7.3. Supposons une coopération de type résolution horizontale entre les caches c1, c2 et c3, dont les contenus respectifs sont [auteur = Blanchet], [année = 2006 auteur = Blanchet] et [année = 2006]. Lorsque la requête année = 2006 est posée sur c1, elle est décomposée en une requête de consultation année = 2006 auteur = Blanchet et une requête restante année = 2006 auteur = Blanchet. Celle-ci est alors envoyée sur c2 et c3. Dans tous les cas, c2 fournit les objets réponses, alors que pour c3, seule une prise en compte des succès étendus évite d obtenir une réponse nulle. 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 portions de résultat 105

118 Chapitre 7 : Caches sémantiques coopératifs associées à des prédicats. Il supprime alors, 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 est important de noter que cette approche est coûteuse et doit donc être employée prudemment Composition de coopérations Fig. 7.5 Caches sémantiques avec coopération hybride Il est possible de proposer des systèmes combinant les coopérations entre caches sémantiques présentées précédemment. Les solutions alors créées correspondent à des caches sémantiques répartis avec résolution horizontale et/ou verticale. Dans le cas où toutes les coopérations sont utilisées (comme illustré par la figure 7.5), un gestionnaire de distribution redirige la requête sur un cache en fonction de la stratégie de répartition employée. Le cache choisi décompose la demande en une requête de consultation et une requête restante. Cette dernière est envoyée sur les caches frères. Si la requête n est pas résolue, elle est alors envoyée à un cache père. Nous illustrons ce processus d évaluation dans un exemple concret ci-dessous. A noter que le traitement dans les autres combinaisons possibles peut facilement être dérivé de ce processus. Exemple 7.4. Soient cr1, cr2 et cr3 des caches sémantiques répartis, cr1 utilisant une résolution horizontale sur ch2 et ch3 et une résolution verticale sur cp. Alors que ch2 est vide, les contenus de cr1, ch3 et cp1 sont respectivement [année > 2005], [année > 2004], [année > 2003] (les contenus de cr2 et cr3 ne sont pas donnés, puisqu ils n interviennent pas ici). Lorsqu une requête année > 2000 est orientée vers cr1, la requête restante année > 2000 année 2005 est alors soumise à la résolution horizontale. En cas de considération des succès partiels, la nouvelle requête restante devient année > 2000 auteur La requête finalement évaluée sur les serveurs est année > 2000 année 2003 après une résolution verticale sur cp. 106

119 7.3 Résolution horizontale basée sur la proximité 7.3 Résolution horizontale basée sur la proximité Nos recherches se sont focalisées sur la coopération basée sur une résolution horizontale. Alors que les caches répartis sont en général limités à un espace physique restreint et que les caches parents peuvent devenir des goulots d étranglement dans une résolution verticale, la résolution horizontale offre la possibilité de faire coopérer plusieurs caches largement distribués. Le prix à payer est alors le coût lié à la localisation des données. Dans cette section, nous proposons le concept de proximité autorisant une configuration fine de la résolution. Nous étudions ensuite l intégration de ce concept dans les protocoles de résolution Notion de proximité entre caches 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 dans des environnements grande échelle, où la localisation de l information est difficile. En effet, les processus de synchronisation des catalogues ou d inondation sont dans ce cas très coûteux. Afin de résoudre ce problème, nous introduisons le concept de proximité. Dans la langue française, la proximité caractérise la situation d une chose qui est à peu de distance d une autre. Dans notre contexte, nous associons le concept de proximité à la définition suivante : Définition 7.1. Proximité La proximité est utilisée pour mesurer, selon divers paramètres, l intérêt d une coopération entre deux caches. Ainsi, lorsque deux caches sont proches, il est intéressant de les faire coopérer. Dans le cas contraire, il est recommandé d éviter qu ils interagissent. La proximité permet donc d associer un coût à une coopération entre deux caches donnés. La proximité peut donc être de nature très diverse selon les contextes ciblés. Il est à noter qu en général, la proximité n est pas symétrique. Ainsi, ce n est pas parce qu il est intéressant pour un cache Ca de contacter un cache Cb pour résoudre des défauts, qu il est pertinent pourcb de transmettre ses demandes à résoudre àca. La proximité est un concept générique, choisie en fonction du contexte applicatif. Deux types de proximités, également adaptables en fonction de l environnement, peuvent être considérées : la proximité physique et la proximité sémantique. Définition 7.2. Proximité physique Une proximité physique est utilisée pour mesurer entre les caches l efficacité des transferts de données. 107

120 Chapitre 7 : Caches sémantiques coopératifs Définition 7.3. Proximité sémantique Une proximité sémantique est utilisée pour mesurer entre les caches la similarité des demandes qu ils ont servies. La proximité physique caractérise le coût d accès aux éléments. Différents paramètres peuvent ainsi être pris en compte, tels que la bande passante, la latence, les caractéristiques techniques de la machine (processeur, disque, etc.) ou encore la charge sur le cache. La proximité sémantique entre deux caches mesure la similarité entre les demandes servies par ces caches. 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 les caches est plus grande si ils ont des intérêts communs, augmentant la probabilité de succès entre leur cache. Il est important de noter qu en fonction de l application, il est possible de considérer de différentes manières les proximités physique et sémantique. Ceci permet, par exemple, de ne prendre en compte qu une seule des deux caractéristiques, l une ou l autre (coopération avec les caches qui sont proches physiquement ou sémantiquement) ou encore l une et l autre (coopération avec les caches qui sont proches à la fois physiquement et sémantiquement). Nos travaux ne se focalisent pas sur les mécanismes de calcul effectif des mesures de proximité, mais s intéressent plutôt à l utilisation de ce concept pour la coopération entre caches. Des outils comme, par exemple, NDS (Network Distance Service) [GP07], permettant de considérer les caractéristiques des réseaux (bande passante, latence) et les caractéristiques des hôtes (processeur, ressources de calcul ou encore mémoire disponible), peuvent être utilisés pour le calcul de la proximité physique. Cette approche permet en particulier de séparer les préoccupations en délégant l observation à un service dédié. Il est important de noter que le calcul de la proximité a lui-mê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 manière évènementielle. 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 à une même grappe pour la proximité physique, assurant des transferts très efficaces de données entre les caches d une même grappe, et les mêmes centres d intérêt pour la proximité sémantique, augmentant ainsi la probabilité d obtenir un succès sur un cache frère. Exemple 7.5. Soit l environnement illustré par la figure 7.1 et la proximité physique suivante : { 1 si a et b appartiennent à la même grappe proxphy(a,b) = proxphy(b,a) = 0 sinon. Selon cette proximité physique, le cache cl1 est proche des caches cl2 et cl3, puisqu ils appartiennent tous les trois à la grappe de Grenoble. Par contre cl1 n est pas proche physiquement de cl4 et cl5 qui sont situés sur une grappe à Rennes. Exemple 7.6. Soit l environnement illustré par la figure 7.1 et la proximité sémantique suivante : { 1 si ds (a,b) < seuil proxsem(a, b) = proxsem(b, a) = 0 sinon. Selon une proximité sémantique où la distance sémantique d s représente le pourcentage de prédicats communs entre a et b et le seuil est égal à x % (imaginons x égal à 70), le 108

121 7.3 Résolution horizontale basée sur la proximité cache cl1 est proche des caches cl3 et cl4, puisqu ils appartiennent à la communauté des utilisateurs intéressés par les Eucaryotes. Par contre, cl1 n est pas proche sémantiquement de cl2 et cl5 qui travaillent sur les Archées Proximité et protocoles de résolution Le concept de proximité entre caches est orthogonal au protocole de résolution choisi. C est pourquoi, une proximité peut être appliquée à une résolution basée sur une inondation, ou encore à une résolution utilisant un catalogue Proximité et inondation La résolution horizontale par inondation est en général problématique dans des environnements où de nombreux caches sont présents. En effet, lorsqu un défaut se produit sur un cache, il transfert sa demande à tous ses caches frères. Ainsi, les messages transmis sur les réseaux et à traiter par les frères augmentent de manière quadratique avec le nombre de caches. La proximité offre une réponse à ce problème, en instaurant des groupes de caches, ce qui permet de limiter le processus d inondation, et donc la charge sur les réseaux et sur les différents caches. Dans une approche par inondation, la proximité est employée au moment de la propagation de la demande d un cache sur ses frères. Ainsi lorsqu une résolution horizontale a lieu, la requête n est envoyée qu aux frères proches selon la définition choisie. La suite du traitement est similaire à une approche classique. Les frères peuvent considérer les succès exacts, étendus et/ou partiels. Dans ce dernier cas, le demandeur réécrit en fonction de leur réponse la requête restante. Quels que soient les cas de figure considérés, si la requête restante n est pas résolue une fois toutes les réponses reçues (ou après expiration d un minuteur), elle est envoyée aux serveurs Proximité et catalogue La résolution horizontale à l aide d un catalogue nécessite une synchronisation du ou des catalogues en fonction du contenu des caches. Ce processus de synchronisation peut être particulièrement coûteux dans un système où sont présents de nombreux caches, chacun utilisant un catalogue local. La proximité peut alors être utilisée pour instaurer des groupes de caches, chaque cache ne prenant en compte que les modifications du contenu des caches appartenant au même groupe que lui. Ceci permet alors de limiter les interactions entre les caches, et de réduire ainsi à la fois leur charge et la consommation de bande passante. La proximité dans une approche par catalogue est donc utilisée dans le processus de synchronisation des catalogues en fonction du contenu des caches. Ainsi, les changements du contenu d un cache (ajout, suppression ou modification d une entrée) sont envoyés uniquement aux caches appartenant au même groupe, en fonction de la proximité considérée. Comme pour une résolution par catalogue classique, la cohérence des catalogues avec les contenus des caches peut être plus ou moins forte. Il est à noter que la proximité n affecte que la gestion du catalogue. Le processus de résolution reste le même que dans une approche classique : consultation du catalogue pour transmettre la demande aux frères qui 109

122 Chapitre 7 : Caches sémantiques coopératifs sont supposés pouvoir la résoudre et, si nécessaire, résolution auprès des serveurs. 7.4 Cache dual coopératif La proximité est particulièrement intéressante pour les caches sémantiques. Elle permet notamment d instaurer des coopérations entre caches dans le but de minimiser les transferts de données et/ou les évaluations. Néanmoins, dans un cache sémantique classique, une seule proximité (combinant éventuellement les proximités physique et sémantique) peut être utilisée. Le cache dual, en distinguant le calcul et les données, permet de lever cette restriction, autorisant ainsi des coopérations fines entre caches. Ces coopérations permettent à la fois une réduction de la consommation de la bande passante, mais également de la charge d évaluation Coopérations entre caches de requêtes Algorithme 14 Résolution horizontale de défaut pour un cache de requêtes : Req- Cache.GRés.charger(req) Entrées : req : requête Sorties : idobjlist : liste d idenfiants d objets, objlist : liste d objets {Tentative de résolution sur les caches frères} idobjlist frèresrés(req) si idobjlist null alors {succès sur un frère} si idobjlist alors {Récupération des objets sur le cache d objets à l aide de la liste d identifiants} objlist ObjCache.charger(idObjList) sinon objlist finsi sinon {défaut sur les frères} {Résolution auprès des serveurs} (idobjlist,objlist) serveurs.charger(req) finsi retourner (idobjlist,objlist) L algorithme 14 présente la résolution horizontale d un défaut pour un cache de requêtes. Cet algorithme est exécuté en cas d appel de méthode ReqCache.GRés.charger(req). L algorithme présenté est un algorithme général, indépendant du protocole de résolution utilisé. En fait, le choix de la méthode frèresrés détermine le protocole de résolution choisi, celui-ci pouvant être basé sur une approche par inondation ou par catalogue. Quel que soit le protocole employé, en cas de succès, un frère fournit la liste des identifiants d objets correspondants à la requête posée. Le cache de requêtes récupère alors les éléments demandés à l aide de son cache d objets. Il est important de noter que la gestion avec le cache d objets est découplée, les objets demandés n étant pas forcément présents en cache. Si aucun frère ne peut résoudre la requête, les serveurs sont contactés pour récupérer les objets demandés. Un succès sur un cache de requêtes frère peut entraîner un grand nombre de défauts lors de la récupération des éléments sur le cache d objets. Néanmoins, si les ser- 110

123 7.4 Cache dual coopératif veurs offrent des mécanismes d indexation efficaces ou si le cache d objets est également coopératif, il est plus intéressant de payer le coût de cette résolution plutôt que de payer le coût de l évaluation de la requête sur les serveurs. Dans le cas contraire, le cache dual peut proposer un comportement adaptable. En fonction du nombre d objets absents, une résolution des objets absents ou une résolution de la requête posée sera exécutée. Algorithme 15 Résolution par inondation : frèresres(req) Entrées : req : requête Sorties : idobjlist : liste d identifiants d objet {Envoi de la requête aux caches frères} pour i allant de 1 à frères.taille en parallèle faire répfrères[i] frères[i].chercher(req) fin pour tantque ( i [1..frères.taille] tel que répfrères[i] null) (minuteur<expiration) faire {Attente d une réponse positive d un frère ou de l expiration du minuteur} fintantque si minuteur>expiration alors retourner null sinon {Réponse positive d un frère} {Sélection d une réponse parmi les réponses positives des frères} idobjlist choixréppositive(répfrères) retourner idobjlist finsi L algorithme 15 fournit un exemple de méthode frèresrés, qui correspond à une résolution par inondation. Dans un premier temps, la requête est envoyée à tous les caches frères. Il est important de noter que les caches frères sont contactés à l aide de la méthode chercher qui fournit le résultat demandé uniquement s il est présent en cache (ne provoquant pas de résolution en cas d absence). La résolution se met alors en attente d une réponse positive d un frère ou de l expiration d un minuteur. En cas d expiration, une réponse nulle est envoyée, pour provoquer une résolution auprès des serveurs. Dans le cas contraire, une réponse est choisie parmi les réponses positives. Une approche simple consiste à choisir le cache frère de plus petit indice (toutes les réponses positives étant normalement identiques). Les algorithmes présentés précédemment correspondent à une résolution horizontale qui ne prend pas en compte les succès partiels sur les frères. Dans le cas d une intersection sans inclusion, se pose le problème de la vérification de la présence de l objet dans la réponse attendue. En effet, cette vérification ne peut être réalisée qu au niveau des caches d objets. Les algorithmes peuvent néanmoins être dérivés pour considérer les succès partiels pour lesquels les réponses retournées font effectivement partie du résultat final, autrement dit, les cas d inclusion d une entrée dans la requête posée. Il convient alors de recevoir d un cache frère en plus de l ensemble des objets réponses, la requête à laquelle ils correspondent. Le cache demandeur construit alors l ensemble des résultats reçus de ses frères (en supprimant la duplication) et réécrit la requête restante. Une fois toutes les réponses considérées (ou après expiration d un minuteur), la liste est utilisée pour récupérer les objets correspondants sur le cache d objets, alors que la requête restante est envoyée aux serveurs, pour récupérer les objets éventuellement absents. L union des deux ensembles correspond alors au résultat final. 111

124 Chapitre 7 : Caches sémantiques coopératifs 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 taille d une entrée d un cache de requêtes est relativement petite, même si le nombre d identifiants est grand, rendant le temps de transfert d un cache à un autre très faible, même si les caches sont très distants géographiquement ou si le débit de communication est faible. 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, par exemple parce qu ils ont les mêmes centres d intérêts que le cache demandeur. Ces deux arguments nous incitent à utiliser une proximité sémantique pour déterminer les caches frères d un cache de requêtes. A noter que l expression protocole de résolution sémantique pour un cache dual sera utilisée pour caractériser l utilisation par un cache de requêtes d une résolution basée sur la proximité sémantique. Fig. 7.6 Cache dual et protocole de résolution sémantique Exemple 7.7. Soient le cache dual cd1 dans le système d interrogation de données considéré et une résolution horizontale basée sur une proximité sémantique pour le cache de requêtes. Dans ce cas, la résolution d un défaut de requête concerne les caches de requêtes de cr3 et cr4 comme illustré par la figure Coopérations entre cache d objets Algorithme 16 Résolution horizontale de défaut pour un cache d objets : Obj- Cache.GRés.charger(absIdObjList) Entrées : absidobjlist : liste d identifiants d objet Sorties : absobjlist : liste d objets absobjlist frèresrés(absidobjlist) si absidobjlist = null alors {défaut sur les frères} {Résolution auprès des serveurs} absobjlist serveurs.charger(absidobjlist) finsi retourner absobjlist L algorithme 16 présente la résolution horizontale pour un cache d objets, correspondant à l appel de méthode ObjCache.GRés.charger(absIdObjList). Évidemment, cet algorithme n a de sens que pour une gestion découplée entre le cache de requêtes et le cache 112

125 7.4 Cache dual coopératif d objets (dans le cas contraire, le cache d objets n aurait pas à résoudre de défauts). L algorithme présenté ne dépend pas du protocole de résolution utilisé. Celui-ci est capturé dans la méthode frèresrés. En cas de succès (quel que soit le protocole de résolution choisi), un frère transfert les objets requis. Il est à noter qu à la différence d une résolution horizontale pour un cache de requêtes, où un succès sur un frère se traduit par la récupération des objets sur le cache d objets, une réponse positive d un cache d objets frère est suffisante. Ainsi, aucun autre traitement n est ensuite exécuté. Si la résolution ne peut se faire par les frères, les serveurs sont contactés pour récupérer les objets. L algorithme 15 peut de nouveau être utilisé pour mettre en œuvre un protocole de résolution horizontale par inondation (mais dans ce cas, l appel ne se fera pas avec une requête en entrée pour obtenir une liste d identifiants, mais avec une liste d identifiants pour obtenir une liste d objets). Dans les caches coopératifs, un frère ne répond à une demande, que s il peut fournir le résultat sans initier une résolution. Ainsi, par défaut un appel à la méthode chercher sur un cache d objets frère ne retourne une réponse positive que si tous les objets demandés sont présents. Dans le cas contraire, une réponse nulle est obtenue. Algorithme 17 Résolution horizontale de défaut pour un cache d objets, avec prise en compte de réponse partielle : ObjCache.GRés.charger(absIdObjList) Entrées : absidobjlist : liste d identifiants d objet Sorties : abobjlist : liste d objets {Tentative de résolution sur les caches frères} (absobjlist,frèresabsidobjlist) frèresrés(absidobjlist) si frèresabsidobjlist alors {Absence d objets après résolution sur les frères} {Résolution auprès des serveurs} absobjlist absobjlist serveurs.charger(frèresabsidobjlist) finsi retourner absobjlist Une approche plus fine (mais également plus complexe) consiste à considérer également les réponses partielles des caches frères, dans le but de limiter autant que possible le volume de données à récupérer auprès des serveurs. L algorithme 17 présente la résolution horizontale pour un cache d objets correspondant à l appel de méthode ObjCache.résoudre(abs- IdObjList) dans ce cas là. L algorithme présenté ne dépend pas du protocole de résolution utilisé, celui-ci étant capturé dans la méthode frèresrés. L exécution de cette méthode permet à un cache d obtenir l ensemble des objets présents chez ses frères, mais également la liste des identifiants des objets n ayant pu être récupérés. Si cette dernière liste n est pas vide, elle est soumise aux serveurs pour compléter le résultat. L algorithme 18 fournit un exemple de méthode frèresrés, qui correspond à une résolution par inondation avec prise en compte de réponses partielles des frères. Pour commencer, la liste des identifiants est envoyée à tous les frères. Contrairement à une approche classique, la méthode chercher permet de récupérer l ensemble des objets présents, ainsi que la liste des identifiants correspondants aux objets absents des caches frères. La résolution est alors en attente d une réponse complète d un frère, des réponses de tous les frères ou de l expiration d un minuteur. Si une réponse complète est obtenue, elle est utilisée comme résultat. En cas de multiple réponses complètes, une approche simple consiste à choisir le cache frère de plus petit indice. Si aucune réponse complète n est obtenue, alors le résultat est construit à l aide des réponses partielles, qui permettent de mettre à jour 113

126 Chapitre 7 : Caches sémantiques coopératifs Algorithme 18 Résolution par inondation avec prise en compte de réponses partielles : frèresres(absidobjlist) Entrées : absidobjlist : liste des identifiants d objet Sorties : absobjlist : liste d objets, frèresabsidobjlist : liste d identifiants d objet {Envoi de la requête aux caches frères} pour i allant de 1 à frères.taille en parallèle faire répfrères[i] frères[i].chercher(req) fin pour tantque ( i [1..frères.taille] tel que exacte(répfrères[i])) (minuteur<expiration) ( i [1..frères.taille] tel que attente(répfrères[i])) faire {Attente d une réponse complète d un frère, de toutes les réponses ou de l expiration du minuteur} fintantque si i [1..frères.taille] tel que exacte(répfrères[i] alors {Sélection d une réponse parmi les réponses complètes des frères} absobjlist choixrépcomplète(répfrères) retourner (objlist, ) sinon {Construction du résultat à l aide des réponses partiels} absobjlist frèresabsidobjlist absidobjlist pour i allant de 1 à frères.taille en parallèle faire si (répfrères[i] null) attente(répfrères[i]) alors absobjlist absobjlist répfrères[i].objlist frèresabsidobjlist frèresabsidobjlist \ répfrères[i].idobjlist finsi fin pour retourner (absobjlist,frèresabsidobjlist) finsi la liste des objets obtenus, ainsi que la liste des identifiants des objets absents. Ces deux listes constitueront alors le résultat final. L utilisation de plusieurs réponses partielles peut bien sûr conduire à une réponse complète, le construction du résultat menant ainsi à un ensemble vide pour la liste des identifiants absents sur les frères (frèresabsidobjlist). L objectif principal d un cache d objets est de limiter les transferts de données. Par conséquent, ses 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. L expression protocole de résolution physique pour un cache dual référencera l emploi par un cache d objets d une résolution basée sur la proximité physique. Exemple 7.8. Soient le cache dual cd1 dans le système d interrogation de données considéré et une résolution horizontale basée sur une proximité physique pour le cache d objets. Dans ce cas, la résolution d un défaut d objets concerne les caches d objets de co2 et co3 comme illustré par la figure 7.7. Il est important de remarquer que la flexibilité du cache dual permet d utiliser conjointement un protocole de résolution physique et un protocole de résolution sémantique. Dans ce cas, nous parlerons de protocole de résolution physique et sémantique pour un 114

127 7.5 Conclusion Fig. 7.7 Cache dual et protocole de résolution physique cache dual. Il convient également de noter que nous appellerons protocole de résolution basique, le protocole où les défauts de requêtes et d objets sont résolus directement par les serveurs. 7.5 Conclusion Ce chapitre a présenté nos travaux sur la coopération entre caches sémantiques. Nous avons, dans un premier temps, étudié le concept de cache sémantique coopératif. Nous nous sommes ensuite intéressés à la notion de proximité dans les protocoles de résolution horizontale. Finalement, nous avons proposé le cache dual coopératif. Le cache sémantique coopératif permet une meilleure distribution de la charge de travail et la réduction des transferts de données entre les sources de données et les différents sites clients. En effet, une optimisation de l utilisation des ressources locales provient de la gestion sémantique du cache, alors que la coopération permet un partage des ressources, particulièrement intéressant pour un très grand nombre de caches. Nous proposons la notion générique de proximité. Ce concept est utilisé pour faciliter la mise en place de coopérations intéressantes entre caches. Ces coopérations peuvent se baser sur différents critères. Il est ainsi possible de prendre en compte des caractéristiques physiques, à l image de la charge sur les caches, de leur localisation ou encore des débits de communication entre eux. Des propriétés plus sémantiques peuvent également être considérées, en particulier les centres d intérêt des clients. La proximité autorise alors un regroupement pertinent et éventuellement dynamique des caches, permettant de créer des réseaux basés sur des topologies physiques et/ou logiques. Le cache dual coopératif s appuie sur cette notion de proximité pour optimiser les stratégies de coopération en fonction des types de caches considérés et de leur environnement. L utilisation de deux caches distincts, un cache de requêtes et un cache d objets, autorise une configuration fine de la stratégie de coopération pour améliorer à la fois le transfert de données, en utilisant une coopération pour les objets, et l évaluation de requêtes, en intégrant des interactions pour les requêtes. Le cache dual coopératif réduit alors le temps d évaluation, puisqu il maximise le partage de calculs entre caches de requêtes et répartit le volume de données transférées, limitant les communications externes en instaurant une coopération entre caches d objets d une même organisation. Dans 115

128 Chapitre 7 : Caches sémantiques coopératifs les expérimentations réalisées au sein d un intergiciel de gestion de données sur grilles présentées dans le chapitre 8, l utilisation d un cache dual coopératif utilisant un protocole physique et sémantique a permis d obtenir des temps de réponses cinq fois inférieurs à ceux obtenus avec un cache dual sans coopérations, grâce à une réduction d un facteur trois du volume de données transférées et une charge d évaluation sur les serveurs divisée par quatre. Ce chapitre marque la fin de la partie présentant nos propositions. Le chapitre 8 s intéresse à la validation de nos travaux. Il présente d abord un prototype du canevas ACS pour la construction de caches adaptables. Ensuite nos propositions sont évaluées dans un intergiciel pour la gestion de données sur grille, appliqué à la bio-informatique. 116

129 Troisième partie Mise en œuvre des propositions et validations 117

130

131 Chapitre 8 Validations dans un intergiciel pour la gestion de données bio-informatiques Les chapitres précédents ont présenté nos différentes propositions. Nous avons d abord introduit ACS, un canevas pour la construction de caches adaptables. Puis, nous avons proposé un nouveau type de cache sémantique, appelé cache dual. Enfin, nous nous sommes intéressés aux caches sémantiques coopératifs. Ce chapitre a pour objectif de présenter le prototype du canevas ACS pour la construction de caches adaptables et les expérimentations que nous avons menées pour valider nos propositions. Ce chapitre est organisé de la manière suivante. La section 8.1 décrit le prototype d ACS que nous avons implanté, en illustrant son utilisation dans une application de surveillance réseau. La suite de ce chapitre vise à valider l ensemble de nos propositions au sein d un intergiciel de gestion de données sur grille, appliqué à la recherche en bio-informatique. La section 8.2 présente le contexte d expérimentation. La section 8.3 s intéresse à la validation d ACS. La section 8.4 se focalise sur les outils utilisés pour évaluer les performances de nos propositions. Les sections 8.5 et 8.6 présentent, respectivement, les résultats des évaluations de performance pour le cache dual et les caches sémantiques coopératifs. Enfin, la section 8.7 conclut ce chapitre. 8.1 Prototype d ACS Un prototype du canevas ACS pour la construction de caches adaptables a été implanté à l aide de Julia, la version Java du modèle à composants Fractal [BCL + 04]. Bien que ce choix ait été influencé par l existence de Perseus et plus particulièrement des composants proposés pour la création de caches, d autres arguments nous ont confortés dans cette approche. Le modèle à composants Fractal présente des propriétés d introspection, de réflexivité, mais surtout dans notre cas, d adaptabilité dynamique. Nous avons choisi d utiliser une version Java pour plusieurs raisons. La première est la facilité de prototypage. Avec son approche objet et son typage fort, Java offre un outil de programmation qui facilite la construction de prototypes. L environnement Java fournit, en plus, de nombreuses classes prédéfinies encapsulant des fonctionnalités utiles comme l introspection des 119

132 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques objets, la communication à distance, etc. La seconde raison est la facilité d utilisation sur différentes plates-formes. Une caractéristique intéressante de Java, qui est à la base de sa popularité, est sa machine virtuelle permettant l exécution de programmes Java sur des plates-formes hétérogènes. En effet, la construction d ACS en Java nous a permis de faire abstraction des systèmes d exploitation et des capacités des plates-formes. Nous avons pu l utiliser aussi bien sur des machines de bureau que sur des nœuds d une grille. A noter que les différentes classes proposées sont compatibles jdk Architecture du canevas Le canevas de caches repose sur un ensemble d interfaces correspondant aux composants pouvant intervenir dans un cache. Nous avons distingué trois niveaux de composants pour un cache : les fonctionnalités minimales d un cache, les fonctionnalités optionnelles et les fonctionnalités gérées par des services externes au cache. Dans la version actuelle d ACS, seules les fonctionnalités minimales et optionnelles d un cache sont considérées, les fonctionnalités optionnelles étant également limitées à la gestion de la sémantique et de l admission. Le canevas correspond à un ensemble d interfaces. Chaque interface permet de caractériser les méthodes devant être fournies par un composant souhaitant assurer une fonctionnalité donnée. Par exemple, l interface d un gestionnaire de résolution contient une unique méthode load, prenant en entrée un identifiant et retournant comme résultat l objet associé. Les interfaces proposées au sein d ACS sont CacheManager, ContentManager, ReplacementManager, ResolutionManager, AdmissionManager, QueryAnalyser, Query- Evaluator Bibliothèque de composants En plus de fournir un canevas, ACS propose une bibliothèque de composants, pouvant être utilisés pour la construction de caches adaptables. Les composants proposés sont génériques, évitant de considérer les types particuliers des données manipulées. Des composants sont, ainsi, proposés pour la gestion du contenu, du remplacement, de la résolution ou encore de l admission. Trois composants sont proposés pour gérer le contenu d un cache. Les deux premiers, utilisés pour des caches d objets classiques, diffèrent au niveau de la structure de données utilisée. Alors que VectorContentManager gère le contenu à l aide d un vecteur d objet, HashTableContentManager utilise une table de hachage. Le troisième composant, PredicateObjectContentManager, permet de mettre en œuvre un cache de prédicats et d objets [KB96] (à noter qu à ce niveau la gestion sémantique n est pas considérée). Ainsi, les entrées sont manipulées en terme de résultats de requêtes, alors que le stockage se fait à la granularité des objets, évitant ainsi la duplication d un même objet au sein du cache. Différentes politiques de remplacement peuvent être mises en œuvre à l aide des composants fournis par la bibliothèque. Ainsi, pour un cache d objets classique, les composants LRUReplacementManager, MRUReplacementManager, FIFOReplacementManager et LIFOReplacementManager autorisent respectivement l utilisation des politiques de remplacement LRU, MRU, FIFO et LIFO. Ces politiques sont également proposées pour des 120

133 8.1 Prototype d ACS caches de prédicats et d objets dans des composants spécifiques : PredicateObjectLRUReplacementManager, PredicateObjectMRUReplacementManager, PredicateObjectFIFO- ReplacementManager et PredicateObjectLIFOReplacementManager. En effet, pour ce type de cache, le remplacement est spécifique, puisque le choix de la victime du remplacement se fait en terme de requêtes, alors que la place est libérée en terme d objets (les objets de la requête victime du remplacement non référencés par d autres requêtes présentes en cache). En ce qui concerne la résolution, divers protocoles sont proposés. Le composant Parent- ResolutionManager permet d instaurer une résolution verticale, une demande étant alors résolue par un autre cache créé par ACS (ou respectant la spécification du canevas). Les composants FloodingResolutionManager et CatalogueResolutionManager permettent de construire des caches avec résolution horizontale basée sur des protocoles par inondation ou par catalogue. Il est important de noter que la bibliothèque fournit un composant BasicCacheManager, qui propose un gestionnaire de cache simple. Ce composant propose une prise en compte uniquement des succès exacts pour les deux possibilités d accès évoquées dans le chapitre 5, charger et chercher distinguant les demandes nécessitant ou non une résolution de défaut. La bibliothèque propose également le composant SizeAdmissionManager, qui met en place une politique d admission basée sur la taille des éléments, pour qu un élément de trop grande taille ne soit pas placé en cache Utilisation dans un logiciel de sécurité réseau Le contexte applicatif étudié nous place dans un cas d accès à des masses de données utilisées pour détecter des problèmes de sécurité sur des réseaux informatiques. L utilisation de caches, pour ce contexte, vise principalement à réduire les accès aux bases gérant les données issues du trafic réseau. Ces accès peuvent en effet être coûteux pour de gros volumes d informations. Si nous considérons les besoins des utilisateurs en terme d interrogation à l aide de successions de requêtes de plus en plus précises, il est pertinent de proposer un cache sémantique pour une meilleure exploitation des données Contexte expérimental EXTRA (External Traffic Analyser) [ext] est un outil de surveillance réseau basé sur l analyse de la journalisation des routeurs des différents sites de l IN2P3 (Institut National de Physique Nucléaire et de Physique des Particules). Cet outil, développé en Java, permet de récupérer et stocker les journaux des routeurs, ou éventuellement les résultats de sondes. Il est alors possible de surveiller finement le trafic, à partir d un navigateur Internet et notamment de détecter des trafics réseaux anormalement importants, pouvant être la conséquence d une intrusion dans le système. L analyse fine du trafic vise à déterminer la source de l attaque en cas d intrusion et la détection de propagation de vers. Les fonctions de base d EXTRA sont la collecte des journaux des routeurs, leur stockage dans une base de données, ainsi que l application de traitements systématiques (appelés prétraitement) calculant à l avance des requêtes pertinentes pour les administrateurs (permettant d accélérer l interrogation). L application fournit également une interface graphique 121

134 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques d analyse, permettant de présenter les résultats des analyses sous forme de graphiques, en général des diagrammes en bâtons. EXTRA possède une carte réseau dédiée à la collecte des journaux. Celle-ci met en œuvre un renifleur (sniffer) qui écoute le réseau sur un port en duplication du trafic entrant dans le site. Dans le cas d un sous-réseau mettant en œuvre une translation d adresses dynamique, (NAT ou Network Address Translation), il est possible d ajouter un renifleur sur ce sous-réseau afin d être à même de visualiser les adresses avant la translation. Un collecteur reçoit les flots réseaux et effectue des permutations sur les adresses IP sources et IP destinations pour les remplacer par des adresses IP internes et IP externes. Pour cela, il utilise l information fournie par un logiciel spécifique qui donne la liste des réseaux internes du laboratoire. Une fois les données reçues, le collecteur effectue l insertion des flux dans la table de la base de données pour le jour considéré. Identifier Machine interne Machine externe Sequence Port Interne Port Externe Protocole Volume Trafic I O I O Tab. 8.1 Format de la table jour La base de données, gérée à l aide de MySQL, fournit les tables nécessaires à l enregistrement des journaux (tables jour), à la gestion des pré-traitements (tables t^ache) et au stockage des résultats des pré-traitements (table pttrafic). Par défaut, EXTRA conserve les traces des trois derniers mois dans sa base de données. Dans le cas d utilisation qui nous intéresse, seule la table jour est considérée, c est pourquoi, le format des autres tables ne sera pas détaillé. La table jour (day) contient les journaux de la journée. Le tableau 8.1 illustre le format de la table jour et notamment les différents attributs sur lesquels peuvent porter les interrogations, comme par exemple les adresses IP interne (inta, intb, intc, intd) et externe (exta, extb, extc, extd) des machines qui communiquent ou le numéro de séquence correspondant à la date et à l heure du flux, les ports interne et externe. La base de données d EXTRA peut être interrogée directement à l aide de scripts SQL. Ce type d accès est réservé aux procédures centralisées de détection de signatures d attaque (virus) et de centralisation des traces pour un archivage conforme à la durée règlementaire d un an. Il existe deux types de requêtes. Premièrement, des requêtes systématiques planifiées régulièrement, un logiciel dédié permettant de définir les scripts, les laboratoires et la fréquence pour l interrogation. Deuxièmement, des requêtes envoyées à la demande sur un ensemble ou la totalité des machines de l IN2P3 sur lesquelles EXTRA est installé. Elles permettent aux coordinateurs de sécurité de rechercher rapidement le trafic vers une adresse IP suspecte ou vers certains services vulnérables en cas d alerte. Le caractère interactif de ces dernières requêtes rend l emploi d un cache particulièrement intéressant, afin de réduire le temps d attente perçu par l utilisateur Choix des composants La première étape du processus de création d un cache consiste à déterminer les composants offerts par ACS pouvant être réutilisés, afin de minimiser le coût de développement. Dans le cas d un cache pour EXTRA, nous avons choisi d utiliser des stratégies classiques 122

135 8.1 Prototype d ACS de stockage et de remplacement, à savoir une table de hachage comme structure de données, et une politique de remplacement LRU. C est pourquoi, nous avons utilisé les composants HashTableContentManager et LRUReplacementManager Création des composants Une fois les composants de la bibliothèque choisis, il est nécessaire de développer les composants pour les fonctionnalités du cache à créer qui ne sont pas encore prises en compte. Dans le cas d un cache pour le logiciel EXTRA, il a été nécessaire de créer un gestionnaire de résolution, mais également un analyseur de requ^etes et un évaluateur de requ^etes. La gestion de la sémantique sera étudiée en détail dans le cadre de l intergiciel de gestion de données sur grille. C est pourquoi, nous ne nous attarderons pas ici sur cet aspect. Le développement d un composant pour ACS contient deux étapes principales. La première étape est l implantation des méthodes permettant de mettre en œuvre le modèle à composant Fractal. Ceci autorise la gestion des liaisons avec les autres composants, d un point de vue générique, permettant de coupler le composant créé à n importe quel composant utilisé respectant la spécification des interfaces. L implantation du modèle est également nécessaire pour la gestion du cycle de vie, qui permettra d adapter dynamiquement le cache créé. La deuxième étape correspond à l implantation des méthodes du composant permettant de mettre en œuvre la stratégie souhaitée. Par exemple, dans le cas d un gestionnaire de résolution pour EXTRA, l implantation de la méthode charger doit permettre de contacter un système de gestion de bases de données MySQL. Ainsi, le gestionnaire de résolution proposé intègre les informations pour permettre l interrogation à l aide de JDBC du système de gestion de bases de données, en particulier l indentifiant et le mot de passe pour la connexion. Le gestionnaire de résolution parcourt ensuite le «ResultSet»obtenu pour le stocker dans une structure de données. Pour le cache proposé, nous avons représenté un n-uplet sous forme d un vecteur d attributs, et la réponse à une requête sous forme de vecteur de n-uplets Création d un cache BasicCacheManager cachem=new BasicCacheManager(); HashTableContentManager contm=new HashTableContentManager(); contm.setmaxsize( ); ExtraResolutionManager resm=new ExtraResolutionManager(); cachem.bindfc("contentmanager",contm); cachem.bindfc("resolutionmanager",resm); cachem.bindfc("queryanalyser",queryana); cachem.bindfc("queryevaluator",queryeval); Fig. 8.1 Création de lien et paramétrisation de composant Une fois les composants sélectionnés et, si nécessaire, développés, le processus de création est très simple. Il convient en effet d assurer les liaisons entre les différents com- 123

136 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques posants. Les liaisons peuvent être codées en dur dans des classes, mais peuvent également être mises en place à l aide d outils existants, notamment l ADL de fractal. La figure 8.1 donne une illustration de code permettant la création des liaisons entre composants dans le cas d un cache sémantique pour le logiciel EXTRA. Le BasicCacheManager est lié au HashTableContentManager, au EXTRAResolutionManager, au QueryAnalyser et au QueryEvaluator que nous avons créés. En plus de la phase de création de liens, une phase de configuration des paramètres peut être nécessaire. Dans le cas d un cache, un paramètre important est la taille du cache, à configurer dans le composant HashTableContentManager, comme illustré par l instruction contm.setmaxsize( ) dans la figure 8.1. Il est important de noter que pour la création de ce type de cache pour EXTRA, moins de 10 % du code fonctionnel a été produit, correspondant au développement d un gestionnaire de résolution spécifique. Une fois le cache créé, il est utilisé comme point d entrée de l application à l aide de la méthode charger du gestionnaire de cache, ou éventuellement de la méthode chercher pour des caches frères. 8.2 Contexte d expérimentation Nos travaux se situent au sein du projet Gedeon, dans un contexte d accès à des masses d informations, et notamment dans des applications en bio-informatique 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 est 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. La forte distribution des données, ainsi que la présence de nombreux caches au sein du système rend pertinente l utilisation de caches coopératifs. Pour la recherche d information, les biologistes accèdent au contenu de fichiers plats de très grande taille à l aide de requêtes successives sémantiquement proches. Par conséquent, des caches sémantiques sont requis pour exploiter aux mieux les données placées en cache. Les caches sont déployés au sein d une architecture spécialisée et pilotée par un intergiciel de gestion de données Aspect logiciel, intergiciel Gedeon Gedeon [VJd + 06, ged] est un intergiciel de gestion de données dédié aux grilles légères. Nous référençons par le terme de «grille légère», une grille composée d un nombre restreint de nœuds sur lesquels des non spécialistes veulent déployer facilement une solution d accès à une masse de données distribuées. Cet intergiciel 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 sur les méta-données (couples attribut-valeur) reste inaccessible 124

137 8.2 Contexte d expérimentation 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 système de gestion de bases de données requiert une structuration forte des données. Plus encore, la complexité de déploiement d un tel système, et donc par extension d un système 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 fichiers à la notion d enregistrement, afin de pouvoir manipuler ces enregistrements en fonction de leurs méta-données associées et de les accéder à travers une grille. Un enregistrement est constitué de toutes les méta-données d une donnée et de la donnée elle-même ou d un pointeur vers cette dernière. Gedeon repose sur une indexation distribuée des données par un ensemble pertinent de méta-données. 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 caches. De nouveaux modules peuvent ainsi être connectés et/ou remplacer d autres modules. Les expériences utilisent comme support la banque biologique de séquences de protéines Swiss-Prot [BBA + 03, swi]. Cette source d informations 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ée en entrée de nombreuses applications de traitement. Cette banque de données est un fichier de 750Mo contenant environ enregistrements. Un enregistrement se compose d une séquence de protéines et de ses annotations (comme illustré dans le chapitre 6. 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 utilisateurs (version ad-hoc de Swiss-Prot). 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 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 grappes de divers sites ont été utilisés. Les caractéristiques des nœuds de chaque site sont données par le tableau 8.2. Pour toutes les grappes, l interconnexion à l intérieur d un site correspond à de l ethernet 1Gbit/s. Les sites sont connectés par des réseaux longue distance à 10Gbit/s. Pour nos expérimentations, deux types d architecture ont été utilisés. La première architecture, appelée serveur simple, correspond à une architecture client-serveur classique. Les clients interrogent une machine qui gère l intégralité de la source de données. 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. 125

138 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques Site Machine Processeur Mémoire Disque Lille IBM eserver 326 AMD Opteron 248 4GB SATA 2.2Ghz Nancy HP ProLiant 2x AMD Opteron 246 2GB SATA DL145G2 2.0GHz Rennes Sun Fire V20z 2x AMD Opteron 248 2GB SCSI 2.2GHz Sophia-Antipolis Sun Fire X4100 2x dual core AMD Opteron 4GB SAS GHz Toulouse Sun Fire V20z AMD Opteron 248 2GB SCSI 2.2Ghz Tab. 8.2 Caractéristiques des nœuds de Grid5000 utilisés pour les expérimentations Fig. 8.2 Union de serveurs L architecture à union de serveurs, illustrée par la figure 8.2, 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 par 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 et indépendante, la fragmentation horizontale évitant les interactions avec les autres serveurs. 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 ce type d architecture sont quasiment proportionnels au nombre de nœuds utilisés [VJd + 06]. Nous avons également proposé des scripts pour faciliter la mise en place d expérimentations multi-échelles. Les scripts proposés se basent sur les outils fournis dans Grid5000 pour la gestion des nœuds réservés sur différents sites. Ainsi, à la suite d une demande de réservation de machines sur Grid5000, les scripts assurent le déploiement de caches sur ces machines (choix d un type de cache, configuration de la taille) ainsi que le choix et l exécution de la charge de travail, que ce soit en terme de localité sémantique, de l ensemble ou du nombre de requêtes (voir la sous-section 8.4.1). Les scripts sont également employés pour instaurer les coopérations entre caches en fonction des proximités considérées. Ce dernier point sera développé dans la sous-section Validation d ACS L objectif de cette partie est de valider notre canevas de caches adaptables ACS. La validation d ACS est présentée en terme de facilité de construction de caches. Il est im- 126

139 8.3 Validation d ACS portant de noter que les différents caches créés sont tous des caches mémoires, l étude des performances des caches disques devant faire l objet d autres travaux de recherche. Nous présentons, dans un premier temps, un cache élémentaire. L expression «cache élémentaire»se réfère ici à un cache de résultats de requêtes pour lequel la gestion de la sémantique n est pas considérée. Autrement dit, ce type de cache ne prend en compte que les succès exacts. Ensuite, sont présentés des caches sémantiques, puis des caches coopératifs. Les différents caches créés seront ensuite utilisés, d une part, pour montrer l intérêt des caches sémantiques et des caches coopératifs dans un système d interrogation de sources de données largement réparties et d autre part, pour valider le cache dual et les caches sémantiques coopératifs utilisant le concept de proximité Mise en œuvre de caches élémentaires Fig. 8.3 Création d un cache élémentaire pour Gedeon avec ACS La création d un cache élémentaire pour l intergiciel Gedeon appliqué à la gestion de données bio-informatiques est illustrée par la figure 8.3. Nous avons choisi des stratégies connues et efficaces. Ainsi, pour le remplacement, la politique LRU a été utilisée et le contenu du cache est géré à l aide d une table de hachage. Puisque le canevas ACS propose des composants de remplacement et de recherche basés sur ces stratégies, aucun développement supplémentaire n a été nécessaire pour ces aspects. En fait, l essentiel du développement s est axé autour de la résolution et de la gestion des réponses d un serveur. En effet, dans notre contexte applicatif, les données sont envoyées par les serveurs sous forme de flux structurés. Nous avons donc proposé un gestionnaire de résolution spécifique permettant de manipuler un flux. La taille du résultat d une requête pouvant excéder la taille de la mémoire, nous avons eu recours à un gestionnaire d admission basé sur la taille des entrées. Ce dernier permet, non seulement, de vérifier qu un résultat peut être gardé en cache, mais également, de prévenir un éventuel débordement de mémoire. C est pourquoi, le gestionnaire de cache, en plus d analyser le flux de données, vérifie que le résultat de la requête peut être mis en cache à chaque enregistrement, et non pas à l obtention du résultat complet de la requête. Ainsi, si la taille du résultat est supérieure au seuil du gestionnaire d admission, les enregistrements sont directement transférés au client sans être stockés. Bien sûr, la vérification de la taille de la réponse à la réception de chaque enregistrement peut se révéler relativement coûteuse. Dans ce cas, elle peut être remplacée par une stratégie réduisant le nombre de vérifications, périodiquement tous les n enregistrements. Le choix de n dépendra de la taille des enregistrements et des ressources offertes au cache. A noter que l approche générique des composants fournis par la bibliothèque, notamment le gestionnaire de contenu, permet de ne pas se préoccuper du type d entrées manipulées. Au total, le code fonctionnel créé pour ce cache ne représente 127

140 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques que 12 % du code du cache final. Autrement dit, 88 % du code du cache simple proposé pour cette application proviennent de la réutilisation de composants de la bibliothèque d ACS Mise en œuvre de caches sémantiques Dans le contexte applicatif ciblé, les séquences d accès des utilisateurs présentent une forte localité sémantique. C est pourquoi, il est pertinent d avoir recours à des caches sémantiques. Dans cette section, nous présentons la mise en œuvre de caches sémantiques à l aide du canevas ACS. Dans un premier temps, nous présenterons les outils d analyse et d évaluation qui seront partagés par les différents caches sémantiques. Ensuite, nous détaillerons la construction des caches sémantiques à l aide du canevas ACS : le cache de résultats de requêtes, le cache de prédicats et d objets et le cache dual Gestion de la sémantique Suite à nos discussions avec des bio-informaticiens, nous avons proposé, dans un premier temps, des caches sémantiques simples, ne considérant que les sélections. Ainsi, l analyseur de requ^etes et l évaluateur de requ^etes que nous présentons dans cette section ne prennent en compte que cette opération. L étude d autres opérateurs fera l objet de recherches futures. Analyseur de requêtes L analyseur de requ^etes que nous proposons permet de confronter les requêtes posées par les utilisateurs aux prédicats gardés en cache. Nous rappelons que les requêtes que nous considérons correspondent à des sélections, formées uniquement de conjonctions. Pour nos expérimentations, nous avons considéré uniquement les cas de succès étendus correspondants à une équivalence ou à l inclusion d une requête dans une entrée. Ces cas de recouvrement sont particulièrement intéressants, puisqu ils permettent d obtenir un résultat en utilisant une unique entrée du cache, minimisant ainsi le coût de l évaluation. L équivalence est, bien sûr, le cas le plus intéressant, puisqu aucune évaluation n est nécessaire et que le parcours d analyse est interrompu à la première entrée pouvant être utilisée. Dans le cas de l inclusion, nous avons opté pour un parcours complet, afin de travailler sur l entrée de plus petite taille incluant la requête posée et ainsi minimiser le processus d évaluation. Il est important de noter que seuls des cas simples d équivalence et d inclusion sont considérés, réduisant ainsi le coût de l analyse des requêtes. Ainsi, deux requêtes sont équivalentes pour l analyseur de requ^etes uniquement si elles sont composées du même ensemble de termes. Exemple 8.1. L analyseur de requ^etes proposé permet de détecter que les requêtes Eucaryote OC Alveolate OC et Alveolate OC Eucaryote OC sont équivalentes. Exemple 8.2. L analyseur de requ^etes proposé ne permet pas de détecter que les requêtes DT > 2006 DT < 2008 et DT = 2007 sont équivalentes. 128

141 8.3 Validation d ACS Du point de vue de l inclusion d une requête dans une entrée, l analyseur de requ^etes utilisé se base uniquement sur l ajout de termes. Ainsi, une requête q1 contient une requête q2, si tous les termes de q1 sont présents dans q2. Les autres types d inclusions ne sont pas pris en compte par cet analyseur de requ^etes. Exemple 8.3. L analyseur de requ^etes proposé permet de détecter que la requête Eucaryote OC contient la requête Eucaryote OC Alveolate OC. Exemple 8.4. L analyseur de requ^etes proposé ne permet pas de détecter que la requête DT > 2005 contient la requête DT > Pour réaliser l analyse de requêtes, nous avons proposé une transformation des requêtes en vecteurs de bits. Une entrée d un cache est alors identifiée par un vecteur de bits. L objectif de cette transformation est de fournir un processus de recherche au sein du cache plus efficace, la comparaison 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). Le processus de transformation repose sur une table de correspondance dynamique entre un terme de sélection et un indice de vecteur, les associations étant mises à jour si nécessaire. Lorsqu une requête est posée, elle est décomposée en fonction des conjonctions, pour n avoir que des termes primitifs de la forme : attribut opération valeur. Chaque terme est ensuite recherché au sein de la table de conversion. S il n est pas représenté, il est associé au premier indice disponible. Ainsi, pour un cache à froid, les termes de la requête correspondront aux premiers indices. Lorsqu une requête est supprimée du cache, tous ses termes qui ne sont référencés par aucune autre requête du cache sont supprimés pour libérer des indices. Il est important de remarquer que deux indices consécutifs sont attribués à un terme au moment d une conversion : un indice pour le terme lui-même et un indice pour sa négation. Ceci permet de distinguer l absence d un terme et sa négation. Il faut bien évidemment prévoir un nombre suffisant d indices, le nombre d indices étant en général dépendant du nombre (et de la complexité) des requêtes pouvant être gardées en cache. Cette approche s inspire des travaux sur les signatures dans les caches sémantiques [CB98, CB00], tout en présentant certaines différences, en particulier l association dynamique d un indice à un terme. Exemple 8.5. Dans le cas d un cache froid et d une table de conversion correspondant par défaut à un vecteur de bits de taille 10, la requête Eucaryote OC Alveolate OC est transformée en vecteur , où l indice 0 correspond à Eucaryote OC et l indice 2 à Alveolate OC ( (Eukaryote OC) et (Alveolate OC) étant respectivement associés aux indices 1 et 3). Avec l analyseur de requ^etes considéré, l utilisation de vecteur de bits permet de détecter efficacement que deux requêtes sont équivalentes, puisque leurs vecteurs de bits sont alors identiques. Exemple 8.6. Soient les indices de la table de conversion 0 et 2 respectivement associés aux termes de sélection Eucaryote OC et Alveolate OC. Dans ce cas, l analyseur de requ^etes utilisé permet de détecter l équivalence entre les requêtes Eucaryote OC Alveolate OC et Alveolate OC Eucaryote OC puisqu elles correspondent au même vecteur de bits, le vecteur Les vecteurs de bits sont aussi pertinents pour détecter les inclusions de requêtes issues de raffinement à l aide de sélections supplémentaires. En effet, l inclusion d un vecteur 129

142 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques associé à une requête q2 dans un vecteur correspondant à une requête q1 est détectée si tous les bits ayant la valeur 1 dans q1 ont également la valeur 1 dans q2. Exemple 8.7. Soient les indices de la table de conversion 0 et 2 respectivement associés aux termes de sélection Eucaryote OC et Alveolate OC. Dans ce cas, l analyseur de requ^etes utilisé permet de détecter l inclusion de la requête Eucaryote OC Alveolate OC dans la requête Eucaryote OC puisqu elles correspondent respectivement aux vecteurs de bits et (tous les bits ayant la valeur 1 dans la première requête ont également la valeur 1 dans la seconde). Évaluateur de requêtes L évaluateur de requ^etes employé autorise l application de prédicats de sélection sur les entrées du cache. Pour le système d interrogation de sources de données bioinformatiques, nous avons réutilisé la brique d évaluation fournie par l intergiciel Gedeon. Le développement de l évaluateur de requ^etes a donc été très peu coûteux, l essentiel du code visant à assurer la liaison entre l intergiciel, codé en C, et le cache développé en Java. Afin de gérer l hétérogénéité, nous avons opté pour des appels système Gestion des régions sémantiques Afin de comparer le cache dual, le cache de résultats de requêtes et le cache de prédicats et d objets, nous avons créé des instances de ces différents caches à l aide du canevas ACS. L objectif étant de focaliser la comparaison sur la gestion des régions sémantiques, les configurations des caches pour les autres caractéristiques sont équivalentes. Le protocole de résolution correspond à un transfert des requêtes aux sources de données. La politique de remplacement utilisée est la politique LRU. La structure de données employée est une table de hachage. En utilisant la bibliothèque d ACS et le gestionnaire de résolution développé pour le cache élémentaire, la création d un cache sémantique de résultats de requêtes reprenant les principes présentés dans [CB98] ne nécessite que l implantation d un gestionnaire de cache spécifique. Ce gestionnaire de cache permet, premièrement, de vérifier l admissibilité d un résultat de requêtes à l aide d un gestionnaire d admission vérifiant la taille d un résultat de requêtes. Il intègre également la gestion de la sémantique pour considérer les succès étendus provenant d une équivalence entre une requête posée et une entrée ou une inclusion d une requête dans une entrée. Au final, seuls 19 % du code final ont été produits spécifiquement pour ce cache sémantique, soit 81 % de code réutilisés à l aide d ACS. Pour la création d un cache sémantique de prédicats et d objets reprenant la spécification proposée par [KB96], aucun code fonctionnel supplémentaire n est nécessaire. D une part, la bibliothèque d ACS fournit un gestionnaire de contenu permettant de gérer des entrées en terme de prédicats et d objets, ainsi qu un gestionnaire de remplacement appliquant une politique LRU pour ce type de cache. D autre part, le gestionnaire de résolution et le gestionnaire de cache employés par le cache de résultats de requêtes peuvent être réutilisés. Par conséquent, le développement d un cache sémantique de prédicats et d objets se focalise sur la mise en place des liaisons entre les différents composants. 130

143 8.3 Validation d ACS La création d un cache dual repose sur la construction d un cache de requêtes et d un cache d objets. Des composants spécifiques sont alors nécessaires, en particulier pour gérer la coopération entre les deux caches. Nous avons, dans un premier temps, développé un gestionnaire de résolution pour le cache d objets, permettant de récupérer des objets via leur identifiant. La coopération entre le cache de requêtes et le cache d objets est ensuite capturée au sein de leur gestionnaire de cache respectif. Le gestionnaire de cache du cache d objets offre la possibilité au gestionnaire de cache du cache de requêtes d accéder à des objets (méthodes charger ou chargeretévaluer) en cas de succès exacts ou étendus pour une requête posée. Il offre, de plus, la possibilité d ajouter des objets (méthode ajouter) lors de la résolution d un défaut de cache pour une requête. Du point de vue de la sémantique, le gestionnaire de cache du cache de requêtes doit intégrer les interactions avec le gestionnaire d admission et l analyseur de requêtes, alors que le gestionnaire de cache du cache d objets doit considérer les appels sur l évaluateur de requêtes Mise en œuvre de caches sémantiques coopératifs Les caches sémantiques coopératifs que nous proposons se basent sur l emploi du cache dual, utilisant des résolutions horizontales par inondation. Le choix d une résolution horizontale est dicté par les caractéristiques de l application considérée : distribution des données sur différents sites pouvant être distants les uns des autres et grand nombre d utilisateurs. Nous avons opté pour un protocole de résolution par inondation, car il permet de mettre en avant l intérêt du concept de proximité sur cette approche réputée pour ses difficultés de passage à l échelle liées à la charge augmentant de manière quadratique avec le nombre de caches. L utilisation du concept de proximité au sein d une approche par catalogue fera, quant à elle, l objet de futures expérimentations. Ces expérimentations seront, notamment, utilisées pour caractériser des patrons d utilisation, permettant de configurer le protocole de résolution à utiliser en fonction d un contexte applicatif donné. Protocole Résolution pour les caches de requêtes Résolution pour les caches d objets Basique Directe auprès des serveurs Directe auprès des serveurs Physique Directe auprès des serveurs Proximité physique Sémantique Proximité sémantique Directe auprès des serveurs Physique et sémantique Proximité sémantique Proximité physique Tab. 8.3 Caractéristiques des protocoles de résolution pour cache dual La prise en compte des inondations par le cache de requêtes et/ou le cache d objets permet de mettre en œuvre les différents protocoles de résolution présentés dans le chapitre 7, la terminologie introduite étant récapitulée par le tableau 8.3. Le protocole de résolution sémantique et physique est obtenu en utilisant des gestionnaires de résolution par inondation, sur une topologie basée sur une proximité sémantique pour les caches de requêtes, et une proximité physique pour les caches d objets. Les protocoles de résolution basique, sémantique, physique, sont obtenus en utilisant un gestionnaire de résolution à l aide des serveurs pour le(s) cache(s) ne considérant pas la coopération (cache d objets et/ou cache de requêtes selon le protocole). La configuration d une résolution par inondation au sein du cache dual est très peu 131

144 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques coûteuse. En effet, nous réutilisons le gestionnaire de résolution par inondation générique proposé par ACS. Il est, cependant, nécessaire de proposer du code spécifique correspondant aux instances de deux composants que le gestionnaire de résolution par inondation utilise : le gestionnaire de topologie et le gestionnaire des réponses des frères. Pour le cache de requêtes et le cache d objets, le gestionnaire de topologie sont identiques. Ici, les communications entre caches sont gérées à l aide de RMI. Ainsi, les informations associées à chaque cache frère, gérées au niveau du gestionnaire de topologie sont l adresse réseau du cache ainsi que son nom pour pouvoir appeler des méthodes. La différence entre les deux provient de l établissement de la topologie. Alors que pour les caches de requêtes, le regroupement des caches se fait en fonction de la proximité sémantique, les caches d objets sont associés en fonction de leur localisation. Ainsi, deux caches de requêtes sont proches, s ils sont associés à des utilisateurs appartenant à la même communauté. On considère ici que deux utilisateurs appartiennent à la même communauté si au moins 70 % de leurs requêtes portent sur un même groupe d espèces (proxsem(a,b) = proxsem(b,a) = 1 si a et b ont au moins 70 % de prédicats sur un même groupe d espèces). Nous distinguons quatre communautés : les utilisateurs intéressés par les Eucaryotes, les Archées, les Virus et les Bactéries. Pour les caches d objets, une coopération est instaurée uniquement s ils appartiennent à une même grappe (proxphy(a,b) = proxphy(b,a) = 1 si a et b appartiennent à la même grappe). Que ce soit pour les caches de requêtes ou pour les caches d objets, les topologies sont créées au moment du déploiement. Les scripts utilisés pour le déploiement font coopérer les caches d objets déployés sur des nœuds dont les adresses contiennent un même nom de site (par exemple node-01@helios.grid5000.fr et node-02@helios.grid5000.fr pour des machines de la grappe Helios à Sophia-Antipolis). L appartenance à une communauté dépend des utilisateurs associés aux caches, et plus particulièrement, des requêtes posées. Afin de réaliser des expériences multi-échelles, nous avons choisi de répartir sur les caches, le plus uniformément possible, les charges de travail simulant les différentes communautés utilisées pour nos expérimentations (voir section 8.4.1). La première charge de travail est associée à la communauté des Eucaryotes, la deuxième aux Archées, la troisième aux Virus, la quatrième aux Bactéries, puis la cinquième de nouveau aux Eucaryotes et ainsi de suite. En supposant que le numéro de cache de requêtes est le même que le numéro de la charge de travail, une coopération est alors instaurée entre caches de requêtes ayant le même reste dans la division de leur numéro par quatre. Ainsi, les caches de requêtes 0, 4, 8, etc. sont frères, de la même façon qu une coopération est mise en place entre les caches 1, 5, 9, etc.... Deux gestionnaires de réponses distincts ont été utilisés. En effet, la considération d une réponse positive diffère entre un cache de requêtes et un cache d objets. Alors que le cache d objets transfert sans aucune autre opération le résultat obtenu par un frère, le cache de requêtes doit contacter le cache d objets afin de récupérer les objets à l aide de la liste d identifiants obtenue. En ce qui concerne le traitement d une réponse à ignorer, les deux caches présentent un comportement identique. Dans ce cas, ils associent au pointeur de la réponse la valeur nulle, afin que la réponse puisse être supprimée par le ramassemiettes. 132

145 8.4 Outils pour l évaluation de performance 8.4 Outils pour l évaluation de performance Cette section présente les outils pour l évaluation de performance des caches construits à l aide du canevas ACS et en particulier des implantations du cache dual et des caches sémantiques coopératifs. Premièrement, elle étudie la génération de la charge de travail. Ensuite, elle présente les métriques étudiées Génération de la charge de travail Il existe deux manières de générer une charge de travail. La première consiste à utiliser des traces réelles. Cette approche est intéressante pour donner une bonne approximation de cas réels d utilisation. Cependant, une trace n est qu un cas particulier et souvent ne représente pas la réalité dans son ensemble. De plus, l utilisation de traces ne permettra pas de mettre en évidence les mécanismes mis en jeu, si le but principal est de comprendre pourquoi une solution est adaptée à un contexte donné. La seconde manière consiste à utiliser une charge de travail synthétique. Une charge de travail synthétique, bien que ne représentant pas un scénario d utilisation réel est, en général, préférable, car elle permet de mettre en œuvre des scénarios critiques et offre la possibilité d une évaluation en détail de certains aspects des mécanismes étudiés. De plus, si des traces sont disponibles, elles peuvent être utilisées pour paramétrer la charge de travail synthétique. Les charges de travail classiques utilisées dans les bancs d essai (par exemple TPC [tpc], Wisconsin pour bases de données [DeW93] et serveurs mandataires [AC98], ou encore Polygraph [pol]) 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 [LNK + 01]. 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 est issue de raffinements de précédentes requêtes. Pour nos expérimentations, nous avons développé un générateur de requêtes permettant de créer une charge de travail de type Rx. Les requêtes créées correspondent à des conjonctions de sélections, les sélections portant sur les espèces de l arbre de vie. Il est à noter que les enregistrements Swiss-Prot ne contiennent qu un seul attribut pour caractériser une espèce. Ainsi, la valeur de cette attribut contient toute la branche de l arbre correspondant. C est pourquoi, une sélection sur une espèce est de la forme espèce OC, l attribut OC correspondant à l espèce. Exemple 8.8. La requête générée Eucaryote OC Alvéolate OC permet de récupérer les enregistrements des séquences de protéines des Eucaryotes et Alvéolates. En cas de raffinement d une requête, un terme de sélection supplémentaire est ajouté à la requête précédente. En ce qui concerne la génération d une nouvelle requête (la première requête générée ou une requête indépendante de la requête précédente), le nombre de termes est choisi aléatoirement de manière non uniforme. Nous avons choisi d utiliser une loi géométrique de paramètre 0,3 pour déterminer le nombre de termes, celui-ci étant limiter au maximum à quatre. Les requêtes composées d un terme sont favorisées par rapport aux requêtes composées de deux termes, de la même façon que les requêtes de 133

146 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques deux termes sont privilégiées par rapport aux requêtes de trois termes, et ainsi de suite. Ce choix de génération vise à offrir un comportement réaliste d utilisation, les premières requêtes posées par un utilisateur étant rarement précises, pour être ensuite raffinées. En plus de la localité sémantique, nous introduisons la notion de communauté, qui regroupe les 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 Swiss-Prot, 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 être particulièrement intéressés par ce groupe. Dans les expériences suivantes, 70 % des requêtes posées par les utilisateurs concernent des enregistrements de leur communauté. Les 30 % restants sont ditribués uniformément sur les enregistrements des autres communautés. Il est à noter que, pour des raisons de reproductibilité des expériences pour les comparaisons entre caches et entre protocoles de résolution, les requêtes générées ont été sauvegardées dans des fichiers. Ainsi l ensemble des requêtes utilisées lors d une comparaison est le même pour les deux éléments confrontés (caches ou protocoles de résolution). Nous avons créé pour R0, R30, R60 et R90 cent fichiers de mille requêtes. Si besoin, le générateur peut évidemment être utilisé pour générer plus, autant ou moins de requêtes, pour des localités sémantiques identiques ou différentes. Il faut également noter que, pour les fichiers générés, il est possible d utiliser un sous-ensemble des mille requêtes. Ce sera notamment le cas des expériences présentées, où, au maximum, seules cent requêtes d un fichier seront posées Métriques pour l interprétation des résultats L une des métriques les plus importantes à étudier, pour analyser des solutions de cache, 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ées entre les clients et les serveurs. En effet, l utilisation d un cache permet d économiser les ressources de calcul des serveurs et la bande passante. Les métriques étudiées par la suite seront : le temps de réponse, le taux de succès de cache, la charge sur les serveurs et le volume de données transférées entre les clients et les serveurs. 8.5 Validation du cache dual Cette section a pour objectif de présenter nos expérimentations portant sur le cache dual, afin de le comparer à un cache élémentaire et aux autres caches sémantiques adaptés à notre contexte. Trois expérimentations ont été menées. Les deux premières visent à étudier l impact de l environnement d exécution sur les performances des caches, en terme de taille du cache et de localité sémantique des requêtes posées. La troisième analyse le comportement des différents caches sémantiques dans un contexte de gestion de données sur grille. 134

147 8.5 Validation du cache dual Influence de l environnement d exécution Le comportement d un cache est en général influencé par la taille de l espace de stockage qui lui est réservé. Les performances d un cache sémantique sont, quant à elles, liées à la localité sémantique des requêtes posées. Les expériences suivantes présentent les résultats obtenus afin d étudier l impact de ces deux paramètres. Les expériences ont été réalisées sur une architecture client-serveur, avec un unique client. Le client et le serveur sont déployés sur deux nœuds d une même grappe à Sophia-Antipolis (voir les caractéristiques techniques des machines dans le tableau 8.2). Pour chaque expérience, cent requêtes sont posées aux différents caches Influence de la localité sémantique des requêtes (a) Temps de réponse moyen (b) Charge sur le serveur (c) Consommation de bande passante Fig. 8.4 Influence de la localité sémantique (sur un cache de 500 Mo) Cette première expérience étudie l impact de la localité sémantique sur la charge du serveur, le volume de données transférées entre le client et le serveur et le temps de réponse moyen, pour un système sans cache, un cache élémentaire et les différents caches sémantiques présentés précédemment. La taille du cache est ici fixée à 500 Méga octets (dont 10 Méga octets sont alloués au cache de requêtes dans le cas d un cache dual). Les graphiques de la figure 8.4 illustrent l impact de la localité sémantique des requêtes posées sur les métriques prises en compte. L axe des abcisses des trois graphiques est le même, faisant varier la localité sémantique de 0 à 90 %. L axe des ordonnées correpond au temps de réponse moyen en secondes pour 8.4(a), à la charge sur le serveur en pourcents pour 8.4(b) et au volume en Méga octets de données transférées entre le cache et le serveur 135

148 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques pour 8.4(c). Il est important de rappeler que ces résultats ont été obtenus pour un contexte sans communication pour contacter un serveur peu chargé. Ainsi, l importance d un cache est moindre et les comparaisons entre les différentes approches sont moins significatives. Néanmoins, des résultats intéressants peuvent être observés. Ces graphiques confirment, dans un premier temps, que l utilisation d un cache dans un système d interrogation distribué permet de réduire la consommation de bande passante et la charge sur le serveur. Il convient, cependant, de noter qu un cache élémentaire peut dégrader les performances du système, les temps de réponse pour un système sans cache étant inférieurs à ceux obtenus avec un cache élémentaire (à l exception d une localité sémantique à 90 %). En effet, un système avec cache doit payer une double lecture du flux de données reçu du serveur, la première par le cache, la seconde par le client. Le gain d un cache élémentaire en terme de performances étant assez faible ici, il ne permet pas de compenser ce surcoût. L apport des caches sémantiques, au contraire, compense largement le surcoût. Les caches sémantiques offrent, en effet, une réduction importante de la charge sur le serveur, puisqu une grande partie des requêtes engendre des succès exacts, mais également des succès étendus. Par conséquent, le volume de données transférées entre le serveur et les caches est grandement diminué. C est pourquoi, les temps de réponse moyens pour les caches sémantiques sont, en général, inférieurs à ceux obtenus avec un système sans cache ou utilisant un cache élémentaire. Il est, néanmoins, important de noter, que pour une localité sémantique nulle, seul le cache dual est plus intéressant qu un système sans cache. Ce résultat montre l efficacité du cache dual, mais confirme également que l utilisation d un cache sémantique est réservée à des contextes présentant une localité sémantique. Les résultats obtenus confirment que l efficacité des caches sémantiques s améliore avec la localité sémantique. En effet, plus les requêtes posées proviennent de raffinement, plus le taux de réutilisation du cache est grand. Ainsi, pour les différents caches sémantiques, la charge sur le serveur et le volume de données transférées entre le serveur et les clients diminuent. La diminution du volume est également liée au fait que les requêtes sont plus précises lorsque la localité sémantique augmente et donc les réponses sont plus petites, comme le montre le volume de données lorsqu aucun cache n est utilisé. C est pourquoi un cache élémentaire est également influencé par la localité sémantique, comme le montre l évolution du temps de réponse. Fig. 8.5 Influence de la localité sémantique sur le cache dual en terme de charge sur le serveur Il est à noter que, pour le cache dual, la charge sur le serveur est répartie en accès par requêtes et par listes d indentifiants. La figure 8.5 permet de remarquer que la charge en 136

149 8.5 Validation du cache dual accès par requêtes n est pas influencée par la localité sémantique. En effet, même si la taille du cache de requêtes est réduite (10 Méga octets), il peut garder en cache les résultats de très grandes requêtes contenant d autres requêtes. Par contre, puisque le cache d objets est de taille limitée, la localité sémantique présente une influence sur la charge en accès par listes d identifiants, puisqu elles sont inversement proportionnelles Influence de la taille du cache (a) Temps de réponse moyen (b) Charge sur le serveur (c) Consommation de bande passante Fig. 8.6 Influence de la taille du cache (pour une localité sémantique de 60 %) La deuxième expérience étudie l influence sur les performances de la taille des caches. Pour cette expérience, la localité sémantique est fixée à 60 %, permettant de simuler un contexte présentant une forte localité sémantique. Les résultats obtenus sont illustrés par les graphiques de la figure 8.6. L axe des abcisses pour tous les graphiques étudiés se rapporte à la taille du cache en Méga octets. L axe des ordonnées représente la métrique considérée, la charge sur le serveur (en pourcents), le volume de données transférées entre le serveur et le client (en Méga octets) et le temps de réponse moyen (en secondes). A noter que dans le cas d un cache dual, seule la taille du cache d objets varie, la taille du cache de requêtes étant fixée à 10 Méga octets. Une première analyse des résultats confirme que l utilisation d un cache sémantique est plus appropriée, si la localité sémantique des requêtes est forte. En effet, même pour un cache de très grande taille, la charge sur le serveur, ainsi que la consommation de bande passante d un cache élémentaire, restent nettement supérieures aux valeurs correspondantes pour des caches sémantiques. 137

150 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques Concernant les caches sémantiques, les résultats obtenus confirment que l efficacité d un cache est proportionnelle à sa taille. En effet, plus un cache est grand, plus les taux de succès exacts et étendus sont importants. Il est important de noter que, lorsque la taille des caches est suffisante pour stocker l intégralité de la source de données, tous les caches sémantiques présentent des résultats similaires en terme de charge sur les serveurs et de volume de données transférées. Néanmoins, lors de nos expérimentations, nous avons remarqué que le cache de résultats de requêtes présente des performances un peu inférieures aux deux autres, liées à la gestion des inclusions. En effet, si une requête est incluse dans une entrée du cache, le résultat est calculé localement, mais n est pas gardé en cache. Ainsi, en cas de raffinements successifs des requêtes posées, le cache travaille toujours sur la même entrée, sans tirer profit des précédents calculs. Fig. 8.7 Influence de la taille d un cache dual en terme de charge sur le serveur En ce qui concerne le cache dual, il est intéressant d analyser la charge sur le serveur, en terme d accès par requêtes et d accès par identifiants. La figure 8.7 permet, ainsi, de remarquer que la taille du cache n influence pas la charge du serveur en terme d accès associatif. En effet, le cache de requêtes, même pour un cache de 100 Méga octets, est suffisamment grand pour stocker un très grand nombre de requêtes. Par contre, les résultats confirment l intuition que la taille du cache à un impact direct sur les accès par listes d identifiants Expérience grille La troisième expérience réalisée correspond à une expérience des différents caches sémantiques dans un contexte de grille. Une caractéristique des grilles provient, premièrement, de l évaluation des requêtes réalisée par les sources de données, à l aide d une architecture d union de serveurs. La source de données est découpée en trois fichiers de taille équivalente, chaque fichier est alors géré par un nœud d un site. Les sites utilisés pour cette expérience sont : Sophia-Antipolis, Rennes et Lille (voir les caractéristiques techniques des sites dans le tableau 8.2). Une autre caractéristique des grilles concerne la distribution des clients sur plusieurs sites de la grille. Cinquante clients, répartis de manière uniforme (treize à Sophia-Antipolis, douze à Toulouse, treize à Rennes et douze à Lille) génèrent des requêtes selon la charge de travail R60. Chaque client dispose d un cache de 500 Méga octets (dont 10 Méga octets seront alloués au cache de requêtes pour le cache dual, le reste étant réservé au cache d objets). Au total, cinq mille requêtes sont évaluées. Pour une même expérience, les caches sont tous de même type, cache de résultats de requêtes, cache de prédicats et d objets ou cache dual. 138

151 8.5 Validation du cache dual Cache Temps Succès Succès Charge Évaluations Volume sémantique de exacts étendus sur les sur les transféré réponse serveur serveurs Cache de s % % 24,46 % 24,46 % Go résultats de requêtes Cache de s % % % % Go prédicats et d objets Cache dual s % % 23,34 % 8.04 % Go Tab. 8.4 Métriques de performances de caches sémantiques dans un contexte grille Le tableau 8.4 détaille les résultats obtenus pour les différents caches sémantiques. Les lignes du tableau représentent les caches sémantiques étudiés : cache de résultats de requêtes, cache d objets et cache dual. Les colonnes du tableau représentent les métriques prises en compte : le temps moyen de réponse à une requête en secondes, le taux de requêtes évaluées sur les serveurs donné en pourcentages et finalement, le volume moyen de données transférées entre les serveurs et un cache. Les expériences montrent que le cache dual est l approche offrant les meilleures performances, le temps d attente moyen perçu par les utilisateurs étant réduit de l ordre de 35 % par rapport aux autres caches sémantiques. Cette amélioration s explique par un volume de données transférées entre les clients et les serveurs plus faible, mais également par des succès exacts et étendus plus importants. Le cache dual permet, en effet, de stocker un très grand nombre de requêtes, indépendamment du stockage des objets correspondants. C est pourquoi, même si la charge sur les serveurs pour les trois caches sémantiques est équivalente (de l ordre de 24 %), il est important de noter que, pour le cache dual, seul le tiers de cette charge (8,04 %) correspond à des évaluations de requêtes, le reste correspondant à des récupérations d objets à l aide de listes d identifiants. Par conséquent, lorsque l accès aux données par leur identifiant est plus performant que l évaluation des requêtes équivalentes, comme c est le cas ici, l utilisation du cache dual est recommandée. D autres expériences ont été réalisées avec des caches de petite taille (25 Méga octets) et la source de données Swiss-Prot. Certaines d entre elles sont présentées dans un article accepté à la conférence nationale en Bases de Données Avancées en 2006 [dvj + 06]. Les expérimentations présentées dans cet article ont été réalisées avec un unique client. Ainsi, ces expériences sont discutables, en particulier parce que les problèmes de charges (sur les serveurs et sur les liens de communication) ne sont pas abordés. C est pourquoi, dans ce document, nous avons souhaité présenter des expériences avec de multiples clients. Pour ce faire et pour offrir des temps de réponses raisonnables, il était alors nécessaire de déployer des caches disposant d espaces de stockage relativement importants, pour augmenter la proportion des requêtes traitées localement. Il convient, cependant, de noter que les résultats obtenus permettent de souligner l intérêt d un cache dual, lorsque l espace physique disponible est restreint et que les serveurs proposent des mécanismes efficaces d accès aux objets à l aide de leur identifiant. 139

152 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques 8.6 Validation du cache sémantique coopératif Cette section vise à valider nos travaux sur les caches sémantiques coopératifs, et plus particulièrement les protocoles de résolution proposés pour le cache dual. Dans une première série d expérimentations, nous présentons l impact du nombre de caches sur les protocoles de résolution basés sur le concept de proximité. Ensuite, nous nous focalisons sur l évaluation des performances des protocoles de résolution proposés dans le chapitre 7 basique, physique, sémantique ou physique et sémantique. Les expériences présentées ont été réalisées avec une architecture de type union de serveurs, l union étant réalisée sur trois serveurs placés sur les sites de Nancy, Rennes et Sophia-Antipolis (voir le tableau 8.2 pour les caractéristiques des différents sites). Pour toutes les expériences considérées, des caches duaux de 325 Méga octets (correspondants à la moitié de Swiss-Prot) sont déployés, dont 10 Méga octets sont alloués au cache de requêtes (suffisants pour stocker tous les résultats des requêtes posées pour l expérience), le reste étant réservé au cache d objets. Chaque cache dual est utilisé par un client générant cinquante requêtes suivant la charge de travail R40 et prenant en compte l appartenance à une communauté (70 % des requêtes se référent à une espèce donnée) Influence du concept de proximité au sein du cache dual L objectif de cette section est d étudier l impact de la proximité sur les performances du système applicatif considéré utilisant un cache dual. L objectif est d analyser les résultats obtenus pour avec un nombre variable de caches duaux, avec d abord des caches d objets pour lesquels une coopération reposant sur une proximité physique est mise en place, puis des caches de requêtes coopérant en fonction d une proximité sémantique. Caches d objets et proximité physique (a) Volume de données transférées (b) Charge sur les serveurs Fig. 8.8 Résolution basée sur la proximité physique La première expérience étudie l impact de l utilisation d une coopération basée sur une proximité physique entre caches d objets (les caches de requêtes résolvant les défauts directement auprès des serveurs). Les données mesurées sont le volume moyen de données transférées par requête entre le cache et les serveurs, ainsi que la charge d évaluation sur les serveurs. Tous les caches déployés appartiennent à une même grappe, la grappe Helios 140

153 8.6 Validation du cache sémantique coopératif localisé sur le site de Sophia-Antipolis. Ainsi, chaque fois qu un cache dual est ajouté, son cache d objets devient un frère pour les autres caches d objets. La figure 8.8(a) présente les résultats pour le volume moyen de données transférées par requête entre un 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 en Giga octets. Pour cette expérience, le nombre de caches varie de un à cinq. Ce graphique permet d observer que le volume diminue, lorsque le nombre de caches augmente. En effet, plus le nombre de cache est important, plus la quantité de données pouvant être stockée dans les caches est grande. Ainsi, la probabilité d obtenir un succès sur un cache frère augmente et par conséquent, les serveurs sont moins contactés pour résoudre des défauts d objets. Les résultats montrent que, de un à quatre caches, le volume moyen engendré par requête entre les caches et les serveurs peut ainsi être réduit de 50 %. Le concept de proximité physique est alors particulièrement pertinent, puisqu il permet une répartition intelligente de la consommation de bande passante en fonction de la topologie. Une partie des transferts a alors lieu au sein d une même grappe, ce qui évite par conséquent des transferts de données équivalents sur des distances géographiques plus importantes et offrant généralement des débits moins bons. Il est, cependant, important de noter que le volume devient stable, lorsque le nombre de caches est supérieur à trois. En effet, avec des caches de 325 Méga octets, la somme des espaces physiques des différents caches est alors largement suffisante pour stocker l intégralité de la source de données. Par conséquent, ajouter de nouveaux caches d objets est inutile, les données qu il pourrait stocker étant déjà gardées par les caches d objets présents. Il convient, néanmoins, de noter que le nombre de caches, à partir duquel le volume devient stable, dépend de la taille des caches. Ainsi, le phénomène de stabilité serait observé avec un plus grand nombre de caches de plus petite taille. La figure 8.8(b) présente le taux moyen de requêtes par client évaluées sur les serveurs. L axe des abcisses représente toujours le nombre de caches variant de un à cinq. L axe des ordonnées représente, cette fois, le taux de requêtes, donné en pourcentage. Cette figure permet de voir que le taux de requêtes reste constant (avec une valeur aux environs de 37%), lorsque le nombre de caches augmente. Autrement dit, le nombre de caches avec une coopération entre caches d objets basée sur une proximité physique n a pas d impact sur le taux de requêtes moyen par client évaluées sur les serveurs. En effet, la résolution des défauts pour les caches de requêtes se fait directement auprès des serveurs. La proximité physique n intervient donc pas sur le nombre de requêtes évaluées, mais uniquement sur le nombre de listes d identifiants soumises aux serveurs. Il est, néanmoins, possible de noter que la première mesure est un peu supérieure aux autres. Nous pensons, que la charge de travail utilisée pour un système avec un seul cache est un peu moins représentative que les autres charges de travail employées, ce qui expliquerait ce léger décalage par rapport à la moyenne. Caches de requêtes et proximité sémantique L expérience suivante se focalise sur l influence d une coopération basée sur une proximité sémantique entre caches de requêtes (la résolution de défaut pour les caches d objets se faisant directement sur les serveurs). Comme dans l expérience précédente, les données mesurées sont le volume moyen de données transférées par requête entre les caches et les serveurs, et le taux de requêtes évaluées par les serveurs. Les caches déployés sont répartis uniformément sur les trois sites utilisés (Nancy, Rennes et Sophia-Antipolis). 141

154 Chapitre 8 : Validations dans un intergiciel pour la gestion de données bio-informatiques (a) Charge sur les serveurs (b) Volume de données transférées Fig. 8.9 Résolution basée sur la proximité sémantique La figure 8.9(a) présente les mesures du taux de requêtes par client évaluées sur les serveurs. L axe des abscisses représente le nombre de caches et l axe des ordonnées correspond au pourcentage de requêtes par client évaluées sur les serveurs. Le nombre de caches varie de un à vingt. La figure montre que la charge d évaluation sur les serveurs baisse, lorsque le nombre de caches augmente. En effet, le nombre de requêtes stockées augmente avec le nombre de caches, la probabilité d obtenir une réponse d un cache frère étant accrue et donc les évaluations sur les serveurs sont moins nombreuses. Le gain ainsi obtenu peut atteindre jusqu à 45.3 %. L utilisation d une proximité sémantique est, dans ce cas, très intéressante. Elle permet, premièrement, d améliorer la probablité d obtenir un succès sur les frères, en ne contactant que les caches des utilisateurs de la même communauté. La proximité sémantique autorise, de plus, les coopérations entre caches de requêtes éventuellement distants, le gain d une évaluation de requêtes pouvant être très important, alors que le coût de la coopération est en général faible, du fait de la petite taille d une liste d identifiants. Il est à noter que le phénomène de stabilité observé pour les caches d objets utilisant une proximité physique, n apparaît pas pour les caches de requêtes avec une proximité sémantique. En effet, le nombre de requêtes possibles est grand, rendant difficile un stockage rapide de tous les résultats dans un faible nombre de caches. La figure 8.9(b) présente le volume moyen de données transférées par client entre les caches et les serveurs. L axe des abcisses correspond, comme précédemment, au nombre de caches, variant de un à vingt. L axe des ordonnées représente le volume moyen en Giga octets de données transférées entre les clients et les serveurs. Cette figure montre que l évolution du volume n est pas monotone en fonction du nombre de caches, les mesures oscillant entre 7.6 et 9.4 Giga octets dans un intervalle de quatre à vingt caches. L interprétation de ces résultats mène à la conclusion que la proximité sémantique pour les caches de requêtes n a pas une influence majeure sur le volume de données transférées. En effet, la coopération entre caches de requêtes correspond uniquement à des échanges de listes d identifiants dont les tailles sont très faibles par rapport aux objets correspondants, les objets devant la plupart du temps être récupérés sur les serveurs Analyse des protocoles de résolution pour le cache dual 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. Le tableau 8.5 présente les résultats des différents protocoles, avec cinquante clients déployés uniformément sur quatre sites (treize à Sophia- 142