• Aucun résultat trouvé

5.4 Validation non-fonctionnelle

5.4.3 Utilisation d’un syst`eme NoSQL pour le stockage de provenance :

5.4.3.2 Exp´erimentations et analyse des r´esultats

Comme la structure de donn´ees de provenance dans Sesame n’est pas identique `a celle de CouchDB, le nombre d’enregistrement g´en´er´e pour les mˆemes sources de provenance est diff´erent. La fonction d’import dans Sesame a g´en´er´e 24.000.416 de triplets RDF, celle de CouchDB a g´en´er´e 3.000.517 documents. La table 5.1ci-dessous donne le temps d’insertion requis pour charger les donn´ees de provenance dans les deux SGBD. Sur ce tableau, nous utilisons l’´equivalent de lignes de log ins´er´ees car les structures de donn´ees et le nombre d’enregistrement sont diff´erents pour les deux syst`emes. Pour des ensembles de donn´ees de taille inf´erieure `a un million de triplet, Sesame ´etait rapide et le temps de chargement ´etait raisonnable. Pour des ensembles de plus grande taille, le temps de chargement n´ecessaire devient beaucoup plus important et n’est plus lin´eaire. Pour charger l’ensemble des triplets g´en´er´es (24.000.416), Sesame a pass´e plus que 7 heures (28302 secondes). Pour CouchDB, nous avons utilis´e la fonction de chargement massif (bulk insert) qui nous a permis de charger les donn´ees d’une mani`ere efficace et dans un temps presque lin´eaire relativement au nombre de documents (voir Table 5.1 et Figure5.7).

Pour CouchDB, un temps pour le calcul des vues mat´erialis´ees avant l’ex´ecution des requˆetes est requis. Nous pr´esentons dans le tableau ci-dessous (voir Table 5.2) le temps n´ecessaire pour deux ensembles de 1 et 6 millions de documents. Ce temps est lin´eaire. Il d´epend du volume de donn´ees et du type de la vue (simple ou param´etr´ee). Le fait d’ajouter de nouvelles donn´ees `a des donn´ees d´ej`a index´ees n´ecessite un temps suppl´ementaire pour recalculer la vue mat´erialis´ee. Ce temps d´epend ´egalement du volume de donn´ees ajout´ees.

Nombre de lignes de log (K) 50 100 500 1000 2500 Temps de chargement (Sesame) 2.97 135 1948 4080 28302 Temps de chargement (CouchDB) 20.89 43.36 219 427 1044

Table5.1: Temps de chargement de la provenance dans Sesame et CouchDB (en secondes).

Nombre de documents (M)

1 6

Temps de calcul des vues 175 363 Temps de calcul des vues

(ajout de + 10 % )

26 41

Table 5.2: Temps de calcul des vues mat´erialis´ees pour CouchDB (en secondes)

Figure5.7 – Courbes de chargement de la provenance dans Sesame et CouchDB

Nous avons test´e les temps de r´eponse pour nos six requˆetes sur les deux syst`emes. Les deux tables suivantes (voir Table 5.3et Table 5.4) pr´esentent les temps de r´eponse pour ces requˆetes. Pour chacune d’entre elles, le r´esultat pr´esent´e est une moyenne du temps de r´eponse sur 10 ex´ecutions cons´ecutives.

En effectuant nos requˆetes sur Sesame avec la configuration standard, nous avons rencontr´e des probl`emes de m´emoire (time-out). En augmentant la m´emoire Xms Java jusqu’`a 6 GO, nous avons r´eussi a r´eduire l’occurrence de ce probl`eme, mais nous n’avons pas r´eussi `a l’´eliminer compl`etement : nous avons eu 4 ´echecs de ce type sur les 60 tests (10 ex´ecutions pour chacune des 6 requˆetes) que nous avons effectu´e. Les r´esultats de ces requˆetes nous permettent de tirer les interpr´etations suivantes pour Sesame :

– sur les ensembles de donn´ees de petite taille (inf´erieure `a 5 million de triplets), les temps de r´eponse sont satisfaisants mˆeme s’il s’agit d’une requˆete de chemin, – compar´ees `a de simples requˆetes de s´election, les requˆetes d’agr´egation et de chemin

50 K 250 K 1 M 5 M 24 M Q1 26 36 49 63 439 Q2 23 92 464 2463 13174 Q3 51 52 55 61 173 Q4 15 17 19 21 994 Q5 157 602 3020 16014 85647 Q6 155 593 2980 15810 84457

Table5.3: Moyenne des temps d’ex´ecution des diff´erentes requˆetes pour diff´erent volumes de donn´ees dans Sesame (en millisecondes).

50 K 250 K 1 M 3 M Q1 57 58 61 63 Q2 48 48 49 51 Q3 561 565 566 566 Q4 55 55 57 58 Q5 4106 4227 4325 4331 Q6 4107 4231 4328 4333

Table5.4: Moyenne des temps d’ex´ecution des diff´erentes requˆetes pour diff´erent volumes de donn´ees dans CouchDB (en millisecondes).

sont les plus lentes,

– toutes les requˆetes d´ependent du volume de donn´ees interrog´ees. Pour les ensembles de donn´ees de grande taille, cet impact est tr`es remarquable surtout pour les requˆetes d’agr´egation et de chemin.

– le temps de r´eponse n’est pas lin´eaire et ne permettra pas de passer `a l’´echelle pour de gros volumes de donn´ees pour les requˆetes de chemin complexes comme Q5 ou Q6. Pour l’ex´ecution des requˆetes sur CouchDB, nous avons tir´e les interpr´etations suivantes : – la premi`ere requˆete prend 269 secondes avant de s’ex´ecuter parce qu’elle lance le

calcul de vues mat´erialis´ees sur toute la base.

– les requˆetes forward et backward (Q1, Q2, Q4) sont tr`es efficaces alors que les requˆetes d’agr´egation (Q3) sont plus lentes,

– les requˆetes de chemin ne sont pas tr`es efficaces mais le temps de r´eponse reste quand mˆeme tr`es raisonnable,

– le temps d’ex´ecution de toutes les requˆetes est ind´ependant du volumes de donn´ees. Effectivement, le m´ecanisme de vues bas´e sur map/reduce est efficace sur de petits et de grands ensembles de donn´ees,

– la d´efinition des vues n´ecessite une bonne maitrise du fonctionnement de map/reduce dans CouchDB. Elles sont relativement complexes pour les requˆetes r´ecursives car Cou- chDB ne propose pas un m´ecanisme int´egr´e pour injecter des r´esultats interm´ediaires dans une mˆeme vue.

Figure 5.8 – Temps d’ex´ecution de Q1 sur Sesame et CouchDB

Figure 5.9 – Temps d’ex´ecution de Q6 sur Sesame et CouchDB

– le temps de calcul des vues mat´erialis´ees (voir Table5.2) est lin´eaire et d´epend du volume de donn´ees et du type de la vue (simple ou param´etr´ee). L’ajout de nouvelles donn´ees `a des donn´ees d´ej`a index´ees relance cette op´eration pour calculer de nouveau les vues mat´erialis´ees.

Ces exp´erimentation en chargement et en interrogation de la provenance nous permettent de tirer les conclusions suivantes :

– CouchDB assure la passage `a l’´echelle en stockage de donn´ees,

– pour des requˆetes simples sur de faibles volumes de donn´ees (≤ 2 million de triplets), Sesame est plus performant. Cependant, CouchDB assure un temps de r´eponse lin´eaire (voir constant) sur des volumes plus importants (voir Figure 5.8).

– pour les requˆetes de chemin, Sesame est plus performent sur de faibles volumes de donn´ees. Cependant, CouchDB assure un temps de r´eponse lin´eaire (voir constant) sur des volumes plus importants (voir Figure5.9).

Documents relatifs