December 2007 - Simexplorer-si-devel - mailman.cloud.codelutin.com

Choix moteur base de données
by landais＠codelutin.com 17 Dec '07

17 Dec '07

Bonjour, après avoir reconsidéré les besoins et les fonctions nécessaires à l'indexation et la recherche d'éléments, nous avons pensé utiliser Lucene pour l'implantation de la base de donnée. Les données ont été décomposées en trois groupes : * les meta-données de chaque élément, permettant de l'identifier, de connaître son type, son parent en version, etc * le contenu indexé, provenant d'une librairie, de résultat, etc. C'est sur ce contenu que la recherche full text sera faite * les données à proprement parler, qui sont stockées sur le système de fichier. On conserve dans ces fichiers les meta données, afin de permettre la reconstruction d'une base à partir d'un dossier. Lucene fonctionne par document indexé. Chaque document a des champs, associant à un libellé une valeur. Cette valeur peut être indexée et/ou stockée. Un document peut avoir plusieurs champs avec le même nom. Nous stockons ainsi les meta données dans des champs prédéfinis, et le contenu à indexer dans un champ non stocké. Une fois les documents indexés, la recherche peut se faire sur des champs de meta donnée afin de récuperer un élément en particulier, ou sur le champ indexé. Cette dernière recherche permet des requêtes textuelles complexes, en autorisant les jokers, les opérateurs booléens, etc. Afin de valider ce choix, nous avons procédé à différents tests, notamment de montée en charge. Ainsi, un test a créé une base de 25 000 documents, contenant chacun entre 10 000 et 30 000 mots d'un dictionnaire de 150 000 mots (entre 2 et 7 lettres). Soit au total environ 11Gb de données indexées. L'index en lui même pèse 3Gb, le contenu n'étant pas stocké. L'ajout atomique de document et la recherche ne pose pas de problème de performance, Lucene étant suffisamment mature et la transformation entre un document et des méta données simple. La principale difficulté se trouvent dans la gestion des fichiers d'index. Une fois que ceux ci sont ouvert en lecture, Lucene conserve un index correspondant au lecteur au moment de son ouverture, tout en laissant la possibilité de continuer l'indexation. Afin de conserver la cohérence entre ce qui est lu et ce qui est écrit, le lecteur est invalidé lors de l'écriture de données. Lors de la première lecture après une écriture, une ouverture d'un nouvel index est réalisé, et est pratiquement immédiat. Les recherches full texte sur deux caractères (type eu*) sont assez rapides (150 à 200ms), le plus long étant la récupération des document depuis l'index, en récupérant tous ses champs associés (3ms par document). Un avantage majeur de Lucene est aussi son aspect portable, il peut être exécuter sur le poste client ou sur le serveur sans problème. L'implantation du moteur Lucene se base sur l'interface Database ci jointe. Ainsi, si vous n'y voyez pas d'objection, Lucene sera utilisé pour stocker les meta données. Cordialement, Gabriel -------------- section suivante -------------- Une pièce jointe non texte a été nettoyée... Nom: fr_cemagref_simexplorer_is_storage_database_classes.png Type: image/png Taille: 4887 octets Desc: non disponible Url: https://lists.labs.libre-entreprise.org/mailman/private/simexplorer-si-deve…

2 3

Questions
by landais＠codelutin.com 12 Dec '07

12 Dec '07

Bonjour, tout d'abord merci pour vos réponses, cela me permet de bien avancer. Savez vous déjà quel sera le format physique utilisé afin d'échanger des données? Il doit contenir dans un premier temps un fichier XML. A l'intérieur de celui-ci, on doit trouver les meta données (attributs du "LoggableElement") ainsi que les données (constantes, valeurs, codes, etc). De plus, ce fichier peut être une librairie avec un fichier attaché binaire, ou une application d'exploration avec des données d'exploration pouvant contenir un résultat sous forme de zip. On peut ainsi se retrouver avec un fichier devant contenir plusieurs zip avec plusieurs données d'exploration. IMHO, il faudrait définir une structure de fichier afin d'être en mesure d'associer un élément xml à un fichier, du type : MyExplorationApplication.zip +--data.xml x--<metadata> x--<id> x--1 x--<version> x--2 x--... x--<ed> x--<result> x--attach1.zip x--... x--<ed> x--<result> x--attach2.zip x--... x--<c> x--... +--attachments +--attach1.zip +--attach2.zip Les metadata peuvent être séparées du data.xml, en ayant leur propre fichier (notamment pour obtenir un checksum sur les données uniquement). Pour le moment ce que j'ai fait est assez générique, j'aurais besoin de ces éléments assez rapidement pour continuer. Aussi, le schéma du fichier xml doit être partagé avec SimExplorer, qui le produit et lequel fait référence? Enfin, l'application sera la plus tolérante possible sur la pertinence des meta données envoyées, mais les informations sur le parent en version ou en données devront être régies par des règles de gestion à définir précisément et à implanter dans SimExplorer. Merci! Gabriel

2 1

Questions
by landais＠codelutin.com 07 Dec '07

07 Dec '07

Bonjour, voici quelques questions : - Quel nom de package doit on utiliser? Je suis parti sur org.cemagref.simexplorer.si pour le moment. - Il est difficile de garantir qu'un contributeur conserve le droit de lecture/écriture si le propriétaire change. Ne serait-il pas préférable d'avoir plusieurs propriétaires pour un seul élément? - Comment gérer la perte de permission de lecture d'un composant par un utilisateur alors qu'il l'utilise dans une de ses explorations? Est ce qu'un utilisateur a toujours la possibilité de lire tous les sous-éléments des éléments dont il est le propriétaire? - Afin de garantir la synchronisation entre le client et le serveur, les identifiants des éléments doivent être unique, dans tous les contextes où ils sont générés. Il est indispensable pour SimExplorer-si d'affecter aux éléments des identifiants du type UUID (http://en.wikipedia.org/wiki/UUID) Est ce que c'est possible/réalisé? Merci Gabriel

2 1