Télécharger
    Installer
    Présentation
    Configuration
      +Base de documents <-
       Entrepôt
    Indexation
    Recherche
    OAI
    Javadoc
    Référence API-XSP
    Migration
    Schemas
    Performances


SDX

Configuration d'une base de documents

Les bases de documents sont l'une des composantes des applications SDX 2. L'élément <sdx:documentBases> du fichier application.xconf contient les informations qui définissent les bases de documents d'une application ; nous allons expliquer ici quelles sont les informations de configuration associées à cet élément.

Il est à noter que la configuration d'une application SDX doit également contenir un élément <sdx:userDocumentBase> qui a exactement la même structure que l'élément <sdx:documentBase> dont il sera principalement question ici. Ainsi, toutes les informations de ce document peuvent également s'appliquer à l'élément <sdx:userDoucmentBase>. Ce dernier permet de configurer la base de documents spéciale qui gère les utilisateurs associés à l'application. Cette base de documents est spéciale à cause du rôle spécifique qu'elle joue pour l'application, mais en fait elle peut également être utilisée de la même manière que toute base de documents, ce qui implique notamment qu'elle peut être utilisée en recherche.

L'architectude de SDX a été conçue de manière à ce que la notion de base de documents soit relativement générique, même si pour l'instant un seul type de base de documents peut être défini, soir les bases de documents Lucene. Si jamais d'autres moteurs de recherche sont interfacés avec SDX, d'autres types de bases de documents verront le jour.

Relation avec les entrepôts

Une base de documents n'est pas suffisante pour construire une application SDX avec du contenu. En effet, même si celle-ci a toute l'information nécessaire pour chercher des documents et les présenter de façon sommaire, elle ne contient pas les documents eux-mêmes, ni même une référence précise avec leur emplacement. Par contre, les bases de documents vont garder une trace de l'entrepôt de documents où se trouve le document indexé, ce qui va permettre de retrouver les documents eux-mêmes lorsque nécessaire.

La configuration d'un entrepôt de documents peut se situer à l'intérieur (dans le sens de la hiérarchie XML) de la configuration d'une base de documents ou encore à l'extérieur, c'est-à-dire au niveau de la configuration d'une application. Lorsque l'entrepôt est défini à l'intérieur d'une base de documents, cela signifie qu'il est accessible seulement pour cette base ; autrement dit, les autres bases de documents de l'application ne pourront pas stocker les documents dans cet entrepôt. A l'opposé, lorsque l'entrepôt est défini au niveau de l'application, toutes les bases de documents peuvent y déposer des documents. L'intérêt de cette configuration sera plus important lorsque différents types de bases de documents seront intégrés à SDX.

L'élément <sdx:documentBases>

Cet élément a simplement pour but de contenir la liste des bases de documents associées à une application. Il doit être à l'intérieur de l'élément <sdx:application>.

Informations générales à propos d'une base de documents

L'élément <sdx:documentBase> contient toutes les informations nécessaires pour définir une base de documents, y compris certaines informations générales. Ces informations générales sont toutes spécifiées en attributs.

Table 1. Attributs de l'élément <sdx:documentBase>

AttributValeurs possiblesDescription
idUn identifiant. Obligatoire.L'identifiant de la base de documents. Cet identifiant est obligatoire, il devient par la suite la clé d'identification de la base de documents pour toutes les opérations de recherche, d'ajout ou de suppression de documents dans cette base.
defaultUn booléen (true ou false), par défaut c'est false.Si true, cette base est la base par défaut pour cette application. Cela signifie que les opérations de recherche, d'ajout ou de suppression de documents se feront dans cette base sauf si une base est explicitement mentionnée par son identifiant.
typeUne chaîne.Le type de base de documents ; pour l'instant, seule la valeur "lucene" est permise.
xml:langUn code de langue selon la norme XML (par exemple fr-CA ou en).La langue par défaut pour le contenu des champs de cette base de documents. Si elle n'est pas spécifiée, c'est la langue par défaut de l'application qui est utilisée.
variantUn code de variante de langue, selon le langage Java.Java permettant de préciser des variantes de langue, le contenu de cet attribut vient préciser la langue donnée par xml:lang.
remote-accessUn booléen (true ou false), par défaut c'est false.Si true, cette base de documents est cherchable par des applications SDX autres que celle où elle est définie.
keepOriginalDocumentsUn booléen (true ou false), par défaut c'est true.Cet attribut n'a de sens que si le tube d'indexation contient plusieurs étapes de transformation. Dans ce cas, une valeur true signifie que le document original fourni à l'indexation est conservé par SDX ; dans le cas contraire, SDX ne conserve que les documents issus des étapes de transformation avec un keep=true.
maxFieldLengthUn nombre entier, par défaut 10 000.Le nombre de mots indexés dans un champ. La modification de ce nombre peut avoir des impacts sur la performance. Consulter la documentation de la classe IndexWriter de Lucene pour en savoir plus.
autoOptimizeUn booléen (true ou false), par défaut c'est true.Par défaut, SDX optimise les index Lucene à toutes les fois qu'un lot de documents est ajouté ou supprimé à l'index. Voir la section sur la gestion des index ci-dessous pour en savoir plus. A noter que cette fonctionnalité n'est disponible que depuis la version 2.3 de SDX. Si vous utilisez cet attribut avec une version antérieure, il est tout simplement ignoré.

Générateur d'identifiants

Tous les documents gérés par SDX doivent avoir un identifiant. Cet identifiant doit être unique dans la base de documents où il se trouve. En général, c'est le processus d'indexation qui est responsable de déterminer cet identifiant qui est fourni par l'attribut id de l'élément sdx:document résultant de ce processus d'indexation.

Toutefois, dans certains cas, il peut être difficile de trouver un identifiant lors du processus d'indexation, et c'est pourquoi SDX 2 offre un moyen d'en générer automatiquement, à l'aide de générateurs d'identifiants. Un générateur d'identifiants est nécessairement une classe Java qui implémente l'interface fr.gouv.culture.sdx.documentbase.IDGenerator ; SDX 2 fournit une telle classe nommée fr.gouv.culture.sdx.documentbase.DefaultIDGenerator qui génère des identifiants de manière aléatoire.

Il n'est pas nécessaire de configurer des générateurs d'identifiants, même si on désire en utiliser un. En effet, dans une telle situation, SDX 2 utilisera toujours son propre générateur d'identifiants par défaut. Toutefois, si on veut en utiliser un autre, on doit le déclarer dans le application.xconf, à l'aide d'un élément sdx:idGenerator, qui doit avoir un attribut class qui indique le nom complet de la classe, et peut avoir des attributs idPrefix et idSuffix pour indiquer un préfixe et/ou un suffixe à ajouter aux identifiants générés. Pour utiliser ce générateur d'identifiants ou celui proposé par SDX 2, on doit spécifier l'attribut generateId de sdx:document dans le document retourné par le processus d'indexation, et lui donner une valeur true.

Gestion des index

Note

Les informations fournies dans cette section ne sont valables que depuis la version 2.3 de SDX. Sur des versions antérieures, elles n'ont aucun effet.

Il est possible de paramétrer la manière dont SDX va gérer les index Lucene pour une base de documents. Le principal objectif de ce paramétrage est de rendre plus efficace la gestion des gros index, c'est-à-dire lorsqu'il y a un très grand nombre de documents ou lorsque les documents sont de grande taille. Pour les petits index, ces paramétrages sont fonctionnels mais peu utiles.

Optimisation

Un index Lucene est optimisé lorsqu'il est stocké dans une structure efficace et optimale. Normalement, lorsqu'on ajoute ou supprime des documents dans un index Lucene, celui-ci n'est plus optimisé, jusqu'à ce qu'on demande explicitement une optimisation. Que l'index soit optimisé ou non, les résultats de recherche seront exactement les mêmes, mais un index optimisé effectuera les recherches plus rapidement. Par ailleurs, l'optimisation d'un index est une opération qui prend un certain sur un index volumineux. C'est pourquoi il ne faut pas chercher à la faire trop souvent. La gestion de l'optimisation d'un index Lucene doit donc être vu comme un compromis entre la performance en recherche (les index optimisés sont plus performants) et la performance en indexation (l'optimisation des index prend du temps).

Si on ne fait rien de spécial pour une base de documents SDX, ou si on utilise une version de SDX antérieure à la 2.3, alors l'optimisation de l'index Lucene sera effectuée l'ajout ou la suppression de chaque lot de documents. La taille d'un lot est spécifiée par le paramètre batch que l'on peut fournir lors de l'indexation ; par défaut la valeur est de 25, ce qui est peu. Donc si vous avez des lots de 25 et que vous indexez 1000 documents, alors l'index sera optimisé 40 fois. Si vous indexez un seul document à la fois, l'index sera optimisé une fois.

C'est pourquoi depuis la version 2.3 de SDX il est possible de configurer une base de documents (et donc des index Lucene) pour que l'optimisation ne soit pas effectuée après l'indexation d'un lot de documents. Pour ce faire, il s'agit d'utiliser l'attribut autoOptimize de l'élément sdx:documentBase et de lui donner la valeur false (voir ci-dessus). Dans ce cas, si vous ne faites rien d'autre, les index ne seront jamais optimisés.

Interprète de requêtes

A faire.

Liste des champs

La liste des champs contient des informations capitales pour une base de documents SDX, puisque toutes les manipulations ultérieures (recherche, tris, résultats, etc.) se font sur des champs. La liste des champs est une liste à plat, une simple collection de champs dont l'ordre n'est pas important. Pour chaque champ, on peut définir un certain nombre de propriétés, certaines ayant des valeurs par défaut, d'autres obligatoires, d'autres optionnelles. De plus, un certain nombre de propriétés peuvent être héritées depuis des éléments parents.

De manière générale, la définition d'une liste de champs intervient à l'intérieur d'un élément sdx:documentBase de la manière suivante :

<sdx:documentBase ...>
  ...
  <sdx:fieldList ...>
    <sdx:field .../>
    ...
  </sdx:fieldList>
</sdx:documentBase>

La liste des champs est obligatoire, sinon votre base de documents ne sera pas disponible dans l'application.

L'élément sdx:fieldList peut avoir les attributs suivants :

Table 2.

AtributValeurs possiblesDescription
refL'attribut id d'un autre élément sdx:fieldList. Optionnel. Pas de valeur par défaut.Cet attribut permet de pointer sur un autre élément sdx:fieldList déclaré globalement, c'est-à-dire au niveau de l'application, et donc dans l'élément sdx:application. Cela permet de réutiliser des listes de champs dans différentes bases de documents. A noter que si vous utilisez cet attribut, toutes les proprités de la liste de champs de référence seront utilisées, mais vous pourrez ajouter des champs en ajoutant des sous-éléments sdx:field.
analyzerClassLe nom qualifié d'une classe Java. Optionnel. Pas de valeur par défaut directe.Cette classe Java sera utilisée comme analyseur de mots par défaut pour tous les champs de cette liste. Ainsi, si un champ de type word n'a pas de précisions sur l'analyseur de mots à utiliser, c'est celui-ci qui le sera. Cet attribut a préséance sur le rôle joué par l'attribut xml:lang présenté ci-dessous.
analyzerConfUne URL. Optionnel. Pas de valeur par défaut.L'URL qui indique le fichier de configuration à utiliser pour l'analyse de mots spécifié par défaut, peu importe la méthode dont celui-ci est spécifié.
xml:langUn code de langue, éventuellement qualifié (par exemple fr-CA). Optionnel. Pas de valeur par défaut directe.La langue par défaut du contenu des champs. Si l'attribut analyzerClass n'est pas utilisé, alors la langue permet de déterminer l'analyseur de mots par défaut. S cet attribut n'est pas spécifié, alors on considère que la langue est donnée par l'attribut xml:lang de l'élément parent sdx:documentBase ou, si celui-ci non plus n'est pas spécifié, on considère que la langue est donnée par l'attribut xml:lang de l'élément racine sdx:application.
variantUne chaîne de caractères. Optionnel. Pas de valeur par défaut.Un complément au code de langue, selon le mécanisme des locale du langage Java. Pour préciser encore plus la langue par défaut des contenus.

Ensuite, à l'intérieur de l'élément sdx:fieldList, on retrouve un ou plusieurs éléments sdx:field, chacun identifiant un champ qui sera disponible en recherche ou pour tout autre traitement.

Le tableau suivant présente les attributs qui peuvent être associés à l'élément sdx:field pour déterminer les caractéristiques de chaque champ.

Table 3.

AtributValeurs possiblesDescription
nameUne chaîne de caractère, unique parmi tous les champs, composée de lettres seulement. Obligatoire.Cet attribut donne un nom unique au champ.
defaultUn booléen, soit true ou false. Optionnel. Par défaut, false.Indique s'il s'agit du champ de recherche par défaut. Il doit y avoir un seul champ par défaut dans une liste de champs.
typeUne des valeurs word, field, date, unindexed ou xml. Obligatoire. Par défaut word.Le type de champ ou d'indexation dont il s'agit. La valeur word indique un champ indexé par mots, avec un analyseur de mots. La valeur field indique un champ indexé tel quel, sans analyse de mots. La valeur date indique que le contenu doit être traité comme une date (format ISO 8601). La valeur unindexed indique que le champ n'est pas indexé. La valeur xml indique que le champ n'est pas indexé mais que sont contenu doit être interprété comme étant du XML, mais non indexé. A noter que cette dernière valeur n'est possible que depuis la version 2.3 de SDX.
briefUn booléen, soit true ou false. Optionnel. Par défaut, false.Indique si le champ doit être retourné en résultat de recherche ou non. Pour un champ de type unindexed ou xml, il est conseillé de mettre cette valeur à true sinon le champ sera inutile.
analyzerClassLe nom qualifié d'une classe Java. Optionnel. Pas de valeur par défaut directe.Cette classe Java sera utilisée comme analyseur de mots par défaut pour tous ce champ, s'il est de type word. Cet attribut a préséance sur l'attribut xml:lang ou sur les informations fournies au niveau de l'élément sdx:fieldList.
analyzerConfUne URL. Optionnel. Pas de valeur par défaut.L'URL qui indique le fichier de configuration à utiliser pour l'analyse de mots pour ce champ.
xml:langUn code de langue, éventuellement qualifié (par exemple fr-CA). Optionnel. Pas de valeur par défaut directe.La langue par défaut du contenu du champs. Si l'attribut analyzerClass n'est pas utilisé, alors la langue permet de déterminer l'analyseur de mots pour le champ de type word. S cet attribut n'est pas spécifié, alors on considère que la langue est donnée par l'attribut xml:lang de l'élément parent sdx:fieldList ou par les règles d'héritage qui lui sont propres..
variantUne chaîne de caractères. Optionnel. Pas de valeur par défaut.Un complément au code de langue, selon le mécanisme des locale du langage Java. Pour préciser encore plus la langue du contenu du champ.
storeTermVectorUn booléen, soit true ou false. Optionnel. Par défaut, false.Indique si le moteur de recherche Lucene doit consigner des informations de type term vectors pour ce champ. Pour en savoir plus sur ces informations, voir la documentation de Lucene. A noter que SDX ne fait aucun usage de cette information, mais si elle est stockée alors elle pourrait être exploitée à l'aide d'autres outils, ou en manipulant directement les index Lucene, sans SDX.

Indexation

A faire.



Auteur : Martin Sévigny ( AJLSM ) - 2004-08-19