habilitation a diriger des recherches en informatique …pucheral/publis/hdr_final.pdf ·...

Cohérence et performance des traitements multibases

Philippe PUCHERAL

Rapport scientifique présenté pour l'obtention de l'

HABILITATION A DIRIGER DES RECHERCHES EN INFORMATIQUE

Université de Versailles / St-Quentin

Rapporteurs : Michel ADIBA (Professeur, Univ. Grenoble I) Jean FERRIE (Professeur, Univ. Montpellier II) Chandrasekaran MOHAN (IBM Fellow, IBM Almaden) Membres : Georges GARDARIN (Professeur, Univ. Versailles) André SCHIPER (Professeur, EPFL) Patrick VALDURIEZ (Directeur de Recherche, INRIA)

Remerciements

Je remercie vivement Michel Adiba, Professeur à l'Université Joseph Fourier de Grenoble, d'avoir accepté d'être rapporteur de ce travail d'habilitation. Nos rencontres précédentes m'ont permis d'apprécier sa rigueur scientifique et la pertinence de ses jugements et conseils.

Je remercie très chaleureusement Jean Ferrié, Professeur à l'Université de Montpellier II, pour m'avoir fortement encouragé à entreprendre ce travail d'habilitation et pour avoir accepté d'en être le rapporteur. Je voudrais également souligner le grand plaisir que j'ai eu à partager des travaux de recherche et de synthèse avec lui et son équipe. J'ai énormément bénéficié de sa large culture du monde transactionnel.

I am very honored by the participation of Doctor Chandrasekaran Mohan, IBM Fellow, to this jury, considering the great impact of his work on the whole database research community. I am particularly grateful to him for accepting to review my work.

Je remercie tout particulièrement Georges Gardarin, Professeur à l'Université de Versailles, pour la confiance permanente qu'il m'a apportée et pour l'ensemble des moyens qu'il a mis à ma disposition afin de mener à bien mes projets de recherche. J'ai trouvé en Georges Gardarin un conseiller chaleureux, avisé et toujours enthousiaste.

Je remercie André Schiper, Professeur à l'EPFL, pour m'avoir fait l'honneur de participer à ce jury et pour m'avoir donné goût à la recherche dans le domaine des systèmes répartis.

Je remercie également Patrick Valduriez, Directeur de recherche à l'INRIA, pour les nombreux conseils qu'il m'a prodigués depuis ma thèse et pour ses encouragements répétés à entreprendre ce travail d'habilitation.

Enfin, je tiens à remercier les thésards avec lesquels j'ai partagé mon travail de recherche, Maha Abdallah, Jérôme Besancenot, Leïla Hammami, Alejandro Gutiérrez et Fernando Machuca, pour leur amitié, leur enthousiasme et leur détermination. Merci également à Jean-Marc Thévenin pour notre longue et fructueuse coopération passée, à Luc Bouganim, Mokrane Bouzeghoub et Béatrice Finance pour leur amitié et leur complicité, à Annick Baffert et Chantal Ducoin pour leur disponibilité, aux membres du PRiSM pour leur sympathie. Merci enfin aux membres de l'ORC "Noyaux Transactionnels", et plus particulièrement à Rachid Guerraoui, Simone Sédillot et Bruno Traverson, pour leur aide et les discussions passionnées que nous avons régulièrement.

Et surtout, je remercie Fabienne, Maxime et Félix qui m'apportent tout ce dont j'ai besoin.

Table des matières

Table des matières 1

Préambule 3

Chapitre 1 : Introduction 7 1.1. Le contexte multibases 7 1.2. Problèmes abordés et contributions 11

1.2.1. Cohérence des traitements multibases 11 1.2.2. Performance des traitements multibases 12

1.3. Structure du document 14

Chapitre 2 : Cohérence des traitements multibases 17 2.1. Le contexte 17

2.1.1. Contrat de cohérence transactionnel 17 2.1.2. Modèle de transactions multibases 18 2.1.3. Problèmes abordés 19

2.2. Atomicité globale des transactions 21 2.2.1. Etat de l'art 21 2.2.2. Contributions 29

2.3. Sérialisabilité globale des transactions 34 2.3.1. Etat de l'art 34 2.3.2. Contributions 35

Chapitre 3 : Performance des traitements multibases 39 3.1. Le contexte 39

3.1.1. Intégration de schémas 39 3.1.2. Modèle d'exécution de requêtes multibases 40 3.1.3. Problèmes abordés 41

1

3.2. Requêtes multibases assertionnelles 43 3.2.1. Etat de l'art 43 3.2.2. Contributions 44

3.3. Requêtes multibases techniques 49 3.3.1. Etat de l'art 49 3.3.2. Contributions 50

3.4. Fouille de données 53 3.4.1. Etat de l'art 53 3.4.2. Contributions 55

3.5. Performance des traitements locaux 58 3.5.1. Etat de l'art 58 3.5.2. Contributions 59

Chapitre 4 : Prototypes 63 4.1. Cohérence des traitements multibases 63

4.1.1. Standardisation de la validation atomique 63 4.1.2. Intégration de NB-SPAC dans OTS et DTP 65 4.1.3. Contributions 67

4.2. Performance des traitements multibases 68 4.2.1. Le prototype GEODE 69 4.2.2. Les expérimentations 75 4.2.3. Contributions 76

Chapitre 5 : Conclusion et perspectives 78 5.1. Cohérence des traitements multibases 78 5.2. Performance des traitements multibases 80

Bibliographie 82

2

Préambule

Ce préambule a pour objectif de situer mes activités de recherche dans le temps. En effet, la

suite de ce document structure l'ensemble des travaux de recherche que j'ai mené ces dix

dernières années en fonction de leur problématique scientifique et non en fonction de leur

chronologie ou des projets dans lesquels ils ont été intégrés1.

J'ai obtenu ma thèse de doctorat de l'Université de Paris VI en Décembre 1989, sous la

direction du professeur Georges Gardarin. Cette thèse a été réalisée à l'INRIA Rocquencourt,

tout d'abord dans le projet SABRE dirigé par Georges Gardarin, puis dans le projet RODIN

dirigé par Patrick Valduriez. La thèse avait pour objet l'exécution efficace de traitements portant

sur de grandes bases de données réparties. Pour répondre à cet objectif, j'ai proposé, en

collaboration avec Jean-Marc Thévenin également thésard, un modèle de stockage et

d'indexation de données spécialisé pour des architectures à grandes mémoires centrales. Ce

modèle, appelé DBGraph, a été prototypé au dessus du gérant d'objets répartis GEODE,

également développé pendant ma thèse en collaboration avec Jean-Marc Thévenin. A la fin de

ma thèse, une version industrielle de ce prototype sera diffusée par Infosys, société pour laquelle

j'ai travaillé pendant dix-huit mois (1989-91).

En 1991, j'obtiens un poste de Maître de Conférences à l'Université de Versailles/St-

Quentin et j'intègre le thème "Bases de données" du laboratoire PRiSM où je poursuit mes

activités de recherche autour de l'exécution efficace de traitements répartis. En 1992, je crée

l'équipe “Noyaux Transactionnels pour Bases de Données” au sein du thème “Bases de

Données”. Quatre étudiants vont successivement effectuer leur thèse dans cette équipe et y

apporter toute leur énergie : Leïla Hammami, Jérôme Besancenot, Alejandro Gutiérrez et enfin

Fernando Machuca qui sera co-encadré par Georges Gardarin. Je commence à m'intéresser à la

1 Ce document fait également abstraction des tâches d'encadrement de thèses, d'animation de la recherche, de conduite de projets, qui sont afférentes à ces travaux. Enfin, certaines de mes publications sont omises ici (par

3

gestion de transactions car celle-ci à un impact important sur la performance des traitements

répartis. Cette même année, je démarre le projet Esprit IMPRESS dans lequel le laboratoire

PRiSM doit fournir un gérant d'objets réparti et transactionnel (c'est à dire tolérant aux

défaillances et contrôlant les accès concurrents) construit sur la base de GEODE.

En 1993, je deviens animateur de l'ORC "Noyaux transactionnels" du PRC-GDR BD3 qui

regroupe la communauté française travaillant dans le domaine des transactions en bases de

données. Mes activités se concentrent désormais sur l'étude des modèles de transactions

multibases2, en coopération avec le professeur Jean Ferrié du laboratoire LSI (Montpellier).

Cette activité d'animation de l'ORC se poursuit et me permet de nouer de nombreux contacts

avec différents laboratoires français publics (LSI, LIFL, IMAG, INRIA, IRIT, CRIN, UTC) et

privés (EDF/DER Clamart, CNET Lannion, Bull-Les Clayes-sous-bois).

En 1996, les thèmes de recherche de Georges Gardarin et les miens se rapprochent autour

de l'étude des systèmes multibases et donnent naissance à l'équipe "Bases de données

hétérogènes". Je démarre cette même année le projet Esprit OpenDREAMS dans lequel le rôle

du laboratoire PRiSM est de concevoir un service de transactions multibases pour une

architecture CORBA3. J'encadre actuellement une étudiante, Maha Abdallah, qui effectue sa

thèse sur ce sujet. A travers l'ORC "Noyaux transactionnels", je noue une collaboration étroite

avec des membres de l'équipe "Systèmes d'exploitation" de l'EPFL (Ecole Polytechnique

Fédérale de Lausanne) dirigée par le professeur André Schiper. Cette collaboration m'ouvre des

horizons sur l'étude des protocoles transactionnels non bloquants (i.e., dont la terminaison est

assurée quel que soit le type de défaillance). Je continue en parallèle à travailler sur l'exécution

efficace de traitements multibases avec Georges Gardarin, notamment sur la fouille de données.

En conclusion, j'ai travaillé pendant ces dix dernières années sur deux thèmes qui sont : (i)

la gestion de transactions réparties et (ii) l'exécution efficace de traitements répartis. Depuis

exemple, les livres d'enseignement). Ces informations font partie intégrante du curriculum vitae fourni en annexe. Ce préambule est donc un lien entre le présent document et le CV joint.

2 Multibases est un terme générique englobant les bases de données réparties et les bases de données hétérogènes. Ce terme sera décrit plus précisément dans l'introduction.

3 CORBA (Common Object Request Broker Architecture) est l'architecture à objets répartis promue par le consortium OMG (Object Management Group).

4

plusieurs années, j'étudie ces deux thèmes dans le contexte des systèmes multibases, ce qui

justifie le titre de ce document "Cohérence et performance des traitements multibases".

Il est tout à fait entendu que la majorité des résultats présentés dans ce document sont le

fruit de collaborations multiples, comme en atteste la liste de mes publications. J'en profite pour

exprimer ici ma reconnaissance à tous ceux et celles qui ont apportés leur concours à ces

travaux et pour cette raison, j'utiliserai dans la suite du document la première personne du

pluriel.

5

Chapitre 1

Introduction

1.1. Le contexte multibases

La diversification des applications bases de données et les récents progrès réalisés en matière de

communication (réseaux haut débit, normalisation des protocoles, explosion de l'internet)

poussent à la réalisation de systèmes d’information répartis de grande envergure. Ces systèmes

permettent d’accéder à de multiples sources de données préexistantes à travers un réseau local

ou longue distance. De ce fait, ils sont communément appelés systèmes d’information

multibases. Une source de données peut être définie comme une collection de données et de

traitements traditionnellement gérée par un Système de Gestion de Bases de Données (SGBD).

Les SGBD peuvent être de type réseau, relationnel, orienté objets ou encore propriétaire. Quand

un système multibases intègre des SGBD de types différents, on parle de système multibases

hétérogène. Un exemple de système multibases hétérogène peut être un système de supervision

d’une centrale nucléaire4 dans lequel les informations d'exploitation sont stockées dans une base

relationnelle, la documentation technique est stockée sous forme de documents hypermédia dans

une base objets et les informations temps-réel issues de capteurs sont stockées dans une base

propriétaire en mémoire centrale. La nécessité d’intégrer des bases de données préexistantes

d’une part et potentiellement hétérogènes d’autre part introduit de nouveaux problèmes non

directement adressés par les SGBD répartis. On peut donc considérer que les SGBD répartis

forment une sous-classe des systèmes multibases dans laquelle toutes les sources de données

sont homogènes et non autonomes.

4 Il s'agit là d'un exemple concret issu du projet Esprit IMPRESS (cf. chapitre 4).

7

Le principe d’un système multibases consiste à fédérer différentes sources de données

potentiellement hétérogènes et autonomes pour donner l’illusion à l’utilisateur d’une base de

données homogène et centralisée. Un exemple d’architecture de système multibases est donné

figure 1.1. On peut remarquer que les SGBD participant au système multibases peuvent être des

SGBD centralisés, répartis ou également multibases. Les participants à un système multibases

seront appelés par la suite SGBD ou sites locaux. Avant de détailler les principes de

l’architecture présentée figure 1.1, il convient de préciser les notions fondamentales qui

caractérisent les systèmes multibases, à savoir l’hétérogénéité et l’autonomie des sites

participants.

– Hétérogénéité structurelle : elle traduit entre les SGBD locaux une différence de modèle de données (e.g., réseau, relationnel, ou orienté objets), de langage de requêtes (e.g., DML Codasyl, SQL ou OQL) ou de protocoles internes (e.g., contrôle de concurrence par verrouillage, estampillage ou certification).

– Hétérogénéité sémantique : elle traduit entre les bases de données locales une différence dans la signification ou l’interprétation d’une même donnée. Par exemple, en supposant l’existence de données de type Voiture dans deux bases distinctes, l’attribut Voiture.prix peut s’entendre hors taxes dans une base et T.T.C. dans une autre.

– Autonomie de conception : elle interdit tout changement dans la conception et l’implantation des SGBD locaux. Le code d’un SGBD local est vu comme une boîte noire dont le système multibases doit s’accommoder. Ce principe garantit la pérennité des applications développées autour d’un SGBD local préalablement à son intégration dans un système multibases.

– Autonomie d’exécution : chaque SGBD local est responsable de l’exécution des transactions sur son site. Il est par exemple libre d’abandonner unilatéralement et à tout moment une transaction qu’il exécute, sans l’avis du système multibases. D'autre part, les exécutions locales issues d'applications existant préalablement à la constitution du système multibases ne doivent pas être gênées par les exécutions globales.

– Autonomie de communication : les SGBD locaux ne communiquent à priori aucune information de gestion à leurs partenaires. Par exemple, la détection d'interblocages globaux ne pourra pas reposer sur une quelconque connaissance des conflits locaux.

8

...

autre systèmeMultibases

Gestionnaire derequêtes globales

Gestionnairede Transactions

Globales

SGBD Objetscentralisé

BD1

SGBD Relationnelréparti

BD3BD2

Gestionnaire deschéma global

Figure 1.1. Exemple d’architecture d’un système multibases

Comme présenté sur la figure 1.1, le gestionnaire de schéma global, le gestionnaire de

requêtes globales et le gestionnaire de transactions globales sont nécessaires pour permettre le

développement d’applications multibases et les gérer de façon cohérente. Le rôle de ces trois

composants est résumé ci-dessous.

Gestionnaire de schéma global

Chaque base de données locale possède son propre schéma local exprimé dans le modèle

de données natif du SGBD local. L'objectif est de fédérer ces schémas locaux en un schéma

global qui donne une vue unifiée et homogène de l’ensemble des bases. Pour ce faire, il faut

choisir un modèle de données pivot dans lequel ce schéma global sera exprimé. Le modèle de

données pivot doit être le plus puissant possible afin de permettre, tant que faire se peut,

l'expression des concepts de l'ensemble des modèles de données locaux. C'est pourquoi l'on

choisit généralement un modèle de données pivot orienté objets tel que le modèle définit par

l'ODMG (Object Database Management Group) [ODM 93]. Tout ou partie de chaque schéma

local peut ainsi être exporté, c'est à dire traduit dans les concepts du modèle de données pivot.

Cette étape de traduction sera d'autant plus complexe que l'hétérogénéité structurelle est grande.

Le schéma global est ensuite construit par union des schémas locaux exportés. Cette union est

également complexe et difficilement automatisable du fait de l'hétérogénéité sémantique des

sites.

Gestionnaire de requêtes globales

On appelle requête globale, une requête d'interrogation ou de mise à jour qui porte sur le

schéma global du système multibases et qui peut donc manipuler des données issues de

plusieurs sites. Cette requête est exprimée dans le langage de manipulation de données (LMD)

9

associé au modèle pivot, par exemple OQL si le modèle pivot est celui de l'ODMG. Chaque

requête globale est décomposée en sous-requêtes locales, chacune étant destinée à un SGBD

local. Chaque sous-requête locale est ensuite traduite dans le langage natif du SGBD local, par

exemple SQL dans le cas d'un SGBD relationnel, puis exécutée. Les résultats des sous-requêtes

locales sont à nouveau traduits dans le modèle de données pivot puis agrégés avant d’être

retournés à l’application. Ces étapes de traduction sont d'autant plus complexes et coûteuses que

l'hétérogénéité structurelle est grande. D'autre part, l'optimisation de requêtes, c'est à dire la

détermination du meilleur plan d'exécution, est rendue difficile du fait de l'autonomie des sites

qui rend très approximative la prévision du coût d'exécution d'une sous-requête locale.

Gestionnaire de transactions globales

On appelle transaction globale, une transaction qui se développe sur plusieurs sites d’un

système multibases. Une transaction globale est décomposée en autant de branches que de sites

accédés. Du fait de l’autonomie d’exécution, chaque SGBD local exécute sans distinction les

branches de transactions globales qui lui sont adressées ainsi que des transactions locales qui

échappent au contrôle du système multibases. Les transactions locales sont des transactions

mono-sites qui proviennent d’applications antérieures à l’intégration du SGBD dans le système

multibases, dites applications héritées. L’hypothèse de base est que chaque SGBD local garantit

les propriétés transactionnelles ACID (Atomicité, Cohérence, Isolation, Durabilité) [BCF 97]

pour toutes les transactions dont il a la responsabilité. De ce fait, la gestion de transactions

globales dans un système multibases doit simplement garantir : (i) l’atomicité de chaque

transaction globale, c'est à dire que soit tous ses effets sont pris en compte sur l'ensemble des

sites soit tous ses effets sont annulés et (ii) la sérialisabilité globale des exécutions, c'est à dire

qu'une exécution concurrente de transactions globales donne un résultat équivalent à une

quelconque exécution en série de ces mêmes transactions globales. La condition (i) est rendue

difficile du fait de l’autonomie d’exécution qui autorise un SGBD local à abandonner

unilatéralement une branche de transaction globale. La condition (ii) est quant à elle rendue

difficile, du fait de l’hétérogénéité structurelle qui autorise différents sites à sérialiser leurs

transactions en utilisant des protocoles différents (verrouillage à deux phases, certification,

estampillage), du fait de l'autonomie de communication qui interdit toute observation des

protocoles locaux et enfin du fait de la présence de transactions locales qui échappent an

contrôle global.

10

1.2. Problèmes abordés et contributions

Comme il est apparu dans la section 1.1, les problèmes de recherche associés aux systèmes

multibases sont multiples et touchent aussi bien l'intégration de schémas que l'évaluation de

requêtes ou encore la gestion de transactions. Chacun de ces problèmes peut à son tour se

décliner en un nombre important de sous-problèmes. Durant les 10 années que couvre ce

document, mes activités de recherche se sont concentrées simplement sur deux aspects

fondamentaux des systèmes multibases, à savoir : (i) la cohérence des traitements, c'est à dire les

protocoles garantissant les propriétés ACID des transactions globales et (ii) la performance de

ces traitements, c'est à dire les modèles d'exécution assurant une exécution efficace des requêtes

globales et les modèles de stockage et d'accès assurant une exécution efficace des requêtes

locales. Les contributions associées à ces deux aspects sont brièvement présentées ci-dessous.

1.2.1. Cohérence des traitements multibases

Etant donné que les sites participant à un système multibases assurent localement les propriétés

ACID des branches de transactions qui les concernent, garantir la cohérence des traitements

multibases revient à assurer les propriétés d'atomicité et de sérialisabilité des transactions

globales.

Le problème d'atomicité des transactions globales a été largement étudié dans les systèmes

répartis mais il reste toujours d'actualité. La résolution du problème nécessite la définition d'un

protocole de validation atomique qui synchronise l'action de validation sur l'ensemble des sites.

Le protocole de validation atomique le plus célèbre est incontestablement le protocole de

validation à deux phases, appelé 2PC. Malgré son succès, ce protocole présente deux défauts

majeurs. Tout d'abord, il introduit un coût de communication important (4n messages échangés

pour n participants). D'autre part, il est bloquant, c'est à dire qu'une défaillance du coordinateur

entre les deux phases du protocole peut conduire les participants dans un état de blocage où ils

ne peuvent ni valider ni abandonner. Des variantes de ce protocole ont été proposées afin de

réduire son coût ou de le rendre non bloquant. Cependant, les optimisations proposées violent

généralement l'autonomie des sites alors que les variantes non bloquantes accroissent les coûts

de communication. Notre contribution sur ce point a été de montrer qu'il était possible de définir

un protocole de validation atomique qui : (i) ait un faible coût de communication, (ii) soit non

bloquant et (iii) préserve l'autonomie des sites, ceci en fixant certaines hypothèses sur le

comportement local de chaque site. Nous nous sommes ensuite attachés à relâcher ces

11

hypothèses ou à les rendre peu contraignantes. Ce travail a nécessité une redéfinition formelle

du problème de la validation atomique que nous avons appelé validation atomique dictatoriale.

Cette formalisation nous a permis de montrer l'équivalence entre le problème de la validation

atomique dictatoriale non bloquante et le problème du consensus, bien connu dans les systèmes

répartis.

Le maintien de la sérialisabilité des transactions globales est rendue difficile dans un

contexte multibases, notamment du fait que les sites participants peuvent sérialiser localement

les transactions en utilisant des protocoles différents. Des études antérieures ont introduit une

classification des protocoles de sérialisation locaux et ont défini pour chacune de ces classes le

contrôle global indispensable au maintien de la sérialisabilité globale des exécutions. La classe

des protocoles de sérialisation dits rigoureux est particulièrement intéressante car elle

caractérise la mise en oeuvre du verrouillage à deux phases (2PL), protocole le plus largement

utilisé dans la pratique. Nous avons montré que le contrôle global défini pour la classe des

protocoles rigoureux pouvait être pris en défaut (i.e., générer des exécutions non sérialisables)

pour une variante du verrouillage à deux phases, appelée 2PL strict, en cas d'exécution

d'opérations asynchrones. Nous avons ensuite proposé différentes alternatives pour rétablir la

sérialisabilité globale des exécutions.

1.2.2. Performance des traitements multibases

Comme il a été mentionné dans la section 1.1, les requêtes de tout utilisateur du système

multibases sont exprimées sur le schéma global dans le LMD associé au modèle de données

pivot. Elles sont ensuite décomposées en requêtes mono-sites puis traduites dans le langage natif

du site auxquelles elles sont destinées. Cette approche pragmatique a été suivie dans de

nombreux prototypes de recherche [Sma 97] mais elle présente peu d'opportunité quant à

l'optimisation des requêtes globales. Le processus traditionnel d'optimisation consiste en effet à

exprimer une requête dans un langage intermédiaire offrant des opérateurs dont le coût est

facilement quantifiable et dont les propriétés algébriques (commutativité, associativité,

distributivité) sont connues, puis à ordonnancer ces opérateurs par le biais de règles ou

d'heuristiques afin de construire un plan d'exécution optimal. Avant de pouvoir appliquer ce

même processus dans un environnement multibases, il faut tout d'abord définir un langage

intermédiaire qui soit suffisamment puissant pour être la cible de l'évaluateur de requêtes

globales et soit suffisamment simple et générique pour être traduit dans le langage natif de

12

chaque site (dont certains peuvent avoir des capacités d'interrogation très réduites). Notre

contribution porte sur la définition d'un tel langage. Le langage proposé, appelé OFL, est un

langage fonctionnel permettant notamment d'exprimer des itérations et des parcours de chemins

sur des collections d'objets génériques. L'originalité du modèle d'exécution associé est d'être

basé sur des parcours de graphes lui permettant de supporter des exécutions ensemblistes,

pipelines ou hybrides. Nous avons montré l'intérêt d'un tel langage dans un environnement

concret : la gestion de requêtes dans l'architecture TINA (Telecommunication Information

Networking Architecture).

La majorité des travaux portant sur l'exécution de requêtes multibases, y compris le travail

présenté ci-dessus, considèrent comme LMD pivot, un langage assertionnel du type OQL ou

SQL. Ces langages sont bien adaptés à la recherche d'objets par valeur. Cependant, de

nombreuses applications multibases s'intéressent plus aux liens entre les objets qu'à leur valeur.

C'est le cas par exemple des systèmes d'informations géographiques, des systèmes de routage,

des systèmes de supervision de réseaux divers (électriques, télécommunication, eau,

ferroviaires), qui introduisent le besoin d'interroger des données de type graphes par le biais

d'opérateurs tels que plus court chemin, chemin de capacité maximum, fermeture transitive. La

difficulté est que les noeuds et arcs du graphe peuvent être stockés sur des sites différents et être

modélisés par des objets complexes de façon très diverses (on ne modélise pas un réseau de

télécommunication comme un réseau ferroviaire). Notre contribution sur ce point a été d'adapter

le modèle traditionnel d'intégration de schéma et d'exécution de requêtes multibases au cas de

données techniques de type graphe. Nous avons ainsi proposé et implanté un modèle de données

pivot directement basé sur le concept de graphes, des opérateurs permettant de composer et de

traverser ces graphes et un modèle d'exécution efficace pour ces opérateurs permettant de

s'adapter aux capacités du langage natif des sites locaux.

Un autre type de traitement fréquent dans les applications multibases et qui ne s'exprime

pas en OQL ou SQL est la fouille de données, plus connu sous le nom anglais de data mining.

L'objectif est d'extraire automatiquement d'une ou plusieurs sources de données des

informations pertinentes cachées. Ces informations sont généralement des corrélations entre

données ou groupes de données (par exemple, les produits fromage et vin s'avèrent être

fréquemment achetés ensemble par les consommateurs). La complexité des algorithmes utilisés

pour la fouille de données est très importante (il existe 2n corrélations possibles dans un groupe

13

de n données). La majorité des travaux sur la fouille de données portent sur la minimisation des

entrées/sorties disque. Or les récents progrès technologiques permettent d'acquérir des machines

à grandes mémoires centrales (typiquement plusieurs Giga-octets) à des coûts abordables. Nous

considérons donc que la minimisation du coût CPU de ces algorithmes ne doit pas être négligée.

Dans cet objectif nous avons proposé un algorithme de fouille de données à base de tables de

bits compressées stockées en mémoire centrale. Des évaluations analytiques ainsi que des

mesures de performance ont montrées l'efficacité de cet algorithme.

L'ensemble des travaux cités précédemment portent sur l'exécution efficace des requêtes

globales. Dans un passé un peu plus lointain (en fait, lors de ma thèse), j'ai également travaillé

sur l'exécution efficace de requêtes locales dans un contexte de grande mémoire centrale. Bien

que ce travail n'ait pas été initialement conduit dans un contexte multibases, il s'y adapte

parfaitement. En effet, de nombreux systèmes multibases, comme les systèmes d'informations

techniques, intègrent des SGBD temps-réel gérant des données résidantes en mémoire centrale

(e.g., données issus de capteurs dans les systèmes de supervision ou encore données de routage

dans les autocommutateurs téléphoniques). La contribution sur ce thème a été la définition et

l'implantation d'un modèle de stockage et d'indexation pour données résidantes en mémoire

centrale. Le principe général de ce modèle, appelé DBGraph, consiste à matérialiser un objet

comme une entité référençant ses valeurs d'attributs par des pointeurs en mémoire. Ainsi, tous

les objets partageant une même valeur pour un de leurs attributs sont inévitablement reliés par

un chemin de longueur deux, aucune valeur n'étant dupliquée dans ce modèle. On montre alors

que toute requête d'interrogation SQL se traduit par un simple parcours de graphe en mémoire et

que la façon dont on exécute ce parcours permet de générer des exécutions ensemblistes ou

pipelines, avec les avantages respectifs associés à chacun de ces deux modes d'exécution. Ces

travaux antérieurs ont influencé d'une part le modèle d'exécution de OFL, en y intégrant des

exécutions ensemblistes et pipelines, et d'autre part l'algorithme de fouille de données en

exploitant la dimension grande mémoire.

1.3. Structure du document

La suite de ce document est structurée comme suit. Le chapitre 2 présente les activités que

j'ai menées sur l'aspect cohérence des traitements multibases. Le chapitre 3 présente quant à lui

mes activités sur l'aspect performance des traitements multibases. Ces deux chapitres sont

organisés de façon similaire. Ils contiennent une section d'introduction présentant le contexte

14

général, puis une section pour chacun des problèmes étudiés. Ces dernières sont elles-mêmes

décomposées en un état de l'art synthétique concernant le problème étudié et un résumé de la

contribution apportée par rapport à cet état de l'art. Le détail de chaque contribution n'est pas

présenté, le lecteur intéressé étant invité à consulter les articles référencés. Le chapitre 4

présente les prototypes réalisés pour valider les résultats théoriques introduits dans les chapitres

2 et 3. Enfin, le chapitre 5 résume les résultats obtenus et trace quelques orientations de

recherche.

15

Chapitre 2

Cohérence des traitements multibases

2.1. Le contexte

2.1.1. Contrat de cohérence transactionnel

La notion de transaction a été initialement introduite dans les SGBD et a été depuis généralisée

à tous les systèmes d’informations, qu'il s'agisse de systèmes de télécommunication, de contrôle

de processus industriel, de finance, ou encore de commerce électronique sur le World Wide

Web. La notion de transaction répond au besoin fondamental du maintien de la cohérence des

informations en cas d’accès concurrents ou de défaillances. De manière plus précise, une

transaction est une séquence d’opérations sur un ensemble d’objets qui vérifie les propriétés

suivantes, communément appelées propriétés ACID [BCF 97] :

(A) Atomicité

Soit une transaction se termine correctement, et elle a les effets désirés sur les objets manipulés (elle est validée), soit la transaction est interrompue et elle n’a aucun effet sur ces objets (elle est abandonnée). Cette propriété traduit un comportement de "tout ou rien".

(C) Cohérence

Une transaction préserve la cohérence des objets qu’elle manipule, c'est à dire qu'elle ne viole aucune des contraintes d'intégrité déclarées sur ces objets.

(I) Isolation

Les effets d’une transaction en cours sont invisibles aux transactions concurrentes. Cette propriété garantit qu'une exécution parallèle de transactions est sérialisable (i.e., équivalente à une exécution en série des mêmes transactions) et sans abandon en cascade (i.e., l'abandon d'une transaction n'a pas d'impact sur les transactions concurrentes).

(D) Durabilité

Les effets d’une transaction validée sont permanents. Ces effets peuvent donc être restaurés même en cas de défaillance mémoire ou de défaillance disque.

17

On parle fréquemment de contrat de cohérence transactionnel établi entre l'utilisateur et le

système transactionnel, dans le sens où la cohérence des informations est préservée si le premier

assure la propriété C et le second les propriétés A, I et D.

2.1.2. Modèle de transactions multibases

La figure 2.1 décrit le modèle de transactions multibases considéré dans ce chapitre et

introduit les notations associées. Il s'agit d'un modèle très général pris comme référence dans la

littérature [BGS 92, BCF 97]. Les sites ou SGBD locaux participant au système multibases sont

notés S1, S2 ..., Sn. Les transactions globales, notées TG, se développent sur plusieurs sites du

système multibases et sont décomposées en autant de branches que de sites accédés. A titre

d’exemple, la figure 2.1 montre une transaction globale TGi décomposée en deux branches TGi1

et TGi2 accédant respectivement aux sites S1 et S2. Les transactions globales sont gérées par un

Gestionnaire de Transactions Globales, noté GTG.

Chaque SGBD intègre un Gestionnaire de Transactions Locales, noté GTL, qui garantit les

propriétés ACID de toutes les transactions qui lui sont soumises. Comme indiqué dans

l'introduction, le GTL traite de façon uniforme les branches de transactions globales soumises

par le GTG et les transactions locales, notée TL, qui sont des transactions mono-site provenant

d'applications antérieures à l’intégration du SGBD dans le système multibases et qui échappent

au contrôle du GTG.

En ce qui concerne les contraintes d'intégrité portant sur les données, on distingue la notion

de contrainte d’intégrité locale, notée CIL, connues des SGBD locaux et ne portant que sur les

données locales à un site, de la notion de contraintes d’intégrité globales, notées CIG, connues

du seul système multibases et pouvant lier des données de différents sites.

Enfin, pour préserver l’autonomie des sites, on considère que les propriétés ACID des

transactions sont localement assurées par des protocoles quelconques. De même, le mode

d’interaction entre le système multibases et les SGBD locaux est considéré comme quelconque,

à l’exception du fait que le système multibases reçoit un acquittement pour chaque opération

soumise. Sans perte de généralité, on considère que les opérations soumises sont des lectures et

écritures sur des objets élémentaires.

18

SGBD 1 sur Site S1

TGTLTL

CIG

TG

GTG

CIL

TG

i

i1 i2

GTL1 2GTL

k m

SGBD 2 sur Site S2

Figure 2.1. Modèle de transactions multibases

2.1.3. Problèmes abordés

Il est facile de montrer qu’en l’absence de contrôle global, l'hétérogénéité et l'autonomie des

sites combinées à la présence de transactions locales peut engendrer une violation de la

sérialisabilité des transactions globales. Pour s'en convaincre, étudions le problème introduit

dans [BGS 92].

Intuitivement, la sérialisabilité des transactions globales devrait être préservée si celles ci

sont exécutées en série par le GTG (i.e., si la première opération de TGj n’est soumise qu’après

l'acquittement de la dernière opération de TGi). L’exemple présenté en figure 2.2 montre le

contraire. Soient les objets x et y stockés sur le site S1 et les objets z et u stockés sur le site S2.

Soient deux transactions globales TG1 et TG2 exécutées en série par le GTG et deux transactions

locales TL3 et TL4 respectivement exécutées sur les sites S1 et S2 et définies comme suit :

TG1 : lire1[x] lire1[z] TL3 : écrire3[x] écrire3[y] TG2 : lire2[y] lire2[u] TL4 : écrire4[z] écrire4[u]

Avec l’hypothèse que les SGBD locaux sérialisent les transactions par un moyen

quelconque, les histoires locales suivantes sont sérialisables et peuvent donc être produites :

H(S1) : lire1[x] V1 écrire3[x] écrire3[y] V3 lire2[y] V2 H(S2) : écrire4[z] lire1[z] V1 lire2[u] V2 écrire4[u] V4 Vi correspond à l'opération de validation de Ti

Figure 2.2. Exemple d’exécution série non globalement sérialisable

L’ordre de sérialisation résultant est TG1→TL3→TG2 sur S1 et TG2→TL4→TG1 sur S2. La

sérialisabilité globale n’est donc pas respectée puisque TG1 et TG2 sont sérialisées dans un ordre

différent sur S1 et S2. Le problème vient du fait que les transactions locales T3 et T4, inconnues

du GTG, génèrent un conflit indirect entre les transactions globales TG1 et TG2.

19

L’atomicité des transactions globales est encore plus facilement violée en l'absence de

contrôle global. En effet, l’autonomie d’exécution autorise un site à abandonner unilatéralement

une branche de transaction globale. Le scénario suivant est par conséquent possible : après

avoir exécuté toutes les opérations d’une transaction globale TGi, il se peut que le GTG

demande la validation des branches TGi1 et TGi2 et que S1 valide TGi1 alors que S2 abandonne

TGi2. Même si le GTG garde trace dans un journal des mises à jour effectuées par TGi, il n’a

plus alors de moyen sûr de restaurer la cohérence de la base du fait de l’existence de

transactions locales. Il ne peut pas lancer une transaction de compensation TGi1-1

pour défaire

les mises à jour de TGi sur S1 car des transactions locales ont pu consulter ces mises à jour entre

la validation de TGi1 et le lancement de TGi1-1. Il ne peut pas non plus lancer une nouvelle

transaction TG’i2 pour refaire les mises à jour de TGi2 sur S2 car ces mises à jour peuvent être

rendues incohérentes ou impossibles du fait d’autres mises à jour effectuées sur les mêmes

objets par des transactions locales entre l’abandon de TGi2 et le lancement de TG’i2.

Dans un système réparti, ce type de situation incohérente est évitée par la mise en oeuvre

d'un protocole de validation atomique (e.g., le 2PC). Imposer la participation à un protocole de

validation atomique va à l'encontre de l'autonomie de sites. Cependant, le protocole 2PC ainsi

que ses interfaces sont désormais normalisés par différents organismes [ISO 92a, OMG 96,

X/Op 96] et ces standards sont aujourd'hui largement suivis par les SGBD, aussi bien

relationnels qu'orientés objets. De ce fait, beaucoup considèrent que l’hypothèse d’autonomie

d’exécution interdisant la participation d’un site à un protocole de validation atomique n'est plus

d’actualité. Cependant, le fait que le protocole 2PC normalisé engendre un coût de

communication important et soit bloquant représente à son tour une violation de l'autonomie des

sites puisqu'il peut ralentir, voire bloquer l'exécution des transactions locales. Par conséquent,

même si l'on accepte l'hypothèse de participation de tous les sites à un même protocole de

validation atomique, il est nécessaire d'en minimiser le coût et d'en assurer le non blocage.

Les sections suivantes présentent un état de l'art ainsi que notre contribution sur ces deux

facettes de la cohérence des traitements multibases, à savoir la préservation de l'atomicité et de

la sérialisabilité des transactions globales. Les travaux sur l'atomicité sont présentés en premier

car certains de leur résultats sont utiles à la compréhension des travaux sur la sérialisabilité.

20

2.2. Atomicité globale des transactions

2.2.1. Etat de l'art

Comme indiqué en section 2.1.3, le problème de l'atomicité globale des transactions multibases

peut être facilement résolu dés lors que l'on fait l'hypothèse, aujourd'hui très raisonnable, que

tous les sites participent à un même protocole de validation atomique. Il est toutefois nécessaire

d'optimiser le protocole normalisé 2PC et d'en étudier des variantes non bloquantes, afin de

préserver l'autonomie des sites. Ceci explique le regain d'intérêt important pour ce problème

difficile, initialement introduit dans [Gra 78] et largement étudié depuis par les communautés

systèmes répartis et bases de données. Dans cette section, nous rappelons tout d'abord la

définition formelle de ce problème, puis nous résumons le protocole 2PC de base et ses

optimisations majeures et enfin, nous introduisons les variantes non-bloquantes de ce protocole.

Nous avons essayé dans cet état de l'art d'être aussi synthétique et complet que possible, pris

entre la contrainte de place et la nécessité d'en dire suffisamment pour que la contribution

introduite en section 2.2.2 soit compréhensible et correctement motivée. Une version étendue de

cet état de l'art peut être trouvée dans [AP 98b].

Définition formelle du problème de validation atomique

Le problème de la validation atomique est un problème d'accord entre les différents

participants à une transaction sur l'issue de cette dernière. Chaque participant révèle sa capacité

à valider en émettant un vote. Un vote oui implique que le participant s'engage à rendre

permanentes les mises à jour effectuées par la transaction même s'il tombe en panne. Un vote

non indique qu'il ne pourra pas valider due à un problème interne. Plus formellement, le

problème de la validation atomique est défini par les quatre propriétés suivantes [BHG 87] :

• Accord Uniforme: tous les participants qui décident (de valider ou d'abandonner), prennent la même décision.

• Validité: la décision de valider est prise uniquement si tous les participants ont voté oui.

• Intégrité: chaque participant décide au plus une fois.

• Non-Trivialité: si tous les participants votent oui et aucune panne ne se produit, alors tous les participants doivent décider de valider.

21

Le protocole 2PC de base

Comme son nom l'indique, le protocole 2PC (Two-Phase Commit) est formé de deux

phases: une phase de vote et une phase de décision. Un site nommé coordinateur a la

responsabilité de diriger les participants d'une transaction distribuée afin d'aboutir à une

décision uniforme. Pendant la phase de vote, le coordinateur envoie un message de demande de

vote, appelé message prepare, à tous les participants. Un participant qui vote pour l'abandon

(message abort) peut abandonner unilatéralement sa branche de transaction. Par contre, s'il vote

pour la validation (message ready), il entre dans un état appelé "prêt à valider" et doit se mettre

en attente de la décision finale du coordinateur. Dans la deuxième phase, le coordinateur reçoit

les votes, puis informe les participants de sa décision. La décision est de valider la transaction si

tous les participants ont voté ready et de l'abandonner sinon.

Un protocole de validation atomique doit être tolérant aux défaillances (de sites ou de

communications). Pour ce faire, les différentes étapes du protocole 2PC sont enregistrées dans

des journaux maintenus par le coordinateur et les participants. Une écriture dans le journal est

dite non forcée si elle est effectuée en mémoire puis reportée de façon asynchrone sur disque.

Elle est dite forcée si elle impose le report immédiat du contenu du journal sur disque. Cette

distinction est importante car elle détermine le nombre d'entrées/sorties disque (E/S) bloquantes

nécessaire au bon déroulement du protocole. La figure 2.3 détaille les deux phases du protocole

ainsi que les informations de journalisation associées.

R/A

E

RP

PreparePrepare

VoteVote

DécisionDécision

Ack_Décision

Ack_Décision

: écriture forcée: écriture non forcée

Coordinateur P1 P2

B

R/A

C/A

C/AC/A

B : Begin C : CommitA : AbortR : ReadyE : End transactionR/A : R ou AC/A : C ou A

Figure 2.3. Le protocole 2PC de base

La simplicité de ce protocole en a fait son succès. Il présente cependant deux inconvénients

majeurs. Premièrement, il est formé de quatre séquences de messages (demande de vote, vote,

décision et acquittement), ce qui introduit un coût de communication important et un temps de

22

latence5 élevé même en l'absence de pannes. Deuxièmement, il est bloquant: si le coordinateur

tombe en panne entre la phase de vote et la phase de décision (cette période est appelée fenêtre

de vulnérabilité), tous les participants qui sont en attente de la décision restent bloqués jusqu'à

la reprise du coordinateur et ne peuvent libérer les ressources détenues par cette transaction.

Les optimisations du protocole 2PC

Les optimisations du 2PC sont nombreuses [Tra 92, LAE 94, BCF 97] et portent

essentiellement sur trois facteurs : réduction du coût de communication, réduction du nombre

d'écritures forcées dans les journaux et enfin réduction de la latence du protocole.

Les optimisations Read-Only et One-Phase Commit sont les plus courantes et les plus

simples. L'optimisation Read-Only concerne les branches de transaction n'ayant fait que des

opérations de lecture. Puisque ces branches ne peuvent en aucun cas violer l'atomicité de la

transaction, on évite de les faire participer à la seconde phase du protocole. L'optimisation One-

Phase Commit est utilisée lorsqu'une transaction n'a accédé qu'à un seul site. Dans ce cas, le

coordinateur diffuse au participant unique sa décision, sans vote préalable.

Le 2PC décentralisé (D2PC) a pour objectif la réduction du nombre d'étapes de

communication. Dans le D2PC, le coordinateur diffuse une demande de vote à tous les

participants et chaque participant diffuse son vote à tous les autres. En l'absence de panne,

chaque participant peut ainsi prendre une décision de façon décentralisée. Une étape de

communication est ainsi gagnée par rapport au 2PC centralisé au prix d'un nombre quadratique

de messages émis pendant la phase de diffusion des votes. Ce protocole n'a donc d'intérêt que si

le nombre de participants est faible ou si le réseau de communication est un réseau à diffusion.

L'objectif du protocole 2PC à abandon présumé (Presumed Abort ou PrA) [BHG 87] est de

réduire le nombre de messages échangés ainsi que le nombre d'écritures forcées dans les

journaux. Le comportement de ce protocole est résumé par la figure 2.4(a). Lorsque la

validation s'effectue avec succès, le comportement est identique à celui du 2PC traditionnel. Par

contre, si la validation échoue, aucune écriture n'est forcée dans le journal du coordinateur ni

5 Le temps de latence correspond au temps écoulé entre le moment où le coordinateur démarre le protocole et le moment où les participants reçoivent la décision et peuvent donc libérer les ressources locales liées à cette transaction.

23

dans celui du (ou des) participant(s) votant négativement. De plus, la diffusion de la décision

d'abandon n'est pas acquittée par les participants. En cas de panne du coordinateur, la trace de

cette transaction peut donc être perdue. Si, après reprise du coordinateur, un participant lui

demande dans quel état se trouve une transaction T et que le coordinateur n'en trouve aucune

trace dans son journal, il est déduit que la transaction a été abandonnée (c'est la présomption

d'abandon) et en informe le participant. Ce protocole a été normalisé par l'ISO sous le nom OSI-

TP (Open Systems Interconnection - Distributed Transaction Processing) [ISO 92a] et est

désormais le protocole de référence. Comme le montre la figure 2.4(b), le protocole 2PC à

validation présumée (Presumed Commit ou PrC) [BHG 87] est le symétrique du protocole PrA.

Il réduit le nombre de messages et d'écritures forcées dans les journaux dans le cas où une

transaction valide. L'absence d'information concernant une transaction dans le journal du

coordinateur est ici interprétée comme une présomption de validation.

R

C

A

E

RP

CV C

PreparePrepare

ReadyReady

CommitCommit

Ack_Commit

Ack_Commit

BPrepare

Prepare

RPR

ReadyKO A

Abort


Coordinateur P1 P2

BR

C

RP

C

PreparePrepare

ReadyReady

CommitCommit

PreparePrepare

RPR

ReadyKO

Abort


Coordinateur P1 P2

B

C

B

A

AAck_Abort

A

E

(a) 2PC à abandon présumé (PrA) (b) 2PC à validation présumée (PrC)

Figure 2.4. Protocole 2PC avec présomption

Le protocole Early Prepare est une version de PrC poussée à l'extrême (cf. figure 2.5).

L'objectif est d'atteindre la borne minimale en nombre de messages échangés pour valider une

transaction. Pour cela, un participant se met dans l'état "prêt à valider" après l'exécution de

chaque opération d'une transaction et avant d'acquitter cette opération. De ce fait, la phase de

vote du protocole 2PC est intégrée à l'exécution même de la transaction. Deux cas sont alors

possibles. Soit au moins une opération échoue pendant l'exécution de la transaction et celle-ci

est abandonnée, soit toutes les opérations sont exécutées avec succès et le coordinateur

enregistre la décision de valider par une écriture forcée dans son journal, puis diffuse cette

décision à tous les participants sans attendre d'acquittement et enfin oublie la transaction. Tous

les participants étant déjà dans l'état "prêt à valider", la validation ne peut échouer.

24

L'inconvénient de EP réside dans le fait qu'il impose à un participant une écriture forcée dans

son journal pour chaque opération exécutée, ceci afin de se placer dans l'état "prêt à valider".

R

C

RP

C

opi

opk

Ready

Ready

CommitCommit


Coordinateur P1 P2

+ P1

C

R

opj

Ready

+ P2

R

opi

Ready+ P1

opk+ P2KO

Abort

A

AAck_Abort

A

E

Figure 2.5. Protocole Early Prepare (EP)

Dans tous les protocoles de validation atomique, le coût de journalisation est

majoritairement dû aux écritures forcées dans les journaux des participants pour que ceux-ci

puissent atteindre l'état "prêt à valider". L'idée maîtresse du protocole Coordinator Log (CL)

[SC 90] est de centraliser l'ensemble des journaux des participants sur le coordinateur. Pour ce

faire, à chaque fois qu'un participant exécute une opération de la transaction, il renvoie dans le

message d'acquittement les enregistrements de journal localement créés par l'exécution de cette

opération. La validation de la transaction s'effectue ensuite en une seule phase. Le coordinateur

enregistre la décision de valider ainsi que l'ensemble des enregistrements de journaux reçus des

participants en une seule écriture forcée dans son journal. Il diffuse ensuite la décision aux

participants sans attendre d'acquittement et oublie la transaction. En cas de panne d'un

participant après la prise de décision mais avant la validation effective du participant, celui-ci

contacte le coordinateur lors de sa reprise. Le coordinateur renvoie au participant les

enregistrements de journal lui permettant de restaurer les mises à jour de la branche de

transaction en question. La force de Coordinator Log par rapport à Early Prepare est de placer

l'ensemble des participants dans l'état "prêt à valider" en une seule écriture forcée. Cet avantage

se paie par la perte d'autonomie des participants, ceux-ci devant exporter leur journal local.

Le protocole Implicit-Yes Vote (IYV) [AC 95] est directement dérivé du protocole

Coordinator Log, bien que sa gestion des journaux diffère quelque peu. Comme dans

Coordinator Log, un participant joint au message d'acquittement de chaque opération les

enregistrements de journal produits par l'exécution de cette opération. Cependant, seuls les

enregistrements du journal d'images après (Redo Log) sont renvoyés et IYV ne les utilise que

25

lors de la reprise d'un participant. En effet, chaque participant continue à gérer son propre

journal de façon traditionnelle. L'intérêt est de conserver une certaine autonomie aux

participants au prix d'une journalisation duale.

Le tableau de la figure 2.6 récapitule la performance de chaque protocole en termes de

nombre de messages échangés, nombre d'écritures forcées et latence (exprimée en nombre

d'étapes de communication). Seul le cas où la transaction est validée est pris en considération, ce

cas étant considéré comme le plus fréquent. P représente le nombre de participants et N le

nombre d'opérations exécutées par la transaction. Les protocoles CL et IYV minimisent le temps

de détention des ressources d'une transaction. Conjointement, ce sont les protocoles qui

génèrent le plus faible nombre de messages et d'écritures forcées. Comme le montrera la section

2.2.2, ces bonnes propriétés se paient par des contraintes fortes sur les protocoles de

sérialisation des participants, par une perte d'autonomie des participants et par le fait qu'ils

étendent la fenêtre de vulnérabilité du protocole à toute la durée d'exécution d'une transaction. Messages Ecritures forcées

(coord. + participants) Latence

2PC 4P 1 + 2P 3 D2PC P + 2P(P-1) 1 + 2P 2 PrA 4P 1 + 2P 3 PrC 3P 2 + P 3 EP P 1 + (P + N) 1 CL P 1 1 IYV 2P 1 + P 1

Figure 2.6. Performance des différents protocoles de validation

La validation atomique non-bloquante

Le problème de la validation atomique non-bloquante est un problème d'accord tolérant

aux défaillances (i.e., non-bloquant) entre les participants à une transaction. Formellement, le

problème de la validation atomique non-bloquante s'exprime par les mêmes propriétés que la

validation atomique, plus la propriété de terminaison énoncée ci-dessous. Cette propriété permet

à tous les sites qui sont corrects (i.e., non défaillants) d'aboutir à une décision uniforme

concernant une transaction, malgré la défaillance d'un ou de plusieurs autres sites.

• Terminaison: tous les participants corrects finissent par prendre une décision.

Ce problème a principalement été étudié dans le contexte des systèmes synchrones. Un

système distribué est dit synchrone s'il existe une borne supérieure connue δ pour le délai

d'acheminement des messages sur un canal de communication. La connaissance de la constante

26

δ permet de détecter les défaillance de sites d'une façon fiable. Par exemple, si un site S1 envoie

un message m à un autre site S2 et qu'il ne reçoit pas de réponse après 2δ unités de temps (le

temps d'acheminement du message m et de sa réponse), il peut déduire, à coup sûr, que S2 est

défaillant. Cette détection fiable des défaillances de sites s'accompagne d'une hypothèse

complémentaire, la fiabilité des canaux de communication. En effet, il a été démontré qu'un

système distribué à communication non fiables n'admet pas de solution au problème de la

validation atomique non-bloquante [Gra 78].

Le premier protocole de validation non-bloquant proposé pour des systèmes synchrones est

le protocole à trois-phases (3PC) [Ske 81]. Le protocole 3PC ajoute au 2PC une phase de pré-

validation qui s'intercale entre la phase de vote et la phase de décision. Le comportement du

protocole 3PC est résumé sur la figure 2.7. L'objectif est de placer chaque participant dans un

état intermédiaire à partir duquel il lui soit impossible d'atteindre à la fois l'état "abandon" et

l'état "validation". Si une panne du coordinateur est détectée, tous les participants qui sont en

attente du message de pré-validation ou de la décision lancent un protocole de terminaison. Ce

protocole de terminaison va permettre de choisir un nouveau coordinateur parmi les sites

corrects. Ce dernier va tenter de terminer la transaction en dirigeant les autres sites vers une

validation ou un abandon, sa décision étant basée sur son seul état local. Le 3PC est non-

bloquant au prix de deux séquences supplémentaires de messages, même en absence de pannes,

ce qui le rend peu adapté aux systèmes actuels où le délai entre deux pannes (Mean Time

Between Failure) est de plus en plus élevé.

participantcoordinateur

Oui

(phase 3)

(phase 2)

(phase 1)

Etat de validation

Etat de pré-validation

Etat d'attente

Acq

Décision

Acq

Pré-validation

Prepare

Figure 2.7. Le protocole 3PC

27

Le protocole de validation non-bloquant ACP-UTRB [BT 93] a été proposé pour remédier

à la latence élevée du 3PC. ACP-UTRB a exactement la même structure que le 2PC et se

distingue simplement par la méthode de diffusion de la décision du coordinateur. Dans ACP-

UTRB, la diffusion de la décision se fait au travers d'une primitive de diffusion fiable qui assure

l'atomicité de la diffusion et dont le délai maximum d'exécution est borné par une constante ∆.

Dans cette primitive, lorsqu'un participant reçoit un message m pour la première fois (dans notre

cas, m contient la décision), il l'envoie à tous les autres participants avant de le traiter. Ainsi, si

un seul participant traite le message m, cette primitive garantit que tous les participants corrects

vont finir par recevoir et traiter ce message même si le site qui en a initié la diffusion (dans notre

cas, le coordinateur) tombe en panne. D'autre part, si un participant détecte la panne du

coordinateur, il arme un temporisateur à la valeur ∆. Si le temporisateur tombe à zéro alors

qu'aucun message de décision n'a été reçu, le participant est certain qu'aucun autre participant,

correct ou incorrect, n'a pu recevoir une décision de validation du coordinateur et il peut donc

abandonner la transaction unilatéralement, sans se bloquer. ACP-UTRB est réputé comme étant

le protocole de validation atomique non-bloquant pour systèmes synchrones le plus performant.

Peu de travaux ont porté jusqu'à présent sur le problème de la validation atomique non-

bloquante dans le contexte des systèmes asynchrones. Ceci s'explique par la démonstration dans

[FLP 85] de l'impossibilité de résoudre d'une façon déterministe un problème d'accord tolérant

aux défaillances dans un système asynchrone, ceci du fait de la non-fiabilité des détections de

défaillance. Il faudra attendre l'introduction du concept de détecteurs de défaillances non-

fiables[CT 96] pour contourner ce problème. [CT 96] montre notamment que le problème de

consensus, une forme abstraite de problèmes d'accord, peut être résolu dans un système

asynchrone augmenté d'un détecteur de défaillances non-fiable. Cependant, le problème de la

validation atomique non-bloquante ne peut toujours pas être résolu avec des détecteurs de

défaillances non-fiables à cause de la propriété de non-trivialité [Gue 95]. En effet, cette

propriété repose sur une connaissance précise, donc fiable, des défaillances des participants.

[Gue 95] montre qu'en affaiblissant la propriété de non-trivialité, on obtient un nouveau

problème, appelée validation atomique non-bloquante faible, qui peut être résolu avec des

détecteurs de défaillances non-fiables. La propriété de non-trivialité devient alors :

• Non trivialité faible: si tous les participants votent oui et aucun participant n'est soupçonné, alors tous les participants décident de valider.

28

Le protocole DNB-AC [GS 95] est ensuite proposé pour résoudre le problème de la

validation atomique non-bloquante faible. Intuitivement, DNB-AC a le même comportement

qu'un protocole 3PC décentralisé à la différence qu'il tolère les cas de pannes dans un système

asynchrone. Pour ce faire, DNB-AC utilise un protocole de consensus uniforme comme

protocole de terminaison en cas de panne d'un ou de plusieurs participants.

2.2.2. Contributions

Pour répondre aux objectifs introduits en section 2.1.3 et dans la droite lignée de l'état de l'art

présenté en section 2.2.1, nous nous sommes intéressé à l'optimisation des protocoles de

validation atomique et à la propriété de non-blocage de ces protocoles. Concevoir des protocoles

de validation atomique dont le coût de communication et la latence sont faibles et qui sont non-

bloquants a de tout temps été un challenge. Ce challenge est d'autant plus important à relever

dans les systèmes multibases qu'il détermine l'autonomie d'exécution des sites participants.

Si l'on se réfère au tableau comparatif présenté en figure 2.6, les protocoles de validation à

une phase, Coordinator Log et Implicit Yes Vote, ont indéniablement le meilleur comportement

en termes de coût de communication, nombre d'écritures forcées dans les journaux et temps de

latence. Leurs atouts sont donc nombreux pour devenir les protocoles de prédilection des

systèmes distribués en général et des systèmes multibases en particulier. Pourtant ces

protocoles, que nous nommerons par la suite protocoles 1PC (One-Phase Commit), ont

largement été ignorés dans l'implémentation et la normalisation des systèmes distribués. Ce rejet

s'explique par les hypothèses fortes faites sur le comportement des sites participants pour

assurer le bon déroulement du 1PC. La viabilité de ces hypothèses n'est pas démontrée et

certains mettent en cause le fait même que le 1PC garantisse vraiment l'atomicité des

transactions. En clair, la question de savoir si les protocoles 1PC ont un intérêt, aussi bien

théorique que pratique, n'a pas été tranchée. L'objectif de nos travaux est justement de tenter de

répondre à cette question. Nous avons tout d'abord montré formellement que le problème résolu

par le 1PC est légèrement différent de celui résolu par le 2PC. Alors que le 2PC prend en

compte le vote des participants pour déterminer leur capacité à assurer localement les propriétés

ACID d'une transaction, le 1PC suppose que ces propriétés sont satisfaites préalablement au

lancement du protocole. Cette observation nous a conduit à reconsidérer les protocoles 1PC

proposés dans la littérature afin d'en mieux cerner les contraintes et tenter de contourner ou

d'éliminer ces contraintes.

29

Définition formelle du problème résolu par le 1PC

Notre première contribution a été de décrire de façon formelle le problème résolu par le

1PC et d'en déduire les contraintes associées à cette classe de protocoles [AGP 98]. Le bénéfice

du 1PC par rapport au 2PC tient dans l'élimination de la phase de vote. Comme nous venons de

le souligner, la phase de vote du 2PC permet à un participant d'exprimer un vote négatif qui

conduira inévitablement à l'abandon d'une transaction si ce participant s'avère incapable

d'assurer localement une ou plusieurs des propriétés ACID de la transaction. L'idée sous-jacente

au 1PC est qu'un participant ne peut jamais voter non, rendant le vote inutile. Ceci ne veut pas

dire que toute transaction est systématiquement validée. L'abandon peut toujours être décidé en

cours de transaction si un participant acquitte négativement ou n'acquitte pas une opération ou

encore si le coordinateur tombe en panne avant la validation. Par contre, dans le cas le plus

fréquent où toutes les opérations de la transaction se sont normalement exécutées, le

coordinateur diffuse simplement la décision de valider aux participants. Puisque les participants

ne participent pas à un vote, on peut exprimer le problème résolu par le 1PC, que nous

appellerons problème de la validation atomique dictatoriale, de la façon suivante. Chaque

participant a une valeur initiale, valider ou abandonner, et peut atteindre la valeur de décision

de telle sorte que les propriétés suivantes soient satisfaites :

• Accord Uniforme: tous les participants qui décident prennent la même décision.

• Validité: la valeur de décision est une valeur initiale.

• Intégrité: chaque participant décide au plus une fois.

Ainsi, si un participant a correctement exécuté toutes les opérations d'une transaction et

qu'il n'a soupçonné aucune défaillance du coordinateur, sa valeur initiale sera valider, sinon elle

sera abandonner. De même, si le coordinateur a reçu un acquittement positif pour toutes les

opérations de la transaction, sa valeur initiale sera valider, sinon elle sera abandonner. D'une

façon similaire au consensus dans les systèmes répartis, le protocole de validation atomique

dictatoriale doit simplement garantir que tous les acteurs (participants et coordinateur)

s'accordent sur la même valeur de décision. Nous reviendrons plus tard sur cette similitude.

Notons que du fait de la propriété de validité, si toutes les opérations ont été correctement

exécutées et acquittées et en l'absence de soupçon de défaillance, la valeur de décision ne peut

être que valider.

30

Un protocole qui résout le problème de la validation atomique dictatoriale ne s'intéresse

qu'à la propriété d'atomicité de la transaction globale. Un tel protocole n'a donc de sens que si

les propriétés ACID de toutes les branches de la transaction globale sont assurées préalablement

au lancement du protocole. La validité des protocoles 1PC impose donc les hypothèses

suivantes [AGP 98] :

1. Toutes les opérations d'une transaction doivent avoir été acquittées avant le lancement du protocole. Ceci assure l'atomicité locale des branches de transaction.

2. Les contraintes d'intégrité doivent être localement vérifiées avant l'envoi de l'acquittement des opérations de mise à jour (i.e., pas de contraintes d'intégrité différées). Ceci assure la cohérence des branches de transaction avant le lancement du 1PC.

3. Les protocoles de sérialisation locaux doivent être pessimistes (i.e., pas de contrôle différé) et éviter les abandons en cascade. Ceci assure l'isolation des branches de transaction avant le lancement du 1PC.

4. Les effets de toutes les branches de transaction doivent être journalisés sur un support stable (e.g., un disque) avant le lancement du 1PC, ceci afin d'assurer la propriété de durabilité de la transaction.

Même si elles n'ont pas toutes été exprimées explicitement, ces hypothèses sont partagées

par les protocoles Coordinator Log et Implicit Yes Vote et plus généralement par tous les

protocoles 1PC. L'hypothèse 1 n'est pas considérée comme contraignante puisqu'elle apparaît

également dans les standards transactionnels tels que DTP de X/Open [X/Op 96] et OTS de

l'OMG [OMG 96] et l'hypothèse 2 peut être vue comme une simple règle de programmation

d'application. Par contre, l'hypothèse 3 est plus forte. En effet, même si la grande majorité des

SGBD sérialisent les transactions par un protocole de verrouillage 2 phases (2PL) qui est

pessimiste et sans abandon en cascade, beaucoup exploitent également les degrés d'isolation

définis dans SQL [ISO 92b] et donc acceptent localement certaines exécutions non isolées.

L'hypothèse 4 est encore plus forte car elle sous-entend que la journalisation sur support stable

est réalisée sur le site du coordinateur et donc que les participants externalisent leurs journaux

(ou pire que chaque opération entraîne une E/S bloquante dans le journal du participant, comme

dans le protocole EP). Cette externalisation, mise en oeuvre aussi bien par Coordinator Log que

par Implicit Yes Vote, constitue une grave atteinte à l'autonomie des sites. Enfin, il faut noter que

la suppression de la phase de vote étend la fenêtre de vulnérabilité du protocole à toute la durée

de la transaction et donc augmente la probabilité de blocage des participants. Nous analysons

chacune de ces contraintes dans les paragraphes suivants.

31

Contrainte d'externalisation des journaux

Notre seconde contribution a été de proposer un mécanisme de journalisation et de reprise

qui évite l'externalisation des journaux des participants [AP 98a]. Le principe consiste à

maintenir sur le site du coordinateur un journal contenant la trace de toutes les opérations

soumises à chaque participant. Une écriture forcée de ce journal est réalisée par le coordinateur

juste avant le lancement du protocole 1PC afin de satisfaire l'hypothèse 4. Journaliser l'envoi des

opérations plutôt que leur effet local, comme c'est le cas dans Coordinator Log et Implicit Yes

Vote, présente trois avantages majeurs : (i) l'autonomie des sites est préservée, (ii) le coût de

communication lié à l'externalisation des journaux est supprimé et (iii) cette technique de

journalisation est indépendance des stratégies locales de journalisation et donc s'adapte

parfaitement à un environnement multibases hétérogène. Ces avantages sont obtenus au prix

d'un mécanisme de reprise plus sophistiqué. En effet, en cas de panne d'un participant pendant le

déroulement du 1PC, la reprise consiste à ré-exécuter la branche de transaction défaillante afin

de préserver l'atomicité de la transaction globale. La difficulté est de garantir que cette ré-

exécution reproduise exactement le même état local que celui atteint lors de l'exécution initiale.

En bref, il faut assurer le déterminisme de la reprise alors que les opérations à ré-exécuter

peuvent être d'une part non-commutatives et d'autre part non-idempotentes. Notre mécanisme de

reprise exploite les hypothèses faites sur les protocoles de sérialisation locaux pour garantir la

correction de la reprise. Nous renvoyons le lecteur à [AP 98a] pour une présentation détaillée de

ce protocole et de la preuve de sa correction.

Contrainte du protocole de sérialisation

La troisième contribution porte sur l'hypothèse 3, imposant un protocole de sérialisation

local pessimiste et sans abandon en cascade. Comme nous l'avons déjà souligné, le protocole de

sérialisation le plus largement utilisé aujourd'hui est le 2PL qui satisfait bien l'hypothèse 3.

Cependant la majorité des SGBD relationnels combinent le 2PL avec les degrés d'isolation

standardisés par SQL 2 [ISO 92b, BCF 97] pour accroître le parallélisme entre transactions. Ces

degrés d'isolation permettent de considérer comme corrects certaines exécutions locales non

sérialisables et par conséquent ne respectent pas l'hypothèse 3. Nous avons montré que, sur les

quatre degrés d'isolation définis dans SQL 2 (Read Uncommitted, Read Committed, Repeatable

Read et Serializable), seuls les degrés Read Committed et Repeatable Read pouvaient générer

des incohérences lors d'une reprise après défaillance du protocole 1PC. Nous avons proposé un

32

protocole simple d'ordonnancement des demandes de validation pour les transactions s'exécutant

dans l'un de ces deux degrés afin de rétablir la cohérence des reprises en cas de pannes [AP 97].

Ainsi, le 1PC devient compatible avec tous les SGBD exploitant le 2PL avec ou sans degré

d'isolation, c'est à dire avec la quasi totalité des SGBD commerciaux.

Contrainte du blocage

Notre dernière contribution porte sur la propriété de non-blocage du protocole 1PC.

Comme nous l'avons déjà noté, la fenêtre de vulnérabilité du 1PC est très supérieure à celle du

2PC. En effet, le 2PC n'est bloquant qu'en cas de défaillance du coordinateur entre la phase de

vote et la phase de décision. Dans le 1PC, le seul moment où un participant est autorisé à

abandonner unilatéralement sa branche de transaction est entre l'instant où il reçoit une

opération à exécuter et l'instant où il renvoit l'acquittement de cette opération. Dans tous les

autres cas, si le participant détecte ou soupçonne une défaillance du coordinateur, il n'a aucun

moyen de savoir si la transaction est en cours d'exécution ou si sa validation a déjà démarrée. Ce

doute bloque le participant jusqu'à la reprise du coordinateur.

Nous avons proposé une première solution à ce problème dans le contexte des systèmes

synchrones [AP 99]. Cette solution est directement inspirée du protocole ACP-UTRB décrit

dans la section 2.2.1. Elle consiste à diffuser la décision du coordinateur par un mécanisme de

diffusion fiable. Le bénéfice par rapport à ACP-UTRB reste le gain de la phase de vote. Nous

sommes en train d'étudier le problème dans le contexte des systèmes asynchrones. En fait,

assurer le non-blocage du protocole 1PC revient à définir un protocole qui soit capable de

résoudre le problème de la validation atomique dictatoriale non-bloquante. Ce problème

s'exprime en ajoutant à la définition de la validation atomique dictatoriale, la propriété de

terminaison stipulant que tout participant correct finit par prendre une décision (cf. section

2.2.1). On montre alors que l'expression de ce problème est rigoureusement équivalente à

l'expression du célèbre problème du consensus dans un modèle crash-recovery [OGS 97]. Toute

solution au problème du consensus dans un modèle crash-recovery [ACT 98] est par conséquent

une solution au problème de la validation atomique dictatoriale non-bloquante.

Nous pouvons donc considérer que les contraintes majeures qui freinent l'exploitation des

protocoles 1PC peuvent être levées ou du moins fortement assouplies. Ce travail constitue le

cadre de la thèse de Maha Abdallah [Abd 99] et est en cours de validation par le développement

33

d'un prototype (cf. Chapitre 4). Les résultats obtenus sur le non blocage du 1PC dans un système

asynchrone ont été rendus possibles par une collaboration étroite avec Rachid Guerraoui,

membre de l'équipe "Systèmes d'exploitation" dirigée par le professeur André Schiper à l'EPFL.

2.3. Sérialisabilité globale des transactions


Puisque même une exécution en série des transactions globales ne garantit pas la

sérialisabilité globale (cf. section 2.1), il est nécessaire d'équiper le GTG d'un protocole de

contrôle de concurrence global. Intuitivement, plus le contrôle local est strict, plus le contrôle

global pourra être permissif et inversement. [BGS 92] a proposé une classification des SGBD en

fonction des propriétés de leur protocole de sérialisation local. Cinq classes de SGBD ont été

identifiées, de la plus générale à la plus restrictive : (i) les SGBD opaques pour lesquels on ne

dispose d'aucune information sur le protocole de sérialisation local, (ii) les SGBD fortement

sérialisables qui garantissent que si la dernière opération de Ti est exécutée avant la première

opération de Tj, alors Ti→Tj (i.e., Ti précède Tj dans l’ordre de sérialisation), (iii) les SGBD à

point de sérialisation pour lesquels il existe une opération particulière de chaque transaction,

identifiable par le GTG (par exemple le début ou la terminaison), dont l'ordre d'exécution

détermine l'ordre de sérialisation des transactions, (iv) les SGBD fortement recouvrables pour

lesquels ce point de sérialisation correspond à l'opération de validation de la transaction et enfin

(v), les SGBD rigoureux qui garantissent que si Tj exécute une opération conflictuelle avec une

opération déjà exécutée par Ti, alors l’opération de Tj n’a lieu qu’après la terminaison de Ti.

Cette classification a représentée une avancée théorique importante car elle a permis d'identifier,

pour chaque classe, le contrôle global nécessaire au maintien de la sérialisabilité globale.

Du point de vue pratique, deux classes sont particulièrement dignes d'intérêt. La classe des

SGBD opaques a l'avantage de la généralité puisque tout SGBD peut y être associé, y compris

les SGBD propriétaires possédant des protocoles de sérialisation exotiques ou les SGBD dont

on ne connaît rien (quel SGBD se cache derrière le site Web www.xxx.com ?). La classe des

SGBD rigoureux recouvre quant à elle la majorité des SGBD commerciaux. Elle capture en fait

le comportement du protocole de verrouillage à deux phases, de très loin le plus utilisé. Rétablir

la sérialisabilité globale dans chacune de ces deux classes s'effectue de la façon suivante. Dans

le cas des SGBD opaques, un objet séquenceur, couramment appelé ticket, est créé sur chaque

34

site. Cet objet est en fait un compteur que chaque transaction globale doit lire puis incrémenter.

La lecture et la mise à jour du ticket sur chaque site introduit un conflit direct entre chaque

transaction globale. La valeur lue du ticket du site Sk par une transaction globale indique donc

au GTG son ordre de sérialisation sur ce site. Il devient alors possible de construire

dynamiquement le graphe de sérialisation global et de détecter l'apparition éventuelle de cycles.

Dans le cas des SGBD rigoureux, il suffit simplement d'imposer que la validation d’une

transaction globale ne soit soumise sur chaque site que lorsque toutes les branches de cette

transaction ont terminé leur exécution. En effet, si l'on reprend l'exemple de la figure 2.2, un

protocole rigoureux autorise l’histoire produite sur S1 mais interdit l’histoire produite sur S2 en

bloquant lire1[z] jusqu’à la terminaison de TL4.

Les techniques précédentes réduisent fortement le parallélisme entre transactions globales

et/ou augmentent le risque d’abandon de transactions. Des techniques plus permissives ont été

proposées afin d’accepter certaines exécutions globalement non sérialisables. Ainsi ont été

introduites les notions d'exécution localement sérialisable (LSR) [KS 88], de sérialisabilité à

deux niveaux (2LSR) [MRK 91] ou encore de quasi-sérialisabilité (QSR) [DEK 91]. Par contre,

l'abandon de la propriété de sérialisabilité engendre un report, au moins partiel, du contrôle de la

cohérence globale des traitements sur l'application.


Dans nos travaux, nous nous sommes intéressé à la classe des SGBD utilisant localement un

protocole de sérialisation à base de verrouillage à deux phases (2PL), que nous considérons

comme la plus représentative de la technologie actuelle. Nous avons d'autre part considéré que

ces SGBD étaient capables de participer à un protocole de validation atomique, ce qui à

nouveau représente la majorité des SGBD depuis l'avénement des standards DTP de X/Open et

OTS de l'OMG. Il a été montré dans [BGR 91] que lorsque les SGBD locaux sont rigoureux et

qu'ils participent au protocole de validation atomique à deux phases (2PC), les exécutions

globales sont obligatoirement sérialisables même en l'absence de contrôle global. Ce résultat

explique pourquoi les moniteurs transactionnels (e.g., Encina, Tuxedo, TopEnd [BCF 97]) ne

proposent aucun protocole de sérialisation globale6. Cependant, s'il est vrai que la majorité des

6 De façon plus pragmatique, il semblerait que l'on ait découvert seulement à postériori que l'absence de protocole de sérialisation globale dans les moniteurs transactionnels était justifiée.

35

SGBD implantent un protocole de sérialisation basé sur du verrouillage à deux phases, tous les

protocoles de verrouillage à deux phases ne sont pas pour autant rigoureux.

Nous avons plus particulièrement étudié l'impact sur la sérialisation globale de l'utilisation

du protocole de verrouillage à deux phases strict (2PL strict), qui est une optimisation du

verrouillage à deux phases. L'idée du 2PL strict est de relâcher les verrous en lecture d'une

transaction dès que cette transaction entre dans l'état "prêt à valider" et de relâcher ses verrous

en écriture uniquement lorsqu'elle atteint l'état "validé" [BHG 87]. Par rapport au 2PL

rigoureux, les ressources en lecture sont donc relâchées de façon anticipée. Cette optimisation

est particulièrement intéressante dans un contexte multibases car elle permet à la fois d'accroître

le parallélisme entre transactions globales et d'accroître l'autonomie des sites en réduisant

l'attente des transactions locales. L'intérêt est encore plus important lorsque les branches d'une

transaction globale s'exécutent de façon asynchrone, comme c'est le cas dans les applications

interactives multi-fenêtres (e.g., CAO, AGL) ou dans les exécutions transactionnelles parallèles

ou à flot de tâches (transactional workflow en anglais). En effet, dans ce cas, certaines branches

d'une transaction globale peuvent entrer dans l'état "prêt à valider", et donc relâcher les

ressources détenues en lecture, alors que les autres branches de cette même transaction n'ont pas

terminé leur exécution.

Notre première contribution est d'avoir montré que l'association 2PL strict et validation

atomique 2PC ne garantit plus la sérialisabilité globale des exécutions [BCF 95a]. Pour s'en

convaincre, il suffit de consulter l'exemple de la figure 2.8. Dans la figure, pik (resp. vik)

représente le point où une branche de transaction TGik rentre dans l'état "prêt à valider" (resp.

"validé"). On remarque que pik précède ici pij avec pour conséquence que TGik relâche ses

ressources détenues en lecture alors que TGij poursuit l'acquisition de verrous. Le verrouillage

n'est plus globalement à deux phases et il peut en résulter une violation de la sérialisabilité

globale.

36

locks locking phase read unlocks write unlocks

v ik

v ij

pik

pij

TGij

TGi

ikTG

write unlocksread unlockslocking phase

1ère phase 2PC 2ème phase 2PC

Figure 2.8. Exécution globalement non 2PL

Notre seconde contribution est d'avoir montré que les SGBD exploitant le protocole 2PL

strict pouvait être rangés dans la classe des SGBD à point de sérialisation [BCF 95a]. En effet,

le point de sérialisation d'une branche de transaction TGik correspond à son point de verrouillage

maximal et ce point peut être estimé par le GTG comme étant atteint à l'instant pik, c'est à dire à

l'instant où le GTG envoie la demande de validation au site Sk. Il en résulte que les algorithmes

proposés pour rétablir la sérialisabilité des exécutions globales pour la classe des SGBD à point

de sérialisation s'appliquent à notre contexte. Le fait que ces SGBD participent au protocole

2PC permet des optimisations supplémentaires par rapport à ces algorithmes. Nous avons

proposé deux protocoles allant dans ce sens. Le premier, qualifié de pessimiste, est préventif de

la part du GTG. Il consiste à séquencer la validation des branches de transactions globales de

sorte à forcer un ordre de validation identique sur tous les sites pour toutes les branches d'un

même transaction globale. Le second protocole, qualifié d’optimiste, n’impose aucun

séquencement mais il contrôle à posteriori que les messages "prêt à valider" sont reçus dans le

même ordre en provenance des différents sites. Ces deux protocoles permettent de conserver le

bénéfice du 2PL strict, tout en assurant la sérialisabilité globale. Ils entraînent évidemment le

rejet de transactions considérées comme non sérialisables par le GTG. Le détail de ces

protocoles est présenté dans [BCF 95a].

Notre troisième contribution est d'avoir proposé des protocoles qui garantissent la

correction des exécutions globales tout en relâchant la propriété de sérialisabilité globale. En

effet, une analyse fine des exécutions non sérialisables produites par le protocole 2PL strict avec

2PC montre qu’elles peuvent entraîner des pertes d’écritures ou des écritures incohérentes vis à

vis des contraintes d'intégrité globales (CIG) pour les transactions globales comportant des

37

dépendances de valeur7. Ces anomalies sont en fait comparables à celles qui caractérisent les

transactions s’exécutant avec le degré d’isolation "Read Committed" dans les SGBD centralisés

[ISO 92b, BCF 97]. Pour éviter la perte d'écriture, les SGBD complètent le degré d’isolation

"Read Committed" avec un protocole appelé "Cursor Stability". Notre première solution étend

le concept de "Cursor Stability" aux transactions multibases pour contrôler la correction

d'exécutions non sérialisables [BCF 96]. Notre seconde solution repose sur la mise en place

d'une gestion de verrous globaux assurant que toutes les exécutions acceptées sont sérialisables

à deux niveaux (2LSR) [BCF 95b]. Il a été montré dans [KMR 91] que les exécutions 2LSR

sont correctes si les transactions globales et locales respectent des règles simples assurant la

préservation des contraintes d'intégrité locales et globales.

Ce travail a été réalisé en collaboration avec l'équipe du professeur Jean Ferrié du LSI

(Montpellier). Il a servi de cadre à la thèse de Jérôme Besancenot. Ainsi, des détails

complémentaires sur cette étude peuvent être trouvés dans [Bes 96].

7 On dit qu'une transaction globale TGi contient une dépendance de valeur si une écriture effectuée par une branche TGij dépend d'une lecture exécutée par une autre branche TGik.

38

Chapitre 3

Performance des traitements multibases

3.1. Le contexte

3.1.1. Intégration de schémas

Dans un système multibases, chaque base de données locale possède son propre schéma local

exprimé dans le modèle de données natif du SGBD local (Codasyl, relationnel, objet). L'objectif

est de fédérer ces schémas locaux en un schéma global qui donne une vue unifiée et homogène

de l’ensemble des bases. Le processus qui conduit à la définition du schéma global est appelé

intégration de schémas et sa complexité peut amener jusqu'à la définition de six niveaux de

schémas intermédiaires [SL 90]. Pour simplifier, on considère le processus suivant. Un modèle

de données pivot est tout d'abord choisit pour l'ensemble du système multibases et sera utilisé

pour déclarer le schéma global. Chaque site exporte ensuite tout ou partie de son schéma local

en traduisant celui-ci dans les concepts du modèle de données pivot. Cette étape, dite de

traduction de schémas, est rendue difficile du fait de l'hétérogénéité structurelle des sites (cf.

Chapitre 1). Enfin, les (sous-)schémas locaux traduits sont fusionnés pour former le schéma

global. Cette étape de fusion est, quant à elle, rendue difficile du fait de l'hétérogénéité

sémantique des sites et peut nécessiter une gestion de divers conflits (niveaux d'abstraction,

définitions de classes, divergences schématiques) [Sma 97].

Le choix du modèle de données pivot est déterminant dans la définition d'un système

multibases. Le modèle relationnel a souvent été retenu dans les premiers systèmes multibases

tels que MULTIBASE [LR 82] ou Mermaid [TBD 87]. Les systèmes multibases de seconde

génération, tels que Pegasus [AAD 93], Interbase [ME 93] ou IRO-DB [GGF 94], ont fait le

choix d'un modèle de données orienté objets, du fait de sa généralité. Dans cette voie, le modèle

39

définit par l'ODMG (Object Database Management Group) [ODM 93] constitue une alternative

standard. C'est donc celle que nous considérerons dans la suite de ce chapitre, à titre illustratif8.

3.1.2. Modèle d'exécution de requêtes multibases

On appelle requête globale, une requête d'interrogation ou de mise à jour qui porte sur le

schéma global du système multibases et qui peut donc manipuler des données issues de

plusieurs sites. Cette requête est exprimée dans le langage de manipulation de données (LMD)

associé au modèle de données pivot, par exemple OQL [ODM 93] si le modèle pivot est celui de

l'ODMG.

Le processus d'évaluation d'une requête globale comprend les étapes suivantes9. Après une

étape d'analyse syntaxique et sémantique traditionnelle, la requête globale est décomposée en

sous-requêtes locales, que nous appellerons par la suite requêtes locales dans un soucis de

simplification10, chacune étant destinée à un SGBD local. Chaque requête locale est ensuite

traduite dans le langage natif du SGBD local, par exemple SQL dans le cas d'un SGBD

relationnel. Cette étape de traduction est d'autant plus complexe que l'hétérogénéité structurelle

est grande. Le Gestionnaire de Requêtes Locales (GRL) du site concerné exécute alors la

requête locale et renvoie le résultat au Gestionnaire de Requêtes Globales (GRG). Le

gestionnaire de requêtes globales a ensuite la responsabilité d'agréger les résultats de l'ensemble

des requêtes locales pour constituer le résultat final, par une phase dite de recomposition ou

post-processing. Cette dernière phase peut correspondre à une simple union des résultats de

requêtes locales ou bien à une composition complexe d'opérateurs algébriques (e.g., jointure),

selon la complexité de la requête globale et les capacités de traitement de chaque site. Par

exemple, si un site n'a pas la capacité d'exécuter un opérateur P nécessaire à l'évaluation de la

requête globale, cette exécution sera à la charge du gestionnaire de requêtes globales lors de la

phase de recomposition.

8 Notons toutefois que les systèmes multibases de troisième génération choisissent des modèles de données pivot semi-structurés afin de permettre la fédération de sources de données contenant notamment des pages Web. Cette problématique est cependant en dehors du contexte de ce document.

9 La présentation du processus d'évaluation est ici simplifiée afin de correspondre à la vue du processus d'intégration de schémas donnée dans la section précédente.

40

SGBD 1 sur site S1

Décomposeur

RLi1 RLi2

GRL 21

GRL

SGBD 2 sur site S2

Requête Globale RGi

Traducteur

Recomposeur

Résultat

1

GRG

Traducteur2

Analyseur

Figure 3.1. Modèle d'exécution de requêtes multibases

La figure 3.1 illustre le modèle d'exécution de requêtes multibases considéré dans ce

chapitre. Comme le suggère la figure, le composant traducteur est spécifique à chaque site ou

plus précisément à chaque famille de participants (e.g., traducteur OQL/SQL, OQL/LMD

Codasyl). L'emplacement de ce composant (associé au gestionnaire de requêtes globales ou bien

à chaque site) est un choix architectural. Volontairement, aucun composant optimiseur

n'apparaît sur la figure 3.1. En effet, l'optimisation peut faire partie intégrante de chaque

composant : dans le décomposeur pour fixer la granularité de la décomposition (1 ou n requêtes

locales par site), dans le recomposeur pour fixer l'ordonnancement des opérations de

recomposition et enfin dans les gestionnaires de requêtes locales qui optimisent les traitements

locaux de façon autonome.

3.1.3. Problèmes abordés

Le premier problème abordé concerne l'évaluation performante de requêtes globales exprimées

dans un langage assertionnel de type OQL. La difficulté du problème provient de trois

principaux facteurs. Tout d'abord, l'autonomie des sites rend difficile, voire impossible,

l'estimation du coût des algorithmes locaux ainsi que l'estimation de la charge de chaque site.

La tâche de l'optimiseur de requêtes s'en trouve donc compliquée et son résultat en est d'autant

moins fiable. D'autre part, l'hétérogénéité structurelle permet l'intégration dans un système

10 En effet, la distinction entre sous-requête locale, issue de la décomposition d'une requête globale, et requête

41

multibases de sites offrant des capacités d'interrogation sommaires (e.g., parcours séquentiels ou

restrictions simples). Dans ce cas, certaines requêtes locales générées par le décomposeur

peuvent s'avérer impossible à évaluer sur les sites concernés. La solution consiste alors à

rapatrier dans le gestionnaire de requêtes globales l'ensemble des données de ces sites sur

lesquelles porte la requête, entraînant un coût de communication et une consommation de

ressources prohibitifs. Enfin, la sémantique même du langage OQL rend difficile le choix d'un

modèle d'exécution optimal11. En effet, OQL permet d'exprimer aussi bien des assertions sur des

ensembles de données, bien prises en compte par les modèles algébriques, que des parcours de

chemins pour lesquels les modèles navigationnels sont mieux adaptés. La section 3.2 présente

notre contribution sur ce point.

La majorité des travaux portant sur l'exécution de requêtes multibases considèrent comme

LMD pivot, un langage assertionnel du type OQL ou SQL, adapté à la recherche d'objets par

valeur. Cependant, beaucoup d'applications multibases s'intéressent autant aux liens entre les

objets qu'à leur valeur (e.g., systèmes d'informations géographiques, systèmes de supervision de

réseaux électriques ou de télécommunication). Ces applications nécessitent l'interrogation de

données de type graphes par le biais d'opérateurs tels que plus court chemin, chemin de capacité

maximum, fermeture transitive. Le second problème abordé concerne donc l'adaptation des

techniques traditionnelles d'intégration de schéma et d'exécution de requêtes multibases à ce

type de données. La section 3.3 présente notre contribution sur ce point.

Un autre type de traitement fréquent dans les applications multibases et qui ne s'exprime

pas directement en OQL ou SQL est la fouille de données (ou data mining). La problématique

n'est plus d'interroger des données stockées dans différentes sources mais plutôt d'extraire

automatiquement d'une ou plusieurs de ces sources des informations pertinentes cachées (e.g.,

des corrélations entre données). La complexité des algorithmes utilisés pour la fouille de

données est très importante (2n corrélations possibles entre n données). Il est donc important de

proposer des algorithmes qui minimisent ce type de traitements. La section 3.4 présente notre

contribution sur ce point.

locale, issue des applications héritées, est sans objet dans le contexte de ce chapitre.

11 Ce problème n'est pas lié au caractère multibases des requêtes mais il se pose avec d'autant plus d'acuité dans ce contexte.

42

Le dernier problème abordé concerne l'exécution efficace des requêtes locales. Il ne s'agit

pas à proprement parler d'un problème induit par les systèmes multibases où, du fait de la

propriété d'autonomie, on ignore le plus souvent le comportement des sites locaux. Cependant,

de nombreux systèmes multibases (e.g., les systèmes de supervision et de contrôle), intègrent

des SGBD temps-réel dont les performances sont cruciales pour le système d'information dans

sa globalité. Dans la section 3.5, nous présentons des travaux menés autour de l'exécution

efficace de requêtes dans un contexte grandes mémoires centrales. Ces travaux ont une

application dés lors que l'on souhaite optimiser les performances d'un site, qu'il soit ou non

intégré dans un système multibases.

3.2. Requêtes multibases assertionnelles


La section 3.1.3 souligne trois facteurs rendant difficile l'évaluation optimale de requêtes

multibases assertionnelles exprimées dans un langage tel que OQL.

Le premier problème est lié à l'autonomie des sites qui prive l'optimiseur de requêtes

d'informations essentielles (e.g., coût des algorithmes locaux, organisation locale des données,

charge de travail locale) lui permettant d'estimer le coût d'exécution d'une requête locale. A

notre connaissance, seules des techniques de calibrage12 permettent de contourner le problème

sans violer l'autonomie des sites. N'ayant pas abordé ce point dans notre étude, nous renvoyons

le lecteur intéressé à [Sma 97].

Le second problème est lié à l'hétérogénéité structurelle qui permet l'intégration dans un

système multibases de sites aux capacités d'interrogation sommaires. Ce problème rejoint celui

de la granularité des requêtes locales [Sma 97]. Plus le décomposeur génère des requêtes locales

simples, plus il maximise la probabilité qu'elles soient traitables par les sites auxquelles elles

sont destinées. Par contre, cette forte décomposition augmente le coût de communication

(plusieurs requêtes locales peuvent être destinées au même site), accroît le traitement de

recomposition et sous-exploite les capacités d'optimisation locale de chaque site. La granularité

des requêtes locales est également étroitement liée au modèle d'exécution considéré (algébrique

12 Le calibrage consiste à déterminer le comportement d'un site par expérimentation, c'est à dire en exécutant des bancs d'essais prédéfinis sur ce site et en analysant les performances obtenues.

43

ou navigationnel). Cet aspect est discuté dans le paragraphe suivant. Quelle que soit sa

granularité, si la complexité d'une requête locale dépasse les capacités de traitement du site, les

données concernées seront extraites de ce site afin d'être directement traitées par le gestionnaire

de requêtes globales dans la phase de recomposition.

Enfin, le troisième problème porte sur le choix du modèle d'exécution le plus approprié

pour un langage tel que OQL. La majorité des modèles d'exécution proposés reposent sur une

approche algébrique, dans laquelle les opérateurs algébriques relationnels sont étendus avec des

concepts orientés-objets [BK 90, CD 92, SAB 94]. Dans ces approches, l'optimiseur de requêtes

produit tout d'abord des arbres algébriques annotés avec les algorithmes associés à chaque

opérateur, puis choisit l'arbre de coût minimal en utilisant une heuristique donnée [VLZ 91, FG

94]. La limite des approches algébriques réside dans le traitement des expressions de chemin

(i.e., traversée des liens inter-objets), très fréquentes dans les applications exploitant des bases

de données orientés objets [KSK 92]. A l'inverse, les modèles navigationnels privilégient le

traitement des expressions de chemin et peuvent s'appuyer sur des index spécialisés pour

accélérer ces traitements [KM 90, OHM 92]. Il n'en reste pas moins vrai que certaines

expressions de chemin sont traitées plus efficacement par un opérateur de jointure explicite que

par de la navigation (jointure implicite) [ShC 90]. Il est donc souhaitable qu'un modèle

d'exécution hybride émerge et puisse marier efficacement des traitements algébriques et

navigationnels.


Nous nous sommes intéressés aux deux derniers problèmes mentionnés dans la section 3.2.1, à

savoir la gestion de l'hétérogénéité structurelle et la définition d'un modèle d'exécution efficace

pour OQL. En réponse à ces deux problèmes, nous avons proposé un langage fonctionnel appelé

OFL (Object Functional Language).

Ce langage permet de manipuler et d'interroger des collections d'objets génériques,

appelées collections abstraites, par le biais d'itérateurs. Les collections abstraites peuvent

représenter aussi bien des ensembles d'objets, des attributs multivalués ou encore des index ou

tables de hachage. Le langage en lui-même est indépendant de tout modèle de données et de tout

modèle de stockage. De ce fait, il peut s'appliquer à des collections issues de n'importe quelle

source de données et pallier les carences d'un gestionnaire de requêtes locales, voire se

44

substituer à lui. OFL constitue donc une réponse au problème de l'hétérogénéité structurelle. Cet

aspect est détaillé dans les sections suivantes "Collections abstraites" et "Le langage OFL".

D'autre part, OFL a été conçu pour servir de cible a un décomposeur/optimiseur de requêtes

orientées objets (i.e., OQL-like). Le modèle d'exécution de OFL est basé sur des parcours de

graphes lui permettant de supporter des exécutions ensemblistes, pipelines (i.e., un objet à la

fois) ou hybrides suivant la façon dont le graphe est traversé. Ce modèle d'exécution permet

ainsi de marier efficacement des traitements algébriques et navigationnels. Cet aspect est

détaillé dans la section "Le modèle d'exécution de OFL". Enfin, nous avons montré l'intérêt d'un

tel langage dans un environnement concret : la gestion de requêtes dans l'architecture TINA

(Telecommunication Information Networking Architecture) [BBI 93]. Cet exemple, présenté

dans la section "OFL dans une architecture multibases", montre le rôle de OFL aussi bien dans

le traitement des requêtes locales que dans la phase de recomposition.

Collections abstraites

Une collection abstraite est un objet groupant d'autres objets, encapsulé par un ensemble de

fonctions de traversée et de fonctions comportementales [GMP 94]. Une collection abstraite

peut être vue comme un conteneur d'objets générique permettant de modéliser aussi bien

l'extension d'une relation ou d'une classe, l'instance d'un attribut multi-valué (e.g., ensemble,

tableau, liste) ou encore une structure de données système telle que un index ou un dictionnaire.

Les fonctions de traversée (First, Next, Get) permettent d'itérer sur les éléments de toute

collection de façon unifiée (en fait, elles encapsulent la structure de stockage de la collection).

Les fonctions comportementales sont, quant à elles, liées à la sémantique de chaque collection

(e.g., la fonction Find(clé) sur une collection index) et leur signature n'est donc pas préétablie.

Toute fonction appliquée à une collection abstraite rend une collection abstraite (de cardinalité

potentiellement égale à 1).

Le langage OFL

OFL est un langage intermédiaire, c'est à dire la cible d'un décomposeur/optimiseur de

requêtes. OFL est basé sur une approche fonctionnelle. Les fonctions OFL peuvent être

composées pour définir des opérateurs algébriques (e.g., restriction, jointure) ou pour exprimer

un plan d'exécution complet. Ces fonctions sont suffisamment générales pour exprimer des

45

itérations sur collections et des traversées de chemins, pour évaluer des prédicats unaires,

binaires et n-aires sur les instances courantes des collections interrogées et pour appliquer des

projections sur ces instances courantes. Pour faciliter la composition de fonctions, OFL offre les

constructeurs suivants (où f et g dénotent des fonctions, p un prédicat et C une collection) [GMP

95a] :

Composition : f.g (x) = f(g(x))

Expression de chemin : f0.f1....fn(x)

Condition : If_Then_Else (p, f, g) (x) = f(x) if p is True

= g(x) if p is False.

Quantification universelle : ForAll(C, p, f) applique f à tout objet de C satisfaisant p.

Quantification existentielle : ForAny(C, p, f) applique f à un objet quelconque de C satisfaisant p.

Position courante : Current(C) rend l'objet courant de C

Itération : While (p,f) applique f jusqu'à ce que p devienne faux

Séquencement : Sequence(f1, f2, …, fn) applique séquentiellement f1, f2, ..., fn dans cet ordre

A titre d'illustration, considérons le schéma ODL [ODM 93] de la figure 3.2 dans lequel les

rectangles représentent des collections abstraites et les arcs les fonctions comportementales

associées. La figure 3.3 illustre la façon dont une requête OQL exprimée sur ce schéma peut être

traduite dans le langage OFL. Dans cet exemple, GreaterInteger et LessInteger sont des

fonctions comportementales prédéfinies de la collection Integer et Display est une fonction

comportementale d'affichage associée à chaque collection. DefVar(nom, expression) est une

facilité d'écriture permettant d'associer un nom logique à la collection abstraite résultat de

l'évaluation d'une expression quelconque.

price

Person Vehicleowner composed

String

Part

partlabellastname

color

Integersalary

birthyearpricemodel

Figure 3.2. Exemple de schéma objet exprimé en ODL

46

SELECT p.lastname, v.model, v.color, c.price FROM p in Person, v in p.Owner WHERE exists c in v.composed : c.price > 20000 and v.model > p.birthyear and p.salary < c.price expression OFL correspondante :

ForAll(Person',null, ForAll(DefVar(Vehicle',Owner(Current(Person'))), GreaterInteger(Model(Current(Vehicle')), BirthYear(Current(Person'))), ForAny(DefVar(Part',Composed(Current(Vehicle'))), And(GreaterInteger(Price(Current(Part')),20000), LessInteger(Salary(Current(Person')), Price(Current(Part')))), Sequence(Display(LastName(Current(Person'))), Display(Model(Current(Vehicle'))), Display(Color(Current(Vehicle'))), Display(Price(Current(Part')))))))

Figure 3.3. Requête OQL et son expression OFL

Le modèle d'exécution de OFL

Plusieurs expressions OFL peuvent correspondre à une même requête OQL, chacune

traduisant un plan d'exécution particulier. Les écarts de coût d'exécution entre ces expressions

sont principalement déterminés par l'ordre de composition des fonctions de quantification. Pour

caractériser cet ordre, nous avons introduit le concept de graphe de traversée de collections

(Collection Traversal Graph) [GMP 95a]. Le graphe de traversée de collections d'une requête

OQL est un graphe orienté valué dans lequel les noeuds représentent les collections abstraites

impliquées dans la requête et les arcs représentent l'application des fonctions

(comportementales, de quantification, ...). Supposons dans ce graphe un chemin de longueur n

valué par des fonctions de quantification. Plusieurs stratégies sont possibles pour traduire ce

chemin en une expression OFL.

La première stratégie, que nous qualifierons de algébrique ou ensembliste, consiste à traiter

séquentiellement chaque arc du chemin et à le traduire en une composition de deux fonctions de

quantification. En effet, de même que ForAll(C, p, f) peut exprimer un opérateur algébrique de

restriction, ForAll(C1, null, ForAll(C2, p, f)) peut exprimer un opérateur algébrique de jointure

de prédicat p entre deux collections C1 et C213. Chacune de ces expressions de jointure va

13 Cette expression est la traduction littérale d'un algorithme de jointure par produit cartésien (Nested Loop).

47

générer un résultat intermédiaire qui représentera une des opérandes de la jointure suivante.

L'expression OFL générée traduira alors un arbre algébrique fixant un séquencement

d'opérateurs ensemblistes unaires ou binaires.

La seconde stratégie, que nous qualifierons de navigationnelle ou pipeline, consiste à traiter

le chemin dans son intégralité et à le traduire en une unique composition de n fonctions de

quantification. Le traitement revient alors à un emboîtement de boucles de la forme :

pour chaque c1∈ C1, faire si (c1, *, *, ...) satisfait Q, alors // où Q est la qualification de la requête pour chaque c2∈ C2, faire si (c1, c2, *, ...) satisfont Q, alors ... pour chaque cn∈ Cn, faire si (c1, c2, ..., cn) satisfont Q, alors exécuter la projection

Cette stratégie correspond à l'exemple donné dans la figure 3.3. Les intérêts d'une telle

stratégie sont d'éviter la matérialisation des résultats intermédiaires et de délivrer les résultats au

fur et à mesure de l'exécution. Par contre, la complexité de cette stratégie est supérieure à la

précédente. Des stratégies mixtes, dans lesquelles un chemin est découpé en sous-chemins de

longueur variable, sont également envisageables. Des mesures de performance de ces différentes

stratégies sont fournies dans [GMP 95a]. Ces mesures ont été réalisées sur le prototype réalisé

par Fernando Machuca au cours de sa thèse [Mac 95]. Le processus de traduction d'une requête

OQL en un graphe de traversée de collections et les stratégies d'optimisation associées sont

discutés dans [GMP 95b].

OFL dans une architecture multibases

Le prototype décrit dans [Mac 95] permet d'utiliser OFL sous la forme d'une librairie

d'opérateurs pouvant être intégrée aussi bien dans le composant Traducteur d'un site local (cf.

figure 3.1), pour pallier les carences du gestionnaire de requêtes locales, ou bien dans le

composant Recomposeur du gestionnaire de requêtes globales pour réaliser la phase de post-

processing sur les collections résultats des requêtes locales. Une telle architecture a été

prototypée dans le cadre de la convention CNET/PRiSM n°96-1B-279 "Spécification et

implantation d'un gestionnaire de requêtes pour TINA (Telecommunication Information

Networking Architecture)". Cette architecture, basée sur CORBA, est illustrée sur la figure 3.4

et est décrite plus précisément dans [FLP 96, FFL 97]. OQL est ici remplacé par un langage

48

dédié à la gestion des réseaux de télécommunication (CMIS-L), ce qui montre la généralité de

OFL. OFL est utilisé dans cette architecture comme complément du gestionnaire de requêtes

locales d'un système temps-réel et comme moteur d'exécution du Recomposeur du gestionnaire

de requêtes globales.

TRADER

Real-Time Data Manager

ORB

Standard DBMS

CMIS-L query

Decomposer &

Executor

CMIS-L Subquery

Subquery Result

OFL evaluator

Data Manager

CMIS Repository

CMIS-L Compiler

OFL evaluatorTranslator

Global Query Manager

Queryable Collections

Queryable Collections

Object Manager

Stand-alone Objects

Figure 3.4. OFL dans le gestionnaire de requêtes de TINA

3.3. Requêtes multibases techniques


A notre connaissance, il n'existe pas à proprement parler d'état de l'art portant sur la gestion

de requêtes techniques (e.g., manipulation de graphes persistants) dans les systèmes multibases,

du fait de la spécificité de ces requêtes. Par contre, des travaux réalisés dans des domaines

connexes peuvent s'appliquer directement ou indirectement au problème considéré. Nous avons

classé ces travaux en trois approches susceptibles de répondre à notre problème.

La première approche consiste à faire migrer les données de type graphe du système

multibases vers un système relationnel étendu au traitement des graphes (ou des règles

récursives en général). De nombreux travaux ont porté sur l'extension de l’algèbre relationnelle

à des opérateurs spécialisés dans la résolution des problèmes de parcours de chemins [Ioa 86, AJ

87, CN 89, Dar 93]. L'opérateur de fermeture transitive généralisée, exploitant les nombreux

travaux théoriques menés sur les algèbres de chemins [GM 90], a été particulièrement étudié.

Cet opérateur unique permet de résoudre une variété de problèmes typiques de parcours de

chemins tels que plus court chemin, chemin de capacité maximale, énumération de composants

49

(bill of materials) et énumération de chemins avec ou sans contraintes. Les langages de requêtes

ont également été étendus à la manipulation de graphes [MS 90, CM 90, CM 94].

La deuxième approche consiste également à faire migrer les données, mais vers un système

entièrement dédié à la modélisation, la représentation et la manipulation de graphes [KSW 93,

Güt 94]. Cette seconde approche offre des outils plus puissants et mieux adaptés à la gestion de

graphes que les SGBD relationnels étendus. Elle partage par contre le même inconvénient, à

savoir l'obligation de faire migrer les données du système multibases vers une nouvelle

plateforme. Le partage des données entre les applications héritées et les applications liées à la

manipulation de graphes est donc problématique.

La troisième approche est basée sur la préservation des sources de données et la définition

d’une vue au-dessus de ces sources pour manipuler l’information. Des travaux ont ainsi porté

sur la définition de vues bases de données sur des fichiers structurés [ACM 93] ou sur des

sources arbitraires de données en utilisant des fonctions externes [CGK 89, CS 93].


Nos travaux s'inscrivent dans la lignée de ceux menés autour de la définition de vues bases de

données au dessus de sources de données existantes. Nous avons spécialisé cette approche au

cas de données de type graphe. Cette spécialisation poursuit deux objectifs : (i) offrir des outils

de modélisation et d'interrogation ad-hoc et (ii) offrir un modèle d'exécution optimal pour les

outils d'interrogation considérés.

Notre contribution porte sur trois points. Tout d'abord, nous avons introduit la notion de

vues de graphe pour définir des graphes sur des données existantes et potentiellement

hétérogènes. La définition d’une vue de graphe établit une correspondance entre les éléments

composant un graphe et les données sous-jacentes, par l’intermédiaire de fonctions qui

spécifient les éléments du graphe et la façon par laquelle le graphe peut être parcouru. Nous

avons ensuite proposé des opérateurs de dérivation (e.g., restriction, projection, union,

intersection, différence) pour définir de nouvelles vues de graphes par composition de celles

existantes. Enfin, nous avons proposé et évalué (analytiquement et par des mesures de

performance) différentes stratégies d'exécution pour les opérateurs de parcours appliqués à des

vues de graphe. Ces trois points sont détaillés dans les sections suivantes.

50

Le modèle de vues de graphe

Le modèle de vues de graphe [GPS 94] peut être vu comme un modèle de données pivot

(au sens multibases du terme, cf. §3.1.1) permettant de définir le schéma d'un graphe et son

instanciation, c'est à dire la correspondance entre les éléments du graphe et les données sous-

jacentes stockées dans le système multibases. Il est possible de définir plusieurs vues de graphe

sur le même ensemble de données. On peut ainsi décrire un même graphe à plusieurs niveaux de

granularité (e.g., graphe des tronçons de route, graphe des connexions routières entre grandes

villes). On peut également définir une vue de graphe sur des données qui n'ont pas été à l'origine

explicitement modélisées comme un graphe (e.g., données contenant des liens quelconques).

Soit Ω un ensemble d’objets d’une source de données sous-jacente. Conceptuellement, un

graphe G sur Ω est défini par un multigraphe étiqueté (N, E, LN, LE, ϕ, α, β) où, N est

l’ensemble des (identifiants de) noeuds, E est l’ensemble des (identifiants d') arcs, LN est

l’ensemble des étiquettes de noeud, LE est l’ensemble des étiquettes d'arc, ϕ est une fonction

d’incidence de E dans N × N, α est une fonction de N dans LN et β est une fonction de E dans

LE.

Une vue de graphe G(Nodes, Edges, Succ, GetLN) est la définition fonctionnelle d'un

graphe. La fonction Nodes rend l’ensemble des noeuds (identifiants et étiquettes), c'est à dire les

éléments N, LN et α du graphe. La fonction Edges rend l’ensemble des arcs (étiquettes et

identifiants des noeuds extrémités), c'est à dire les éléments E, LE, β etϕ du graphe. La fonction

Succ rend l’ensemble des noeuds et des arcs connectés à un noeud donné n. Enfin, la fonction

GetLN rend l’étiquette d’un noeud donné n. Bien que redondantes par rapport à Nodes et Edges,

Succ et GetLN sont intégrée à la définition d'une vue de graphe car elles permettent des

optimisations importantes dans la traversée d'un graphe. Ces quatre fonctions sont écrites dans

le langage natif de la source de données dont on extrait le graphe (e.g., SQL, OQL, C, Java, ...)

et jouent le rôle du composant traducteur de la figure 3.1. Les signatures de ces quatre fonctions

représentent le modèle de données pivot du système.

Les opérateurs de dérivation

De nombreuses applications introduisent le besoin de dériver un graphe par composition de

graphes déjà existants [GPT 93]. A titre d'exemple, il peut être nécessaire de dériver le réseau

routier national par union des réseaux de routes départementales, nationales et autoroutes. Dans

51

cet objectif, nous avons défini : (i) des opérateurs de dérivation unaires permettant de

sélectionner des noeuds et arcs d’une vue de graphe selon la valeur de leurs étiquettes et (ii) des

opérateurs de dérivation binaires permettant de construire des vues de graphes à partir de

l’union, l’intersection ou la différence (de noeuds ou d'arcs) de deux vues de graphes. Ces

opérateurs produisent une nouvelle vue de graphe dont les fonctions Nodes, Edges, Succ et

GetLN sont automatiquement construites par composition des fonctions des vues de graphe

opérandes. Ces opérateurs peuvent être appliqués de façon récursive de sorte qu'une vue de

graphe peut être le résultat d'un arbre complexe d'enchaînement d'opérateurs de dérivation.

A titre illustratif, la figure 3.5 montre la structure du graphe G résultant de l’application de

la différence d'arcs sur deux graphes opérandes G1 et G2. Dans cet exemple, ni et ei

représentent respectivement les identifiants de noeuds et d'arcs (les étiquettes sont ignorées).

n1

n3

e1

n2

n5 n4

e3

e4

e5

n2

n5

e5

n1

n3

e1

n4

=Edge

G1 G2

n2

e3

n5

Gn4

n1 e4

n6n6 n6

_

e6

Figure 3.5. Différence d'arcs entre deux graphes

Les fonctions Nodes, Edges, Succ et GetLN de la vue de graphe résultat G sont dérivées des

fonctions des vues de graphe opérandes par des expressions algébriques relationnelles. En effet,

ces fonctions rendent des ensembles de valeurs que l'on peut modéliser sous la forme d'une

relation. Par exemple, la fonction Edges rend un ensemble de n-uplets de la forme <Id_Arc,

Id_NoeudOrigine, Id_noeudDestination, étiquette>. La fonction Edges de la vue de graphe

résultat G correspond à l'expression suivante (où ∝ et Π dénotent respectivement les opérateurs

relationnel de semi-jointure et de projection et où les indices représentent la position des

attributs) : ( )G Edges G Edges G Edges G Edges. . . ., , , ,= ∝ −1 1 21 2 3 1 2 3Π Π .

Le modèle d'exécution

Considérons l'exécution d'un algorithme de parcours de graphe quelconque P (par exemple

l'algorithme de fermeture transitive généralisée) sur une vue de graphe G. Schématiquement, un

tel algorithme est constitué d'une boucle où chaque itération traite les successeurs d'un noeud

52

courant. Deux stratégies d'exécution sont possibles pour l'algorithme P. La stratégie par

matérialisation consiste à construire une image complète du graphe en mémoire par application

de ses fonctions Nodes et Edges avant l'exécution de l'algorithme P. Cette image est stockée

dans une structure de données déterminée pour laquelle la fonction Succ est prédéfinie.

L'algorithme P peut ensuite être exécuté. A chaque demande des successeurs d’un noeud, la

fonction prédéfinie Succ est alors utilisée. La stratégie par dérivation consiste au contraire à

appliquer directement l’algorithme P sur la vue de graphe G. Chaque fois que l’algorithme P

demande les successeurs d’un noeud, la fonction Succ de G est appelée pour récupérer

l’information depuis les sources de données sous-jacentes. Ce résultat est fourni à l’algorithme P

qui continue son exécution. A noter que les deux stratégies s'appliquent aussi bien à des vues de

graphe de base (i.e., directement définie sur les données sous-jacentes) qu'à des vues de graphe

dérivées.

Il existe un parallèle entre ces deux stratégies et les stratégies ensembliste et pipeline

discutées dans la section 3.2.2, de même qu'il existe un parallèle entre l'évaluation d'un arbre

d'opérateurs de dérivation de vues de graphe et l'évaluation d'un arbre algébrique traditionnel. Il

est ainsi possible de ne matérialiser qu'une partie de l'arbre de dérivation. Le modèle d'exécution

des vues de graphe supporte aussi bien des exécutions par matérialisation, par dérivation ou

hybrides. Des évaluations analytiques de performance ont permis de déterminer dans quelles

situations une stratégie est supérieure à l'autre. Ces évaluations analytiques ont été corroborées

par des mesures de performance sur un prototype développé par Alejandro Gutiérrez au cours de

sa thèse. Le résultat des évaluations analytiques, des mesures et la description du prototype

peuvent être trouvées dans [Gut 97].

3.4. Fouille de données


La fouille de données, plus connue sous le nom anglais de data mining, regroupe un ensemble

de techniques issues de l'analyse statistique et de l'intelligence artificielle, dont l'objectif est

d'extraire des connaissances d'un ensemble de données (stockées dans une ou plusieurs bases) et

d'en déduire un modèle (décrivant une situation ou permettant de prédire une situation future).

La communauté bases de données s'est plus particulièrement penchée sur une des branches de la

fouille de données, l'extraction de règles associatives. Le concept de règle associative a été

53

introduit formellement dans [AIS 93] de la façon suivante. Soient I un ensemble d'items A, B,

..., Q et T un ensemble de transactions T1, T2, ..., Tn où chaque transaction correspond à

ensemble d'items ⊆ I, une règle associative est une implication de la forme X=>Y, avec X⊆I,

Y⊆I et X∩Y=∅. Une règle associative caractérise donc une corrélation entre deux ensembles

d'items. Par exemple, si I représente l'ensemble des produits vendus dans une grande surface et

chaque Ti∈T représente les achats d'un client, une règle associative peut traduire un

comportement d'achat (e.g., fromage=>vin). La qualité d'une règle X=>Y est traduite par deux

facteurs : support(X=>Y) qui correspond au pourcentage de transactions possédant X et Y, et

confiance(X=>Y) qui correspond au pourcentage de transactions possédant Y parmi les

transactions possédant X (i.e., confiance(X=>Y) = support(X=>Y)/support(X)). La confiance

permet d'isoler des règles très pertinentes (i.e., traduisant une forte corrélation) dont le support

n'est pas obligatoirement élevé (e.g., escabeau=>pinceaux). L'objectif est donc de retrouver

toutes les règles dont le support et la confiance dépassent les seuils minsup et minconf fixés par

l'utilisateur.

La recherche des règles associatives se décompose en deux étapes [AIS 93]. La première

étape consiste à retrouver tous les ensembles fréquents (i.e., dont le support est supérieur à

minsup) quelle que soit leur cardinalité. Dans la suite, on appellera k-ensemble un ensemble de

cardinalité k. La seconde étape consiste à générer les règles pertinentes à partir de tous les

ensembles fréquents. Cette seconde étape se résume, pour chaque ensemble fréquent X, à

trouver tous les sous-ensembles non vides X' de X et à générer la règle X'=>(X-X'), si

support(X)/support(X') est supérieur à minconf. Etant donné que pour N items, il existe 2N

ensembles fréquents potentiels, on comprend que la complexité réside dans la première étape et

non dans la seconde.

La majorité des travaux relatifs à l'extraction de règles associatives se sont donc

naturellement concentrés sur la minimisation des entrées/sorties disque (E/S) nécessaires à la

recherche des ensembles fréquents. Une stratégie naïve consisterait à maintenir en mémoire 2N

compteurs, à balayer séquentiellement la base des transactions et, pour chaque transaction, à

incrémenter le compteur de chaque ensemble contenu dans cette transaction. Cette stratégie est

clairement irréaliste dès que N est grand. L'algorithme Apriori [AS 94] exploite le fait que tout

k-ensemble fréquent est inévitablement composé de (k-1)-ensembles fréquents (e.g., si A,B,C

est fréquent, alors A, B, C, A,B, A,C, B,C sont obligatoirement fréquents).

54

Partant de ce principe, l'algorithme Apriori se déroule en k étapes. La première étape traverse la

base des transactions afin de déterminer les 1-ensembles fréquents parmi les N possibles. La

seconde étape traverse la base des transactions afin de déterminer les 2-ensembles fréquents

qu'il est possible de construire en combinant les 1-ensembles fréquents déterminés à l'étape

précédente et ainsi de suite. La base des transactions est donc parcourue k fois (si k est le

cardinal du plus grand ensemble fréquent).

L'algorithme Partition [SON 95] réduit à 2 le nombre de parcours de la base des

transactions en découpant celle-ci en partitions de taille inférieure ou égale à la taille de la

mémoire centrale. Lors de la première passe, on calcule les k-ensembles fréquents locaux à

chaque partition. La deuxième passe sert à éliminer, parmi ces ensembles, ceux qui ne sont pas

fréquents globalement. L'idée sous-jacente à l'algorithme est que tout ensemble globalement

fréquent est inévitablement fréquent dans au moins une partition et est donc repéré lors de la

première passe. Enfin, l'algorithme DIC (Dynamic Itemset Counting) [BMU 97] permet de

réduire le nombre de passes effectives à 1,5 en moyenne, en anticipant sur les ensembles

fréquents à chercher dans la kème partitions à partir des ensembles estimés fréquents dans les

partitions précédentes.


Les algorithmes présentés dans la section précédente se concentrent tous sur la minimisation des

E/S, qui représentent effectivement le coût dominant dans la recherche des règles associatives.

Cependant, les progrès technologiques des dernières années permettent d'acquérir des machines

à grandes mémoires centrales (typiquement plusieurs Giga-octets) à des coûts abordables. Nous

considérons donc que la minimisation du coût CPU de ces algorithmes ne doit pas être négligée.

Notre contribution porte de ce fait sur les structures de données utilisées en mémoire pour

calculer le support des k-ensembles afin de déterminer ceux qui sont fréquents. Les structures de

données proposées ainsi que l'algorithme qui en découle peuvent parfaitement être intégrés aux

algorithmes précédents, Partition ou DIC, pour prendre en charge le traitement réalisé en

mémoire.

Dans l'algorithme Partition, le traitement réalisé en mémoire pour chaque partition consiste

à retrouver les 1-ensembles localement fréquents, puis en déduire les 2-ensembles supposés

localement fréquents et évaluer leur support et ainsi de suite jusqu'à avoir calculé le support des

k-ensembles supposés localement fréquents. Les structures de données utilisées en mémoire par

55

cet algorithme sont des listes d'identifiants de transaction (Trid) [SON 95]. Ainsi, si l'ensemble

X apparaît dans les transactions Ti, Tj et Tk, cet ensemble sera représenté en mémoire par une

liste triée Ti, Tj, Tk. Calculer le support(X=>Y) revient à compter le cardinal de liste(XY) =

Liste(X)∩Liste(Y).

Notre proposition repose sur un principe simple. Il s'agit de représenter chaque ensemble

par un vecteur de bits et non plus par une liste de Trid. La taille du vecteur est égale au nombre

P de transactions considérées (e.g., le nombre de transactions d'une partition) et le bit i est

positionné à 1 si la transaction Ti possède l'ensemble en question. Ainsi, l'ensemble X considéré

ci-dessus sera représenté par un vecteur de P bits dont les bits i, j, et k seront à 1 et tous les

autres bits seront à 0. Calculer le support(X=>Y) revient désormais à compter le nombre de bits

à 1 dans vecteur(XY) = vecteur(X) AND vecteur(Y), où AND est l'opérateur logique

traditionnel appliqué à deux vecteurs de bits. Cet algorithme, appelé Naïve-Bitmap (N-BM)

s'avère plus efficace que l'algorithme par intersection de listes dés lors que les listes ont une

cardinalité élevée [GPW 98]. C'est donc un algorithme bien adapté au cas où les items ont un

support élevé. Cet algorithme est également bien adapté au cas des règles associatives générales

de la forme (X=>¬Y) ou encore (X=>Y∨Z), difficilement traitables par l'algorithme par

intersection de listes du fait de la taille des listes générées. Par contre, Naïve-Bitmap s'avère peu

efficace sur le banc d'essai introduit dans [AS 94] où le support moyen des 1-ensembles est

faible. En effet, le coût de l'algorithme est indépendant du nombre de bits positionnés dans

chaque vecteur alors que l'algorithme par intersection profite pleinement de la faible taille des

listes.

Pour pallier cette limitation, nous avons indexé le vecteur de bits initial par l'intermédiaire

d'un nouveau vecteur de bit, qui joue le rôle de vecteur de compression, donnant ainsi naissance

à l'algorithme Hierarchical-Bitmap (H-BM) [GPW 98]. Le vecteur de bits initial, appelé 1-BM

(bitmap de 1er niveau), est découpé en fragments de b bits14 et chacun de ces fragments est

représenté par un bit dans le vecteur de compression, appelé 2-BM. Le bit i du vecteur 2-BM est

à 1 si le ième fragment du vecteur 1-BM contient au moins un bit à 1, il est à 0 sinon. Supposons

que l'on veuille calculer vecteur(XY) = vecteur(X) AND vecteur(Y). Le vecteur (XY) est tout

14 La valeur optimale de b, déterminée par évaluation analytique et confirmée par expérimentation, s'avère être b=16 [GPW 98].

56

d'abord entièrement positionné à 0. L'algorithme H-BM calcule ensuite 2-BM(XY) = 2-BM(X)

AND 2-BM(Y). Pour chaque bit i positionné à 1 dans 2-BM(XY), on calcule vecteuri(XY) =

1-BMi(X) AND 1-BMi(Y), où l'indice i représente le ième fragment d'un vecteur. L'algorithme 2-

BM réduit donc très fortement le nombre d'opérations binaires à effectuer lorsque les vecteurs

1-BM sont creux, c'est à dire que le support moyen des 1-ensembles est faible. Lors d'un calcul

de vecteur(XY), le gain est d'autant plus important que la corrélation entre X et Y est faible, car

une faible corrélation favorise l'apparition de 0 dans 2-BM(XY) (alors que ce facteur n'influe

pas sur le coût de l'algorithme par intersection).

Un autre avantage de l'algorithme H-BM est la très faible taille des vecteurs 2-BM (P/b

bits, soit plus de 130.000 transactions par K-octets). Ainsi, pour maximiser la probabilité que les

traitements s'effectuent en mémoire, il est possible de stocker en mémoire uniquement les 1-BM

des 1-ensembles fréquents et les 2-BM des k-ensembles fréquents ou en cours d'évaluation (∀k

> 1). Cette caractéristique peut être mise à profit dans des algorithmes tels que DIC où le

nombre de k-ensembles en cours d'évaluation au même instant peut être très important. Enfin,

nous avons montré que H-BM avait des propriétés idéales pour être parallélisé. L'ensemble de

ces travaux sont décrits dans [GPW 98] et ont été validés par une première expérimentation

(pour la version séquentielle uniquement) et des mesures de performance. Ces travaux en sont

cependant à un stade préliminaire et méritent de futures investigations.

57

3.5. Performance des traitements locaux


Comme il a été dit dans la section 3.1, de nombreux systèmes multibases, notamment dans le

domaine de la supervision et du contrôle (SCS), intègrent des SGBD propriétaires dont les

performances sont cruciales pour le système d'information dans sa globalité. Dans ce contexte,

nous nous intéressons plus particulièrement aux SGBD qui exploitent la taille croissante des

mémoires centrales pour accélérer les traitements locaux. Nous les appellerons par la suite

MMDBMS (Main Memory DBMS). Quatre points fondamentaux sont adressés par les

MMDBMS [Eic 89]: (i) exécution efficace des requêtes d'interrogation par élimination des E/S

disque, (ii) compacité des structures de stockage et d'indexation pour maximiser la probabilité

que la base de données active (i.e., en cours d'utilisation) tienne en mémoire, (iii) optimisation

de requêtes peu coûteuse et (iv) gestion de transactions peu coûteuse. Les deux derniers points

sont liés au fait que le coût relatif de l'optimisation de requêtes et du contrôle de concurrence

augmente naturellement lorsque le coût d'exécution même de la requête décroît fortement.

L'exécution efficace de requêtes en mémoire fait largement appel aux accès directs aux

données par pointeurs [DKO 84]. Cependant, les nombreuses structures d'indexation proposées

pour les SGBD orientés disque [Val 87] s'adaptent mal au cas des MMDBMS car elles

introduisent un coût supplémentaire de stockage et de mise à jour et permettent difficilement

d'indexer des résultats intermédiaires. Des modèles de stockage et d'accès intégrant de façon très

compacte données, index et résultats intermédiaires ont été proposés spécifiquement pour les

MMDBMS [AHK 85, LC 86]. Ces modèles d'accès et de stockage permettent d'adresser les

deux premiers points mentionnés ci-dessus. Concernant l'optimisation de requête, la tendance

est à la simplification du processus d'optimisation, du fait que la minimisation des E/S n'est plus

à prendre en compte et que l'utilisation d'index est dans la majorité des cas la meilleure

alternative, quel que soit l'opérateur impliqué dans la requête [Eic 89]. Enfin, le contrôle de

concurrence doit être adapté à l'utilisation massive d'index, la contention sur les index étant une

des sources majeures de réduction du débit transactionnel dans un MMDBMS [GLV 84, LC

89].

58


Nous avons proposé un modèle de stockage et d'accès qui adresse les quatre points

fondamentaux des MMDBMS cités dans [Eic 89]. Ce modèle, appelé DBGraph, est basé sur la

représentation d'une base de données sous la forme d'un graphe [PT 89]. Plus précisément, un

DBGraph est un graphe biparti contenant un ensemble T de noeuds tuples, un ensemble V de

noeuds valeurs et un ensemble E d'arcs valués reliant T à V. Chaque arc (t, v, R.k) modélise

l'association entre un tuple t de la relation R et la valeur v de son kème attribut. Un tuple est donc

relié par un arc à la valeur de chacun de ses attributs. Les noeuds tuples sont groupés par

relations, qui forment une partition de T. Les noeuds valeurs sont regroupés par domaines, qui

forment une partition de V. Un domaine étant un ensemble de valeurs, il ne contient par

définition aucun doublon. Par conséquent, deux tuples partageant la même valeur pour un de

leurs attributs sont inévitablement reliés par un chemin de longueur deux. La structure de

stockage physique d'un DBGraph15 est illustrée sur la figure 3.6.

Résultat Join(R,S) Domaine Dj

Relation R

Relation SListes inversées de R.5

Indexde domaine

valeur Vj

valeur ViS.4 R.5

Figure 3.6. Structure de stockage d'un DBGraph

Sur cette figure, on remarque qu'un tuple est matérialisé par un tableau de pointeurs

référençant ses valeurs d'attributs. Le domaine Dj est partagé par l'attribut R.5 de la relation R et

S.4 de la relation S. Chaque domaine est indexé pour accélérer les recherches par valeur.

Chaque valeur contient une liste inversée par attribut variant sur le domaine. Cette liste

référence l'ensemble des tuples possédant cette valeur pour l'attribut considéré. Dans l'exemple

de la figure, l'attribut S.4 est clé de la relation S et à ce titre, chaque liste inversée de S.4 ne

15 Plus précisément, il s'agit de la structure de stockage retenue dans notre prototype [Ren 93]. D'autres structures de stockage sont vraisemblablement possibles pour traduire le concept de DBGraph.

59

contient qu'un pointeur. Les résultats intermédiaires sont eux-mêmes matérialisés au travers de

tables de pointeurs. Comme illustré sur la figure, le résultat d'une jointure entre R et S est ainsi

matérialisé par une table contenant un couple de pointeurs référençant les tuples de R et S

joignant deux à deux. Il est intéressant de noter que ce modèle de stockage hérite du modèle

OBE [AHK 85] les liens entre tuples et valeurs d'attributs, et du modèle DB-MAC [MS 83], qui

n'a pourtant pas été proposé dans un contexte MMDBMS, les liens entre valeurs de domaine et

tuples. Nous résumons ci-dessous la façon dont le modèle DBGraph atteint les quatre objectifs

des MMDBMS.

Exécution efficace des requêtes d'interrogation

Nous avons montré dans [PTV 90] que l'ensemble des opérateurs de l'algèbre relationnelle

peuvent se traduire par un parcours de graphe (i.e., traversée de pointeurs en mémoire) sans

générer aucune comparaison ni recopie de tuples. A titre d'illustration, une restriction de la

forme σ(R.5) = Vi s'exécute en traversant l'index du domaine Dj pour se positionner sur la

valeur Vi, puis, en récupérant la liste inversée R.5 associée à cette valeur. Cette liste est la

matérialisation même du résultat de la restriction. Une équi-jointure entre R.5 et S.4 peut

s'exécuter (il y a plusieurs alternatives) en parcourant séquentiellement le domaine Dj et en

calculant, pour chaque valeur de domaine, le produit cartésien des listes inversée R.5 et S.4. Ce

produit cartésien est la matérialisation du résultat de la jointure. Les résultats intermédiaires

étant représentés par des n-uplets de pointeurs référençant les tuples de la base, on peut à leur

tour leur appliquer les mêmes algorithmes (à une indirection près). Le même principe

d'exécution peut également s'appliquer à des opérateurs récursifs tels que la fermeture transitive

[GP 88].

Compacité de la structure DBGraph

Nous avons montré au travers d'évaluations analytiques [PTV 90] que l'ensemble de la

structure DBGraph est généralement plus compacte qu'une structure de stockage traditionnelle

dans laquelle les tuples contiennent leurs valeurs d'attributs. Le gain est lié à la non redondance

des valeurs dans la base de données et au fait qu'un seul index de domaine permet d'indexer

l'ensemble des attributs variant sur ce domaine. A titre illustratif, le coût de stockage de la base

de données définie dans le banc d'essai du Wisconsin [BDT 83] est approximativement

60

identique avec un modèle traditionnel non indexé qu'avec le modèle DBGraph entièrement

indexé.

Optimisation de requêtes

Comme il a été montré ci-dessus, l'exécution des opérateurs de l'algèbre relationnelle se

traduit par un simple parcours du DBGraph. Si ces opérateurs sont appliqués en séquence, leur

caractère ensembliste génère un parcours en largeur du DBGraph. Nous avons étudié dans [PT

92] l'opportunité d'exécuter une requête par un parcours en profondeur du même DBGraph. Un

tel parcours revient à une exécution pipeline (ou tuple à tuple) de la requête. L'intérêt d'une

exécution pipeline par rapport à une exécution ensembliste est de ne pas générer de résultat

intermédiaire, maximisant ainsi la probabilité que la base de données active tienne en mémoire,

et de fournir les tuples résultats au fur et à mesure de l'exécution, réduisant ainsi le temps de

latence pour l'utilisateur. Nous avons également proposé une stratégie d'optimisation de requêtes

permettant de générer un programme pipeline qui minimise le nombre de chemins non

pertinents (i.e., n'aboutissant pas à une solution finale) traversés dans le DBGraph. L'ensemble

de cette étude a été récompensée par le best paper award de la conférence EDBT'92 [PT 92].

Gestion de transactions

Comme il a déjà été mentionné, l'usage intensif d'index dans les MMDBMS introduit des

risques importants de contention en cas de mise à jour. Il en va de même pour la structure de

DBGraph. De nombreux travaux ont porté sur l'optimisation des algorithmes de contrôle de

concurrence appliqués aux index de type arbre-B [BCF 97]. Parmi ces travaux, un des plus

significatifs est certainement la stratégie ARIES/IM [ML 89] qui, grâce à une distinction très

claire entre données utilisateur (tuples) et données systèmes (index), montre qu'il est possible de

déverrouiller entièrement la structure d'index après chaque mise à jour. ARIES/IM repose sur un

mécanisme de latches (ou verrous courts) et un mécanisme de recouvrement approprié. La

stratégie de verrouillage proposée pour la structure de DBGraph utilise le principe de latches

introduit dans ARIES/IM et spécialise le mécanisme de verrouillage de clés introduit dans

ARIES/KVL [Moh 90] pour se prémunir contre l'apparition de fantômes. Nous montrons dans

[PT 93] que cette stratégie minimise les problèmes de contention et permet de résumer un

nombre important de verrous posés sur les tuples en un seul verrou posé sur une liste inversée.

61

Intuitivement, l'idée consiste à verrouiller l'accès à un chemin dans le DBGraph plutôt que

l'ensemble des tuples auquel ce chemin conduit.

62

Chapitre 4

Prototypes

4.1. Cohérence des traitements multibases

Le protocole de validation atomique non-bloquant à une phase, présenté dans le chapitre 2, est

en cours de réalisation sur une architecture à objets distribuée CORBA16 [OMG 95]. Ce

prototype est appelé NB-SPAC (Non-Blocking Single-Phase Atomic Commit protocol).

L'objectif du prototype NB-SPAC est de démontrer l'applicabilité du protocole de validation

proposé dans une architecture réelle. Plus précisément, ce prototype doit montrer :

• qu'il est possible d'intégrer un protocole de validation atomique à une phase non-bloquant dans un service transactionnel standard,

• qu'il est possible de piloter des SGBD commerciaux existants (Oracle et POET dans notre expérimentation) et donc que ce protocole préserve bien l'autonomie des sites participants,

• que ce protocole a les performances escomptées.

Dans la suite de cette section, nous rappelons les travaux de standardisation menés par les

consortiums X/Open et OMG autour de la validation atomique de transactions puis nous

montrons comment intégrer NB-SPAC à ces standards.

4.1.1. Standardisation de la validation atomique

Le modèle DTP (Distributed Transaction Processing) [X/Op 96] publié par X/Open définit des

interfaces standard entre composants transactionnels afin d'assurer leur portabilité. Dans sa

version de base (i.e., un seul gestionnaire de transaction), DTP distingue trois composants

fonctionnels participant à l'exécution d'une transaction: (i) un application program (AP) est un

16 CORBA (Common Object Request Broker Architecture) est une architecture à objets distribuée promue par l'OMG (Object Management Group) afin d'assurer l'interopérabilité entre composants logiciels hétérogènes.

63

programme d'application quelconque, (ii) un resource manager (RM) est un gestionnaire de

ressources (par exemple un SGBD), (iii) un transaction manager (TM) est un gestionnaire de

transactions (par exemple un moniteur transactionnel) qui doit garantir l'atomicité de chaque

transaction sur l'ensemble des RM qu'elle a accédés. La figure 4.1 représente les composants

fonctionnels du modèle DTP et leurs interactions. Schématiquement, un AP communique avec

le TM via l'interface Tx pour démarrer/valider/abandonner une transaction et avec les RM via

leur interface native (par exemple SQL) pour exécuter des traitements. Lorsque l'AP décide de

valider une transaction, le TM agit comme coordinateur du protocole 2PC et utilise l'interface

Xa de chaque RM participant pour piloter le protocole. La majorité des SGBD commerciaux

supportent aujourd'hui l'interface Xa leur permettant de s'intégrer dans le modèle DTP.

ApplicationProgram (AP)

TransactionManager (TM)Resource

Manager (RM)

interface native (ex. SQL)

Tx

Xa

tx_begin,tx_commit,tx_rollback, ... ,

xa_start,xa_prepare,xa_commit, xa_rollback,xa_recover,...

Figure 4.1. Le modèle DTP de X/Open

Le service OTS (Object Transaction Service) [OMG 96] est la spécification du service

transactionnel définit par l'OMG pour l'architecture à objets répartis CORBA. Comme l'illustre

la figure 4.2, on peut voir OTS comme une redéfinition orientée objets du modèle DTP. En

effet, il existe une correspondance assez directe entre Transactional Client et AP, Transaction

Service et TM et Recoverable Server et RM. Dans OTS, une transaction est représentée par un

groupe d'objets CORBA. Schématiquement, quand un client transactionnel s'adresse au service

de transactions pour démarrer une transaction, ce dernier crée un objet que nous appellerons

coordinateur qui représente cette transaction. Le client peut ensuite s'adresser à un ou plusieurs

serveurs recouvrables pour exécuter des traitements (ces traitements sont en fait supportés par

des objets recouvrables (RO) gérés par le serveur). La première fois qu'un objet recouvrable est

accédé par une transaction, il crée un objet ressource pour cette transaction et l'enregistre auprès

du coordinateur. Lorsque le client désire valider sa transaction, il en informe le service

transactionnel. A cet instant, l'objet coordinateur démarre le protocole 2PC dans lequel les

64

objets ressources enregistrés pour cette transaction agissent comme participants. Comme

l'illustre la sphère grise sur la figure 4.2, l'interopérabilité entre OTS et DTP a été étudiée afin

d'autoriser OTS à piloter des SGBD conformes à DTP (i.e., supportant l'interface Xa).

Recoverable Server

resource

Transaction Service Transaction Coordinator

Transactional Client RO

begin,commit,rollback

invocation

register resource,may force rollback,recovery actions

2PC actions

SGBD

Xa

SQL/OQL

Figure 4.2. Le service OTS de l'OMG

4.1.2. Intégration de NB-SPAC dans OTS et DTP

Les standards transactionnels présentés dans la section précédente étant suivis par la grande

majorité des éditeurs de SGBD et de moniteurs transactionnels, il est important de montrer

comment le protocole NB-SPAC peut être intégré dans ces standards sans remettre en cause

l'existant. Notre objectif a donc été de préserver les composants des modèles existants ainsi que

leur interface externe. Trois problèmes majeurs doivent être résolus pour intégrer un protocole

de validation à une phase dans OTS/DTP :

• l'automate du coordinateur doit être modifié afin d'exécuter le protocole 1PC au lieu du protocole traditionnel 2PC,

• les participants (i.e., les objets Resource ainsi que les SGBD sous-jacents) doivent être en mesure de participer au protocole 1PC,

• le coordinateur doit maintenir un journal contenant la trace de toutes les opérations soumises à chaque participant afin d'être en mesure de ré-exécuter une branche de transaction en cas de défaillance d'un participant (cf. Chapitre 2, §2.2.2).

Nous avons résolu le premier problème grâce à une collaboration avec l'équipe CEDIA

dirigée par Simone Sédillot à l'INRIA. Cette équipe a réalisée une implantation complète du

service OTS, appelée MAAO-OTS [SED xx]. Les membres de l'équipe CEDIA maîtrisant

parfaitement les sources de l'automate du coordinateur, il leur a été aisé d'en modifier

légèrement le comportement. La modification à effectuer est relativement simple du fait que

65

OTS (resp. DTP) prévoit qu'un objet Resource (resp. RM) puisse participer à une validation

atomique à une seule phase (l'opération correspondante s'appelle commit_one_phase dans les

deux modèles). Dans ces deux modèles, cette opération est déclenchée lorsqu'un seul site a été

atteint par une transaction. En effet, déclencher le 2PC traditionnel dans pareil cas est sans objet

(cf. Chapitre 2). Nous avons détourné l'existence de cette opération commit_one_phase pour

notre besoin. Désormais, le coordinateur de MAAO-OTS invoque systématiquement l'opération

commit_one_phase de chaque objet Resource participant à la transaction.

Le second problème est encore plus simple a résoudre. Puisque l'opération

commit_one_phase fait partie intégrante de l'interface standardisée Xa, tout SGBD compatible

avec le modèle DTP de X/Open (c'est à dire la grande majorité des SGBD) peut participer à un

protocole 1PC.

Le dernier problème est plus complexe à résoudre. En effet, contrairement au modèle de

transactions multibases couramment considéré dans la littérature (cf. Chapitre 2, §2.1.2), le flux

d'opération dans OTS entre un client transactionnel et les serveurs recouvrables ne traverse pas

le coordinateur. Afin de journaliser les opérations de ce flux, sans violer l'autonomie des sites,

sans générer de communication supplémentaire et de façon transparente au client, nous avons

construit un filtre17 interceptant tous les appels sortants d'un client. Ces appels sont journalisés

en mémoire par un objet appelé Replay, associé à chaque transaction. A la validation de la

transaction, l'objet Replay sauvegarde le journal sur un support stable. Cet objet possède une

interface re-execute permettant au coordinateur de ré-exécuter toute branche de transaction.

L'intégration complète d'un protocole 1PC dans le modèle OTS/DTP est illustré sur la figure

4.3.

17 Le concept de filtre a été initialement introduit dans l'ORB Orbix distribué par IONA afin d'intercepter les messages entrant et/ou sortant de tout processus. Ce concept a depuis été standardisé par l'OMG dans l'architecture CORBA 2.2 sous le nom d'objet Interceptor.

66

ORB

Transactional Client

Transaction Service

.

Client Filter

Recoverable Server

ROResourceregister_op()

flush()

re_execute()

Replay

TransactionCoordinator

StableLog

1PClib

begincommitrollback

register resource,may force rollbackrecovery actions

commit-one-phase,

SGBD

xa_commit_one_phase

SQL/OQLRM

OTS X/Open

Figure 4.3. Intégration d'un protocole 1PC dans OTS/DTP


Le prototype NB-SPAC est en cours de réalisation par Maha Abdallah et une description

complète de ce prototype pourra être trouvée dans [Abd 99]. Les objectifs fixés à ce prototype

(cf. section 4.1) n'ont pas encore tous été atteints, notamment en ce qui concerne les mesures de

performance, car le prototype n'est pas encore opérationnel. Cependant, l'implantation est

suffisamment avancée pour pouvoir raisonnablement penser que les deux premiers objectifs

seront satisfaits, à savoir (i) montrer que l'intégration du 1PC dans des modèles de transactions

standards tels que OTS et DTP est possible et (ii) que les SGBD existants peuvent participer à

ce protocole sans remettre en cause leur autonomie. La réalisation de ce prototype a été rendue

possible par une coopération étroite avec l'équipe CEDIA de l'INRIA Rocquencourt.

La propriété de non-blocage du protocole n'est pas pour l'instant intégrée au prototype.

L'analyse de cette intégration n'est d'ailleurs pas terminée. Comme il a été montré dans le

chapitre 2, assurer le non-blocage de ce protocole est équivalent à résoudre le problème du

consensus. Pour résoudre ce problème, nous envisageons d'utiliser OGS [OGS xx], une librairie

d'outils de communication et de protocoles répartis (dont notamment le consensus) développée

sur Orbix par l'EPFL. La réalisation de ce prototype s'avère donc une excellente source de

coopérations.

67

D'autre part, le prototype NB-SPAC est réalisé en partie dans le cadre du projet européen

OpenDREAMS-II. OpenDREAMS-II est le projet n° 25262 du programme Esprit-IV. Démarré

en Décembre 1997 pour une durée de 24 mois, il fait suite au projet OpenDREAMS-I. Son

objectif est de concevoir et de valider une plateforme à objets distribuée dédiée aux systèmes de

supervision et de contrôle (SCS). Des exemples typiques de SCS sont : la gestion des réseaux de

transport, le contrôle de la production et de la distribution d'énergie ou encore la gestion des

réseaux de télécommunication. Les SCS sont caractérisés par la nécessité d'acquérir et de traiter

des données en temps-réel, d'accéder à des sources de données distribuées et fréquemment

hétérogènes et surtout d'assurer une forte disponibilité du système. L'hétérogénéité et la

distribution des sources de données accédées ont conduit le projet à sélectionner l'architecture

CORBA comme épine dorsale de la plateforme OpenDREAMS et à ajouter à cette plateforme

les composants indispensables au support des SCS. Un de ces composants est un service de

transactions dédié aux SCS, dont le laboratoire PRiSM à la charge de la conception et de la

réalisation. Le protocole NB-SPAC exhibe d'excellentes propriétés pour les SCS : performance,

non-blocage, compatibilité avec les standards et enfin prédictabilité (le temps d'exécution réel

du 1PC est plus facile à prévoir que celui du 2PC). Les deux applications développées dans

OpenDREAMS, à savoir la gestion d'une centrale électrique et le guidage de véhicules sur le

tarmac des aéroports, ainsi que la présence sur la plateforme des SGBD Oracle et POET

devraient nous servir à valider le protocole NB-SPAC dans un environnement concret. La

description technique du service de transaction peut être trouvée dans [ABG 98]. Une

spécification formelle de ce service [CGP 98] a été réalisée en langage TRIO [GMM 90] en

collaboration avec Alberto Cohen du Polytechnico de Milano.

4.2. Performance des traitements multibases

Hormis NB-SPAC qui a fait l'objet d'un prototypage séparé, toutes les expérimentations menées

autour des travaux présentés dans les chapitres 2 et 3 ont été intégrées dans une même

plateforme. Le développement de cette plateforme, appelée GEODE [GPT 88, Puc 89, BHP 93,

BHP 95], représente un travail de longue haleine auquel de nombreuses personnes (thésards et

stagiaires de DEA et du CNAM) ont contribuées. Le développement de GEODE avait pour

objectif la conception et la réalisation d'un gérant d'objets extensible permettant de faire diverses

expérimentations dans le domaine des SGBD répartis. En ce sens, GEODE s'inscrit dans la

lignée des gérants d'objets génériques [CH 90], tels que EXODUS [CDR 86], Mneme [Moss 90]

68

ou Papyrus [CN 92]. Ce travail a été initié par Jean-Marc Thévenin et moi-même à l'INRIA

pendant notre thèse puis j'ai poursuivi le développement et la maintenance de la plateforme au

sein du laboratoire PRiSM jusqu'en 1995. GEODE représente plus de 100.000 lignes de C

développées sous Sun OS puis sous Sun Solaris.

Dans la suite de cette section, nous détaillons tout d'abord l'architecture de GEODE, puis

nous présentons les expérimentations les plus marquantes qui ont été réalisées autour de ce

prototype.

4.2.1. Le prototype GEODE

Comme il a été mentionné dans l'introduction, les systèmes multibases intègrent de multiples

sources de données préexistantes dont certaines sont sous le contrôle de SGBD traditionnels

(relationnels ou orientés objets) alors que d'autres sont gérés par des systèmes propriétaires. On

entend par système propriétaire, un système dédié à une certaine catégorie d'applications (e.g.,

système temps-réel, serveur multimédia, serveur Web), qui assure la persistance des données

sans pour autant offrir toutes les fonctionnalités d'un SGBD. Le développement de systèmes

propriétaires peut être justifié par plusieurs raisons : besoin de structures de stockage et

d'indexation spécifiques, besoin d'opérateurs spécifiques, besoin de protocoles transactionnels

spécifiques, besoin d'un ensemble restreint de fonctionnalités bases de données permettant de

satisfaire des contraintes fortes de performance et/ou de consommation de ressources systèmes.

L'objectif de GEODE est de fournir un ensemble d'outils facilitant : (i) le développement

ou la simulation d'un gestionnaire de ressources traditionnel ou spécialisé et (ii) son intégration

cohérente dans un système multibases. Dans la suite, nous reprenons le terme RM, introduit par

X/Open, pour désigner un gestionnaire de ressources. Comme le montre la figure 4.4, la librairie

GEODE se compose de deux familles d'outils. Les outils de construction d'un RM, représentés

en gris foncé sur la figure, assurent le stockage persistant d'objets (Storage Manager),

l'allocation de thread d'exécution permettant de traiter différentes requêtes en parallèle (Task

Manager) et la garantie des propriétés ACID sur les données gérées localement (Local

Transaction Manager). Ces outils doivent permettent à un concepteur de RM de développer

rapidement les opérateurs, protocoles et services spécifiques à ce RM (représentés en blanc sur

la figure). Les outils d'intégration d'un RM, représentés en gris clair sur la figure, assurent la

localisation transparente des services exportés par l'ensemble des RM du système multibases

(Location Manager), l'établissement des connexions entre un client et un ou plusieurs RM et la

69

gestion des talons de communication (Communication Manager) et la garantie des propriétés

ACID des transactions globales (Global Transaction Manager). Les sections suivantes

détaillent chacun de ces gestionnaires.

DSLoMServices

Communication ManagerStorage

Manager

LocalTransactionManager

TaskManager Global Transaction

Manager

Location Manager

DB Log

network RMServices

RM

R

M

Com

munica

tion

Stub

s

Figure 4.4. Outils de développement et d'intégration d'un gestionnaire de ressources

Gestionnaire de stockage (Storage Manager)

Le rôle du gestionnaire de stockage est de stocker tous les objets nécessaires au

fonctionnement interne du RM (tables, index, dictionnaires, méthodes d'accès spécialisées) ainsi

que tous les objets constituant la base de données locale gérée par ce RM. Ce gestionnaire se

doit donc d'offrir des structures de stockage très génériques et de ce fait, la gestion des types est

laissée à la charge du concepteur de RM. Le gestionnaire de stockage offre des services pour

créer, détruire, mettre à jour, agrandir et rétrécir des objets élémentaires correspondants à des

chaînes d'octets de taille variable non typées ainsi que des services pour créer, détruire et faire

des manipulations complexes sur des objets structurés (ensemble, tuple tableau, séquence). Une

description détaillée de ce gestionnaire peut être trouvée dans [Puc 89].

Les objets élémentaires servent de support de stockage indifféremment pour des valeurs

atomiques, des fragments d'objets structurés ou encore des objets non structurés de grande taille

(e.g., image). Les objets élémentaires sont gérés à travers un mécanisme de mémoire virtuelle

persistante. L'espace mémoire est partitionné en segments paginés. Les pages d'un segment sont

chargées en mémoire à la demande et les pages modifiées sont périodiquement reportées sur

disque par un mécanisme de point de reprise asynchrone. Une version matérielle de ce

mécanisme de gestion mémoire a été étudiée et a conduit au dépôt de deux brevets européens

conjointement par le CNRS et l'INRIA. Le premier brevet [FBE 88] porte sur un mécanisme de

70

décodage d'identifiants logiques invariants pour objets complexes. Le second brevet [FGP 88]

complète le premier avec un mécanisme de verrouillage des objets à la volée (i.e., lors du

décodage de leur identifiant), afin de préserver la cohérence des accès concurrents à ces objets.

Les objets structurés sont des structures de données génériques et dynamiques encapsulées

par une collection d'opérateurs prédéfinis, dont la figure 4.5 donne un aperçu. Les objets

structurés peuvent être associés de façon récursive (e.g., tableau de tuples) sans limite afin de

construire des structures aussi complexes que nécessaire.

CONSTRUCTORS SPECIFIC METHODS COMMON METHODS

O1, O2,...,On

CREATE DELETE

[O1,O2,...,On]

Append, Access to Ith index

Access to a given field, Append, suppress,

(A1:O1,...,An:On)

<O1,O2,...,On>

Insert/suppressa sequence into another one

TUPLE

DYNAMIC VECTOR

Update index, First, Next

SEQUENCE

∩, , ∪, ∈, ..., SET

update a field, ...

Update element, First, Next

Figure 4.5. Objets structurés

Gestionnaire de transactions locales (Local Transaction Manager)

Le rôle du gestionnaire de transactions locales est de garantir les propriétés ACID des

branches de transactions qui lui sont soumises (i.e., qui accèdent des données locales à ce site).

L'isolation des transactions est assurée par un protocole de contrôle de concurrence à base de

verrouillage alors que l'atomicité et la durabilité sont assurées par un mécanisme de

journalisation logique. Lorsqu'une transaction manipule un objet géré par le gestionnaire de

stockage, cet objet est automatiquement verrouillé selon un protocole 2PL strict et les opérations

effectuées sur cet objet, ainsi que leurs paramètres, sont automatiquement journalisés. Un

concepteur de RM peut désactiver les services de verrouillage et de journalisation automatiques

afin de définir des protocoles ad-hoc sur des données particulières (e.g., index spécialisé). Des

outils de verrouillage et de journalisation manuels sont proposés à cet effet. Dans tous les cas, la

détection des verrous mortels, la validation et l'abandon des transactions sont gérés

automatiquement par le gestionnaire de transactions locales. Ces mécanismes sont décrits dans

71

le mémoire d'ingénieur CNAM de Alain Bessede [Bes 94] qui a réalisé une partie de ces outils

au cours de son stage de fin d'étude.

Le modèle de transactions supporté est un modèle générique de transactions emboîtées. Il

généralise le modèle de transactions emboîtées fermé [Mos 85] et le modèle de transactions

multi-niveaux [Wei 91]. Ce modèle générique repose sur les concepts de sphère de validation et

de sphère d'abandon [Wal 84] qui permettent de lier des sous-transactions dont l'issue

(validation ou abandon) doit être uniforme. Par exemple, on voit sur la figure 4.6 que la

validation de T11 est conditionnée à la validation simultanée de T111 et T112 (et vice versa),

que l'abandon de T12 entraîne l'abandon de T121 (et vice versa) mais que pas contre, cet

abandon n'a pas d'impact sur T1. L'implémentation de ce modèle dans GEODE est complète et

supporte le parallélisme entre sous-transactions. Une description détaillée de ce modèle peut être

trouvée dans la thèse de Jérôme Besancenot qui a fortement contribué à son élaboration et en a

assuré l'implantation [Bes 96].

T1

T12

T121

T11

T111 T112

Commit Sphere

Abort Sphere

Figure 4.6. Modèle de transactions à sphères de contrôle

72

Gestionnaire de tâches (Task Manager)

Le rôle du gestionnaire de tâches est d'allouer les supports d'exécution permettant le

traitement parallèle des invocations de services issus des processus clients. Le parallélisme est

supporté par des threads (fils d'exécution). On distingue les tâches en arrière plan et les tâches

en avant plan. Une tâche en arrière plan est une boucle infinie qui teste une condition de réveil

et, en fonction du résultat du test, exécute une certaine portion de code ou bien s'endort pour un

quantum de temps. Ces tâches restent actives tant que le processus RM est vivant. Certaines

tâches en arrière plan sont prédéfinies, comme la détection des verrous mortels et la prise

asynchrone de points de reprise, mais d'autres peuvent être définies par le concepteur de RM

(e.g., un ramasse-miettes). Les tâches en avant plan sont utilisées pour supporter le parallélisme

inter et intra transaction. Tout démarrage de transaction crée un nouveau thread d'exécution

(parallélisme inter transactions et inter utilisateurs). L'allocation d'un thread indépendant pour

supporter l'exécution d'une sous-transaction (parallélisme intra transaction) est par contre

conditionnel.

Gestionnaire de transactions globales (Global Transaction Manager)

Comme cela a été mentionné dans l'introduction de ce document, le rôle d'un gestionnaire

de transactions globales est d'assurer : (i) l'atomicité des transactions globales et (ii) la

sérialisabilité globale des exécutions. Dans notre prototype, seule l'atomicité des transactions

globales a été traitée, grâce à un protocole de validation atomique traditionnel (2PC). La

sérialisabilité globale des exécutions est toutefois préservée si tous les RM sérialisent

localement les transactions par l'intermédiaire d'un protocole 2PL strict (protocole mis en oeuvre

par défaut par le gestionnaire de transactions locales de GEODE).

Une particularité de notre gestionnaire de transactions globales est de supporter le même

modèle de transactions que le gestionnaire de transactions locales des RM (i.e., modèle de

transactions emboîtées à sphères de contrôle). Ainsi, il est possible d'exécuter des sous-

transactions d'une même transaction globale sur des sites différents ou d'exécuter une sous-

transaction sur plusieurs sites, tout en gardant les dépendances entre sous-transactions telles

qu'elles sont définies par les sphères de validation et d'abandon. A nouveau, une description

détaillée de ce gestionnaire peut être trouvée dans la thèse de Jérôme Besancenot [Bes 96].

73

Gestionnaire de localisation (Location Manager)

Le gestionnaire de localisation assure la transparence à la localisation pour les données

gérées par les RM ainsi que pour les services qu'ils exportent. Cette localisation est enregistrée

dans un dictionnaire traditionnel. Le rôle de ce gestionnaire est proche du service de nommage

dans une architecture CORBA.

Gestionnaire de communication (Communication Manager)

Le gestionnaire de communication gère quant à lui les connexions entre les processus

client et les serveurs RM. La gestion d'une connexion client/serveur comprend : l'établissement

de la connexion, la gestion des talons de communication et enfin le routage transactionnel des

messages, appelé RPC transactionnel [GR 93]. Le routage transactionnel des messages est

illustré par la figure 4.7. Quand (1) le gestionnaire de communication reçoit une demande

d'invocation d'un service distant pour le compte d'une transaction globale, (2) il demande au

gestionnaire de localisation d'identifier le RM exportant le service en question, puis (3) il

demande au gestionnaire de transactions globales d'identifier la transaction locale qui représente

la transaction globale sur ce RM et enfin (4) il intègre cet identifiant de transaction local au

message et l'envoie au RM concerné. Ce routage transactionnel est transparent au client qui

garde l'illusion d'invoquer un service local pour le compte d'une transaction courante.

DB_RM Server i

Global Transaction Manager

Location

Manager

Communication ManagerGet_RM(Resource_ID)

RM_IDLocal TRID

Get_LocalTRID(Global TRID, RM_IDRM_ID, ...)

1

2

Send(RM_ID, Local TRID,Message)

Call(GlobalTRID, Resource_ID, Parameters) 4

3

Figure 4.7. Routage transactionnel

Comme cela est détaillé dans la thèse de Leïla Hammami [Ham 95], le gestionnaire de

transactions globales, le gestionnaire de localisation et le gestionnaire de communication

peuvent prendre la forme d'une librairie ou d'un serveur indépendant, conduisant ainsi à

plusieurs typologies d'architectures réparties, chacune ayant un intérêt particulier suivant leur

contexte d'utilisation.

74

4.2.2. Les expérimentations

L'expérimentation du modèle de stockage et d'accès grande mémoire DBGraph (cf. Chapitre 3,

§3.5) a été la première menée sur GEODE. Nous rappelons que dans ce modèle, les valeurs

d'attributs sont regroupées par domaines et référencés par les tuples via des pointeurs. Dans

l'implantation de ce modèle, les choix suivants ont été faits. Les tuples d'une même relation sont

stockés séquentiellement dans un même segment. Chaque tuple est matérialisé par un tableau

d'identifiant d'objets (OID) référençant les valeurs des attributs de ce tuple. Les domaines sont

matérialisés par des ensembles de valeurs, afin de bénéficier des opérateurs prédéfinis

d'insertion et de recherche d'un élément dans un ensemble. Les listes inversées associées à

chaque valeur sont matérialisées par des ensembles d'OID, afin de bénéficier des opérateurs

prédéfinis d'union, intersection, différence. Les services proposés par le gestionnaire de

stockage ont très largement facilité le prototypage du modèle DBGraph. Ce prototype, mené a

bien par Sylvie Renard au cours de son stage de fin d'étude d'ingénieur CNAM, est décrit dans

[Ren 93]. Ce rapport inclut également des mesures de performance du prototype réalisé.

La seconde expérience menée a été l'implantation du langage OFL (cf. Chapitre 3, §3.2).

Nous rappelons que OFL est un langage intermédiaire (i.e., langage cible d'un

décomposeur/optimiseur de requêtes) qui permet d'appliquer des itérateurs sur des collections

abstraites d'objets et de combiner ces opérateurs de sorte à produire des exécutions ensemblistes

ou pipelines d'une même requête. Les collections abstraites ont tout d'abord été modélisées par

des segments contenant des objets élémentaires. Puis l'implantation a été étendue afin que tous

les objets structurés (tuple, tableau, ensemble, séquence) puissent être considérés comme des

collections abstraites sur lesquels il est possible d'appliquer des itérateurs. Cette

expérimentation, menée par Fernando Machuca au cours de sa thèse, est décrite dans [Mac 95].

Ce travail a permis d'enrichir le gestionnaire de stockage avec une librairie d'itérateurs

applicables aux segments et aux objets structurés.

Le modèle de vues de graphes ( cf., Chapitre 3, §3.3), a également donné lieu à une

expérimentation autour de GEODE. GEODE a servi ici de simple support de stockage persistant

pour des données de type graphe. Ces données étaient matérialisées par des objets élémentaires

reliés entre eux par des OID. Cette expérimentation, menée par Alejandro Gutiérrez au cours de

sa thèse, est décrite dans [Gut 97]. Elle a permis d'enrichir le gestionnaire de stockage avec un

75

opérateur général de parcours récursif applicable à tout groupe d'objets reliés entre eux par des

OID.

Enfin, bien que les travaux menés sur la sérialisabilité globale des transactions (cf.,

Chapitre 2, §2.3) n'ait pas donné lieu à expérimentation, ils ont été inévitablement influencés par

le développement, en cours à l'époque, du gestionnaire de transactions globales de GEODE.


Le prototype GEODE a constitué, pour moi et les thésards et stagiaires que j'ai encadrés, une

formidable base d'expérimentation. Le fait que le prototype intègre l'ensemble des

fonctionnalités demandées à un noyau de SGBD (stockage persistant, contrôle transactionnel,

multi-tâches, distribution) a permis d'une part de valider les algorithmes expérimentés dans un

environnement concret et d'autre part de faire des mesures de performance significatives.

Cependant, la maintenance de ce logiciel est devenue de plus en plus lourde au fur et à mesure

de sa croissance et du départ naturel des personnes qui y ont contribué. Nous n'avons peut être

pas su gérer correctement cette croissance qui nous a amené à arrêter la maintenance de GEODE

fin 1995, faute de temps et de moyens. Aujourd'hui, nous recentrons nos activités de

développement autour d'architectures distribuées normalisées et autour de composants logiciels

déjà existants. C'est par exemple le cas du prototype NB-SPAC, présenté en début de chapitre,

qui est développé sur une architecture CORBA autour de logiciels existants tels que Orbix,

POET, Oracle et MAAO-OTS. Le résultat en est une expérimentation certes plus modeste mais

dont le coût de développement et de maintenance reste à notre portée.

La diffusion du logiciel GEODE nous a permis d'établir des coopérations avec diverses

équipes de recherche françaises et étrangères. Ainsi, l'équipe du professeur Jean Ferrié du LSI

de Montpellier a utilisé GEODE pour valider différents protocoles de contrôle de concurrence.

L'équipe du professeur Jacques Lemaître du GRTC de Marseille a réalisé une version persistante

du langage de programmation fonctionnel Griffon. L'équipe GeoTropics du PRiSM de

Versailles a utilisé GEODE comme support de stockage pour des données géographiques. Enfin,

le professeur Matthias Jarke a utilisé GEODE comme support de persistance dans l'atelier de

génie logiciel ConceptBase développé par son équipe.

GEODE a également connu une courte histoire industrielle (2 ans), sous le nom de

ObServer. Le prototype a été fiabilisé, porté sur différents systèmes d'exploitation et diffusé par

76

la société Infosys. La diffusion du logiciel s'est arrêtée avec le rachat de la société Infosys par

EDS (Electronic Data Systems). Cette expérience nous a permis de mesurer l'écart existant entre

un bon prototype de recherche et un produit industriel.

Le développement de GEODE a été en partie supporté par le projet européen IMPRESS.

IMPRESS est le projet n° 6355 du programme Esprit-III. Il a démarré en Mai 1992 pour une

durée de trois ans. L'objectif du projet IMPRESS était de concevoir et développer une

plateforme à objets distribuée efficace et fiable (au sens transactionnel du terme) pour stocker et

manipuler différents types d'informations (objets complexes, données techniques, images,

documents hypermedia). Dans ce projet, le laboratoire PRiSM avait la responsabilité d'étendre

le prototype GEODE dans trois directions [BHP 93]: (i) gérer la distribution des données et des

traitements, (ii) supporter un modèle de transactions avancées et (iii) offrir une librairie

d'opérateurs de parcours et de manipulation d'objets complexes. Le prototype final a été validé

par le développement d'une application de gestion et de maintenance de réseaux électriques.

L'ensemble de l'application a été écrite en langage SPOKE (un langage orienté objets développé

par Alcatel), GEODE assurant le stockage persistant de toutes les données (alphanumériques,

graphes, images et documents hypermedia) manipulées par SPOKE.

77

Chapitre 5

Conclusion et perspectives

Comme il a été mentionné dans l'introduction, la diversification des applications bases de

données et la poussée technologique et commerciale autour des réseaux de télécommunication

poussent à la réalisation de systèmes d’information répartis de grande envergure. Dans ce

contexte, les systèmes multibases permettent d’accéder à de multiples sources de données

préexistantes à travers un réseau local ou longue distance. Les problèmes posés par la

conception des systèmes multibases englobent des problèmes récurrents, étudiés depuis bientôt

vingt ans dans le contexte des systèmes répartis, ainsi que de nouveaux problèmes liés à

l'hétérogénéité et à l'autonomie des sources de données participantes.

Ce chapitre résume brièvement les contributions apportées dans chacun des deux axes de

recherche développés dans ce document, à savoir la cohérence et la performance des traitements

multibases et introduit quelques perspectives de recherche prometteuses. Ces deux axes nous

paraissent fondamentaux et complémentaires dans le sens où le premier garantit la cohérence

globale des traitements et des données auxquelles ils s'appliquent (il s'agit là d'un objectif capital

des SGBD) et le second rend l'approche multibases réaliste en lui garantissant un niveau

acceptable de performance.

5.1. Cohérence des traitements multibases

La gestion de transactions a été intensivement étudiée depuis [Gra 78] et d'aucuns pensent qu'il

est temps de considérer ce problème comme étant définitivement résolu. Je pense au contraire

que la gestion de transactions fait partie des problèmes récurrents, à la base de tout système

d'information et en perpétuelle mutation pour s'adapter à de nouveaux environnements.

78

Dans le contexte des systèmes multibases, les protocoles hérités des systèmes répartis pour

assurer les propriétés d'atomicité globale et de sérialisabilité globale ont du être adaptés pour

intégrer l'hétérogénéité et l'autonomie des sites participants. Le chapitre 2 détaille notre

contribution sur ce point. Plus précisément, sur la base d'une étude formelle du problème de la

validation atomique et d'une caractérisation des protocoles de validation atomique, nous avons

fixé, puis raffiné, les hypothèses sous lesquelles il était possible de définir un protocole de

validation qui : (i) ait un faible coût de communication, (ii) soit non bloquant et (iii) préserve

l'autonomie des sites participants. D'autre part, nous avons caractérisé un type d'exécution qui

pouvait prendre en défaut le contrôle de sérialisabilité globale jusque là établit et avons

complété ce contrôle global afin d'écarter toute histoire non globalement sérialisable ou

n'accepter, parmi celles-ci, que celles qui préservent la cohérence du système multibases.

Les perspectives de recherche autour de la gestion de transactions sont nombreuses. Parmi

ces perspectives, trois peuvent constituer des prolongements des travaux déjà entrepris.

La première perspective concerne l'intégration des propriétés ACID dans le concept de

qualité de service. Ainsi, au même titre qu'il est possible de négocier un débit minimum lors de

l'établissement d'une connexion, on peut envisager de négocier également la satisfaction d'une

ou plusieurs propriétés ACID (e.g., atomicité d'une diffusion de message à n destinataires).

La seconde perspective concerne l'intégration du concept de transaction dans Internet en

général et dans les applications de commerce électronique en particulier. La réponse actuelle à

ce problème consiste à intégrer dans l'architecture un moniteur transactionnel qui pilote un

protocole 2PC auquel participent différents sites Internet (e.g., les serveurs d'une galerie

marchande virtuelle et la banque du client). Le fait que le protocole 2PC soit bloquant freine

considérablement son utilisation sur Internet (comment un site peut-il accepter de se bloquer à

cause de la panne d'un autre site qu'il ne connaît même pas). Le même problème de blocage se

pose dans les applications qui cherchent à intégrer un protocole de validation atomique dans les

cartes à puces (cette alternative est en cours d'étude chez les fabricants de cartes à puces pour

pallier certains problèmes de sécurité). Des alternatives au protocole de validation 2PC doivent

donc impérativement être trouvées.

La troisième perspective concerne la gestion de transactions dans le contexte des bases de

données mobiles. Ce domaine de recherche est en pleine expansion, dopé par le succès de la

79

téléphonie mobile. Le problème consiste à assurer un contrôle transactionnel en présence de PC

portables qui se connectent par une interface hertzienne pour extraire des données d'une ou

plusieurs bases présentes sur le réseau filaire. La mobilité pose deux problèmes distincts. Tout

d'abord, la topologie de communication n'est ni prédéfinie, ni fixe, ce qui peut avoir un impact

important sur le coût engendré par des protocoles distribués de validation atomique et de

sérialisation globale. D'autre part, la mobilité est fréquemment synonyme de déconnexion,

volontaire (e.g., économie des batteries et de la note de téléphone) ou accidentelle (e.g., passage

dans un tunnel). La difficulté est alors d'assurer la cohérence de copies multiples d'une même

donnée, certaines étant accessibles via le réseau fixe et d'autres étant momentanément hébergées

sur un PC portable déconnecté.

5.2. Performance des traitements multibases

Augmenter la performance des traitements est un objectif qui est né avec l'informatique et qui en

est indissociable. Cela constitue l'attrait sans cesse renouvelé pour ce problème ainsi que cela en

explique sa difficulté, du fait de la rapidité avec laquelle même les résultats les plus significatifs

deviennent obsolètes.

Le chapitre 3 propose tout d'abord un langage intermédiaire fonctionnel facilitant

l'évaluation et l'optimisation de requêtes multibases traditionnelles (e.g., OQL) et dont la

généricité permet de s'affranchir de l'hétérogénéité des sites participants. L'originalité du modèle

d'exécution associé est d'être basé sur des parcours de graphes lui permettant de supporter des

exécutions ensemblistes, pipelines ou hybrides. La seconde contribution porte sur un modèle

pivot permettant de manipuler des données de type graphe stockées dans différentes sources de

données. A nouveau, le modèle d'exécution associé permet de supporter des exécutions

ensemblistes ou pipelines. Ces travaux, menés dans des contextes très différents, ont été

inévitablement influencés par les résultats obtenus autour des modèles de stockage et d'accès

pour bases de données grandes mémoires (MMDBMS), qui ont mis en lumière tout l'intérêt des

modèles d'exécution pipeline. Enfin, des algorithmes efficaces de recherche de règles

associatives (data mining) ont été proposés. Ces algorithmes tiennent leur performance de

l'utilisation en mémoire centrale de vecteurs de bits compressés. On peut donc considérer que la

conception de ces algorithmes a également été influencée par les travaux antérieurs menés

autour des MMDBMS, notamment dans la prise de conscience de l'importance de la ressource

mémoire centrale.

80

Les perspectives en termes de performance des traitements (multibases ou autres) sont

intrinsèquement liés aux progrès technologiques réalisés sur les architectures de machines.

Notamment, il est surprenant de constater qu'aussi peu de travaux aient été menés autour des

MMDBMS et du peu d'écho qu'ils ont générés comparativement aux travaux menés autour des

SGBD parallèles. Cet état de fait pourrait changer avec l'avènement de PC d'entrée de gamme

doté au minimum de 64 Mo (voire 128 Mo) de mémoire centrale et l'engouement pour les bases

de données personnelles gérées par ces mêmes PC (potentiellement mobiles). De plus, des

mesures récemment publiées par Oracle ont montré la crédibilité (en termes de performance et

de coût) des architectures mono-processeurs à grandes mémoires centrales (4 Go) vis à vis des

architectures parallèles symétriques (SMP). On peut donc imaginer que la recherche sur les

MMDBMS redevienne d'actualité dans les prochaines années. De même, si l'adaptation des

SGBD aux différents types d'architectures parallèles (SMP, cluster, MPP) a été très largement

étudiée, la parallélisation des E/S n'a pas jusqu'à présent connue le même succès. Alors que le

coût des unités de disques RAID (Redondant Array of Inexpensive Disks) baisse et que leur

miniaturisation devrait permettre à moyen terme de les intégrer à la carte mère d'un processeur,

une voie de recherche intéressante pourrait s'ouvrir sur ce thème.

81

Bibliographie

[AAD 93] R. Ahmed, J. Albert, W. Du, W. Kent, W. Litwin, M. Shan, " An Overview of Pegasus", Proc. of the RIDE-IMS conference,Vienna, April 1993.

[Abd 99] M. Abdallah, " Validation atomique dans les architectures à objets distribuées", Thèse de doctorat de l'université de Versailles/St-Quentin, soutenance prévue en Juin 1999.

[ABG 98] M. Abdallah, C. Bobineau, R. Guerraoui, P. Pucheral, "Specification of the Transaction Service" Deliverable OD-II-TLMG-WP1-IR13, OpenDREAMS Esprit Project, July 1998.

[AC 95] Y. Al-Houmaily and P. Chrysanthis, "Two-phase Commit in Gigabit-Networked Distributed Databases", Proc. of the 8th International Conference on Parallel and Distributed Computing Systems (PDCS), September 1995.

[ACM 93] S. Abiteboul, S. Cluet, T. Milo, "Querying and Updating the File", Proc. of the 19th International Conference on Very Large Data Bases (VLDB), Dublin, August 1993.

[ACT 98] M. Aguilera, W. Chen, S.Toueg, "Failure Detection and Consensus in the Crash-Recovery Model", Technical report, Cornell University, 1998.

[AGP 98] M. Abdallah, R. Guerraoui, P. Pucheral, "One-Phase Commit: Does it make sense ?", Proc. of the International Conference on Parallel and Distributed Systems (ICPADS), Taïwan, December 1998.

[AHK 85] A. Ammann, M. Hanrahan, R. Krishnamurthy, "Design of a Memory Resident DBMS", IEEE COMPCON, San Fransisco, California, February 1985.

[AIS 93] R. Agrawal, T. Imielinski, A. Swami, "Mining Association Rules between Sets of Items in Large Databases", Proc. of the International Conference on Management of Data, ACM SIGMOD, 1993.

[AS 94] R. Agrawal, S. Srikant, "Fast Algorithms for Mining Association Rules in Large Databases", Proc. of the 20th International Conference on Very Large Data Bases (VLDB), Santiago de Chile, September 1994.

[AJ 87] R. Agrawal, H. Jagadish, "Direct Algorithms for Computing the Transitive Closure of Database Relations", Proc. of the 13th International Conference on Very Large Data Bases (VLDB), Brighton, September 1987.

82

[AP 97] M. Abdallah, P. Pucheral, "A Non-Blocking Single-Phase Commit Protocol for Rigorous Participants", 13èmes journées Bases de Données Avancées (BDA), Grenoble, Août 1997.

[AP 98a] M. Abdallah, P. Pucheral, "A Single-Phase Non-Blocking Atomic Commitment Protocol", Proc. of the 9th International Conference on Database and Expert Systems Applications (DEXA), Vienna, August 1998.

[AP 98b] M. Abdallah, P. Pucheral, "Validation atomique : état de l'art et perspectives", revue Ingéniérie des Systèmes d'Information (ISI), Vol.5, n° 6, 1998.

[AP 99] M. Abdallah, P. Pucheral, "A Non-Blocking Single-Phase Commit Protocol for Rigorous Participants", Networking and Information Systems Journal, Vol.1, n° 2, to appear. Cette publication est une version retravaillée et raccourcie de [AP 97].

[BBI 93] W.J. Barr, T. Boyd, Y. Inoue, "The TINA Initiative", IEEE Communications Magazine, March 1993.

[BCF 95a] J. Besancenot, M. Cart, J. Ferrié, C. Morpain, J.F. Pons, P. Pucheral, "Preserving the Benefit of Strict 2 Phase Locking with Parallel Multidatabase Transactions", Proc. of the 6th International Conference on Database and Expert Systems Applications (DEXA), London, 1995.

[BCF 95b] Version étendue de [BCF 95a] (même titre, mêmes auteurs) publiée dans : 11èmes journées Bases de Données Avancées (BDA), Nancy, France, Septembre 1995.

[BCF 96] J. Besancenot, M. Cart, J. Ferrié, C. Morpain, J.F. Pons, P. Pucheral, "Correctness of Parallel Executions in MultiDatabase Systems Ruled by Strict 2 Phase Locking", Proc. of the 9th International Conference on Parallel and Distributed Systems (PDCS), September 1996.

[BCF 97] J. Besancenot, M. Cart, J. Ferrié, R. Guerraoui, P. Pucheral, B. Traverson, "Les systèmes transactionnels : concepts, produits et normes", Livre, Editions Hermès, 416 p, 1997.

[BDT 83] D.Bitton, D. DeWitt, C. Turbyfill, "Benchmarking Database Systems: a Systematic Approach”, Proc. of the 9th International Conference on Very Large Data Bases (VLDB), Florence, Italy, November 1983.

[Bes 96] J. Besancenot, "Gestion de Transactions Avancées dans les Bases de Données Distribuées et Hétérogènes", Thèse de doctorat de l'université de Paris VI, 22 Mai 1996.

[Bes 94] A. Bessede, "Etude de la fiabilité et du contrôle de concurrence sur une boîte à outils orientée base de données mémoire", Mémoire en vue d'obtenir le diplôme d'ingénieur CNAM en informatique, CNAM Versailles, 3 Mars 1994.

[BGR 91] Y.Breitbart, D.Georgakopoulos, M.Rusinkiewicz, A. Silberschatz, "On Rigorous Transaction Scheduling", IEEE Transactions on Software Engineering, vol. 17, n° 9, 1991.

[BGS 92] Y.Breitbart, H.Garcia-Molina, A. Silberschatz, "Overview of Multidatabase Transaction Management", VLDB Journal, vol. 1, n° 2, 1992.

83

[BHG 87] P. Bernstein, V. Hadzilacos, N. Goodman, "Concurrency Control and Recovery in Database Systems", Livre, Addison Wesley Publishing, Reading, MA, 1987.

[BHP 93] J. Besancenot, L. Hammami, P. Pucheral, J.M. Thevenin, "Distributed Architecture of the IMPRESS Object Server", Esprit project IMPRESS n°6355, Deliverable n° W7-007-R1, September 1993.

[BHP 95] J. Besancenot, L. Hammami, P. Pucheral, J.M. Thevenin, "IMPRESS Object Server User's Manual", Esprit project IMPRESS n°6355, Internal Report n° IR72, June 1995.

[BK 90] C. Beeri, Y. Kornatzky, “Algebraic Optimisation of Object-Oriented Query Languages”, Proc. of the International Conference on Database Theory (ICDT), Paris, France, 1990.

[BMU 97] S. Brin, R. Motwani, J. Ullman, S. Tsur, “Dynamic Itemset Counting and Implication Rules for Market Basket Data”, Proc. of the International Conference on Management of Data, ACM SIGMOD, 1997.

[BT93] O. Babaoglu, S. Toueg, "Non-Blocking Atomic Commitment", Distributed Systems, Sape Mullender (Ed.), ACM Press, 1993.

[CD 92] S. Cluet, C. Delobel, “A General Framework for the Optimization of Object-Oriented Queries”, Proc. of the International Conference on Management of Data, ACM SIGMOD, 1992.

[CDR 86] M. Carey, D. DeWitt, J. Richardson, E. Shekita, "Object and File Management in the EXODUS Extensible Database System", Proc. of the 12th International Conference on Very Large Data Bases (VLDB), Kyoto, August 1986.

[CGK 89] D. Chimenti, R. Gamboa, R. Krishnamurthy, "Towards an Open Architecture for LDL", Proc. of the 15th International Conference on Very Large Data Bases (VLDB), Amsterdam, The Netherlands, 1989.

[CGP 98] A. Cohen, R. Guerraoui, P. Pucheral, "Services Specifications Assessment and Formalization", Deliverable OD-II-TLMG-WP1-IR11, OpenDREAMS Esprit Project, May 1998.

[CH 90] M. Carey, L. Haas, "Extensible Database Management Systems", in Special Issue on Directions for Future Database Research and Development, ACM SIGMOD Record, Vol. 3, N° 4, 1990.

[CM 90] M. Consens, A. Mendelzon, "Graphlog: a Visual Formalism for Real Life Recursion", Proc. ACM Symposium on Principles of Database Systems, Nashville, 1990.

[CM 94] D. Calcinelli, M. Mainguenaud, "Cigales: A Visual Query Language for Geographical Infornation System. The User Interface", International Journal of Visual Languages and Computing, Academic Press, Vol. 5, 1994, pp. 113-132.

[CN 89] I. Cruz, T. Norvell, "Aggregative Closure: An Extension of Transitive Closure", Proc. IEEE of the 5th. International Conference on Data Engineering (ICDE), Los Angeles, February 1989.

[CN 92] T. Connors, M. Neimat, "The Papyrus Object Library", International Workshop on Persistent Object Systems, San Miniato, Italy, September 1992.

84

[CS 93] S. Chaudhuri, K. Shim, "Query Optimization in the Presence of Foreign Functions", Proc. of the 19th International Conference on Very Large Data Bases (VLDB), Dublin, Ireland, 1994.

[CT 96] T. Chandra, S. Toueg, "Unreliable Failure Detectors for reliable Distributed Systems", Journal of the ACM, Vol. 43, n°4, July 1996. Une version préliminaire est parue dans ACM International Symposium on Principles of Distributed Computing (PODC), August 1991.

[Dar 93] S. Dar, "Augmenting Databases with Generalized Transitive Closure", Ph.D. thesis, University of Wisconsin-Madison, August 1993.

[DEK 91] W.Du, A. Elmagarmid, W. Kim, "Maintaining Quasi Serializability in Multidatabase Systems", Proc. of the 7th IEEE International Conference on Data Engineering, Kobe, Japan, April 1991.

[DKO 84] D. DeWitt, R. Katz, F. Olken, L. Shapiro, M. Stonebraker, D. Wodd, "Implementation Techniques for Main Memory Database Systems", Proc. of the International Conference on Management of Data, ACM SIGMOD, 1984.

[Eic 89] M. Eich, "Main Memory Database Research Directions", Proc. of the 6th International Workshop on Database Machines (IWDM), Deauville, France, June 1989.

[FBE 88] P. Faudemay, J.L. Bechennec, D. Etiemble, G. Gardarin, P. Pucheral, J.M. Thévenin, "Unité de gestion d'accès en mémoire, à identifiants logiques invariants, notamment pour la gestion des bases de données", Dépôt de brevet Européen no 88401819.3-.

[FGP 88] P. Faudemay, G. Gardarin, P. Pucheral, J.M. Thévenin, "Moyen de verrouillage d'accès pour unité de gestion d'accès en mémoire et gestion de conflits d'accès utilisant de tels moyens de verrouillage", Dépôt de brevet Européen no 88401820.1-.

[FFL 97] J. Fessy, B. Finance, Y. Lepetit, P. Pucheral, “Data Management Framework & Telecom Query Service for TINA”, Proc. of the 5th International Conference on Telecommunication Systems Modeling and Analysis, Nashville, TN, March 1997.

[FG 94] B. Finance, G. Gardarin, “A rule-based optimizer with multiple search strategies”, Data & Knowledge Engineering, Vol.13, 1994.

[FLP 85] M. Fisher, N. Lynch, M. Paterson, "Impossibility of Distributed Consensus with one Faulty Process", Journal of the ACM, Vol. 32, 1985.

[FLP 96] J. Fessy, Y. Lepetit, P. Pucheral, “Object Query Service for Telecommunication Networks”, Proc. of the 5th International Conference on Extending Data Bases Technology (EDBT), Avignon, France, March 1996.

[Gue 95] R. Guerraoui, "Revisiting the Relationship between Non Blocking Atomic Commitment and Consensus Problems", International Workshop on Distributed Algorithms (WDAG'95), Mont St-Michel, September 1995.

[GGF 94] G. Gardarin, S. Gannouni, B. Finance, W. Klas, "IRO-DB : a Distributed System Federating Object and Relational Databases", in the book "Object-oriented

85

Multibase Systems : a Solution for Advanced Applications", Chap. 1, O. Bukhres and A. Elmagarmid Editors, 1994.

[GLV 84] H. Garcia Molina, R. Lipton, J. Valdes, "A Massive Memory Machine", IEEE COMPCON, May 1984.

[GM 90] M. Gondran, M. Minoux, "Graphes et Algorithmes", Livre (Chap. 3), Editions Eyrolles, 1990.

[GMM 90] C. Ghezzi, D. Mandrioli, A. Morzenti, "TRIO, a Logic Language for Executable Specifications of Real-Time Systems", Journal of Systems and Software, Vol. 12, n° 2, May 1990.

[GMP 94] G. Gardarin, F. Machuca, P. Pucheral, “A Functional Execution Model to Evaluate Object-Oriented Queries”, Poster Paper Collection of the 20th International Conference on Very Large Data Bases (VLDB), Santiago, Chile, September 1994.

[GMP 95a] G. Gardarin, F. Machuca, P. Pucheral, "OFL: A Functional Execution Model for Object Query Languages", Proc. of the International Conference on Management of Data, ACM SIGMOD, June 1995.

[GMP 95b] G. Gardarin, F. Machuca, P.Pucheral, "Evaluating Object-Oriented Queries as Graph Traversal Functional Programs", Proc. of the International Conference on Intelligent Information Management Systems, Washington DC, USA, June 1995.

[GP 88] G. Gardarin, P. Pucheral, " A graph Operator to Process Efficiently Linear Recursive Rules in a Main Memory Oriented DBMS", Proc. of the 3rd Brazilian Database Symposium, Recife-Pernambuco, Brazil, March 1988.

[GPS 94] A. Gutiérrez, P. Pucheral, H. Steffen, J-M. Thévenin, "Database Graph Views: A Practical Model to Manage Persistent Graphs", Proc. of the 20th International Conference on Very Large Data Bases (VLDB), Santiago, Chile, September 1994.

[GPT 88] G. Gardarin, P. Pucheral, J.M. Thévenin, H. Steffen, "Overall Architecture of the GEODE Extensible DBMS Kernel", Proc. of the 5th European Esprit Conference, Bruxelles, Belgium, November 1988.

[GPT 93] A. Gutierrez, P. Pucheral, J.M. Thevenin, "Specification of Graph Views and Graph Operators", Esprit project IMPRESS n°6355, Deliverable n° R75, August 1993.

[GPW 98] G. Gardarin, P. Pucheral, F. Wu, “Bitmap Based Algorithms For Mining Association Rules”, 14èmes journées Bases de Données Avancées (BDA), Hammamet, Tunisie, Octobre 1998.

[Gra 78] J. Gray, Notes on Database Operating Systems. "Operating Systems: An Advanced Course", Lecture Notes in Computer Science 60:393-481, Springer Verlag, 1978.

[GR 93] J. Gray, A. Reuter, "Transaction Processing: Concepts and Techniques", Livre, Morgan Kaufmann, San Mateo, California, 1993.

86

[GS 95] R. Guerraoui, A. Schiper, "The Decentralized Non-Blocking Atomic Commitment Protocol", IEEE International Symposium on Parallel and Distributed Processing (SPDP), 1995.

[Gue 95] R. Guerraoui, "Revisiting the Relationship between Non-Blocking Atomic Commitment and Consensus Problems", Proc. of the International Workshop on Distributed Algorithms (WDAG), 1995.

[Güt 94] R. Güting, "GraphDB : A Data Model and Query Language for Graphs in Databases", Proc. of the 20th International Conference on Very Large Data Bases (VLDB), Santiago, Chile, September 1994.

[Gut 97] A. Gutiérrez, "Extraction et manipulation d'information structurée sous la forme de graphe à partir de sources de données existantes", Thèse de doctorat de l'université de Versailles, 3 Octobre 1997.

[Ham 95] L. Hammami, "Une Boîte à Outils pour la Construction et la Fédération de Multiples Sources de Données dans un Système Distribué", Thèse de doctorat de l'université de Paris VI, 15 Février 1995.

[Ioa 86] Y. Ioannidis, "On the Computation of the Transitive Closure of Relational Operators", Proc. of the 12th International Conference on Very Large Data Bases (VLDB), Kyoto, Japan, August 1986.

[ISO 92a] International Standardization Organization ISO, "Information Technology - Open Systems Interconnection - Distributed Transaction Processing", ISO/IEC 10026, 1992.

[ISO 92b] International Standardization Organization ISO, "Information Processing Systems - Database Language SQL", ISO/IEC 9075, 1992.

[KM 90] A. Kemper, G. Moerkotte, “Advanced Query Processing in Object Bases Using Access Support Relations”, Proc. of the 16th International Conference on Very Large Data Bases (VLDB), Brisbane, Australia, 1990.

[KMR 91] H. Korth, S. Mehrotra, R. Rastogi, A. Silberschatz,"Non-Serializable Executions in Heterogeneous Distributed Database Systems, Proc. of the 1st International Conference on Parallel and Distributed Systems (PDIS), Miami Beach, December 1991.

[KS 88] H. Korth, G. Speegle, "Formal Model of Correctness without Serialisability", Proc. of the International Conference on Management of Data, ACM SIGMOD, 1988.

[KSK 92] W. Kim, Y. Sagiv, M. Kifer, “Querying Object-Oriented Databases”, Proc. of the International Conference on Management of Data, ACM SIGMOD, USA, June 1992.

[KSW 93] N. Kiesel, A. Schürr, B. Westfechtel, "Design and Evaluation of GRAS, a Graph-Oriented Database System for Engineering Applications", Proc. IEEE of the 6th International Conference. on Computer-Aided Software Engineering (CASE), 1993.

87

[LAE 94] M. Liu, D. Agrawal, A. El Abbadi, "The Performance of Two-phase Commit Protocols in the Presence of Site Failures", Proc. of the 24th International Symposium on Fault-Tolerant Computing, 1994.

[LAE 94] M. Liu, D. Agrawal, A. El Abbadi, "The Performance of Two-phase Commit Protocols in the Presence of Site Failures", Proc. of the 24th International Symposium on Fault-Tolerant Computing, 1994.

[LC 86] T. Lehman, M. Carey, "A Study of Index Structures for Main Memory Database Management Systems", Proc. of the 12th International Conference on Very Large Data Bases (VLDB), Kyoto, Japan, August 1986.

[LC 89] T. Lehman, M. Carey, "A Concurrency Control Algorithm for Memory-Resident Database Systems", Foundation of Data Organization and Algorithms (FODO), 1989.

[LR 82] T. landers, R. Rosenberg, "An overview of MULTIBASE", in Distributed Databases, H.J Schneider Editor, North-Holland, 1982.

[Mac 95] F. Machuca, "Optimization of Query Evaluation in Object Database Systems", Thèse de doctorat de l'université de Versailles, 24 Novembre 1995.

[ME 93] J. Mullen, A. Elmagarmid, "InterSQL : a Multidatabase Transaction Programming Language", Proc. of the Workshop on Database Programming Language, 1993.

[ML 89] C. Mohan, F. Levine, "ARIES/IM: An Efficient and High Concurrency Index Management Method Using Write-Ahead Logging", IBM Reseach Report RJ6846, IBM Almaden Research Center, August 1989.

[Moh 90] C. Mohan, "ARIES/KVL: A Key-Value Locking Method for Concurrency Control of Multiaction Transactions Operating on B-Tree Indexes", Proc. of the 16th International Conference on Very Large Data Bases (VLDB), Brisbane, Australia, August 1990.

[Mos 85] J. Moss, "Nested Transactions: An Approach to Reliable Distributed Computing", The MIT Press, Cambridge, MA, 1985.

[Mos 90] J. Moss, "Design of the Mneme Persistent Object Store", ACM TOIS, Vol. 8, No. 2, 1990.

[Mot 95] F. Mottuel, "Conception et réalisation d'un protocole de validation atomique", Mémoire en vue d'obtenir le diplôme d'ingénieur CNAM en informatique, CNAM Paris, 13 Déc. 1995.

[MRK 91] S.Mehrotra, R.Rastogi, H.Korth, A. Silberschatz, "Non-serializable Executions in Heterogeneous Distributed Database Systems", Proc. of the first International Conference on Parallel and Distributed Information Systems (PDIS), 1991.

[MS 83] M. Missikov, M. Scholl, "Relational Queries in a Domain Based DBMS", Proc. of the International Conference on Management of Data, ACM SIGMOD, 1983.

[MS 90] M. Mannino, L. Shapiro, "Extensions to Query Languages for Graph Traversal Problems", IEEE Trans. On Knowledge and Data Engineering (TKDE), Vol. 2, No. 3, September 1990.

88

[ODM 93] R. Cattell, "The Object Database Standard : ODMG-93", Livre, Morgan Kaufmann Publishers, 1994.

[OHM 92] J. Orenstein, S. Haradhvala, B. Margulies, D. Sakahara, “Query Processing in the ObjectStore Database System”, Proc. of the International Conference on Management of Data, ACM SIGMOD, 1992.

[OMG 95] OMG, "CORBA: Architecture and Specification", Livre, OMG editor, Framingham, USA, August 1995.

[OMG 96] OMG, "Object Transaction Service, CORBAservices: Common Object Services Specification", OMG document 96.11.02.

[OGS 97] R. Oliveira, R. Guerraoui and A. Schiper, "Consensus in the Crash-Recover Model, Technical Report N0 97/239, Computer Science Department, Ecole Polytechnique Fédérale de Lausanne, Switzerland, 1997.

[OGS xx] OGS

[PT 89] P. Pucheral, J.M. Thévenin, "A Graph Based Data Structure for Efficient Implementation of Main Memory DBMS's", Proc. of the 6th International Workshop on Database Machines (IWDM), Deauville, France, June 1989.

[PT 92] P. Pucheral, J.M. Thévenin, "Pipelined Query Processing in the DBGraph Storage Model", Proc. of the 3rd International Conference on Extending Data Bases Technology (EDBT), Vienna, Austria, March 1992. (Best paper award).

[PT 93] P. Pucheral, J.M. Thévenin, "The DBGraph Storage Structure with Extensions to Complex Objects", Esprit project IMPRESS n°6355, Deliverable n° R74, February 1993.

[PTV 90] P. Pucheral, J.M. Thévenin, P. Valduriez, "Efficient Main Memory Data Management Using the DBGraph Storage Model", Proc. of the 16th International Conference on Very Large Data Bases (VLDB), Brisbane, Australia, August 1990.

[Puc 89] P. Pucheral, "Extensibilité et performance d'un gérant d'objets pour applications bases de données", Thèse de doctorat de l'université de Paris VI, Décembre 1989.

[Ren 93] S. Renard, "Réalisation et évaluation d'un modèle de stockage et d'accès pour bases de données grandes mémoires", Mémoire en vue d'obtenir le diplôme d'ingénieur CNAM en informatique, CNAM Versailles, 17 Mai 1993.

[SAB 94] H. Steenhagen, P. Apers, H. Blanken, R. de By, “From Nested-Loop to Join Queries in OODB” Proc. of the 20th International Conference on Very Large Data Bases (VLDB), Santiago de Chile, Chile, September 1994.

[SC 90] J. Stamos, F. Cristian, "A Low-Cost Atomic Commit Protocol", Proc. of the 9th Symposium on Reliable Distributed Systems, 1990.

[ShC 90] E. Shekita, M. Carey, “A Perfomance Evaluation of Pointer-Based Joins”, Proc. of the International Conference on Management of Data, ACM SIGMOD, 1990.

[SED xx] MAAO-OTS

[Ske 81] D. Skeen, "Non-Blocking Commit Protocols", Proc. of the International Conference on Management of Data, ACM SIGMOD, 1981.

89

[SL 90] A. Sheth, J. Larson, "Federated Database Systems for Managing Distributed, heterogeneous and Autonomous Databases", ACM Computing Surveys, Vol. 22, n° 3, 1990.

[Sma 97] V. Smahi, "L'optimisation de requêtes dans les bases de données interopérables", Thèse de doctorat de l'Université de Paris VI, Janvier 1997.

[SON 95] A. Savasere, E. Omiecinski, S. Navathe, "An Efficient Algorithm for Mining Association Rules in Large Databases", Proc. of the 21th International Conference on Very Large Data Bases (VLDB), Zurich, Swizerland, 1995.

[TBD 87] M. Templeton, D. Brill, S. Dao, E. Lund, P. Ward, A. Chen, R. Macgregor, "Mermaid - A Front-end to Dsitributed Heterogeneous Databases", Proc. of 3rd IEEE the International Conference on Data Engineering, 1987.

[Tra 92] B. Traverson, "Le protocole de validation en deux phases - Stratégies d'optimisation et évaluation de performance", Réseaux et Informatique Répartie, Volume 2, N°4, 1992.

[Val 87] P. Valduriez, "Join Indices", ACM TODS, Vol. 12, No 2, June 1987.

[VLZ 91] P. Valduriez, R. Lanzelotte, M. Ziane, J-P. Cheiney, “Optimization of non Recursive Queries in OODB”, Proc. of the International Conference on Deductive and Object-Oriented Databases (DOOD), Munich, Germany, 1991.

[Wal 84] B. Walter, "Nested Transactions with Multiple Commit Points: an Approach to the Structuring of Advanced Database Applications", Proc. of the 10th International Conference on Very Large Data Bases (VLDB), Brisbane, Singapore, August 1984.

[Wei 91] G. Weikum, "Principles and Realization of Multilevel Transaction Management", ACM Transactions on Database Systems, vol. 16, n° 1, march 1991.

[X/Op 96] X/Open Company Limited, "Distributed Transaction Processing: Reference Model", X/Open Guide, Version 3. G307, 1996.

90

Bibliographie personnelle référencée dans ce document18

Travaux relatifs à l'atomicité des transactions (Chapitre 2, §2.2) : [AP 97], [AP 98a], [AP 98b], [AGP 98], [AP 99]

Travaux relatifs à la sérialisabilité des transactions (Chapitre 2, §2.3) : [BCF 95a], [BCF 95b], [BCF 96], [BCF 97]

Travaux relatifs aux requêtes multibases assertionnelles (Chapitre 3, §3.2) : [GMP 94], [GMP 95a], [GMP 95b], [FLP 96], [FFL 97]

Travaux relatifs aux requêtes multibases techniques (Chapitre 3, §3.3) : [GPT 93], [GPS 94]

Travaux relatifs à la fouille de données (Chapitre 3, §3.4) : [GPW 98]

Travaux relatifs aux MMDBMS (Chapitre 3, §3.5) : [GP 88], [PT 89], [PTV 90], [PT 92], [PT 93]

Travaux de prototypage (Chapitre 4) : [FBE 88], [FGP 88], [GPT 88], [Puc 89], [BHP 93], [BHP 95], [ABG 98], [CGP 98]

18 Une liste exhaustive des publications est fournie dans le Curriculum Vitae joint.

91

habilitation a diriger des recherches en informatique …pucheral/publis/hdr_final.pdf ·...

Documents