Sur cette page, il est possible de voir le statut de la dernière compilation nocturne. Si ce statut indique une compilation réussie, la procédure pour obtenir et compiler les sources est la suivante :

Créer un répertoire de travail :

mkdir ~/solr-4.0

Se placer dans ce répertoire et récupérer les sources :

cd ~/solr-4.0
svn checkout http://svn.apache.org/repos/asf/lucene/dev/trunk

Compiler les sources :

cd ~/solr-4.0/modules
ant compile
cd ~/solr-4.0/lucene
ant dist
cd ~/solr-4.0/modules
ant dist

Le tour est joué !

Lucene et différentes contributions permettent de disposer d’analyzer et même de « stemmer » pour un grand nombre de ces langues. Avec Solr, le seul moyen pour associer le bon analyzer à chaque langue est d’avoir autant de champs dans le shema qu’il y a de langues possibles et d’associer à chaque champ le bon analyzer. Pour Hurisearch, cela aurait donc fait 60 champs pour le contenu des documents et 60 champs pour les titres. L’autre problème dans ce cas est également de ne pas pouvoir chercher lors d’une même requête dans la totalité des langues  simultanément. Autant dire que ces contraintes et limitations ne sont pas acceptables.

Il est impératif d’utiliser un champ unique pour toutes les langues. Comme il est possible d’associer un seul analyzer à ce champ, ce dernier doit donc s’adapter à la langue du texte en cours d’indexation et à la langue de la requête (il faut également traiter la requête en fonction de sa langue). Deux analyzers ont donc été développés afin de traiter le texte au mieux en fonction de sa langue : un analyzer pour indexer le texte sans le « stemmer » et un en le « stemmant » lorsque cela est possible (voici une explication en anglais de ce qu’est un stem).

Le dernier point à résoudre a été de trouver comment indiquer à l’analyzer la langue du texte qu’il va traiter. Avec Lucene, cela n’est pas un problème car les constructeurs (classes java) des analyzers  peuvent posséder une paramètre qui indique la langue. Par contre, avec Solr, cela n’est pas possible, les paramètres passés aux constructeurs des analyzers sont figés dans le fichier shema.xml. La solution a donc été de passer cette information en en-tête du texte lors de l’indexation et de la requête lors de la recherche.

En conclusion, nous avons été en mesure d’indexer un grand nombre de langues tout en pouvant rechercher simultanément dans tous les documents quelque soit leur langue et en offrant la possibilité de retrouver les mots indépendamment de leurs formes (genre, nombre, conjugaisons, …). Aujourd’hui, Hurisearch crawle 5400 sites Web sites qui représentent plus de 10 millions de pages indexées pas Solr.

* créer un répertoire de travail

mkdir /tmp/solr

* copier solr.war dans /tmp/solr

* extraire le contenu de solr.war et effacer solr.war

cd /tmp/solr
jar -xvf solr.war
rm solr.war

* remplacer dans /tmp/solr/WEB-INF/lib tous les fichiers lucene-…-2.9.0.jar par leurs équivalents en version 2.9.3.

* astuce pour les utilisateurs de mac os, il faut supprimer les fichiers cachés « .DS_Store » qui ont été créés dans chaque répertoire

find . -name .DS* -print -exec rm -rf {} \;

* reconstruire solr.war

jar cvf solr.war .

Pour consulter la liste des évolutions et corrections depuis Lucene 2.9.0, vous pouvez consulter le « Lucene Change Log« .

A lire ici

A lire sur  ARTICLE GALLERY

Erik Hatcher est un développeur de logiciels open-source. Avant Lucene et Solr, il a participé à de nombreux projets comme Ant, Tapestry et plusieurs sous-projet Jakarta.

Lisez son interview sur The Bitsource

Dans les précédents articles consacrés à Solr, j’en décris les principes (Présentation de Lucene Solr) et comment installer et configurer de façon très basique Solr afin de pouvoir indexer et rechercher dans le jeu de données de test fourni dans la distribution (Solr – Installation et configuration (1)).

Dans ce nouvel article, je vais expliquer plus en détail les points suivants :

• Le contenu de la distribution
• Les fichiers de configuration
• Comment gérer plusieurs indexes ?
• Comment gérer plusieurs applications ?

Le contenu de la distribution

Une fois récupérée et décompressée dans un répertoire, la distribution de Solr contient différents répertoires.

Mettre en place un environnement d’exécution de Solr à partir des éléments de la distribution est très simple. Il faut :

1. créer un environnement d’exécution en copiant le répertoire « /example/solr », sous par exemple « /opt/solr » (Linux) ou « c:/solr » (windows)
2. copier le fichier solr.war contenu dans le répertoire webapps des exemples vers le répertoire approprié du serveur d’application (répertoire webapps par exemple pour Tomcat)
3. configurer le serveur d’application pour qu’il soit lancé avec la variable d’environnement solr.home.home pointant vers le répertoire d’exécution (par exemple : -Dsolr.solr.home=/opt/solr) et le redémarrer

Dans le répertoire pointé par la variable d’environnement « solr.solr.home », on retrouve donc les répertoires « bin » (scripts utilitaires pour un environnement Linux), « conf » (fichiers de configuration) et « data » (y sera entre autres localisés l’index Lucene des données indexées).

Les fichiers de configuration

Les fichiers de configuration sont localisés dans le répertoire « /conf ». Il s’agit principalement de solrconfig.xml et schema.xml.

solrconfig.xml

Il s’agit du fichier qui contient l’essentiel des paramètres liés au fonctionnement de Solr et plus particulièrement des paramètres de l’API Lucene qu’utilise Solr (longueur maximale d’une champs, taille des buffer mémoire, fréquence de commit, …) . Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entière dans le wiki Solr.

schema.xml

Il s’agit du fichier qui décrit comment seront indexées les données dans Solr. Il définit les types de données, les champs, les manipulations sur les données lors de l’indexation, les champs obligatoires, le champ de requête par défaut, …

Ce fichier est très bien auto-documenté et fait l’objet d’un document a part entiere dans le wiki Solr.

Exemple de déclaration d’un type

<fieldType name=”string” class=”solr.StrField” sortMissingLast=”true” omitNorms=”true”/>

Ce type a pour nom « string », il sera pris en charge lors de l’indexation par la classe « solr.StrField », lors d’un tri du résultat sur ce champ, les documents ne le possédant pas seront positionnés en dernier (sortMissingLast= »true ») et lors de l’indexation les informations de normalisation basées sur la taille du champ seront calculées et stockées (omitNorms= »true »).

Exemple de déclaration d’un champ

<field name=%u201Dword%u201D type=%u201Dstring%u201D indexed=%u201Dtrue%u201D stored=%u201Dtrue%u201D/>

Les données indexées dans Solr par le service d’indexation sont contenues dans un datagramme de type XML. Lorsque Solr traite ce datagramme, il rapproche le nom de chaque élément XML avec le nom d’un champ. Il manipule alors la donnée associé à cet élément comme cela est défini par la définition du champ.
Ce champ est du type « string » (donc il hérite des propriétés de ce type). Il est indexé (donc les recherches peuvent porter sur son contenu) et les données de ce champs sont stokées (donc elles peuvent être récupérées au moment de l’affichage d’une liste de résultats par exemple). D’autres paramètres importants peuvent également être définis lors de la déclaration d’un champ. Il s’agit de la méthode d’analyse lors de ‘indexation ou de la recherche. La méthode d’analyse permet de définir comment seront traitées les données du champ, à savoir son mode de découpage en mots (tokenizer) et les filtres qui lui seront appliqués (filter). Les filtres permettent par exemple de supprimer les mots vides, de mettre tous les mots en minuscule, de convertir les mots accentués en leurs équivalents sans accent, …

Exemple de déclaration d’un champ dynamique

Une déclaration de champ dynamique permet d’associer un traitement à des éléments du datagramme XML même si ces derniers ne sont pas spécifiquement déclarés comme champs.

<dynamicField name=%u201D*_s%u201D  type=%u201Dstring%u201D  indexed=%u201Dtrue%u201D  stored=%u201Dtrue%u201D/>

Tout élément du datagramme XML dont le nom se termine par « _s », est considéré comme un élément de nom « string ».

Comment gérer plusieurs indexes ?

Par défaut, une instance Solr ne peut manipuler qu’un index. Comment faire si mon application doit permettre l’indexation de plusieurs types de données comme par exemple un annuaire de personnes et les messages d’un forum de discussion ? Jusqu’à la version de 1.2 de Solr, il existait 2 solutions : associer un type à chaque document dans l’index (personne, message, …) ou utiliser plusieurs webapps dans le serveur J2EE et les faire pointer vers des environnements différents (-D=solr.solr.home=…). L’association d’un type à chaque document permet lors de la recherche de filtrer la liste de résultats en se limitant aux documents d’un ou plusieurs types. Utiliser plusieurs webapps permet d’utiliser un index distinct pour chaque type de documents. Avec la version 1.3 de Solr est apparue la notion de « SolrCore » multiples. Un « SolrCore » est un environnement complet Solr (configuration et index) qui est exécuté par une webapps du serveur j2EE. Il est donc possible au moyen d’une seule webapps Solr de gérer plusieurs « SolrCore ». les SolrCore sont déclarés dans un fichier XML « solr.xml » localisé dans le répertoire solr.solr.home associé à la webapp.

Exemple d’un environnement mono-core

solr.solr.home=/opt/solr  

Les répertoires d’installation sont organisés comme ceci :

/opt
    /solr
        /bin
        /conf
        /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Les urls d’accès à l’administration et aux web service Solr sont :

Exemple d’un environnement multi-core

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt

    /solr
        solr.xml
        /core0
            /bin
            /conf
            /data
        /core1
            /bin
            /conf
            /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier solr.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/" override="true" />
</Context>

Dans le répertoire pointé par solr.solr.home, on place de féchier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="core0" instanceDir="core0" />
        <core name="core1" instanceDir="core1" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr des cores 0 et 1 sont :

Comment gérer plusieurs applications ?

Imaginons que vous souhaitez indexer des données issues de différentes applications, pour l’exemple, un outil de gestion de contenu (ECM) et un forum de discussion. Chacune de ces applications nécessitant l’indexation de 2 types de données totalement différentes, pour l’exemple, des utilisateurs et des documents (ECM) ou des messages (forum).

Dans ce cas, je propose d’utiliser une webapp par application et un core par type de données.

On a donc un environnement comme celui-ci :

solr.solr.home=/opt/solr

Les répertoires d’installation sont organisés comme ceci :

/opt

    /solr
        /ecm
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /documents
                /bin
                /conf
                /data
        /forum
            solr.xml
            /utilisateurs
                /bin
                /conf
                /data
            /messages
                /bin
                /conf
                /data
        /webapps
            solr.war

Pour un paramétrage de Tomcat au moyen de JNDI, on place dans le répertoire conf/Calalina/localhost de Tomcat, le fichier ecm.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/ecm" override="true" />
</Context>

et le fichier forum.xml suivant :

<Context docBase="/opt/solr/webapps/solr.war" debug="0" crossContext="true" >
    <Environment
        name="solr/home"
        type="java.lang.String"
        value="/opt/solr/forum" override="true" />
</Context>

Dans le répertoire « /opt/solr/ecm », on place de fichier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="documents" instanceDir="documents" />
    </cores>
</solr>

Dans le répertoire « /opt/solr/forum », on place de fichier solr.xml suivant :

<solr persistent="true" sharedLib="lib">
    <cores adminPath="/admin/cores">
        <core name="utilisateurs" instanceDir="utilisateurs" />
        <core name="messages" instanceDir="messages" />
    </cores>
</solr>

Les urls d’accès à l’administration et aux web service Solr de l’application ECM sont :

Les urls d’accès à l’administration et aux web service Solr de l’application Forum sont :

Sous Linux, une optimisation peut être de factoriser le répertoire « bin » de chaque core car il contient exactement les mêmes scripts. On place un répertoire « bin » dans « /opt/solr » et dans chaque core, on créer un lien symbolique nommé « bin » et qui pointe sur « /opt/solr/bin ».

Pour synthétiser les différents cas de figure lors du choix d’une configuration de Solr, voici un tableau récapitulatif.

Suite au premier article Présentation de Lucene Solr, voici un article sur la mise en oeuvre de ce moteur de recherche. Les différents sujets abordés seront :

• L’installation
• La configuration
• L’indexation
• La recherche

Cette première partie a pour but l’installation et la configuration minimum afin de pouvoir rechercher dans les documents d’exemple fournis dans la distribution de Solr.

Pré-requis

• Installer Java 1.6 update 11 ou supérieur. Pour récupérer Java SE, c’est ici.
• Installer Tomcat. Pour récupérer Tomcat 5.5, c’est ici.
• Récupérer une distribution de Solr. C’est ici pour la version officielle et ici et pour les derniers builds nocturnes.

Installation

Décompresser l’archive dans un répertoire de travail. Pour cet article, il s’agit de « d:\solr ». Un sous-répertoire est créé. Selon la version de Solr que vous aurez récupéré, ce répertoire peut s’appeller « apache-solr-nightly » ou « apache-solr-1.4.0″. Je suggère donc pour simplifier de renommer ce répertoire en « apache-solr ».

Configurer Solr pour un fonctionnement avec Jetty

Pour faire fonctionner avec la version de Jetty fournie avec Solr, il n’y a pas vraiment de configuration. Pour démarrer Jetty, il faut ouvrir une console et se placer dans le répertoire « d:\solr\apache-solr\example » et exécuter la commande suivante :

java -jar start.jar

Une fois que vous voyer apparaître la ligne suivante, le serveur est démarré :

INFO: [] Registered new searcher Searcher@d642fd main

On accède alors à l’administration de Solr avec l’url suivante :

http://localhost:8983/solr/admin

Pour une utilisation avec une instance existante de Jetty, la page du wiki qui explique la configuration est ici.

Configurer Solr pour un fonctionnement sous Tomcat 5.5

1. Afin de pouvoir passer en mode HTTP-GET des critères de recherche utilisant des caractères internationaux (code supérieur à 127) il est nécessaire d’éditer le fichier conf/server.xml de Tomcat et d’ajouter l’attribut suivant à l’élément Connector approprié : URIEncoding="UTF-8".

Il s’agit à priori du connecteur correspondant au port 8080, ce qui donne quelque chose comme ceci :

<Connector port="8080" maxHttpHeaderSize="8192" maxThreads="150"
 minSpareThreads="25" maxSpareThreads="75" enableLookups="false"
 redirectPort="8443" acceptCount="100" connectionTimeout="20000"
 disableUploadTimeout="true" URIEncoding="UTF-8" />

2. Copier le fichier « d:\solr\apache-solr\example\webapps\solr.war » dans le répertoire webapps de Tomcat.

3. Au moyen de la console Tomcat (dans le system tray), ajouter le paramètre

-Dsolr.solr.home=d:\solr\apache-solr\example\solr

4. Redémarrer Tomcat.

On accède alors à l’administration de Solr avec l’url suivante :

http://localhost:8080/solr/admin

Indexer un jeu de données en exemple

La distribution de Solr inclue un jeu de documents de test pour l’indexation. Il est possible de les indexer au moyen du package java post.jar.

Ouvrir une console et se placer dans le répertoire « d:\solr\apache-solr\example\exampledocs »

Avec Jetty, lancer la commande :

java -jar post.jar *.xml

Avec Tomcat, lancer la commande :

java -Durl=http://localhost:8080/solr/update -jar post.jar *.xml

Pour obtenir la liste de toutes les options de cet utilitaire, la commande est :

java -jar post.jar -help 

Exécuter des recherches

Solr est maintenant fonctionnel et des données sont indexées. Il est donc possible d’exécuter les premières recherches avec le formulaire suivant :

http://localhost:8080/solr/admin/form.jsp

Vous pouvez constater que les résultats sont fournis au format XML. C’est effectivement à l’application appelant Solr de mettre en forme ces résultats.

Conclusion

Dans cet article, nous avons installé et fait fonctionné Solr dans un environnement Tomcat sous Windows. Par la suite j’aborderai plus en détail la configuration, les options de recherche et l’exploitation des résultats.