Optimisation de la localité spatiale des données temporelles et multiversions

´

Ecole Doctorale D´

ecision, Informatique, Math´

ematiques,

Organisation

N˚ attribu´e par la biblioth`eque

Optimisation de la localit´

e spatiale des donn´

ees

temporelles et multiversions

Th`

ese

Pour l’obtention du titre de

Docteur en Sciences

Sp´

ecialit´

e : Informatique

(Arrˆ

et´

e du 07 Aoˆ

ut 2006 )

Pr´

esent´

ee et soutenue publiquement par

Khaled JOUINI

Jury

Directeur de th`

ese

Mme Genevi`

eve JOMIER

Professeur `

a l’Universit´

e Paris Dauphine

Rapporteurs

Mme Claudia BAUZER MEDEIROS

Professeur `

a l’Universit´

e de Campinas, Br´

esil

M. Wojciech CELLARY

Professeur `

a l’Universit´

e des Sciences ´

Economiques de Pozna`

n, Pologne

M. Michel SCHOLL

Professeur au Conservatoire National des Arts et M´

etiers

Suffragants

M. Philippe RIGAUX

Professeur `

a l’Universit´

e Paris Dauphine

Mme. Marta RUKOZ

Professeur `

a l’Universit´

e Paris X Nanterre

M. St´

ephane GAN ¸

CARSKI

Maˆıtre de conf´

erences H.D.R `

a l’Universit´

e Pierre et Marie Curie

Mme. Maude MANOUVRIER

Remerciements

D

urant toutes ces ann´

ees de th`

ese, j’ai appris non sans mal `

a r´

ediger des

documents scientifiques. Mais voil`

a venu, comme le veut la tradition,

une tˆ

ache encore plus ardue : la page de remerciements. Non que t´

emoigner

ma gratitude envers les personnes en qui j’ai trouv´

e un soutien soit contre

ma nature, bien au contraire. La difficult´

e tient plutˆ

ot dans le fait d’exprimer

cette gratitude par des mots. Comme j’ai fait comme j’ai pu, sachez que mes

sentiments d´

epassent mes paroles.

Je tiens tout d’abord `

a t´

emoigner une profonde et sinc`

ere gratitude

en-vers Mme. Genevi`

eve Jomier, Professeur `

a l’Universit´

e Paris Dauphine et

directeur de cette th`

ese, qui par sa confiance, par la rigueur et la

clair-voyance de ses jugements et par ses qualit´

es humaines et professionnelles, a

permis `

a cette th`

ese d’exister.

Je tiens ´

egalement `

a remercier particuli`

erement Mme. Claudia

Bauzer-Medeiros, Professeur `

a l’Universit´

e de Campinas et rapporteur de cette th`

ese,

avec qui il a ´

et´

e extrˆ

emement agr´

eable de collaborer. Je la remercie pour sa

disponibilit´

e, son ´

ecoute, ses encouragements et ses pr´

ecieux conseils qui ont

permis tout au long de ces ann´

ees d’am´

eliorer la qualit´

e de mon travail.

Merci de me faire l’honneur de participer `

a ce jury.

Je remercie vivement, M. Michel Scholl, Professeur au Conservatoire

Na-tional des Arts et M´

etiers et rapporteur de ce m´

emoire, de me faire l’honneur

de participer `

a ce jury.

M. Wojciech Cellary, Professeur `

a l’Universit´

e des Sciences ´

Economiques

de Pozna`

n et rapporteur de cette th`

ese, pour l’int´

erˆ

et port´

e `

a mon travail.

Merci de me faire l’honneur de participer `

a ce jury.

Mme Marta Rukoz, Professeur `

a l’universit´

e Paris Dauphine et

rappor-teur de ce m´

emoire, de me faire l’honneur de participer `

a ce jury et pour sa

chaleur humaine et sa gentillesse.

M. Philippe Rigaux, Professeur `

a l’Universit´

e Paris Dauphine, pour m’avoir

fait l’honneur de participer `

a ce jury.

Je remercie tout le personnel du Service Commun de Documentation

et particuli`

erement, Mme. Isabelle Sabatier, S´

ebastien (Abou Ugo),

Hi-cham, Jocelyne, Nicole, Martine, Isabelle, Laurence, S´

everine, Saloua, Luc,

Alexandre, G´

erard, Caroline, St´

ephanie, Andr´

e et Christine. Merci d’avoir

fait en sorte que la biblioth`

eque soit devenu pour moi comme une famille.

Je remercie mes fr`

eres Zied (zaydoun) et Souhayel (sousou) et leurs

´

epouses, Rihab et Souhir, qui ne m’ont m´

enag´

e ni soutien ni assistance

quand le besoin s’en est fait sentir. Merci `

a la petite derni`

ere, Lina, qui

par sa simple pr´

esence a ´

egay´

e mes journ´

ees.

Je remercie mes adorables grands parents maternels, Belgacem et

Ha-biba, pour leurs encouragements et pour avoir demand´

e r´

eguli`

erement de

mes nouvelles. J’ai une pens´

ee particuli`

ere pour mes grands parents

pater-nels, Boulˆ

ares et Omm Elkhir, qui ne sont plus parmi nous, et qui, j’en suis

sˆ

ur, auraient ´

et´

e fiers de moi.

Je remercie vivement ma belle famille Salem, Hasna, Aymen et Achref

pour leur confiance et soutien ind´

efectible. Je remercie particuli`

erement

Ay-men pour toute l’aide et l’assistance qu’il m’a apport´

e pendant ses ann´

ees

d’´

etude en France.

Je remercie ´

egalement mes amis Moncef, Houssem et Monem pour leur

soutien et pour avoir demand´

e r´

eguli`

erement de mes nouvelles.

Je remercie du fond du cœur mes parents Mokhtar et Zaineb. Cette

th`

ese est un peu la leur, aussi. Merci mon papa pour ton soutien, ta

pa-tience et aussi pour m’avoir offert l’opportunit´

e de venir en France pour

poursuivre mes ´

etudes. Merci Zaynouba pour ton irrempla¸

cable et

incondi-tionnel soutien et pour n’avoir jamais su ˆ

etre objective `

a mon ´

egard. Tes

coups de t´

el´

ephones m’ont permis d’´

ecarter les doutes, soigner les blessures

et partager les joies. Si la page de remerciements a une raison d’ˆ

etre, c’est

certainement parce qu’elle donne l’occasion de vous remercier.

Le plus fort de mes remerciements revient `

a ma tendre moiti´

e Imen.

Merci de m’avoir tenu la main jusqu’aux derni`

eres lignes de ce m´

emoire. Par

ton aide, tes inlassables encouragements et ton d´

evouement tu as permis `

a

cette th`

ese d’exister. Cette th`

ese est un peu la tienne, aussi. Merci d’avoir

support´

e mon rythme de vie d´

ecal´

e et mon humeur de barbu en fin de th`

ese.

Merci d’ˆ

etre l`

a tous les jours.

La gestion efficace des donn´

ees temporelles et multiversions est cruciale pour

nombre d’applications de base de donn´

ees, des plus classiques aux plus r´

e-centes. La hi´

erarchie de m´

emoires est le goulot d’´

etranglement majeur pour

les syst`

emes de gestion de base de donn´

ees. Un des principaux moyens pour

optimiser l’utilisation de la hi´

erarchie de m´

emoires et d’optimiser la localit´

e

spatiale des donn´

ees, c’est-`

a-dire de placer de mani`

ere contigu¨

e les

don-n´

ees qui ont de grandes chances d’ˆ

etre lues au mˆ

eme moment. Le probl`

eme

pos´

e dans cette th`

ese est d’optimiser la localit´

e spatiale des donn´

ees

tempo-relles et multiversions `

a tous les niveaux de la hi´

erarchie de m´

emoires, via

les structures d’indexation et les strat´

egies de stockage. Cette th`

ese d´

efinit

un mod`

ele de coˆ

ut, l’analyse en r´

egime permanent, permettant d’estimer

avec pr´

ecision les performances des diff´

erentes structures d’indexation et de

comprendre leur comportement. Ainsi, l’analyse fournit aux concepteurs de

bases de donn´

ees temporelles ou multiversions les outils leur permettant de

choisir la structure d’indexation qui sied le mieux `

a leurs applications. Cette

th`

ese ´

etudie ´

egalement l’impact de la redondance due au versionnement sur

l’utilisation du cache de second niveau. La th`

ese propose `

a cet effet deux

mod`

eles de stockage qui, contrairement aux mod`

eles de stockage standards,

´

evitent la redondance due au versionnement et optimisent l’utilisation du

cache de second niveau et de la bande passante de la m´

emoire vive.

many traditional and emerging database applications. A major performance

bottleneck for database systems is the memory hierarchy. One of the main

means for optimizing the utilization of the memory hierarchy is to

opti-mize data spatial locality, i.e. to put contiguously data that are likely to

be read simultaneously. The problem studied in this thesis is to optimize

temporal and multiversion data spatial locality at all levels of the memory

hierarchy, using index structures and storage policies. In particular, this

thesis proposes a cost model, the steady state analysis, allowing an accurate

estimation of the performance of different index structures. The analysis

provides database designers tools allowing them to determine the most

suit-able index structure, for given data and application characteristics. This

thesis also studies the impact of version redundancy on L2 cache utilization.

It proposes two storage models which, in contrast with the standard storage

models, avoid version redundancy and optimize L2 cache and main memory

bandwidth utilization.

Table des mati`

eres

Introduction

1

1

Concepts et d´

efinitions

4

1.1

Version d’entit´

e et version de base de donn´

ees . . . .

4

1.2

Partage implicite . . . .

7

1.3

Etendue de VBD . . . .

´

8

1.4

Op´

erations de modification

. . . .

9

1.5

Interrogation des donn´

ees multiversions . . . .

11

2

Indexation des versions d’entit´

e

12

2.1

Comparaison de m´

ethodes d’indexation des versions . . . . .

16

2.2

Indexing Multiversion DataBases . . . .

36

2.3

Design and Analysis of Index Structures in MultiVersion Data

Warehouses . . . .

40

3

Optimisation de l’utilisation du cache L2

62

3.1

Read-Optimized Page Layouts for Temporal Relational Data

66

3.2

Avoiding Version Redundancy for High Performance Reads

In Temporal DataBases . . . .

80

3.3

Cache-Conscious Page Layouts for Temporal Data . . . .

86

Conclusion et perspectives

105

Introduction

L

es donn´

ees temporelles et multiversions sont au cœur de nombre

d’ap-plications de bases de donn´

ees, des plus classiques, telles que les

ap-plications de gestion, aux plus r´

ecentes, telles que les entrepˆ

ots

multiver-sions [BEK

_{04, GLRV06] et les syst`}

_{emes d’information sur la bio-diversit´}

_e

[JM07]. Les bases de donn´

ees d´

edi´

ees `

a ces applications doivent fournir les

outils ad´

equats pour mod´

eliser, stocker et interroger efficacement les

don-n´

ees temporelles et multiversions. Le cadre g´

en´

eral de cette th`

ese est relatif

`

a l’optimisation de requˆ

etes aux donn´

ees temporelles et multiversions.

Les Syst`

emes de Gestion de Base de Donn´

ees (SGBD) transf´

erent les

donn´

ees de la m´

emoire persistante (disque) vers le processeur pour ex´

ecuter

une requˆ

ete. Les donn´

ees traversent la hi´

erarchie de m´

emoires, compos´

ee

du disque, de la m´

emoire vive, du cache de second niveau L2 et du cache

de premier niveau L1 [Bay05]. L’acc`

es au disque est classiquement

consi-d´

er´

e comme le principal goulot d’´

etranglement pour les SGBD. Cependant,

des travaux r´

ecents sur des SGBD tournant sur des plateformes modernes,

montrent que les d´

efauts de cache L2 ont un impact de plus en plus

im-portant sur les temps d’ex´

ecution des requˆ

etes [ADHW99, MBK00, ADH02,

SAB

05]. Le nouveau goulot d’´

etranglement que repr´

esente l’acc`

es `

a la m´

e-moire vive est dˆ

u `

a : (i ) l’accroissement de la taille des m´

emoires vives et

en cons´

equence de celle des m´

emoires tampons (Buffer pool ); (ii ) la diff´

e-rence de plus en plus grande entre la vitesse du processeur et celle de la

m´

emoire vive; et (iii ) le d´

eveloppement de techniques software et hardware

permettant d’amortir le coˆ

ut de l’acc`

es au disque, telles que le pr´

echarge-ment (prefetching) et les processus l´

egers (multi-threading). Par cons´

equent,

la conception des SGBD doit prendre en consid´

eration, aussi bien l’acc`

es au

disque que l’acc`

es `

a la m´

emoire vive et au cache de second niveau [ADH02].

L’unit´

e de transfert entre le disque et la m´

emoire vive est une page, dont

la taille varie typiquement de 4 `

a 64 Kilo octets [SSS

04]. L’unit´

e de

trans-fert entre la m´

emoire vive et le cache de second niveau est une ligne de cache,

dont la taille varie typiquement de 8 `

a 512 octets [SSS

04]. Lorsqu’une

don-n´

ee n´

ecessaire `

a l’ex´

ecution d’une requˆ

ete est charg´

ee du disque en m´

emoire

vive, les donn´

ees qui se trouvent `

a proximit´

e dans la page sont ´

egalement

charg´

ees. De mˆ

eme, lorsque cette donn´

ee est charg´

ee de la m´

emoire vive au

cache de second niveau, les donn´

ees limitrophes dans la ligne de cache sont

charg´

ees. L’utilisation de la hi´

erarchie de m´

emoires peut donc ˆ

etre optimis´

ee

si `

a chaque niveau de cette hi´

erarchie, les donn´

ees qui ont de grandes chances

d’ˆ

etre lues au mˆ

eme moment sont plac´

ees de mani`

ere contigu¨

e. C’est le

prin-cipe de localit´

e spatiale [RG00]. L’objectif de cette th`

ese est d’optimiser la

localit´

e spatiale des donn´

ees temporelles et multiversions, `

a tous les niveaux

de la hi´

erarchie de m´

emoires, par l’utilisation de structures d’indexation et

de mod`

eles de stockage sp´

ecifiques.

Classiquement, les structures d’indexation sont optionnelles puisqu’un

balayage s´

equentiel permet de trouver les donn´

ees d’int´

erˆ

et [BO99].

Cepen-dant, dans les base de donn´

ees volumineuses, telles que peuvent l’ˆ

etre les

bases de donn´

ees temporelles et multiversions, le parcours s´

equentiel est

prohibitif et les structures d’indexation, qui sont le premier moyen pour

avoir un acc`

es rapide et s´

electif aux donn´

ees, sont employ´

es [BO99]. Cette

th`

ese d´

efinit un cadre pour la conception, l’analyse et la comparaison de

structures d’indexation pour donn´

ees temporelles et multiversions. En

par-ticulier, ce cadre permet l’extension des structures d’indexation con¸

cues pour

les donn´

ees `

a ´

evolution lin´

eaire aux donn´

ees `

a ´

evolution arborescente et d´

e-finit un mod`

ele de coˆ

ut appel´

e l’analyse en r´

egime permanent. L’analyse en

r´

egime permanent permet : (i ) d’estimer avec pr´

ecision les performances des

diff´

erentes structures d’indexation; (ii ) de mieux comprendre leur

compor-tement; et (iii ) de d´

eterminer la structure d’indexation la plus adapt´

ee en

fonction des caract´

eristiques des donn´

ees et de l’application.

G´

en´

eralement, les SGBD implantent un seul mod`

ele de stockage, le N-ary

Storage Model (NSM) [RG00, GMUW00]. NSM est un mod`

ele de stockage

orient´

e n-uplet (row-store [SAB

05]), dans le sens o`

u les valeurs d’attributs

sont regroup´

ees par n-uplet dans les pages disque [SAB

05]. Le mod`

ele NSM

offre une plateforme g´

en´

erale pour les diff´

erents besoins du SGBD.

Cepen-dant, de r´

ecentes ´

etudes montrent que son utilisation pour les applications

orient´

ees interrogation (query-intensive applications [SAB

05]) a un impact

n´

egatif sur l’utilisation du cache de second niveau et de la bande passante

de la m´

emoire vive [ADH02, Sc05, SAB

05, AMF06, SMA

07, AMH08].

R´

ecemment, plusieurs syst`

emes acad´

emiques et commerciaux utilisant des

mod`

eles de stockage autres que NSM et visant `

a optimiser l’utilisation du

cache de second niveau ont ´

et´

e propos´

es : SybaseIq [Syb], KDB [KDB],

Sen-Sage [Sen], VectorNova [Vec], Fractured Mirrors [RDS03], Monet [BZN05],

C-Store [SAB

_{05], Google Bigtable [CDG}

_{06], Vertica [Ver07], etc.. En d´}

e-pit de la diffusion des donn´

ees temporelles et multiversions, les syst`

emes

susmentionn´

es ne leur ont pas accord´

e une attention particuli`

ere. Cette

th`

ese d´

efinit deux mod`

eles de stockage sp´

ecialement con¸

cus pour les

don-n´

ees temporelles et permettant l’optimisation de l’utilisation du cache de

second niveau et de la bande passante de la m´

emoire vive.

Les principales contributions de la th`

ese sont donc :

• L’extension des structures d’indexation con¸cues pour les donn´

ees `

a

´

evolution lin´

eaire aux donn´

ees `

a ´

evolution arborescente

• La d´

efinition d’un mod`

ele de coˆ

ut, l’analyse en r´

egime permanent,

pour analyser et comparer les structures d’indexation con¸

cues pour

les donn´

ees temporelles et multiversions.

• Le d´

efinition de deux mod`

eles de stockage pour les donn´

ees

tempo-relles, optimisant l’acc`

es au cache de second niveau.

Cette th`

ese est organis´

ee en trois chapitres. Le premier chapitre

intro-duit les principaux concepts. Le deuxi`

eme chapitre concerne l’indexation

des donn´

ees temporelles et multiversions. Le troisi`

eme chapitre concerne les

mod`

eles de stockage dans les bases de donn´

ees temporelles et multiversions.

Chapitre 1

Concepts et d´

efinitions

C

e chapitre, largement inspir´

e de [CJ90], [GJ95] et [CJGM01], pr´

esente

les concepts et d´

efinitions n´

ecessaires `

a la compr´

ehension de la suite

de la th`

ese. Dans la suite de ce chapitre le terme entit´

e est utilis´

e pour

d´

esigner toute information persistante (n-uplet ou objet). La section 1.1

d´

efinit les concepts de version d’entit´

e et de version de base de donn´

ees

conform´

ement au mod`

ele des Versions de Base de Donn´

ees [CJ90, GJ95,

JC00]. La section 1.2 introduit le concept de partage implicite. La section

1.3 d´

efinit le concept d’´

etendue de versions de base de donn´

ees. La section

1.4 revoit les diff´

erentes op´

erations de modification dans une base de donn´

ees

multiversions. La section 1.5 brosse une vue globale sur les types de requˆ

etes

aux donn´

ees multiversions.

1.1

Version d’entit´

e et version de base de donn´

ees

Classiquement, une base de donn´

ees (monoversion) repr´

esente un seul

´

etat de l’univers mod´

elis´

e, compos´

e du dernier ´

etat persistant de chacune

des entit´

es pr´

esentes dans la base. La modification d’une entit´

e entraˆıne

la cr´

eation d’un nouvel ´

etat de l’univers mod´

elis´

e. Une fois valid´

e, ce

nou-vel ´

etat devient le seul ´

etat persistant que la base repr´

esente [GJ95]. Une

base de donn´

ees temporelles ou multiversions permet de rendre simultan´

e-ment persistants le nouvel et l’ancien ´

etat de l’univers mod´

elis´

e. Une base

de donn´

ees temporelles ou multiversions peut donc repr´

esenter un nombre

quelconque d’´

etats persistants, ou versions, de l’univers mod´

elis´

e; chacun

´

etant compos´

e d’´

etats persistants, ou versions, d’entit´

es de la base [GJ95].

Un ´

etat persistant d’une entit´

e est appel´

e version d’entit´

e [CJ90, GJ95]. Un

´

etat persistant de l’univers mod´

elis´

e est appel´

e Version de Base de Donn´

ees

Fig. 1.1 : Les conceptions v2 et v3 sont d´eriv´ees `a partir de v1. La

conception de la cuisine est modifi´ee dans v2et la conception

de la chambre `a coucher est modifi´ee dans v3

ou VBD [CJ90, JC00, SJL

_04].

Dans la suite de cette th`

ese le terme bases de donn´

ees multiversions

uti-lis´

e seul, inclut les bases de donn´

ees temporelles. Concr`

etement, dans le cas

temporel, une version de base de donn´

ees repr´

esente l’´

etat de l’univers

mo-d´

elis´

e `

a un instant t. Cet instant t est m´

emoris´

e dans l’estampille temporelle

(timestamp) utilis´

ee pour l’identification de la version de base de donn´

ees.

Dans le cas g´

en´

eral d’une base de donn´

ees multiversions, une version de base

de donn´

ees est identifi´

ee par une estampille de version v, dont la s´

emantique

est associ´

ee `

a l’application pour laquelle la base est construite.

Lorsqu’au-cune confusion n’est possible, nous ne distinguerons pas une version de base

de donn´

ees de l’estampille v qui l’identifie.

Consid´

erons `

a titre d’exemple la figure 1.1 o`

u une base de donn´

ees est

uti-lis´

ee par un architecte pour mod´

eliser le processus de conception de maisons

[JSLB00b]. La conception de la premi`

ere maison commence `

a partir d’une

page blanche (version v

dans la figure 1.1). Pour garder une trace de son

travail, l’architecte cr´

ee, `

a chaque ´

etape importante, une nouvelle version

de la maison (version v

dans la figure 1.1). Plus tard, l’architecte

com-mence la conception d’une deuxi`

eme maison. Au lieu de partir d’une page

blanche, il d´

ecide de partir de la conception d’une des versions existantes de

la premi`

ere maison (la version v

dans la figure 1.1). Une telle approche cr´

ee

des branches d’´

evolution ind´

ependantes et parall`

eles : ´

evolution arborescente

(branched evolution [LST95, JSLB00a, SJL

04]).

Soit E = {e} et V = {v}, respectivement, l’ensemble des identificateurs

d’entit´

e et d’estampilles de version de base de donn´

ees repr´

esent´

ees dans

la base. Dans une version de base de donn´

ees v ∈ V, une entit´e e ∈ E est

Chapitre 1 : Concepts et d´efinitions

6

Fig. 1.2 : (a) VBD initiale v1. (b) Les VBD v2 et v3 sont d´eriv´ees de

v1. c est mis `a jour dans v2, d est mis `a jour dans v3. (c)

Arbre des VBD et versions d’entit´e stock´es.

repr´

esent´

ee par une seule de ses versions, identifi´

ee par (e, v) [CJ90]. Une

version d’entit´

e est donc un couple ((e, v) , val), o`

u val est la valeur prise par

l’entit´

e e dans la version de base de donn´

ees v. Si l’identificateur d’entit´

e

fait partie de la valeur de l’entit´

e, comme c’est le cas pour la cl´

e primaire

d’un n-uplet dans le mod`

ele relationnel, il est n´

ecessaire d’imposer qu’il ne

puisse ˆ

etre modifi´

e [GJ95]. Dans le cas o`

u une entit´

e e n’existe pas dans une

version de base de donn´

ees v, une valeur sp´

eciale, nil (qui signifie ”n’existe

pas”), est associ´

ee au couple (e,v ) [CJ90].

Une version de base de donn´

ees v ∈ V est compos´ee de l’ensemble des

(e, v), versions d’entit´

e estampill´

ees par v : VBD v = {(e, v), pour tout

e ∈ E}. Ceci est illustr´e par les figures 1.2.a, o`

u sont appliqu´

ees, comme

dans la suite de la th`

ese, les conventions d’´

ecriture suivantes :

• les identificateurs d’entit´

e sont des minuscules latines du d´

ebut de

l’alphabet.

• les valeurs de versions d’entit´

e sont des minuscules grecques du d´

ebut

de l’alphabet.

• les changements dans une figure par rapport `

a celle qui la pr´

ec`

ede dans

un exemple sont marqu´

es en gras.

Exception faite de la premi`

ere version de base de donn´

ees v

, toute

nou-velle version de base de donn´

ees v

est cr´

e´

ee par d´

erivation (c’est-`

a-dire copie

logique) `

a partir d’une version de base de donn´

ees pr´

eexistante v

[CJ90]. v

est alors dite parente de v

et v

version de base de donn´

ees fille de v

. Une

fois la version de base de donn´

ees v

d´

eriv´

ee, des op´

erations de modification

(insertion, suppression, mise `

a jour) peuvent ˆ

etre effectu´

ees sur les versions

d’entit´

es (e, v

) qui la composent. Les liens de d´

erivations structurent

des VBD ou arbre de d´

erivation [CJ90, SJL

04]. Ceci est illustr´

e dans la

figure 1.2.b o`

u deux nouvelles versions de base de donn´

ees v

et v

sont

d´

eriv´

ees `

a partir de la version de base donn´

ees initiale v

.

1.2

Partage implicite

Tr`

es souvent deux versions de base de donn´

ees successives ne diff`

erent

que par la valeur d’une faible proportion des entit´

es repr´

esent´

ees [GJ95].

Une entit´

e peut donc garder la mˆ

eme valeur dans plusieurs versions de base

de donn´

ees successives. Un espace de stockage consid´

erable peut ˆ

etre ´

eco-nomis´

e si une version d’entit´

e est associ´

ee, non pas `

a une seule version de

base de donn´

ees, mais `

a l’ensemble des versions de base de donn´

ees dans

lesquelles l’entit´

e garde la mˆ

eme valeur. Cette observation est utilis´

ee dans

le partage implicite de valeur de versions d’entit´

e [CJ90, GJ95]. Avec le

par-tage implicite, seules les valeurs des versions d’entit´

e correspondant `

a une

modification de l’´

etat d’une entit´

e sont explicitement stock´

ees. Pour

retrou-ver la valeur d’une retrou-version d’entit´

e (e, v

), la r`

egle suivante est utilis´

ee : ”la

valeur de (e, v

), si elle n’est pas explicitement stock´

ee, est la mˆ

eme que celle

stock´

ee pour la version d’entit´

e (e, v

), o`

u v

est le plus proche ancˆ

etre de v

identifiant une version de l’entit´

e e” [CJ90, GJ95]. La version d’entit´

e (e, v

)

est dite valide pour la version de base de donn´

ees v

et pour toute version

de base de donn´

ees v

, telle que :

1. v

est un ancˆ

etre de v

.

2. il n’existe pas de version de base de donn´

ees v

, telle que :

(a) la valeur de (e, v

) est explicitement stock´

ee; et

(b) v

est un plus proche ancˆ

etre de v

que v

.

La figure 1.2.c illustre le contenu effectivement stock´

e de la base de la figure

1.2.b. La valeur de (a, v

) n’est pas explicitement stock´

ee. Le principe du

partage implicite permet de d´

eduire que (a, v

) est valide pour v

et donc

que (a, v

) poss`

ede la mˆ

eme valeur que (a, v

), c’est-`

a-dire α

.

La notion de partage implicite est intuitive dans les bases de donn´

ees

temporelles `

a ´

evolution lin´

eaire. Ainsi, dans ces bases, o`

u typiquement seul

ce qui a chang´

e est repr´

esent´

e, si une version d’entit´

e (e, t

) n’est pas stock´

ee,

alors la valeur de (e, t

) est la mˆ

eme que celle de (e, t

) avec t

la plus grande

estampille temporelle inf´

erieure `

a t

et identifiant une version stock´

ee de

l’entit´

e e.

L’utilisation du partage implicite n´

ecessite la connaissance des ancˆ

etres

d’une version de base de donn´

ees. Lorsque le versionnement est lin´

eaire la

d´

etermination des ancˆ

etres d’une version de base de donn´

ees est triviale,

puisque l’ordre entre les estampilles est total. Dans le cas arborescent, pour

des raisons ´

evidentes de performances, il est pr´

ef´

erable que les estampilles

de versions de base de donn´

ees soient construites de mani`

ere que la

connais-sance de l’estampille d’une version de base de donn´

ees implique celle de ses

ancˆ

etres [CJ98]. Ceci peut ˆ

etre fait par l’utilisation de techniques d’´

enum´

e-ration d’arbre dans l’identification des versions de base de donn´

ees [CJ90].

Avec ces techniques, l’estampille d’une version de base de donn´

ees v est

obte-nue par l’ajout d’un identificateur de fils `

a l’estampille identifiant la version

de base donn´

ees parente de v.

Dans [CJ90] le p

fils d’un nœud s est identifi´

e par s.p. Par exemple,

`

a la figure 1.2.c, v

, v

et v

auraient comme estampilles respectives, v

, v

et v

. Cette technique convient aux cas o`

u l’arbre des VBD est large et peu

profond comme il est classiquement le cas dans les applications de gestion

de configurations.

Dans [KU95] le premier fils d’un nœud s est identifi´

e par s+1 et le p+1

fils par s.p.1. Par exemple, `

a la figure 1.2.c, v

, v

et v

auraient comme

estampilles respectives, v

, v

et v

. Cette technique d’estampillage est

bien adapt´

ee aux cas o`

u l’arbre des VBD est profond et peu large, comme

c’est classiquement le cas des applications de conception.

1.3

Etendue de VBD

´

L’ensemble des versions de base de donn´

ees pour lesquelles une version

d’entit´

e (e, v) est valide, et les arcs qui les lient dans l’arbre des VBD, forment

un arbre inclus dans l’arbre des VBD. Un tel arbre est dit sous-ensemble

connexe de VBD ou ´

etendue de VBD (version range) [JSLB00a, JSLB03,

SJL

04]. Les figures 1.3.a, 1.3.b et 1.3.c, illustrent, respectivement, les ´

eten-dues de VBD correspondant aux versions des entit´

es a, c et d de la figure

1.2.c.

Dans le cas particulier d’une base de donn´

ees temporelles `

a ´

evolution

lin´

eaire (i.e. arbre d´

eg´

en´

er´

e), une ´

etendue de VBD R est repr´

esent´

ee par

un intervalle de temps [t

, t

[, o`

u t

et t

, sont respectivement la

borne sup´

erieure et la borne inf´

erieure d´

elimitant l’intervalle [SJL

04]. Par

analogie, dans le cas plus g´

en´

eral des donn´

ees multiversions `

a ´

evolution

ar-borescente, une ´

etendue de VBD R a une ”borne inf´

erieure”, ou un point

de d´

epart, v

, qui correspond `

a la version de base de donn´

ee racine de

R. Cependant, dans le cas arborescent, R peut avoir plusieurs ”bornes sup´

e-rieures”, ou points d’arrˆ

et : un par branche de l’arbre des VBD, cr´

e´

ee `

a partir

Chapitre 1 : Concepts et d´efinitions

9

R

R

R

R

Fig. 1.3 : (a) R1=(v1, ∅) : ´etendue de VBD de (a, v1). (b) R2=(v1, {v2})

et R3=(v2, ∅) : respectivement, ´etendue de VBD de (c, v1)

et de (c, v2). (c) R4=(v1, {v3}) et R5=(v3, ∅) : respectivement,

´

etendue de VBD de (d, v1) et de (d, v3).

d’un des descendants de v

. Ainsi, dans le cas arborescent une ´

etendue de

VBD R est repr´

esent´

ee par un couple (v

, {v

}), o`

u v

est la racine

de R et {v

} un ensemble de versions de base de donn´ees [SJL

04]. Une

version de base de donn´

ees v

, telle que v

∈ {v

}, n’appartient pas `

a R,

mais sa version de base de donn´

ees parente appartient `

a R. Ceci est

illus-tr´

e dans la figure 1.3.b, o`

u par exemple l’´

etendue de VBD correspondant `

a

(c, v

) est (v

,{v

}). Une version de base donn´ees v appartient `

a une ´

etendue

de VBD (v

, {v

}) si :

1. v est un descendant de v

;

2. v n’est le descendant d’aucune version de base donn´

ees v

, telle que

v

∈ {v

}.

Une valeur particuli`

ere de {v

} est l’ensemble vide ∅, signifiant que

l’´eten-due de VBD R n’a pas de ”points d’arrˆ

et”. R inclut ainsi toutes les versions

de base de donn´

ees du sous-arbre de l’arbre des VBD ayant pour racine

v

.

1.4

Op´

erations de modification

L’´

evolution d’une base de donn´

ees multiversions se fait par d´

erivation ou

modification de versions de base de donn´

ees. ”La modification d’une version

de base de donn´

ees revient `

a la cr´

eation, suppression ou mise `

a jour

d’en-tit´

es ou de versions d’entit´

e” [CJGM01]. Cette section revoit ces op´

erations

conform´

ement `

a l’approche des versions de base de donn´

ees [CJ90].

D´

erivation d’une nouvelle version de base de donn´

ees.

Grˆ

ace `

a la

r`

egle du partage implicite, la d´

erivation d’une version de base de donn´

ees

v

`

a partir d’une version de base de donn´

ees v

, se fait ”d’une mani`

ere quasi

la base [CJGM01]. Lors de la d´

erivation, la seule op´

eration `

a faire est de

mettre `

a jour l’arbre des versions de base de donn´

ees. Suite `

a cette mise `

a

jour et par le principe du partage implicite, toute version d’entit´

e (e, v

) a

la mˆ

eme valeur que la version de la mˆ

eme entit´

e identifi´

ee par (e, v

).

Mise `

a jour d’une version d’entit´

e.

La mise `

a jour d’une entit´

e e dans

une version de base de donn´

ees v se fait de deux mani`

eres, selon que

l’an-cienne valeur de e dans v, val

, est implicitement partag´

ee ou non avec

d’autres versions de e. Si val

n’est pas partag´

ee, il suffit de changer la

va-leur val

en val

, avec val

la nouvelle valeur de e dans v

. Si val

est

partag´

ee implicitement, le partage concerne uniquement les filles de v

, dont

l’estampille n’identifie aucune version explicitement stock´

ee de l’entit´

e e. Le

cas ´

ech´

eant, le partage doit ˆ

etre rompu de mani`

ere que e ait comme valeur

val

dans v

et garde la valeur val

dans les filles de v

qui partageaient

implicitement val

avec v

[CJGM01]. La rupture du partage implicite

s’ef-fectue en associant explicitement la valeur val

`

a chaque version d’entit´

e

(e, v

), avec v

une version de base de donn´

ees fille de v

dont l’estampille

n’identifie aucune version explicitement stock´

ee de e. Notons qu’il est

pos-sible de mettre `

a jour, simultan´

ement, les valeurs de plusieurs versions d’une

mˆ

eme entit´

e. Pour cela il suffit de bien choisir o`

u rompre le partage implicite.

Suppression d’une version d’entit´

e.

Le fait qu’une entit´

e e n’existe pas

dans une version de base de donn´

ees v, est mat´

erialis´

e par l’association du

couple (e,v ) `

a la valeur nil, qui signifie ”n’existe pas”. La suppression d’une

version d’entit´

e identifi´

ee par (e,v ) est un cas standard de modification, o`

u

la valeur de la version d’entit´

e passe de val `

a nil (cf. ci-dessus).

Insertion d’une version d’entit´

e.

Lorsque l’utilisateur ins`

ere une

ver-sion d’entit´

e (e,v,val ) dans la base, cette op´

eration s’effectue de deux

ma-ni`

eres diff´

erentes, selon que l’entit´

e e existe dans la base mais n’apparaˆıt pas

dans la version de base de donn´

ees v, ou que l’entit´

e e n’existe pas dans la

base. Dans le premier cas l’insertion d’une version d’entit´

e est un cas

stan-dard de modification o`

u la valeur de la version d’entit´

e passe de nil `

a val.

Dans le deuxi`

eme cas, l’insertion de la version d’entit´

e (e,v,val ) doit ˆ

etre

pr´

ec´

ed´

ee par l’insertion de l’entit´

e e. L’insertion de l’entit´

e e s’effectue par

l’affectation de la valeur nil `

a la version de e dans la version de base de

don-n´

ees racine de l’arbre des VBD. Ainsi, par le principe du partage implicite,

e existe d´

esormais dans la base, mais poss`

ede la valeur nil dans toutes les

versions de base de donn´

ees. Suite `

a l’insertion de e, l’insertion d’une version

de cette entit´

e se passe comme dans le premier cas.

1.5

Interrogation des donn´

ees multiversions

Les deux modes primitifs de requˆ

ete aux bases de donn´

ees multiversions

[AJ97], consistent pour le couple (e,v ) `

a :

1. fixer v et faire varier e : l’interrogation est interne `

a la version de base

de donn´

ees v (version slice query [SJL

_{04]) : ”quelles sont les surfaces}

de la cuisine et de la chambre d’amis dans v

?”.

2. fixer e et faire varier v : il s’agit de suivre l’´

evolution de l’entit´

e e `

a

travers un ensemble de versions de base de donn´

ees : ”quelle surface a

la cuisine dans v

et v

?”.

La composition des deux types primitifs de requˆ

etes aux bases de donn´

ees

multiversions, pr´

esent´

es ci-dessus, permet de poser des requˆ

etes complexes

mˆ

elant des recherches de donn´

ees `

a l’int´

erieur d’une version de base donn´

ees

et le suivi d’entit´

es `

a travers un ensemble de versions de base de donn´

ees

[AJ97]. Par exemple : ”quelles sont les pi`

eces limitrophes `

a la cuisine dans

v

dont la conception a ´

et´

e modifi´

ee dans v

?”.

Conclusion

Ce chapitre a pr´

esent´

e les principaux concepts et d´

efinitions li´

es aux

don-n´

ees multiversions et temporelles, conform´

ement `

a l’approche des Versions

de Base de Donn´

ees [CJ90, GJ95, CJGM01]. En particulier, ce chapitre a

pr´

esent´

e les diff´

erents types de requˆ

etes primitifs et les concepts de partage

implicite et d’´

etendue de VBD, n´

ecessaires `

a la compr´

ehension des diff´

erentes

strat´

egies d’indexation et de stockage des donn´

ees multiversions. Ces

stra-t´

egies d’indexation et de stockage sont ´

etudi´

ees dans les chapitres suivants

du m´

emoire.

Chapitre 2

Indexation des versions

d’entit´

e

L

es donn´

ees multiversions sont particuli`

eres, non seulement parce que

bi-dimensionnelles, mais surtout parce que le syst`

eme doit g´

erer `

a la fois

de l’information explicite (les valeurs de versions d’entit´

e explicitement

sto-ck´

ees) et de l’information implicite (les valeurs de versions d’entit´

e d´

eduites

par l’application du principe du partage implicite). De ce fait, les structures

d’indexation classiques, mˆ

eme multi-dimensionnelles, se r´

ev`

elent g´

en´

erale-ment inadapt´

ees [JSLB00a].

Pour illustrer ceci, consid´

erons l’exemple de donn´

ees temporelles `

a ´

evo-lution lin´

eaire, index´

ees par un arbre R [Gut84]. L’arbre R est classiquement

utilis´

e pour indexer les donn´

ees spatiales et g´

eom´

etriques [RSV00], ou plus

pr´

ecis´

ement, les rectangles englobants minimums de ces donn´

ees [Man00].

L’arbre R pr´

esente les caract´

eristiques suivantes [Man00, RSV00] :

• L’arbre R est ´

equilibr´

e : les nœuds feuilles se trouvent toutes au mˆ

eme

niveau de l’arbre.

• Un nœud feuille r´

ef´

erence un ensemble d’objets spatiaux ou g´

eom´

e-triques.

• Un nœud interne r´

ef´

erence les nœuds de niveau inf´

erieur dans l’arbre.

• Un nœud, interne ou feuille, est associ´

e `

a une partie rectangulaire de

l’espace, de sorte que [Man00] :

– Le rectangle associ´

e `

a un nœud feuille est le rectangle englobant

minimum des rectangles englobants minimums des objets spatiaux

ou g´

eom´

etriques r´

ef´

erenc´

es par le nœud feuille.

– Le rectangle associ´

e `

a un nœud interne est le rectangle englobant

minimum des rectangles englobants minimums associ´

es `

a chacun de

ses fils.

– L’´

eclatement d’un nœud satur´

e, donne lieu `

a deux nœuds dont les

rectangles associ´

es peuvent se chevaucher.

Dans une base de donn´

ees temporelles `

a ´

evolution lin´

eaire, une version

d’en-tit´

e peut ˆ

etre repr´

esent´

ee sous forme de segment dans l’espace bi-dimensionnel

entit´

e-temps, o`

u les deux extr´

emit´

es du segment correspondent aux bornes

de l’intervalle de validit´

e temporelle de la version d’entit´

e. L’indexation de

ces segments par un arbre R pose deux probl`

emes. Le premier est li´

e au fait

que les donn´

ees temporelles ´

evoluent g´

en´

eralement `

a leur propre rythme :

ind´

ependamment les unes des autres. En cons´

equence, dans une base de

donn´

ees temporelles, il est fr´

equent de trouver des versions d’entit´

e valides

pour des intervalles de temps relativement courts et d’autres valides pour

des intervalles de temps relativement longs. Les donn´

ees dont l’intervalle de

validit´

e est long ont tendance `

a augmenter la taille des rectangles englobants

minimums des nœuds feuilles qui les stockent. Ceci conduit au

chevauche-ment des rectangles englobants associ´

es aux nœuds et donc `

a la d´

et´

erioration

des performances. Le deuxi`

eme probl`

eme pos´

e par l’utilisation des index

spa-tiaux est la repr´

esentation des intervalles de temps semi-ouverts. En effet,

lors de l’insertion d’un segment dans un arbre R, les deux extr´

emit´

es du

segment sont suppos´

ees connues. Pour les donn´

ees temporelles, ceci n’est

pas le cas des versions d’entit´

e valides au moment de l’insertion.

La sp´

ecificit´

e des donn´

ees multiversions a conduit `

a la cr´

eation de

nou-velles structures d’indexation et `

a l’adaptation de structures existantes [BO99].

Les structures d’indexation propos´

ees dans la litt´

erature peuvent ˆ

etre

grou-p´

ees en trois grandes familles, selon que le regroupement des versions d’entit´

e

dans les pages disque favorise l’acc`

es rapide `

a la dimension entit´

e, l’acc`

es

ra-pide `

a la dimension version de base de donn´

ees ou un compromis entre l’acc`

es

`

a la dimension entit´

e et l’acc`

es `

a la dimension version de base de donn´

ees.

Si l’on veut acc´

eder rapidement `

a toutes les versions d’une entit´

e, alors

le regroupement se fait pr´

ef´

erentiellement par entit´

e [CJGM01]. Parmi les

structures d’indexation appartenant `

a cette famille d’approches il y a

essen-tiellement des adaptations de l’arbre B+ [Nør99, ND99, JJ06].

Si au contraire, l’acc`

es aux versions d’entit´

e qui composent une version de

base de donn´

ees est favoris´

e, alors le regroupement se fait pr´

ef´

erentiellement

par version de base de donn´

ees. Les principales structures d’indexation de

cette famille sont : le chevauchement de structures d’indexation (Overlapping

Index Structures) [CDRS86, MK90, TML99], l’approche des gros nœuds (Fat

Node Method ) [DSST89, LM91] et les structures g´

en´

eriques [Man00].

Pour avoir un compromis entre les acc`

es par entit´

e et les acc`

es par

version de base de donn´

ees, la troisi`

eme famille d’approches utilise des

structures d’indexation bi-dimensionnelles. Les principales structures

d’in-dexation de cette famille sont : le Write Once B-tree (WOBT ) [Eas86],

le Time-Split tree (TStree) [LS89, LS90, LS93], le MultiVersion

B-tree (MVBT ) [BGO

96, VV97], le Branched and Temporal Tree (BT-tree)

[JSLB00a, SJL

04] et le BTR-tree [JSLB03].

De mani`

ere intuitive, il est assez ais´

e d’identifier le type de requˆ

ete

primi-tif qu’une famille d’approches favorise a priori. Cependant, dans une base de

donn´

ees multiversions, les requˆ

etes sont g´

en´

eralement complexes et mˆ

elent

`

a la fois des recherches `

a l’int´

erieur d’une version de base de donn´

ees et des

recherches `

a travers un ensemble de versions de base donn´

ees [AJ97, DTS02].

Pour ces requˆ

etes complexes, il n’est pas imm´

ediat d’identifer les situations

o`

u les courbes de performance des diff´

erentes approches se croisent, ni

d’iden-tifier et de quand’iden-tifier les param`

etres qui donnent lieu `

a ces situations.

Pour ces motifs nous avons propos´

e un mod`

ele de coˆ

ut, appel´

e l’analyse

en r´

egime permanent, permettant l’identification des param`

etres pr´

epond´

e-rants et la comparaison ais´

ee des performances de ces approches (sans avoir

`

a les implanter). Les r´

esultats de ce travail de recherche ont ´

et´

e publi´

es dans

trois articles [JJ06, JJ07, JJ08c].

L’article Comparaison de m´

ethodes d’indexation des versions [JJ06]

pro-pose l’arbre B+V, une structure d’indexation appartenant `

a la premi`

ere

famille d’approches, con¸

cue pour les donn´

ees multiversion `

a ´

evolution

arbo-rescente. Cet article compare par l’analyse en r´

egime permanent, les

perfor-mances de l’arbre B+V aux perforperfor-mances d’une structure d’indexation de

la deuxi`

eme famille d’approches, le chevauchement d’arbres B+ (OB+trees)

[CDRS86, MK90, TML99], et d’une structure d’indexation de la troisi`

eme

famille d’approches, le BT-tree [JSLB00b, SJL

04]. Comme l’OB+trees a

´

et´

e con¸

cu pour les donn´

ees `

a ´

evolution lin´

eaire, dans l’article [JJ06],

l’ana-lyse en r´

egime permanent a ´

et´

e d´

evelopp´

ee uniquement dans le cadre des

donn´

ees `

a ´

evolution lin´

eaire.

L’article Indexing Multiversion DataBases [JJ07] revoit et am´

eliore l’arbre

B+V et propose une extension de l’OB+trees aux donn´

ees `

a ´

evolution

arbo-rescente. Ceci a permis de d´

evelopper l’analyse en r´

egime permanent dans

le cadre des donn´

ees `

a ´

evolution arborescente.

Dans les articles [JJ06, JJ07], notre recherche s’est uniquement focalis´

ee

sur les index primaires groupants (index construit sur les identificateurs de

versions d’entit´

e et contrˆ

olant le placement physique des donn´

ees). L’article

Design and Analysis of Index Structures in MultiVersion Data Warehouses

[JJ08c], ´

etend l’analyse en r´

egime permanent aux index secondaires (index

ne contrˆ

olant pas le placement physique des donn´

ees) dans le cadre des

entrepˆ

ots de donn´

ees multiversions [BEK

_{04, GLRV06].}

Article Index primaires Index secondaires Evolution´ [JJ06] Arbre B+V, OB+trees, BT-tree - Lin´eaire [JJ07] Arbre B+V, OB+trees, BT-tree - Arborescente [JJ08c] Arbre B+V, OB+trees, BT-tree Arbre B+V, OB+trees, BT-tree Arborescente

Fig. 2.1 : Champs d’application de l’analyse en r´egime permanent dans les diff´erents articles

La suite du chapitre pr´

esente les articles [JJ06, JJ07, JJ08c]. Le tableau

de la figure 2.1 r´

ecapitule les th`

emes qui y sont abord´

es.

Nota Bene.

Comme les articles [JJ06, JJ07, JJ08c] constituent en r´

ealit´

e

les diff´

erentes ´

etapes d’un mˆ

eme travail de recherche, certaines parties y sont

redondantes. Pour ne pas encombrer le lecteur, nous lui recommandons de

passer directement `

a la section 1 dans l’article [JJ06] (les concepts pr´

esent´

es

bri`

evement dans l’introduction de l’article [JJ06] sont expliqu´

es en d´

etail

dans le premier chapitre de ce m´

emoire). Parall`

element, dans les articles

[JJ07, JJ08c], nous lui recommandons de se focaliser essentiellement sur :

1. la sous section 3.2 et la section 4 de l’article [JJ07] qui pr´

esentent,

res-pectivement, l’extension de l’OB+trees aux donn´

ees `

a ´

evolution

arbo-rescente et l’application de l’analyse en r´

egime permanent aux donn´

ees

`

a ´

evolution arborescente;

2. l’introduction, la sous section 1.3.2 et la sous section 1.4.6 de l’article

[JJ08c], qui pr´

esentent, respectivement, notre conception des

entre-pˆ

ots multiversions, l’utilisation des diff´

erentes structures d’indexation

comme index secondaires et l’application de l’analyse en r´

egime

per-manent aux index secondaires.

Comparaison de méthodes d’indexation des versions

Khaled JOUINI

Geneviève JOMIER

Université Paris Dauphine, LAMSADE Place du Mal _{de Lattre de Tassigny}

75775 Paris Cedex 16, France

{khaled.jouini, genevieve.jomier}@dauphine.fr

Résumé. De nombreuses structures d’indexation prenant en compte les spécificités des bases de données temporelles et des bases de données multiversions ont été proposées. La grande diversité de propositions rend difficile de déceler leurs potentiels et limites respectifs. Cet article définit un cadre permettant d’analyser des structures d’indexation de versions d’entité et propose une nouvelle structure d’indexation pour bases de données multiversions, le B+V arbre. L’article caractérise les types de requêtes dans une base de données multiversions et propose une classification des structures d’indexation liée au type de requêtes qu’elles favorisent a priori. Le travail présente également un modèle pour l’évaluation analytique des performances des différentes structures d’indexation. Cette évaluation est validée par une étude expérimentale.

Abstract. Many access methods taking into account the specificities of temporal and multiversion databases have been proposed. The variety of proposals makes it difficult to identify their respective potentials and limits. The present paper defines a framework for understanding the versionned data indexing related issues. It identifies the main types of queries in a multiversion database and classifies data access methods according to the queries they more efficiently support. This work also presents a model for an analytical evaluation of the efficiency achieved by the different indexation methods. This evaluation is validated by an experimental study.

Mots-clés : Indexation de versions, analyse de performances, comparaison de performances d’index Keywords : Index for versions, performance analysis, comparison of index for versionned data

1 Introduction

La diffusion des bases de données temporelles [ST99] et multiversions [CJ90, BM03, JSL+_{04] a conduit à}

élaborer des structures d’index destinées à optimiser les requêtes à ces bases [TPZ02]. Le but de cet article est de déceler leurs potentiels et limites respectifs en terme qualitatif et quantitatif. Ces structures d’index tiennent compte de la spécificité de ces bases qui rendent simultanément persistantes les représentations de plusieurs états du monde réel modélisé, dits Versions de Base de Données (DataBase Versions [CJ90, JSL+_{04]) ou}

VBD. Le concept de version de base de données, essentiel pour l’élaboration de ces structures d’index, est analogue pour les bases de données temporelles et les bases de données qui implantent les versions pour des besoins autres que la gestion du temps.

Par exemple, dans les applications de génie logiciel les concepteurs gardent une trace de leur travail, en créant successivement, à chaque étape, une nouvelle version du logiciel à concevoir, dite révision. Parvenu à une étape importante, la version stable de la figure 1, le développement continue sur deux branches : la branche de développement prépare la version majeure suivante, dite variante, et la branche de maintenance gère les mises-à-jour corrigeant la version stable. Des outils comme Oracle Workspace Manager [BM03], subVersion [CS02] ou CVS [Mor96], assistent les concepteurs dans la gestion des versions.

Valeurs prises par un module m dans les différentes versions du logiciel ré vi si on_s variante Figure 1: Arbre des versions d’un logiciel

Dans la suite de cet article le terme bases de données multiversions utilisé seul inclut les bases de données temporelles. Concrètement, dans le cas temporel, une VBD représente un état du monde réel modélisé par la base à un instant t, d’où le nom de slice [JSL+_{04] en anglais, symbolisant le fait}

qu’on prend une tranche de la base. Cet instant t est mémorisé dans l’estampille temporelle utilisée pour l’identification de la VBD. Dans le cas général

d’une base de données multiversions, une VBD est identifiée par une estampille de version v dont la sémantique est associée à l’application pour laquelle la base est construite. Lorsqu’aucune confusion n’est possible nous ne distinguerons pas une VBD de l’estampille v qui l’identifie. Le terme entité de la base désigne un élément persistant : n-uplet, objet,... Si E est l’ensemble des entités e de la base, alors la VBD v est composée de l’ensemble des (e,v), versions d’entité estampillées par v :

VBD v={(e,v), pour tout e∈ E}.

Dans cet article nous nous intéressons à la structure de l’ensemble des estampilles V={v}, mais pas à sa sémantique. Celle-ci peut représenter un temps linéaire [LS90, BGO+_{96, TML99], et V est}

un ensemble ordonné, ou un temps arborescent [JSLB00, JSLB03, JSL+_{04], V a alors une structure}

d’arbre. Dans le cas général, l’ensemble V des estampilles est structuré en arbre. La relation liant deux nœuds successifs v et v’ de V, est la dérivation de VBD. En effet, classiquement une VBD v’ est créée par dérivation, c’est-à-dire copie matérialisée ou non, à partir d’une VBD v préexistante et persistante. Une fois la VBD v’ créée, des modifications peuvent être portées à ses versions d’entité (e,v’).

Les deux modes primitifs de requête aux bases de données multiversions [AJ97], consistent pour le couple (e,v) à :

1. fixer v et faire varier e : l’interrogation est interne à la VBD v (version slice query [JSL+_04]).

2. fixer e et faire varier v : il s’agit de suivre l’évolution de l’entité e à travers un ensemble de VBD. Si v est une estampille temporelle linéaire, ce type de requête suivra la série chronologique des valeurs prises par l’entité e au fil du temps.

La composition des deux types primitifs de requêtes aux bases de données multiversions, présentés ci-dessus, permet de poser des requêtes mêlant des recherches de données à l’intérieur d’une VBD et le suivi d’entités à travers un ensemble de VBD. Ainsi, dans une base de données temporelles décrivant une partie du système éducatif on pourrait poser une requête comme : "Combien y avait-il d’élèves dans les classes de cours préparatoire fréquentées dans leur enfance par les lauréats du Concours Général de 2006 ?".

a,α1 d,δ1 Version v1 Figure 2: VBD initiale v1 Arbre des VBD v1 v2 a,α1 d,δ1 Version v1 a,α1 d,δ2 Version v2

Figure 3: Deux VBD, v1et v2vues

par les utilisateurs

(a,v1,α1) (d,v1,δ1) (d,v2,δ2) Arbre des VBD

v1 v2

Figure 4: Versions d’entité stockées dans la base

L’évaluation de cette requête se fait en plusieurs étapes :

1. identification des lauréats du concours général dans la VBD correspondant à 2006.

2. pour chaque lauréat :

(a) remonter dans son histoire, donc à travers un ensemble de VBD, jusqu’à trouver la VBD v de l’année où il était en cours préparatoire.

(b) dans cette VBD v, extraire le

nombre d’élèves de sa classe de cours préparatoire.

L’optimisation de ces différents types de requête a amené la proposition de différentes structures d’index [BGO+_{96, TML99, JSLB00, JSL}+_04].

L’optimisation des requêtes dans une VBD amène à regrouper les (e,v) selon les valeurs de v. En revanche, l’optimisation des requêtes de type suivi de versions de l’entité e à travers un ensemble de VBD amène à regrouper les (e,v) selon les valeurs de e, donc par entité.

Ce dernier type de regroupement des versions par entité est très naturel dans les bases de données structurées (relationnelles ou objets) multiversions. En effet, le concept de version est intéressant quand, d’une VBD à la suivante dans l’ordre de dérivation, seule une faible proportion des versions d’entité est modifiée. Par conséquent, des mécanismes de partage de valeur entre deux ou plusieurs versions d’entité sont mis en œuvre. Le principe du partage implicite [CJ90] est le suivant :

"lorsque la valeur d’une version d’entité (e,v) n’est pas explicitement stockée dans la base, elle est la même que celle de (e,v’), où v’ est le plus proche ancêtre de v (au sens de la dérivation des VBD dans V) dont la valeur est explicitement stockée dans la base" [CJ90].

La valeur de la version d’entité (e,v’) est dite alors valide par rapport à v.

Ceci est illustré par les figures 2, 3 et 4, où sont appliquées, comme dans la suite de l’article, les conventions d’écriture suivantes :

· les identificateurs d’entité sont des minuscules latines du début de l’alphabet.

· les valeurs de versions d’entité sont des minuscules grecques du début de l’alphabet. Dans le cas relationnel une entité est un n-uplet et l’identificateur la clé primaire de la relation · les estampilles sont des vi.

· les changements dans une figure par rapport à celle qui la précède dans un exemple sont marqués en gras.

La figure 2 montre les versions d’entité composant la VBD v1: (a,v1) a pour valeur α1et (d,v1), δ1. À

la figure 3 une deuxième VBD v2 est dérivée de v1.

Dans v2, l’entité d a une nouvelle valeur δ2et l’entité

a garde la même valeur que dans v1. La figure 4

représente le contenu effectivement stocké de la base. La valeur de (a,v2) n’est pas explicitement

stockée. Le principe du partage implicite permet de déduire, en utilisant l’arbre des versions, que (a,v2)

partage sa valeur α1avec (a,v1).

Dans la suite de l’article, la section 2 présente trois types d’index pour bases de données multiversions. La section 3 analyse théoriquement les performances des différentes familles d’index. La section 4 compare expérimentalement les performances des différentes familles d’index. Suit la conclusion.

2 Indexation des bases de données

multiversions

Les index destinés à optimiser les requêtes aux bases de données multiversions sont de deux sortes selon qu’à partir de la valeur d’attribut on retrouve des identificateurs de versions d’entité (e,v) ou qu’à partir des identificateurs de versions d’entité (e,v) on retrouve les valeurs des attributs de (e,v). Dans la suite nous ne nous intéressons qu’aux index permettant, à partir de (e,v), de retrouver la