• Aucun résultat trouvé

Repr´esentation et interrogation de la provenance dans Cou-

5.4 Validation non-fonctionnelle

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

5.4.3.1 Repr´esentation et interrogation de la provenance dans Cou-

Nous avons choisi d’utiliser comme base NoSQL CouchDB qui est une base de donn´ees non relationnelle orient´ee documents. CouchDB a ´et´e d´evelopp´e en Erlang16 et utilise plusieurs technologies con¸cues pour le Web comme les services REST [Fielding, 2000] pour les op´erations d’insertion, mise `a jour, lecture et suppression et JSON comme format de stockage de donn´ees. CouchDB introduit la notion de document qui est la structure ´equivalente `a un tuple dans un SGBD relationnel. L’interrogation d’une base CouchDB est effectu´ee `a travers des vues dont la d´efinition et l’ex´ecution se base sur le mod`ele map/reduce. CouchDB permet aussi de r´epliquer les donn´ees sur plusieurs nœuds de fa¸con incr´ementale.

Nous proposons de repr´esenter les instances d’un M DI en se basant sur trois types de documents (document au sens de CouchDB) que nous d´efinissons. Ces types sont ActorDocument, ActionDocument et Document. Nous proposons aussi de mat´erialiser la corr´elation entre les artifacts en utilisant un type de document d´edi´e que nous appelons CorrelationDocument qui contient un ensemble d’informations permettant de d´efinir les liens entre les identifiants d’objets distribu´es. Cette mod´elisation permet ainsi de projeter les concepts du M DM dans CouchDB. N’importe quel type de document parmi les types que nous avons d´efini peut r´ef´erencer d’autres types de documents. Ainsi, notre mod´elisation permet de manipuler les concepts du M DM comme des documents et donc comme des objets de premier ordre.

Nous mat´erialisons les liens qui existaient dans les triplets RDF en tant qu’attributs dans nos diff´erents documents. Nous pr´esentons sur la Figure 5.6illustrant un exemple de notre mod´elisation de la provenance dans CouchDB. Cet exemple pr´esente des documents et les liens qui les relient. Sur cet exemple, l’action “send-28-11-2011” est pr´ec´ed´ee par l’action “emit-63”. Cette action a pris en entr´ee le document identifi´e par “744438” pour g´en´erer le document identifi´e par “744439”. Elle a ´et´e effectu´ee par l’acteur “sftpSender”. Nous illustrons aussi une relation de correspondance entre le document identifi´e par “744439” et celui identifi´e par “cust356 12”. Cette correspondance est sauvegard´ee dans un document sp´ecifique “corr 569”.

Certes, ce choix de mod´elisation de la provenance dans CouchDB n’est pas unique et d’autres alternatives pour la mod´elisation des documents dans CouchDB existent. Une premi`ere alternative est de repr´esenter et de stocker dans un document unique toute la provenance d’une source donn´ee. L’inconv´enient dans ce cas est de d´epasser la taille maximale autoris´ee pour un document dans CouchDB (fix´ee `a 4GB). Une autre alternative est de repr´esenter dans un document unique toutes les informations relatives `

a une d´eclaration de provenance (qui correspond `a une ligne dans un fichier de log par exemple). Dans ce cas, toutes les informations relatives `a un action sont stock´ees dans ce mˆeme document en tant qu’attributs. Une telle repr´esentation est pauvre d’un point de

vue s´emantique et est centr´ee uniquement sur les processus (i.e les actions). Elle permet de cr´eer uniquement des liens entre les diff´erentes actions. Par contre, les liens entre les documents et les acteurs seront d´efinis comme des attributs de ce mˆeme document ce qui rend la formalisation des requˆetes map/reduce complexes. Une troisi`eme alternative est d’utiliser une mod´elisation similaire `a celle que nous avons choisi (c’est `a dire de d´efinir trois types de documents et de les r´ef´erencer par des attributs) en dupliquant les r´ef´erences entre les documents dans les deux sens. Cette mod´elisation facilite la navigation dans le graphe de provenance `a partir de n’importe quel document.

Figure 5.6 – Mod´elisation de la provenance dans CouchDB ´

Etant donn´e qu’il s’agit d’une base NoSQL qui ne poss`ede pas un sch´ema pr´ed´efini, les instances du M DM peuvent ˆetre enrichies pour cr´eer dans le mˆeme document un mod`ele de domaine instanci´e. Ainsi, nous n’avons pas besoin de r´epliquer autant de fois les M DIs `a chaque fois que nous souhaitons instancier un nouveau M D. Il suffit juste d’enrichir le M DI existant. L’exemple de code suivant (voir Exemple de code5.10) illustre une repr´esentation JSON de donn´ees de provenance stock´ees dans CouchDB.

1 A c t i o n Document : 2 { 3 ” i d ”: ”0 0 1 e 3 8 d 8 2 a 5 8 1 8 e a 6 0 d e e 3 c e f 1 0 0 1 5 2 5 ” , 4 ” r e v ”: ”1−0 d 7 0 8 6 8 8 3 d 4 7 c 8 7 2 d 5 c 5 3 7 6 1 1 3 d 1 1 e c 4 ” , 5 ”name ”: ”SEND” , 6 ” i d ”: ”send −28 −11 −2011”, 7 ” t y p e ”: ”ActionDocument ” , 8 ”timestamp ”: ”2 8 / 1 1 / 2 0 1 1 − 2 1 : 3 2 : 5 2 ” , 9 ” i n p u t ”: [

10 ”7 4 4 4 3 8 ” 11 ] , 12 ” o u t p u t ”: [ 13 ”7 4 4 4 3 9 ” 14 ] , 15 ” a c t o r ”: ” s f t p S e n d e r ” , 16 ”precededBy ”: ”emit −63” 17 } 18 19 A c t o r Document : 20 { 21 ” i d ”: ”0 0 1 e 3 8 d 8 2 a 5 8 1 8 e a 6 0 d e e 3 c e f 1 0 3 7 9 4 c ” , 22 ” r e v ”: ”1 −702717 b 4 f 4 2 6 6 9 9 8 7 9 1 c 6 3 7 a b d d 6 e a 4 b ” , 23 ”name ”: ” s f t p S e n d e r ” , 24 ” t y p e ”: ”ActorDocument ” , 25 ” c h a r a c t e r i s t i c ”: ” A u t h e n t i c a t e d ” 26 } 27 28 Document : 29 { 30 ” i d ”: ”0 0 1 e 3 8 d 8 2 a 5 8 1 8 e a 6 0 d e e 3 c e f 1 0 3 2 d 1 c ” , 31 ” r e v ”: ”1−2 d e e 8 a 5 0 8 9 7 0 7 1 b e 3 1 4 0 d a b a c 4 2 9 0 2 3 3 ” , 32 ” t y p e ”: ”Document ” , 33 ” s t a t u s ”: ” s e n t ” , 34 ” i d s ”: [ ” c e g i d : 7 4 4 4 3 8 ” , ” nova : p a i e \ 1 1 −2011−custCE4 ” 35 ] , 36 ”path ”: [ ’ ’ output , s p l i t , 7 4 4 4 3 9 , 2 8 / 1 1 / 2 0 1 1 − 2 1 : 3 2 : 5 5 ’ ’ ] , 37 ”s h a 2 5 6 ”: ”D12AB8F6200BD0AAE1B1F5B9B5317F8F4113B2B9C015B3734045FA463B5A6D0D ” , 38 ” i d e n t i f i e r ”: ”7 4 4 4 3 8 ” 39 }

Exemple de code 5.10: Repr´esentation de la provenance en JSON dans CouchDB Nous avons d´evelopp´e la fonction d’import en Java et nous avons utilis´e le client Ektrop17 qui est un client Java proposant des fonctions de persistance pour interagir avec les bases CouchDB. Comme la logique orient´ee triplet de Sesame est diff´erente de la logique orient´ee document de CouchDB, le nombre d’enregistrements g´en´er´es par la fonction d’import sur les mˆemes logs ´etait diff´erent du nombre de triplets RDF g´en´er´es. En effet, notre fonction d’import a g´en´er´e 3.000.517 documents. Pour les charger dans notre module de stockage, nous avons utilis´e la fonction « bulk insert » du client Ektrop. Cette fonction est efficace pour une int´egration de documents en masse dans CouchDB.

Pour pouvoir interroger les donn´ees de provenance stock´ees dans CouchDB, nous avons besoin de cr´eer des vues. Elles peuvent ˆetre d´efinies en Javascript. Dans CouchDB, deux types de vues existent :

– les vues temporaires : elles ne sont pas mat´erialis´ees en base et sont ex´ecut´ees `a la demande. L’ex´ecution de ce type de vue est lente. Cette lenteur augmente au fur et `a mesure que la taille de la base augmente.

– les vues permanentes : ce type de vue est stock´e dans un type sp´ecial de document appel´e design document. Un design document peut contenir plusieurs vues. Chaque vue est identifi´e par un nom unique au sein de ce document. Elle d´efinit n´ecessairement une fonction map et optionnellement une fonction reduce.

La fonction map consulte tous les documents dans CouchDB de fa¸con incr´ementale pour g´en´erer un premier r´esultat. Ce r´esultat est une liste ordonn´ee de cl´es/valeurs. Elles sont d´efinies par l’utilisateur qui d´eveloppe cette fonction. Cette fonction fait appel `a la fonction int´egr´ee emit(cl´e/valeur) de CouchDB entre 0 et N fois par document pour ajouter une entr´ee dans le r´esultat de map. Les exemples de code suivants (voir Exemple de code

5.11, Exemple de code5.12et Exemple de code5.13) pr´esentent nos requˆetes Q1, Q2 et Q6 en map/reduce.

1 ‘ ‘ d o c u m e n t s b y a c t o r ”: { 2 ‘ ‘ map ”: ” f u n c t i o n ( doc )

3 { i f ( ( doc . a c t o r ) && ( doc . t y p e ==‘ActionDocument ’ ) ) 4 e m i t ( doc . a c t o r , doc . i d ) } ’ ’

5 }

Exemple de code 5.11: Q1 en map/reduce

1 ‘ ‘ d o c u m e n t s a r c h i v e d n u m b e r ”: {

2 ”map ”: ” f u n c t i o n ( doc ) { i f ( ( doc . t y p e ==’Document ’ ) && ( doc . s t a t u s ) && ( doc . a r c h i v e r ) &&(doc . i d e n t i f i e r ) )

3 e m i t ( [ doc . i d e n t i f i e r , doc . s t a t u s , doc . a r c h i v e r ] , doc . i d ) } ” , 4 ” r e d u c e ”: ‘ ‘ c o u n t ”

5 }

Exemple de code 5.12: Q3 en map/reduce

1

2 ‘ ‘ p a t h b y d o c i d ”: { 3 i f ( doc . i d e n t i f i e r ) {

4 e m i t ( [ doc . i d e n t i f i e r , 0 ] , doc . path ) ; 5 i f ( doc . i n p u t s ) {

6 f o r ( v a r i i n doc . i n p u t s ) {

7 e m i t ( [ doc . i d e n t i f i e r , Number ( i ) + 1 ] , { path : doc . path [ i ] } ) ;

8 }

9 }

10 i f ( doc . o u t p u t s ) {

11 f o r ( v a r j i n doc . o u t p u t s ) {

12 e m i t ( [ doc . i d e n t i f i e r , Number ( j ) + 1 ] , { path : doc . path [ j ] } ) ; 13 }

14 } 15 } 16 }

Exemple de code 5.13: Q6 en map/reduce

Ces exemples montrent que mˆeme si les requˆetes map/reduce ne sont pas tr`es complexes `

a d´efinir et `a comprendre, elles ne sont pas aussi d´eclaratives et lisibles que les requˆetes SPARQL. La complexit´e de ces fonctions augmente d’autant que la requˆete est complexe.

1 { ” i d ”: ”8 4 4 7 c 2 5 1 7 d 6 b b f 5 6 b 0 2 5 2 3 c 3 a 9 d 7 4 c 6 e ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ”8 4 4 7 c 2 5 1 7 d 6 b b f 5 6 b 0 2 5 2 3 c 3 a 9 d 7 4 c 6 e ”} , 2 { ” i d ”: ”8 4 c 9 7 6 4 b 2 6 b 5 9 5 1 e 5 7 f 1 f d a 6 5 4 2 c a 8 a a ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ”8 4 c 9 7 6 4 b 2 6 b 5 9 5 1 e 5 7 f 1 f d a 6 5 4 2 c a 8 a a ”} ,

3 { ” i d ”: ”8 6 5 9 5 9 6 b c 9 4 d 3 3 5 2 8 c 3 7 b 4 7 2 d c f e a b 1 0 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ”8 6 5 9 5 9 6 b c 9 4 d 3 3 5 2 8 c 3 7 b 4 7 2 d c f e a b 1 0 ”} , 4 { ” i d ”: ”9 5 d d c 9 f 0 6 1 3 1 f 0 2 e 7 6 2 2 3 0 6 5 8 b 6 8 c a b 4 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ”9 5 d d c 9 f 0 6 1 3 1 f 0 2 e 7 6 2 2 3 0 6 5 8 b 6 8 c a b 4 ”} , 5 { ” i d ”: ”9 8 a c 0 8 1 0 d 6 a 8 5 4 3 8 d c 7 7 6 d 0 6 b 8 7 b 9 b 1 8 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ”9 8 a c 0 8 1 0 d 6 a 8 5 4 3 8 d c 7 7 6 d 0 6 b 8 7 b 9 b 1 8 ”} , 6 { ” i d ”: ” a 0 1 d 8 a 5 3 c a 6 4 d 3 7 2 7 9 d f b 0 f 5 a 6 0 0 2 4 4 5 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ” a 0 1 d 8 a 5 3 c a 6 4 d 3 7 2 7 9 d f b 0 f 5 a 6 0 0 2 4 4 5 ”} , 7 { ” i d ”: ” b 3 6 a d d f b 7 9 f 8 3 f a 4 b 7 e e a 5 3 c 5 7 0 5 c 6 5 a ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ” b 3 6 a d d f b 7 9 f 8 3 f a 4 b 7 e e a 5 3 c 5 7 0 5 c 6 5 a ”} , 8 { ” i d ”: ” c d b 8 d 8 a d 9 f d c d 4 2 b e 4 2 9 6 c 4 5 3 2 d 8 7 e 4 6 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ” c d b 8 d 8 a d 9 f d c d 4 2 b e 4 2 9 6 c 4 5 3 2 d 8 7 e 4 6 ”} , 9 { ” i d ”: ” d c c d b a 3 4 a 3 6 f c b 5 c b 2 6 2 3 1 c 3 7 4 7 c f b 4 9 ” , ” key ”: { ” i d e n t i f i e r ”: ”UBISOFT : ” , ” l o c a l I d ”: ”” , ” i d e n t i f c a t i o n S y s t e m I d ”: ”UBISOFT ”} , ” v a l u e ”: ” d c c d b a 3 4 a 3 6 f c b 5 c b 2 6 2 3 1 c 3 7 4 7 c f b 4 9 ”} ,

Exemple de code 5.14: Un exemple du r´esultat de l’ex´ecution de la fonction map pour Q1

5.4.3.2 Exp´erimentations et analyse des r´esultats

Documents relatifs