Précédent : Logiciels Remonter : Projet RODIN, Systèmes de Bases Suivant : Actions industrielles
Précédent : Logiciels Remonter : Projet RODIN, Systèmes de
Bases Suivant : Actions industrielles
Participants : Georges Gardarin , Helena Galhardas , Yosr
Hmaied , Olga Kapitskaia , Hubert Naacke , Joao Pereira , Anthony
Tomasic , Patrick Valduriez , Khaled Yagoub
Mots-clés : optimisation, répartition,
hétérogénéité
Résumé : Disco (Distributed Information Search COmponent) est un système de recherche d'informations dans des sources de données hétérogènes, réparties dans un réseau de type Internet/Intranet. Disco est en cours de transfert dans le GIE Dyade.
Cette action s'est concentrée sur la définition de l'architecture de Disco, et sur trois points techniques dont les solutions ont été intégrées dans le prototype : (i) traitement des requêtes multi-sources de données, (ii) modèle de coût générique, et (iii) gestion des réponses partielles.
Pour uniformiser la représentation des données, Disco s'appuie sur le modèle standard de l'ODMG en étendant le langage ODL avec la définition de vues globales. L'architecture de Disco comprend deux types de composants principaux: le médiateur qui gère les méta-données et uniformise la représentation des sources de données, et les adaptateurs qui exécutent les requêtes sur les sources de données locales. Un médiateur est un serveur pour les applications ou d'autres médiateurs. Il gère un catalogue des sources de données accessibles et traduit une requête globale multi-source en un ensemble de requêtes locales (chacune pour un adaptateur) et une requête de composition du résultat. Un médiateur fournit aussi un système d'exécution pour gérer l'accès concurrent aux méta-données et intégrer les résultats des requêtes locales. Le traitement des requêtes repose sur des techniques de reformulation et d'exécution répartie, et prend en compte les différences entre les capacités de calcul des sources ainsi que l'indisponibilité des sources de données pendant l'exécution.
Un second prototype de médiateur a été réalisé en Java (environ 30000 lignes de code). Il supporte la définition de schéma global, de schéma local, et de vue et peut décomposer les requêtes depuis le niveau global vers le niveau local. Il offre une interface HTML utilisable à partir de n'importe quel navigateur Web. La technologie des adaptateurs est développée avec Bull dans le contexte du GIE Dyade. Disco a été démontré à la conférence ACM SIGMOD avec une application de bourse d'affaires électronique. Il va aussi être déployé dans une application environnementale (projet européen Thetis).
Avec Disco, l'utilisateur a une vision commune des données hétérogènes et peut les interroger de manière transparente via un médiateur avec le langage OQL. Cependant, le traitement de requêtes est compliqué par le fait que les sources ont des capacités de calcul très différentes. Par exemple, une source peut être une base de données SQL et une autre un système de recherche d'information avec une interface de requête très limitée.
L'interface entre médiateur et adaptateur est déterminante pour l'efficacité du traitement de requête et le coût de développement d'un adaptateur. En effet, une interface de haut niveau (par ex. SQL) est très chère à développer sur une source simple alors qu'une interface simple (par ex. scan d'un fichier) conduit à déplacer le traitement de la requête dans le médiateur, et ainsi à recopier toutes les données de la source au niveau du médiateur. Nous résolvons ce problème en offrant une interface adaptative par une machine abstraite d'opérateurs algébriques. Ainsi le développeur d'un adaptateur peut choisir un sous-ensemble des opérateurs à implémenter, en fonction du degré de difficulté. Cependant, un nouveau problème apparait pour le médiateur, qui doit pouvoir produire du code pour des adaptateurs de fonctionnalités variables. Pour ce faire, le médiateur exploite la connaissance des fonctionnalités des adaptateurs, exprimées par les opérateurs logiques supportés, et étend les algorithmes traditionnels de traitement de requête par manipulation d'arbres algébriques.
Pour traiter efficacement une requête, le médiateur doit produire un plan d'exécution optimisé, sous forme d'un arbre d'opérateurs algébriques dont les sous-arbres sont envoyés aux adaptateurs concernés. Dans une base de données traditionnelle, l'optimisation de requête repose sur l'estimation de coût (en terme de temps de calcul) des différents plans d'exécution possibles. Avec Disco, ce type d'optimisation est délicat car les sources de données n'exportent pas d'information sur le coût des opérateurs supportés.
Notre approche à ce problème est nouvelle. Elle s'appuie sur un modèle de coût générique, qui peut être progressivement affiné en par l'ajoût d'information de coût spécifique exportée par les adaptateurs. Ainsi le développeur d'un adaptateur peut choisir de spécifier avec une interface standard tout ou partie de l'information de coût. Par défaut, le médiateur supporte son modèle de coût générique et le corrige dynamiquement avec l'information importée des adaptateurs. Nous avons expérimenté cette approche sur des sources de données ObjectStore avec le benchmark OO7 et les résultats donnent des performances bien meilleures qu'avec l'approche plus classique de calibration.
Lorsque l'on déploie un système comme Disco sur un grand nombre de sources de données, il est très possible qu'une source soit indisponible (pour raison de panne, de surcharge ou autre). La solution la plus employée est d'ignorer silencieusement le problème (sans en informer l'utilisateur) ou de générer une erreur. Cependant, cette approche est inacceptable lorsque la probabilité de source indisponible n'est pas négligeable, ce qui est le cas sur Internet.
Notre solution consiste, lors de l'exécution de la requête, à noter l'indisponibilité d'une source et de produire une réponse partielle. Une réponse partielle est elle-même une requête qui résulte de l'évaluation partielle de la requête. Elle est composée des données qui ont pu être obtenues lors de l'évaluation et d'une représentation du travail restant à faire. Une réponse partielle peut être soumise ultérieurement pour obtenir le résultat complet. En attendant, l'utilisateur peut extraire l'information obtenue en formulant une requête secondaire, appelée requête parachute. Nous avons procédé à une étude systématique des différents types de réponses partielles et de requêtes parachutes, et développé les algorithmes pour les supporter dans Disco.
Participants : Mokrane Amzal , Mokrane Bouzeghoub ,
Françoise Fabret , François Llirbat , Maja Matulovic , Eric
Simon
Mots-clés : base de données active, optimisation
Résumé : Une application active est une application de bases de données qui permet l'exécution automatique de règles (dites actives) lorsque certains évènements surviennent. Le gestionnaire de règles actives est le composant de cette application qui est responsable de la définition et de l'exécution des règles actives.
Cette action s'est concentrée sur deux problèmes: (i) le développement de méthodes et d'outils permettant de concevoir et déployer au dessus de SGBD existants un gestionnaire de règles actives adapté aux besoins d'une application, et (ii) la conception d'algorithmes d'optimisation de règles actives.
Nous proposons une nouvelle approche pour la conception et le déploiement d'un gestionnaire de règles actives qui se décompose en trois phases successives. La phase conceptuelle consiste à concevoir un ensemble de tâches, et d'évènements associés déclenchant leur exécution, indépendamment de tout langage de règles actives. La phase logique consiste à définir une règle active pour chaque tâche, puis à spécifier la sémantique d'exécution de ces règles actives en fonction des besoins de l'application. Enfin, la phase physique consiste à réaliser un système d'exécution de règles actives efficace, et qui supporte exactement la sémantique spécifiée au cours de l'étape précédente, au dessus d'un SGBD donné, puis à programmer les parties condition et action de chaque règle dans un langage exécutable par ce SGBD. Nous proposons un modèle formel paramétré qui permet au développeur de facilement décrire la sémantique de ses règles, c'est à dire quand et comment les règles sont déclenchées, et quand et comment elles sont exécutées. Une propriété remarquable de notre modèle est qu'il capture à l'aide de quelques paramètres synthétiques, une très grande variété de modèles d'exécution de règles actives. Pour faciliter la mise en oeuvre du système actif qui supporte l'exécution des règles spécifiées pour l'application, nous proposons une boîte à outils qui comporte un module logiciel générique (propre à toute application active) et des modules ad-hoc que l'on doit spécialiser en fonction des paramètres du modèle d'exécution des règles qui ont été choisis. Notre approche a trois avantages majeurs: (1) elle permet d'adapter précisément le modèle d'exécution de règles, et son système d'exécution associé, aux besoins d'une application; (2) à toute tâche définie au niveau conceptuel, il correspond une seule règle exécutable dans le système actif; (3) cette approche s'accomode naturellement d'une démarche incrémentielle de découpage successif d'une tâche en sous-tâches.
Une des principales entraves au développement d'applications actives dans l'industrie est le manque de performances des systèmes de bases de données actives existants. Nous avons développé deux méthodes complémentaires d'optimisation qui répondent à ce problème. La première permet une vérification efficace des contraintes d'intégrité (règles actives particulières) en fin de transaction. L'exécution de ces contraintes réduit le débit transactionnel pour deux raisons : (i) les verrous en lecture pris par les contraintes obligent des transactions écrivains à attendre (et inversement), et (ii) les verrous obtenus par une transaction ne sont libérés qu'après l'exécution des contraintes, ce qui crée des attentes avec des transactions concurrentes. Nous proposons de réduire considérablement cette perte de débit en utilisant un protocole spécial de contrôle des accès concurrents basé sur des versions. Ce protocole est implanté dans le système Validity commercialisé par NCM et l'étude fine de ses performances au sein de ce système fait l'objet d'une convention industrielle.
La seconde méthode permet d'optimiser l'exécution répétée de règles actives en évitant de générer des calculs redondants dans les composantes condition et action des règles. En utilisant un modèle capable de décrire des programmes, des règles et leurs interactions, nous avons proposé un algorithme qui extrait des expressions de requêtes invariantes dans les composantes condition et action des règles, suivant l'analyse de leurs contextes d'exécution. Des heuristiques simples s'appuyant sur des modèles de coût existants sont utilisées afin d'isoler les invariants les plus rentables à anté-mémoriser. Un algorithme permet de générer différentes versions d'une même règle en fonction de son contexte d'exécution et des invariants mémorisés. Ces versions de règles sont gérées dynamiquement pendant l'exécution d'une application. Cette méthode a été élaborée dans le cadre de règles actives se conformant au modèle d'exécution de la proposition de standard SQL3. Elle a été mise en oeuvre au dessus du SGBD Oracle.
Participants : Mokrane Bouzeghoub , Françoise Fabret ,
François Llirbat , Maja Matulovic , Esther Pacitti , Khalil
Seklani , Eric Simon
Mots-clés : gestion de transactions, réplication de
données
Résumé : Un entrepôt de données (``data warehouse'', en anglais) contient des données intégrées et synthétisées à partir de multiples sources de données opérationnelles. Ces entrepôts sont essentiels pour les systèmes d'aide à la décision, l'orpaillage des données, et la gestion intégrée des données d'entreprise.
Cette action se concentre sur deux problèmes importants qui sont la conception et le rafraîchissement des entrepôts de données.
Lorque les sources de données opérationnelles changent, il faut rafraîchir les données de l'entrepôt. Ce processus comporte trois grandes tâches elles mêmes décomposées en sous-tâches : (1) la tâche de préparation qui comprend l'extraction, la transformation, le nettoyage, et l'archivage intermédiaire éventuel de données, (2) la tâche d'intégration qui comprend l'intégration de données, le calcul des changements à effectuer sur l'infocentre (ou ``operational data store'', en anglais), lorsqu'il existe, et sa mise à jour, et enfin (3) la tâche de chargement qui comprend le calcul des changements sur l'entrepôt et sa mise à jour. Concevoir un système de rafraîchissement est compliqué pour trois raisons. D'abord, la gestion des évènements qui déclenchent l'exécution des sous-tâches est complexe (conditions temporelles, conditions logiques portant sur des évènements distribués). Ensuite, la planification des tâches est délicate (exécutions en série ou parallèle, ordonnancement, synchronisation). Enfin, les spécifications du système sont sujettes à changement et il faut donc disposer de méthodes de maintenance rapides et efficaces. Nous appréhendons un système de rafraîchissement comme une application active de gestion d'évènements distribuées dans un environnement de bases de données. Pour déployer cette application, nous utilisons l'approche développée plus haut.
Pour construire un entrepôt de données, on est souvent amené à copier des données (les copies sont appelées réplicats) provenant de plusieurs sources de données, puis à les recomposer dans une base de données particulière sur le site de l'entrepôt. Cet entrepôt doit servir à répondre à des requêtes décisionnelles tout en garantissant des contraintes de fraicheur, c.à.d. que les données de l'entrepôt diffèrent des données initiales dans des limites spécifiées à l'avance. Nous avons développé de nouvelles méthodes de propagation des mises à jour des sources vers les copies secondaires qui augmentent la fraîcheur des données lorque les transactions sont longues ou peu denses. Le comportement de nos méthodes a été comparé aux méthodes existantes de gestion des réplicats à l'aide d'un simulateur construit au dessus du SGBD Oracle.
Participants : Ioana Manolescu , Marcin Skubiszewski ,
Florian Xhumari
Mots-clés : gestion d'objets, ramasse-miettes
Résumé : Cette action a pour objectif la conception de mécanismes et d'outils système performants qui sont à la base des SGBD à objets. Les SGBD à objets sont en forte croissance. Le caractère moderne et solide de la technologie objet permet de croire que cette croissance se poursuivra à long terme.
Cette année, nous avons continué le travail sur un ramasse-miettes (GC) concurrent et efficace pour SGBD à objets. Nous avons également commencé a travailler sur un microbenchmark pour SGBD à objets, c'est-à-dire sur un banc d'essai destiné à mesurer le coût individuel de chaque opération élémentaire qui peut être effectuée dans un système.
Notre ramasse-miettes fonctionne selon le principe bien connu de marquage-balayage, mais utilise une technique nouvelle pour résoudre le problème le plus délicat, à savoir pour avoir une vision cohérente du système malgré le fonctionnement concurrent (concurrent signifie que le GC peut s'exécuter en parallèle avec les autres activités du système, sans être gêné par elles, et sans les gêner). Ce mécanisme s'appelle coupes GC-cohérentes; il consiste à mémoriser l'ancien état des pages dont la modification risque d'introduire des incohérences. Le GC utilise l'état mémorisé à la place de l'état courant. Les coupes GC-cohérentes ressemblent aux coupes causales, bien connues dans le monde des systèmes répartis.
Les coupes GC-cohérentes présentent deux avantages. D'abord, contrairement à toutes les autres techniques, elles n'impliquent aucun surcoût lorsque le GC ne s'exécute pas. Cette qualité est plus importante que l'efficacité du GC car dans les applications réelles, le GC ne s'exécute que pendant une faible fraction du temps total de fonctionnement d'un système. Ensuite, elles sont très efficaces (peu d'entrées-sorties) lorsque le système utilise un journal des images après, ce qui est le cas de plusieurs SGBD à objets, comme par exemple O2.
Notre contribution de cette année a consisté d'une part à continuer (et pratiquement terminer) la mise en oeuvre industrielle du ramasse-miettes, et de l'autre à raffiner le travail sur les fondements théoriques du projet.
Le microbenchmark qui nous sommes en train de développer servira à mesurer individuellement les performances de chaque opération élémentaire d'un SGBD à objets. Il permettra une étude détaillée de l'influence de différents facteurs sur cette performance (ces facteurs incluent la taille de la base de données, le nombre de clients simultanément connectés, la répartition des objets sur le disque etc.).
Ce projet est motivé par un très fort besoin de bancs d'essai, qui existe aujourd'hui dans le monde des SGBD à objets et des systèmes à objets persistants. Il n'existe pas aujourd'hui de bancs d'essai répondant convenablement à ce besoin. Les deux seuls bancs d'essai publiés, à savoir OO1 et OO7, sont loin d'être satisfaisants (notamment, ils donnent des résultats difficiles à interpréter).
Cette année, nous avons terminé la phase préliminaire de travail sur le microbenchmark : nous avons développé une première version, et effectué plusieurs mesures de performances sur trois systèmes à objets persistants (les systèmes industriels O2 et ObjectStore, ainsi que le système expérimental Shore).
Précédent : Logiciels
Remonter : Projet RODIN, Systèmes de Bases
Suivant : Actions industrielles