Expérimentations

Il convient de signaler qu’à ce jour, à notre connaissance, il n’existe pas de benchmark pour les mises à jour XML. Pour expérimenter notre technique, nous avons proposé 7 mises à jour conformes à XQuery Update Facility [XUP] et couvrant la plupart des mises à jour de cette norme (i.e inser- tion, suppression, remplacement et renomage). Les documents utilisés pour les tests ont été générés en utilisant XMark [SWK+02], l’un des benchmarks les plus utilisés pour les requêtes XML. La taille de ces documents varie entre 52 Mo et 2 Go. Les mises à jour utilisées pour les tests sont présentés, ainsi que leur projecteur associé, dans la Figure 4.32.

La machine utilisée pour les expérimentations possède les caractéristiques suivantes : elle est équi- pée d’un processeur Intel Core 2 Duo d’une fréquence de 2.53 GHz, elle possède une mémoire vive de 2Go et elle utilise le système d’exploitation Mac OSX version 10.6.4. Nous avons fixé la taille de la mémoire virtuelle de Java à 512 Mo

4.5.2.1 Limite des moteurs mémoire-centrale

La première expérimentation réalisée vise à évaluer les limites des principaux moteurs de mises à jour mémoire-centrale à savoir : MXQuery 0.6.0 [mxq], eXist 1.2.5 [exi], Saxon EE 9.2.0.2 [saxb] et QizX Free-Engine-3.2.0 [qiza]. Nous avons mesuré la taille maximale des documents pouvant être traités par ces moteurs sans projection. La mise à jour choisie pour ce test estu4: elle effectue

une simple suppression de noeuds et requiert le moins d’espace. La taille maximale des documents pouvant être traités par chacun de ces moteurs est donnée dans la Table 4.4. Parmi les moteurs testés, seul QizX a permis de traiter des documents d’une taille supérieure à 150 Mo ce qui s’explique par le fait qu’il utilise un format de stockage optimisé.

Moteurs MXQuery Saxon eXist QizX F-E

Taille (Mo) 52 128 148 580

TABLE 4.4 – Tailles maximales des fichiers traités

4.5.2.2 Evaluation de la technique de projection : espace

Afin de mesurer l’impact de la projection en terme de réduction de la taille des documents, nous présentons un graphique (Figure 4.31) montrant pour chaque mise à jourui et pour chaque

document, la taille du document projeté obtenu en utilisant le projecteurπui. L’axe des abscisses indique la taille des documentst et l’axe des ordonnées indique la taille des projections πui(t). Il est aisé de constater que la projection permet un gain considérable en terme d’espace. Le meilleur taux

de réduction est celui obtenu pour la mise à jouru4: la projection permet de réduire la taille de 2

Go (2048 Mo) à 20 Mo. Ceci est dû au fait que le projecteurπu4 est très sélectif. Cependant, même avec un projecteur moins sélectif (par exemple le projecteurπu5) le gain en espace reste significatif (pour la mise à jouru5, la projection permet de réduire la taille de 2 Go à 100 Mo).

FIGURE4.31 –Taille des documents après projection

4.5.2.3 Evaluation de la technique de projection : temps

Pour ces expérimentations, nous nous sommes focalisés sur les moteurs Saxon et QizX. Pour chacun de ces moteurs, nous avons mesuré le temps nécessaire à l’exécution des sept mises à jour sans projection et le temps nécessaire à l’exécution des mises à jour en utilisant notre technique de projection. Le temps mesuré pour notre technique de projection comprend : le temps d’exécution des étapes d’élagage, de mise à jour et de fusion plus le temps nécessaire au chargement et à la matérialisation des résultats intermédiaires produits pour et par chacune de ces étapes.

Les résultats de temps d’exécution pour Saxon sont présentés dans la Figure 4.33-(1) pour le cas sans projection et dans la Figure 4.33-(2) pour le cas avec projection. Les valeurs manquantes dans la Figure 4.33-(1) correspondent à des documents qui n’ont pas pu être chargés par Saxon en raison de leur taille. Ces graphiques montrent que notre technique atteint son objectif principal, celui de mettre à jour des documents volumineux avec des moteurs mémoire-centrale. En effet, la projection permet de mettre à jour des documents allant jusqu’à 2 Go. Cependant, nous remarquons que le temps d’exécution pour mettre à jour les documents de 52 Mo et de 128 Mo sans projection est légèrement inférieur au temps pour mettre à jour ces documents en utilisant la projection. La raison d’un tel écart est que le temps comptabilisé pour la méthode de mise à jour avec projection comprend le temps de matérialisation et de chargement des résultats intermédiaires. Ces graphiques donnent un autre éclairage sur la limite en taille des documents pouvant être traités par Saxon. En particulier, la mise à jouru5n’a pu être effectuée pour les documents dont la taille est supérieure à

1 Go même si la taille de leur projection est d’environ 60 Mo (donc inférieure à la limite mesurée dans le tableau 62). Nous avons pu expérimenter que la taille d’un document n’est pas le seul facteur limitatif de l’utilisation de Saxon, le nombre de noeuds du document est un autre facteur important.

Les résultats des tests pour QizX sont présentés dans les Figures 4.34-(1) et 4.34-(2). On re- marque d’abord que ce moteur est moins limité que Saxon puisqu’il permet de mettre à jour des documents de taille 520 Mo là alors que Saxon s’arrête à 128 Mo. La méthode avec projection permet de mettre à jour des documents dont la taille atteint 2Go. Le temps d’exécution mesuré pour l’évaluation avec projection est meilleur que le temps d’exécution de la méthode sans projection. Ceci est dû au temps consacré par QizX à la construction d’indexes lors du chargement des do- cuments avant leur mise à jour. Intuitivement, plus les documents sont volumineux, plus le temps nécessaire pour cette indexation est important. A titre d’exemple, si on prend le document de 52 Mo, le gain en temps pour chaque mise à jour est :

mise à jour u1 u2 u3 u4 u5 u6 u7

gain 45,4% 60,3% 74,3% 72,2% 45,2% 63,6% 24%

Pour les autres documents, le gain est similaire. Notons qu’il a été possible d’exécuter toutes les mises à jour avec projection en utilisant QizX du fait de sa capacité à traiter des documents plus volumineux que Saxon.

Les mises à jour et les projecteurs associés

Toutes les mises à jour ci-dessous partagent un binding :

let $doc := document("auctions.xml)

u1

for $x in $doc/site/closed_auctions/closed_auction where not ($x/annotation) return

insert node <annotation>Empty Annotation</annotation> as last into $x

u2

for $x in $doc/site/people/person/address

where $x/country/text()="United States" return (replace node $x with

<address> <street>{$x/street/text()}</street> <city>"NewYork"</city> <country>"USA"</country> <province>{$x/province/text()}</province> <zipcode>{$x/zipcode/text()}</zipcode> </address>) u3 for $x in $doc/site/regions//item/location where $x/text()="United States"

u4

delete nodes $doc/site/regions//item/mailbox/mail

u5

for $x in $doc/site//text/bold return

rename node $x as "emph"

u6

for $x in $doc/site/people/person where not($x/homepage)

return insert node

<homepage>www.{$x/name/text()}Page.com</homepage> after $x/emailaddress

u7

for $x in $doc/site/people/person, for $y in $doc/site/people/person

where $x/name/text() = $y/name/text()

and not ($y/address) and $x/country=’Malaysia’ return insert node $x/address

after $y/emailaddress

πno πolb πeb

u1 site, closed_auctions, annotation closed_auct ∅

u2 site, people, address person, country, street,

province, zipcode

∅ u3 site, regions, africa, asia, australia, europe, name-

rica, samerica, item

location ∅

u4 site, regions, africa, asia, australia, europe, name-

rica, samerica, item, mailbox, mail

∅ ∅

u5 site, regions, africa, asia, australia, europe, name-

rica, samerica, listitem, bold, mailbox, mail, item, description, text, open_auctions, open_auction clo- sed_auctions, closed_auction, annotation, parlist

∅ ∅

u6 site, people, homepage person, name ∅

u7 site, people person, name, country address

(1) mise à jour sans projection

(2) mise à jour avec projection

(1) mise à jour sans projection

(2) mise à jour avex projection

4.5.2.4 Traitement de workloads

Le dernier test que nous avons effectué concerne l’utilisation de notre méthode pour exécuter un workload de mises à jour i.e. une séquence de mises à jour. En effet, il est immédiat d’étendre notre scénario d’évaluation d’une mise à jour utilisant la projection au cas d’une séquences. Le tri-projecteurπsassocié à une séquence de mises à jour est construit par union des tri-projecteurs

inférés pour chaque mise à jour. Etant donné un documentt, il est projeté suivant πs. La séquence s est évaluée sur le document projeté et la mise à jour partielle est fusionnée avec le document t. Pour cette expérimentation, nous avons considéré la séquence de mises à jour u1, u2, . . . , u7 et

un document de taille 128 Mo afin de pouvoir utiliser Saxon. Nous avons comparé, pour chaque moteur, le temps nécessaire lorsque les mises à jour sont appliquées successivement en utilisant la projection séparément et le temps nécessaire lorsque la séquence est traitée en utilisant la projection associée à la séquence. Dans le premier cas, Saxon exécute les mises à jour en 196 secondes contre 181 secondes pour Qizx. Dans le deuxième cas, Saxon exécute les mises à jour en 82 secondes contre 64 secondes pour Qizx.