A lire sur Solutions Logiciels

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é !

• 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).

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

01 Net Pro

This paper provides an overview of both the requirements and the opportunities for search applications. It then explores how real world organizations are successfully using Lucene/Solr search applications to meet those opportunities, presenting how the technology is used for specific business models and use cases across industries. In addition, it offers a baseline for setting search requirements that managers and architects can use to adopt Lucene/Solr, and adapt this open source search technology to the unique needs of their business.

• Performance
• Fonctionnalités avancées (stemming, facettes, mise en évidences des termes recherchés, …)
• Recherche déportée sur un serveur dédié

Pour ez Publish, il s’agit du plugin ez Find.

Pour Drupal, il s’agit du module apachesolr.

Pour Django, c’est Haystack.

Pour Typo3, il s’agit de l’extention Apache Solr for Typo3.

Cette adoption de Solr par ces 3 CMS majeurs confirme la puissance de ce dernier.