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 (Introduction à 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.

Client
	Des API clientes pour Java (solrj) et Ruby (solr-ruby). Il existe en fait des solutions d’intégration avec d’autres langages (Perl, PHP, Python, C#, …). Une liste est disponible ici sur le wiki de Solr.
Contrib
	Des outils qui contribuent à étendre les fonctionnalités de Solr. Dans la distribution 1.3.0, il s’agit uniquement de l’outil dataimporthandler pour l’importation et l’indexation de données issues d’une base de données. Dans les versions futures, il pourrait s’agir également d’un outil d’extraction du contenu de documents Office ou PDF (basé sur Tika), d’une intégration avec Jsdoc Toolkit et d’une intégration avec le framework Velocity.
Dist
	Les binaires issus de la compilation des sources de Solr et les librairies dont dépend Solr.
Docs
	La documentation de Solr
Example
	Des exemples de mise en oeuvre et le nécessaire pour exécuter Solr avec Jetty. Les principaux sous-répertoires sont :
	Multicore
		Exemple de paramétrage en mode multi-core afin de gérer des applications et des index multiples dans une même webapp du serveur J2EE.
	Solr
		Exemple de répertoire « Home » de Solr et fichiers de configuration par défaut.
	Webapps
		Le fichier war à déployer dans la serveur J2EE et utiliser par le lanceur jetty fourni en exemple.
Lib
	Les librairies java dont dépend Solr
Src
	Les sources de Solr

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 » sous Linux ou « c:/solr » sous 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

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.

<field name=”word” type=”string” indexed=”true” stored=”true”/>

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=”*_s”  type=”string”  indexed=”true”  stored=”true”/>

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 :

Administration	=>	http://<server>:<port>/solr/admin/
Indexation / suppression	=>	http://<server>:<port>/solr/update
Recherche	=>	http://<server>:<port>/solr/select

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 :

Administration	=>	http://<server>:<port>/solr/core0/admin/ http://<server>:<port>/solr/core1/admin/
Indexation / suppression	=>	http://<server>:<port>/solr/core0/update http://<server>:<port>/solr/core1/update
Recherche	=>	http://<server>:<port>/solr/core0/select http://<server>:<port>/solr/core1/select

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 féchier 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 féchier 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 :

Administration	=>	http://<server>:<port>/ecm/utilisteurs/admin/ http://<server>:<port>/ecm/documents/admin/
Indexation / suppression	=>	http://<server>:<port>/ecm/utilisteurs/update http://<server>:<port>/ecm/documents/update
Recherche	=>	http://<server>:<port>/ecm/utilisteurs/select http://<server>:<port>/ecm/documents/select

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

Administration	=>	http://<server>:<port>/forum/utilisteurs/admin/ http://<server>:<port>/forum/messages/admin/
Indexation / suppression	=>	http://<server>:<port>/forum/utilisteurs/update http://<server>:<port>/forum/messages/update
Recherche	=>	http://<server>:<port>/forum/utilisteurs/select http://<server>:<port>/forum/messages/select

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.

Une seule application avec un seul type de données à indexer	=>	1 webapp, pas de SolrCore
Une seule application avec plusieurs types de données très similaires. Par exemple, des articles de presse, des dossiers, des rapport, des études, … qui ont tous des meta-données communes (titre, auteur, date de publication et contenu)	=>	1 webapp, pas de SolrCore mais une donnée qualifiant le type permettant le filtrage de la liste de résultat sur une ou plusieurs de ces valeurs.
Une seule application avec plusieurs types de données sans similarité (documents, utilisateurs, …)	=>	1 webapp et des SolsCore pour indexer les différents types de données dans des index disctincts
Plusieurs applications (ECM, Forum, messagerie).	=>	1 webapp par application avec ou sans SolrCore multiple en fonction des données à indexer pour chacune des applications (voir les cas précédents)