Projet : CARAVEL - caravel

<body bgcolor="#FFFFFF" text="#000000" link="#9944EE" vlink= "#0000FF" alink="#00FF00">  <a name="CHILD_LINKS" id= "CHILD_LINKS"><strong>Sous-sections</strong></a> <ul> <li><a name="tex2html241" href= "resul_theme1_mn.html#SECTION00061100000000000000" target= "main" id="tex2html241"><small>Optimisation de requêtes incluant des traitements coûteux</small></a></li> <li><a name="tex2html242" href= "resul_theme1_mn.html#SECTION00061200000000000000" target= "main" id="tex2html242"><small>L'interrogation des données XML</small></a></li> <li><a name="tex2html243" href= "resul_theme1_mn.html#SECTION00061300000000000000" target= "main" id="tex2html243"><small>Index plein-texte et requêtes XML</small></a></li> <li><a name="tex2html244" href= "resul_theme1_mn.html#SECTION00061400000000000000" target= "main" id="tex2html244"><small>Intégration de données XML et relationelles</small></a></li> <li><a name="tex2html245" href= "resul_theme1_mn.html#SECTION00061500000000000000" target= "main" id="tex2html245"><small>Algorithmes de pattern matching</small></a></li> </ul> <hr /> <h2><a name="SECTION00061000000000000000" id= "SECTION00061000000000000000">Accès à des ressources distribuées</a></h2> <a name="CARAVEL_resultats_theme1" id= "CARAVEL_resultats_theme1"></a> <p><strong>Mots clés :</strong> <i>hétérogénéité, optimisation, répartition .</i></p> <h3>Résumé :</h3> <div class="ABSTRACT"> <i>le problème général abordé dans ce thème est celui de la publication de ressources dans un réseau ainsi que l'accès à ces ressources au moyen de langages de haut niveau. Les ressources peuvent être des données (structurées ou non) ou des services (librairies, programmes scientifiques, sites Web, etc), l'ensemble formant un <em>système d'information global</em>. Le système de médiation a la charge de mettre en relation de façon transparente les éditeurs des ressources avec les clients qui veulent utiliser ces ressources. Les actions de recherche qui structurent ce thème se distinguent selon l'approche, push ou pull, utilisée. Pour l'approche pull nous nous sommes concentrés sur deux questions essentielles. La première question est quelle vue uniforme des données faut-il présenter à l'utilisateur et quel est le langage de requêtes associé. Jusqu'à présent nous avons centré nos recherche sur le modèle relationnel et le langage SQL. Cette année, nous avons mené des recherches sur l'utilisation de XML comme formalisme de représentation uniforme des données, et sur la conception d'un langage de requêtes pour XML. La deuxième question est quelles techniques d'exécution efficaces peut-on élaborer pour les langages de requêtes supportés par le système de médiation. Dans l'approche push les clients sont intéressés par des informations hautement volatiles et dynamiques (des événements); ils souscrivent des abonnements auprès du médiateur indiquant les informations qui les intéressent, les éditeurs font parvenir leurs informations (événements) au médiateur. Ce dernier se charge d'alerter les souscripteurs chaque fois qu'une information intéressante est émise par un éditeur. Dans la mesure où l'utilisation de médiateurs push dans les applications web telles les applications de commerce électronique "B2C" (bourse d'échange, billeterie, informations sur le trafic,...) est conditionnée par la faculté du système à supporter un grand nombre de clients et un flux élevé d'événements, la question est quelles sont les techniques de filtrage efficaces dans un tel contexte.</i> </div> <h3><a name="SECTION00061100000000000000" id= "SECTION00061100000000000000">Optimisation de requêtes incluant des traitements coûteux</a></h3><br /> <br /> <span class="textbf">Participants :</span> Luc Bouganim, Francoise Fabret, Fabio Porto, Patrick Valduriez.<br /> <br /> <p>Dans le cadre des applications environnementales que nous envisageons avec Le Select, les scientifiques peuvent typiquement avoir à poser des requêtes impliquant des données et des programmes (par exemple, un programme d'extraction de motifs dans une image) publiés en divers points du réseau. Même s'il est possible d'exprimer ces requêtes en SQL, les techniques classiques d'optimisation et d'exécution de requêtes sont insuffisantes pour deux raisons. Tout d'abord les optimiseurs de requêtes SQL considérant que le facteur prédominant est le coût des opérations de jointure, cherchent à minimiser ce coût en jouant sur l'ordre dans lequel sont exécutées les jointures. A contrario, dans notre contexte, le coût prédominant est celui de l'exécution des programmes et du transport des données volumineuses (telles que des images) depuis le site publiant ces données vers les lieux de traitement. D'où la nécessité d'établir des techniques d'optimisation spécifiques qui minimisent le nombre d'exécutions de programmes et la quantitié de données volumineuses transférées. Nous proposons deux techniques qui exploitent les possibilités d'optimisation inhérentes à l'architecture distribuée de systèmes comme Le Select. La première consiste à exécuter les traitements chers (appel des fonctions et transfert des données volumineuses) le plus tard possible: l'optimiseur planifie donc d'exécuter d'abord les opérations standard (sélections, jointures, etc). La seconde consiste à utiliser du caching pour éviter des traitements redondants. Le coût total en temps d'exécution est minimisé en parallélisant l'exécution des traitements: paralléllisme entre le transfert des données et l'exécution des programmes, exécution concurrente de plusieurs programmes. Le problème pour l'optimiseur est de décider de l'ordonnancement des programmes entre eux, et de décider la forme de parallélisme inter-programme: parallélisme pipeline, ou parallélisme indépendant. Nous proposons des algorithmes de planification dynamique permettant de s'adapter au flot de données constaté en cours d'exécution. Nous montrons que l'approche dynamique peut apporter des gains considérables en termes de temps de réponse. En effet, une mauvaise appréciation du flot de données peut avoir des conséquences désastreuses sur le temps de réponse si la planification est faite statiquement sans possibilité d'adaptation à l'exécution. Or, nous montrons que, dans de nombreux cas, il est très difficile d'avoir une connaissance du flot de données de façon statique. En effet, d'une part les statistiques sont peu fiables dans le contexte qui nous intéresse, et d'autre part même avec des statistiques très précises, il est la plupart du temps impossible d'avoir des informations sur la distribution des données (cette dernière n'est connue qu'à l'exécution), or cette information est déterminante pour planifier l'exécution de plusieurs fonctions en parallélisme pipeline.</p> <h3><a name="SECTION00061200000000000000" id= "SECTION00061200000000000000">L'interrogation des données XML</a></h3><br /> <br /> <span class="textbf">Participant :</span> Daniela Florescu.<br /> <br /> <p>Depuis quelques années, le langage XML (eXtensible Markup Language) est de plus en plus souvent utilisé comme langage de description de données, en raison de sa flexibilité et de son grand pouvoir d'expression. Ainsi, pour échanger des données (dont les formats et schemas peuvent être differents) entre plusieurs organisations coopérantes, une solution consiste à choisir XML comme le modèle commun, et de présenter toutes les collections de données comme des documents XML. D'autres contextes d'application justifient la mise en place des vraies bases de données/documents XML (e.g. documents administratifs, fonds bibliographiques etc.). De tous ces contextes applicatifs surgit le besoin d'un langage d'interrogation de haut niveau pour ce nouveau format de données. L'élaboration d'un standard pour le langage de requêtes pour XML est en cours, elle s'effectue dans le cadre d'un groupe de travail du World Wide Web Consortium (W3C); l'INRIA a été activement representée dans ce groupe de travail. En collaboration avec Jonathan Robie (Software AG) et Donald Chamberlin (IBM), nous avons élaboré un nouveau langage de requêtes pour XML nommé Quilt. Ce langage combine des éléments utiles de plusieurs langages existants et une syntaxe structurée similaire aux requêtes SQL. Quilt est un langage fonctionnel, centré sur la notion d'expression. Un type important d'expression est constitué par les expressions de chemin qui, à partir de la racine d'un document, sélectionnent un ensemble d'attributs ou d'éléments dans le document. Pour spécifier les expressions de chemin dans des documents XML, Quilt utilise la version courte de XPath, le standard du W3C. Par sa structure, Quilt permet aussi une interrogation très facile des données en format relationnel (présentées sous forme XML). Quilt a été proposé en novembre 2000 au groupe de travail du W3C sur les langages de requêtes pour XML et vient d'être adopté par ce groupe de travail.</p> <h3><a name="SECTION00061300000000000000" id= "SECTION00061300000000000000">Index plein-texte et requêtes XML</a></h3><br /> <br /> <span class="textbf">Participants :</span> Daniela Florescu, Ioana Manolescu.<br /> <br /> <p>Dans le cadre de l'interrogation des données XML, la complexité de la structure des données, ou l'absence d'information sur la structure sont une source de difficulté majeure pour l'utilisateur. En effet, la structure d'un document XML peut être décrite par une grammaire (bien plus compliquée qu'un schéma relationnel), mais cette description n'est pas toujours présente. Pour explorer le contenu d'une source de données, l'utilisateur a donc besoin d'une mécanisme pour poser des requêtes qui ne nécessitent pas une connaissance préalable de la structure. De telles requêtes sont proches des recherches documentaires sur mot-clé, habituelles lors de la recherche d'information dans des documents HTML. Nous avons proposé d'ajouter à un langage d'interrogation de données XML l'expression de critère de sélection à base de mots-clé. Cette extension est rendue possible par l'utilisation d'un index plein-texte sur le contenu des documents XML. Cet index peut être matérialisé sur le même site que celui qui contient les données ou, dans le cas d'une architecture à médiateur, il peut être stocké dans le médiateur si les propriétaires des données ne désirent pas héberger un tel index sur leur site. Au niveau du langage, cet index est rendu visible par la présence d'une fonction spéciale qui permet de tester si un certain élément contient ou non un mot donné. Nous avons montré l'interêt qu'il y a à ce que l'index retienne non pas seulement l'information sur les mots contenus directement dans un élément (sous forme de texte), mais aussi sur les mots contenus dans les descendants de cet élément, jusqu'à une profondeur fixée à l'avance.</p> <h3><a name="SECTION00061400000000000000" id= "SECTION00061400000000000000">Intégration de données XML et relationelles</a></h3><br /> <br /> <span class="textbf">Participants :</span> Daniela Florescu, Ioana Manolescu.<br /> <br /> <p>Dans certains types d'applications d'intégration de données très structurées (tables relationelles) et de documents (qui peuvent être modélisées en XML), il est nécessaire d'être capable de répondre à des requêtes portant sur les deux types de données en même temps. Un exemple de ce genre d'application est la gestion des données médicales: certaines informations font référence aux données personnelles des malades et sont plutot structurées, tandis que le dossier médical cummule les annotations faites par le personnel médical au cours d'une longue période de temps (parfois plusieurs années) et est plus proche par structure d'un document XML. Le médiateur Le Select, réalise déjà l'intégration de données relationelles; nous l'avons donc étendu avec la capacité d'interroger, en même temps que des données relationelles, des documents XML. Pour ce faire, nous avons construit un adapteur (wrapper) spécial pour des documents XML, qui se base sur l'interface DOM, et qui présente le document à l'unité de traitement de requêtes sous la forme d'une collection de tables virtuelles. En posant une requête sur ces tables, on extrait de ce document les informations désirées. Par la suite, les tuples fournis par ce wrapper sont traités dans un cadre uniforme, avec les tuples de données relationnelles, ce qui permet la construction du résultat à partir des deux sources d'information. Nous avons réalisé le système Agora, qui ajoute à LeSelect une interface de type XML : toutes les données publiées via Le Select sont vues dans un format XML sur lequel les utilisateurs posent des requêtes en Quilt. Ces requêtes des utilisateur sont traduites vers des requêtes SQL sur un schéma canonique virtuel. Une étape supplémentaire de réecriture transforme la requête posée sur le schéma virtuel en une requête exécutable par LeSelect. Les tuples résultant de cette exécution sont ensuite fournis à un module qui en compose les éléments XML demandés par la requête en Quilt.</p> <h3><a name="SECTION00061500000000000000" id= "SECTION00061500000000000000">Algorithmes de pattern matching</a></h3><br /> <br /> <span class="textbf">Participants :</span> FranÇoise Fabret, FranÇois Llirbat, João Pereira, Ken Ross, Arno Jacobsen.<br /> <br /> <p>"Publier et souscrire" (publish/subscribe en anglais) est un paradigme dans lequel des utilisateurs expriment leurs sujets d'intérêt (des "souscriptions") et des agents externes (pouvant être eux-même des utilisateurs) "publient" des événements (par exemple des offres). Le rôle des logiciels pour "publier et souscrire" est d'envoyer les événements aux propriétaires des souscriptions satisfaites par ces événements. Par exemple, la souscription émise par un souscripteur peut exprimer l'intérêt de ce dernier pour toute proposition de voyage en avion ayant certaines caractéristiques et dont le prix n'excède pas une certaine somme. Parallèlement, un événement publié peut consister en une offre de voyage en avion dans laquelle sont précisées certaines propriétés du voyage et son prix. En fait, une souscription ressemble à un déclencheur (trigger) en ceci qu'elle exprime une requête continuelle (plus exactement une condition) assortie d'une action (consistant en général à avertir le souscripteur) qui est déclenchée chaque fois que la condition est satisfaite. Cependant le concept de souscription est moins général que celui de déclencheur. De ce fait, de nouvelles structures de données et des implémentations doivent permettre de concevoir des systèmes pour la publication/souscription qui supportent de façon efficace un très grand nombre de souscriptions et un haut débit d'événements. Ceci conduit à la conception de nouveaux algorithmes et à de nouvelles techniques d'implémentation. En combinant des structures de données, avec des politiques de caching spécifiques et une technique particulière d'exécution des requêtes, nous avons obtenus un module de filtrage des événements capable de traiter 600 événements par seconde alors que 6 milions de souscriptions consistant en des conjonctions de triplets (attribut, comparateur, valeur) sont présentes dans le système. Le rôle d'un algorithme de filtrage est de calculer pour un événement arrivant dans le système, quelles sont parmi les souscriptions actuellement présentes dans le système celles qui sont satisfaites par cet événement. Nos algorithmes de filtrage sont basés sur deux principes. Tout d'abord, ils sont conçus pour s'exécuter exclusivement en mémoire centrale, d'où la nécessité d'optimiser la localité temporelle et spatiale pour prendre en compte le comportement des processeurs en terme de caching (cache processor). Ensuite, ils ont pour but de réduire au maximum le nombre de souscriptions à tester grace à l'utilisation de techniques d'indexage et de groupement des souscriptions. Les algorithmes ont été testés dans le module de filtrage du prototype Le Subscribe.</p> </body>