L’implantation et l’expérimentation des méthodesIt-CompetIt-Updateconstituent une contribu- tion personnelle. Nous présentons ici les aspects techniques liés aux implantations des ces méthodes ainsi que les résultats de leur évaluation.
6.3.1 Implantation
L’implantation des méthodesIt-CompetIt-Updatesuit leurs spécifications formelles présentées dans les Sections 6.2.1 et 6.2.2 respectivement en modifiant certaines hypothèses faites lors de chacune des présentations. L’hypothèse commune à ces deux méthodes concerne le stockage des estampilles. Dans la présentation formelle, nous avions choisi d’associer à chaque noeud d’un document estampillé une estampille. Cette hypothèse s’avère inutile en pratique puisque, le plus souvent, il est possible de déduire l’estampille d’un noeud de manière directe à partir de l’estampille de son parent ou plus généralement de celle d’un ancêtre. Ce même principe a été utilisé dans [BKTT04a] où il est appelé héritage des estampilles. Il est illustré avec l’exemple suivant.
Exemple 84. Considérons les documents estampillés de la Figure 6.19. Le document à gauche de cette Figure représente la version "tout estampillé", le document à droite représente la version qui optimise le stockage des estampilles. Dans la première version, on constate que les noeuds identifiés
doc #0 [0,1] a #1 [0,N[ b #1.1 [0,N[ f #1.1.1 [0,N[ g #1.1.2 [0,N[ a #2 [0,N[ b #2.1 [0,N[ g #2.1.1 [0,1[ e #2.2 [1,N[ f #2.2.1 [1,N[ g #2.2.2 [1,N[ doc #0 [0,1] a #1 [0,N [ b #1.1 f #1.1.1 g #1.1.2 a #2 [0,N [ b #2.1 g #2.1.1 [0,1[ e #2.2 [1,N [ f #2.2.1 g #2.2.2
Version "tout estampillé" Version estampilles optimisées
FIGURE6.19 – Optimisation du stockage des estampilles
par1, 1.1, 1.1.1 et 1.1.2 ont tous la même estampille [0, N [. Comme les noeuds 1.1.1 et 1.1.2 sont fils du noeud1.1 lui même fils du noeud 1, il suffit de stocker l’estampille de ce dernier seulement et ses descendants hériteront de cette estampille. Lorsque cette stratégie est choisie et qu un noeud
possède une estampille différente de celle de son parent ou d’un ancêtre, cette estampille est stockée. Ceci est le cas des noeuds identifié par2 et par 2.1.
Pour ce document, qui est peu profond, on constate que la stratégie avec optimisation permet un gain de plus de 50% par rapport à la stratégie "tout estampillé". Dans le cas pratique où les documents sont très volumineux ce gain peut être plus important. La deuxième hypothèse concerne les identifiants explicites des noeuds. Ces identifiants sont stockés uniquement pour les documents estampillés générés par la méthode It-Comp puisqu’ils sont utilisés pour identifier les noeuds qui capturent le même élément. Les documents estampillés générés par la méthodeIt-Updatene contiennent pas d’identifiants explicites puisque l’identification des noeuds se fait de manière sémantique en utilisant les requêtes de mises à jour. La gestion des positions pour la méthodeIt-Updatea déjà été commentée lors de la présentation de cette méthode et reprend la stratégie mise en oeuvre pour l’évaluation de mises à jour par la méthode de projection.
L’implantation de la méthodeIt-Compa été réalisée en Java en utilisant deux threads permettant de gérer le parsing de ∆t−1 et dt. Ces deux threads interagissent suivant le mode producteur-
consommateur un peu comme la méthode de fusion développée dans le Chapitre 4. L’utilisation du paradigme producteur-consommateur permet de gérer facilement la synchronisation des parsings de∆t−1etdtqui se base sur l’examen des identifiants explicites.
L’implantation de la méthodeIt-Updatepossède des points en commun avec l’implantation de la fusion présentée dans le 4. L’implantation de la projection temporelle a nécessité d’adapter l’implantation de la projection pour les types afin de prendre en compte les estampilles, elle ne nécessite pas de commentaires particuliers.
L’implantation de la fusion temporelle T reeU M ergea été réalisée de manière à prendre en compte efficacement certains aspects techniques tels que la gestion optimisée des estampilles. Le principe utilisé dans cette implantation reste le même et utilise les threads afin de gérer le parsing des documents∆t−1etut(πNow∆t−1).
Scénario des tests Les expérimentations ont été réalisées sur un machine équipée d’un processeur Intel Core 2 Duo d’une fréquence de 2.53 GHz, possédant une mémoire vive de 2Go et utilisant le système d’exploitation Mac OSX version 10.6.4. Le moteur mémoire-centrale utilisé pour effectuer le test de la méthodeIt-Updateest Qizx [qiza].
Actuellement, il n’existe pas de benchmark pour les données XML temporelles ni même de benchmark pour les mises à jour XML. Afin d’effectuer nos tests, nous avons généré des documents abstraits à partir de documents XMark [SWK+02]. Comme notre objectif est de comparer les méthodesIt-CompetIt-Update, nous avons choisi de traiter des documents abstraits qui représentent un historique. Nous considérons quatre documents abstraitsd0, ..., d3 où, pouri = 0, .., 3 chaque diest de la forme : di0, di1, di2, di3, et où, pourj = 0, .., 3 chaque dijest obtenu en appliquant une
mise à jourujsur le documentdij−1.
Les mises à jour utilisées sont données ci-dessous. Les tailles des document initiaux di 0 de
chaque historiquedivarient entre 45 Mo et 1Go. u1. delete node /site/regions/australia
u2. for $x in /site/closed_auctions/closed_auction
u2.where $x/annotation
u2.return insert node <amount> to be determined </amount>
u2.insert after $x/price
u3. for $x in /site/open_auctions/open_auction
u2.where $x/privacy
return
delete node $x
Rappelons que la méthodeIt-Compnécessite de stocker les identifiants explicites qu’elle utilise pour identifier les éléments. Dans le but d’évaluer cette méthode, nous avons dû générer les docu- mentsdi
j avec des identifiants explicites associés à leurs noeuds. Cette tâche a nécessité un effort
supplémentaire d’implémentation entraîné par le besoin de gérer l’interaction entre l’application des mises à jour et la génération des identifiants explicites et par la nécessité de manipuler des documents volumineux (notons que notre objectif est de tester It-Comppour des documents attei- gnant 1 Go). Le but de gérer l’interaction entre l’application des mises à jour et la génération des identifiants explicites est de respecter l’hypothèse faite au début de ce chapitre selon laquelle les identifiants explicites des noeuds supprimés ne doivent pas être réutilisés. Dans notre cas, le travail a consisté à empêcher que les identifiants des noeuds supprimés par la mise à jouru1ne soient attri-
bués aux noeuds insérés par la mise à jouru2. Enfin, pour pouvoir générer des documents de taille
de 1 Go, à partir des mises à jour u1, u2 etu3, nous avons eu recours à la méthode de projection
pour dans le Chapitre ??.
Il est important de rappeler que l’évaluation de la méthodeIt-Updatene nécessite pas un traite- ment particulier puisqu’elle utilise le document initiald0et seulement des mises à jour .
Les résultats des tests sont donnés dans la Table 6.1. Dans cette Table : – ∆iest le résultat de l’application deIt-Compsur les documentsd0, . . . , di,
– ∆′i est le résultat de l’application de l’application de la mise à jour ui sur le document
estampillé∆′i−1en utilisant la méthodeIt-Update.
Nous avons comparé la taille des documents estampillés∆i et∆′i pour i allant de 0 à 3. La
différence de taille pour les documents estampillés ∆0 et ∆′0 est due aux identifiants explicites
générés pour le besoin de la méthode It-Comp. Remarquons que la taille du document initial d0
est égale à la taille de sa version estampillée ∆′
0 puisque, initialement, seule la racine de ∆′0 est
estampillée.
Les résultats présentés dans la Table 6.1 montrent clairement que la méthode It-Update est plus efficace en terme de stockage que la méthode It-Comp. Alors que la taille des documents ∆i
augmente à chaque étape, la taille des document ∆′i reste constante. Cette différence est due au fait queIt-Compréplique des noeuds Cela montre queIt-Updateparvient à éviter la réplication des noeuds en utilisant l’information des mises à jour. La gain en terme d’espace obtenu en utilisant la méthode It-Updateest significatif. Il est de 38.5 % pour la première mise à jour, et arrive jusqu’à 50.9% pour la dernière mise à jour.
Pour ces expérimentations, nous avons considéré un document abstrait de taille 4. L’améliora- tion de la taille des documents estampillés obtenue en utilisant la méthode It-Updaterelativement
d0 45.4MB 112.4MB 454.8MB 1126.8MB ∆0 55.7 138.5 563.5 1351.7 ∆′ 0 45.4 112.4 454.8 1126.8 ∆1 76.5 190.5 774.7 1833.0 ∆′ 1 45.4 112.4 454.8 1126.8 gain 40.7% 41.0% 41.3% 38.5% ∆2 84.5 210.1 853.6 2027.5 ∆′ 2 45.6 112.9 456.4 1130.7 gain 46.0% 46.3% 46.5% 44.2% ∆3 91.7 228.6 929.0 2207.5 ∆′ 3 45.6 112.9 456.4 1130.7 gain 50.3% 50.6% 50.9% 48.8%
TABLE 6.1 – Taille des documents construits parIt-UpdateetIt-Comp
à la taille des documents construits par la méthode It-Comp est susceptible de rester stable pour des scénarios plus réalistes où la taille des documents abstraits est plus grande. En effet, plus la taille (de la séquence) du document abstrait est importante, plus grande sera la probabilité pour
It-Compde répliquer des noeuds alors que la méthodeIt-Updateest capable d’éviter cette réplication grâce à l’utilisation de l’information sur les mises à jour. Des expérimentations pour tester les deux méthodes pour des documents abstraits de plus grande taille sont en cours de réalisation.
Pour conclure, il est important de souligner que même si la méthodeIt-Compn’est pas capable de produire des documents estampillés aussi compacts que ceux construits parIt-Update, elle reste particulièrement intéressante car elle permet de traiter des documents volumineux quelconques. Notons que la méthode It-Update permet de traiter, en utilisant le moteur QizX, des documents atteignant 1Go alors même que la taille maximale des documents pouvant être traités par ce moteur est de 580 Mo.