MySolrServer gère la mise en place et le paramétrage des instances Solr de façon transparente et ne nécessite donc pas de compétences Solr particulières. En quelques cliques de souris, une instance pré-paramétrée pour les plugins ou extensions Solr de WordPress, Joomla, eZ Publish ou Drupal est déployée et prête à l’emploi.

Pour l’utilisation avec d’autres CMS ou pour des besoins très spécifiques, il est possible de créée une instance de type API (ou plutôt RESTful).

L’utilisateur garde le contrôle total des fichiers de paramétrages Solr (synonymes, mots vides, …) au moyen d’une interface Web d’administration (le manager).

Cerise sur le gâteau, MySolrServer propose des instances de type Crawler afin d’indexer des sites web et disposer d’une interface de recherche complète. MySolrServer utilise le crawler Crawl Anywhere.

Si vous souhaitez en savoir plus sur  MySolrServer, vous pouvez consulter la liste des fonctionnalites.

Si vous souhaitez voir des copies d’écran de l’interface web d’administration, vous pouvez consulter la documentation.

MySolrServer est actuellement en mode bêta avec quelques conditions d’utilisation temporaires durant cette période.

Après plusieurs mises en production chez des clients et les différents retours d'expériences, un certain nombre de nouvelles fonctionnalités ont été ajoutées à Crawl Anywhere. Une liste des principales nouvelles fonctionnalités est disponible sur le wiki dans la release note.

Un bon rappel des concepts de base.

[slideshare id=5658889&doc=zendconsolrphp-101103144414-phpapp02]

Lucene se distingue dans tous les domaines sauf celui d'indexer une collection de document de 10 Go. Au vu des progrès réalisés par Lucene ces dernières années, je pense que la version actuelle n'aurait aucun problème.
 

Il existe actuellement 2 versions en cours de développement : Solr 3.1 et Solr 4.0. Ma compréhension est que :

• Solr 3.1 est une version plutôt stable qui devrait la prochaine version de Solr et embarquent Lucene 3.1. Sortie possible : mars ou avril 2011.
• Solr 4.0 est la version de développement (trunk) moins stable et dont le disponibilité dervait être pour 2012.

Pour une explication sur ces 2 versions des sources de Solr, lire ce message de Uwe Schindler : Lucene 3.x branch created et cette discussion : Solr 3.1

Solr 3.1

Créer un répertoire de travail :

mkdir ~/solr-3.1

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

cd ~/solr-3.1
svn co http://svn.apache.org/repos/asf/lucene/dev/branches/branch_3x

Compiler les sources :

cd ~/solr-3.1/branch_3x/lucene
ant dist
cd ~/solr-3.1/branch_3x/solr
ant dist

La javadoc est disponible ici : https://hudson.apache.org/hudson/job/Lucene-3.x/javadoc/all/index.html

Solr 4.0

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 co http://svn.apache.org/repos/asf/lucene/dev/trunk

Compiler les sources :

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

La javadoc est disponible ici : https://hudson.apache.org/hudson/job/Lucene-trunk/javadoc/all/index.html

Note du 2/11/2011 :

Le meilleur endroit pour récupérer les builds nocturnes ainsi que les liens vers les javadoc est : http://wiki.apache.org/solr/NightlyBuilds

Si un crawler web avec une vrai interface d'administration vous intéresse, je vous invite à lire ou relire l'article que j'ai écris il y a quelques mois : "Crawl Anywhere : un crawler Web pour Solr" et à aller sur www.crawl-anywhere.com.

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.

• Nutch (bien que faisant partie de la famille Lucene) ne semble de pas être un projet très actif et son intégration à Solr est peu aisée malgré quelques efforts récents.
• Apache Droids semblait prometteur, mais lui non plus n'est plus actif depuis plus d'un an.
• Heritrix est de loin de plus poussé de ces 3 crawlers et est un projet actif.

Heritrix semblait être le bon choix, mais entre autres lacunes, il ne possède pas d'interface Web d'administration et de monitoring "user friendly". Ce point étant crucial dans le cadre du projet Hurisearch, nous avons décidé de développer notre propre crawler Web que nous avons baptisé : "Crawl Anywhere". Ce nom peut paraitre prétentieux, mais pouvoir crawler tous types de sources est un réel objectif. De plus, trouver un nom disponible et encore plus un nom de domaine n'est pas chose aisé.

Voici donc un résumé de ce que permet Crawl Anywhere :

• crawler tous types de sources : web, bases de données, systèmes de fichiers, CMS, …
  Chaque type de source est géré par un connecteur (source connector)
• permet n'importe quelles actions avec les éléments crawlés : page web, document ou dossier d'un CMS, enregistrement d'une base de données, …
  Les éléments crawlés sont envoyés à un gestionnaire de documents (document handler). Pour une indexation par Solr, nous utilisons le "Solr document handler"
• peut crawler plusieurs sources et éléments par source en même temps
• est hautement configurable :
  - nombre de sources crawlées simultanément
  - nombre d'éléments par source crawlés simultanément
  - fréquence de recrawle en fonction du type d'élément
  - règles d'inclusion et d'exclusion en fonction du type d'élément
  - règles d'inclusion et d'exclusion en fonction du chemin
  - profondeur
  - …
• est capable d'extraire le texte des éléments crawlés pour une grande variété de types mime. Pour cela, la librairie Tika (http://lucene.apache.org/tika/) et d'autres outils sont utilisés.
• supporte le format Flash
• fournit une interface Web d'administration et de monitoring (voir les copies d'écran)
• est ouvert (au moyen des connecteurs et des gestionnaires de documents)

Crawl Anywhere est écrit en Java et est donc compatible Windows et Linux.

Une base de données MySQL est utilisée afin de mémoriser la référence de chaque élément crawlé (statut, date de dernier crawl, date de prochain crawl, type mime, …).

L'interface d'administration et de monitoring permet de suivre le travail du crawler ainsi que la gestion des différentes sources. Voici quelques copies d'écran de cette interface.

Monitoring du crawler :

Liste des sources :

Détails d'une source :

Pour Hurisearch, Crawl Anywhere crawle 5400 sites Web sites qui représentent plus de 10 millions de pages indexées pas Solr. L'ensemble des sources peut être crawlé et indexé en 3 jours avec un serveur Linux Debian non dédié (Intel Core2Duo 2x 2.66+ GH équipé de 4 Go de Ram).

Si vous êtes intéressé par un crawler tel que Crawl Anywhere n'hésitez pas à nous contacter au moyen de ce formulaire.

* 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.x.

* sous mac os, 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« .

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 » 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 :

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 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 :

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.