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.

Voici quelques commandes simples et bien utiles utilisant curl afin de manipuler un index Solr.

• Supprimer un document à partir de sa valeur de clé unique
• Supprimer un document à partir d'une requête
• Vider totalement un index
• Forcer un commit d'un index
• Forcer un optimize d'un index

Supprimer un document à partir de sa valeur de clé unique :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><id>SP2514N</id></delete>"

Supprimer un document à partir d'une requête :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><query>type:book</query></delete>"

Vider totalement un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<delete><query>*:*</query></delete>"

Forcer un commit d'un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<commit/>"

Forcer un optimize d'un index :

curl "http://server:port/solrpath/solrcore/update" -H "Content-Type: text/xml" --data-binary "<optimize/>"

Pour plus d'exemples, vous pouvez consulter cette page du Wiki Solr : http://wiki.apache.org/solr/UpdateXmlMessages

Voici la méthode pour intégrer le patch suivant : https://issues.apache.org/jira/browse/SOLR-785

• Commencer par récupérer une distribution des sources de Solr (http://www.apache.org/dyn/closer.cgi/lucene/solr/).
• Décompresser l'archive dans un répertoire. Pour l'exemple on utilise /tmp, ce qui donne un répertoire /tmp/apache-solr-1.4.1
• Dans /tmp/apache-solr-1.4.1, placer le fichier correspondant au patch (pour le patch SOLR-785, c'est SOLR-785.patch)
• Patcher
  cd /tmp/apache-solr-1.4.1
patch -p0 -i SOLR-785.patch
• Recompiler
  ant clean
ant dist

Le war compilé est dans le répertoire dist

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.

Cependant, cette méthode n’est pas fiable à 100% et NgramJ est limitée dans sa version actuelle à 26 langues détectables : Bulgare (bg), Tchèque (cz), Danois (da), Allemand (de), Grec (el), Anglais (en) Espagnol (es), Estonien (et), Finlandais (fi), Français (fr), Hongrois (hu), Islandais (is), Italien (it), Lituanien (lt), Letton (lv), Maltais (mt) , Néerlandais (nl), Norvégien (no), Polonais (pl), Portugais (pt), Roumain (ro), Russe (ru) , Slovaque (sk), Slovène (sl), Suédois (sv) et Thaï (th).

Je voudrais proposer 2 pistes pour améliorer NGramJ : la fiabilité de la détection et le nombre de langues détectables.

La fiabilité de la détection

NgramJ utilise un algorithme complexe de calcul statistique sur les n-grams et je n’ai pas la prétention de l’améliorer. Par contre, on peut facilement fournir des informations complémentaire à NGramJ afin qu’il oriente sa détection sur un sous-ensemble restreint de langues et non pas sur toutes les langues qu’il gère (surtout si on veut en augmenter le nombre).

Que connait-on du texte que l’on veut analyser ? On connait l’encodage de ses caractères (iso-8859-1, iso-8859-5, windows-1252, … et souvent unicode ou utf-8). Chacun de ces jeux de caractères permet d’écrire un ensemble plus ou moins important de langues (voir Character encoding). Unicode est particulier car il permet de coder toutes les langues, par contre une ou plusieurs langues partagent un sous ensemble d’unicode qu’il est facile d’identifier (voir Unicode 5.2 Character Code Charts). On peut donc pour un texte donné se limiter à la détection des langues couvertes par le sous ensemble unicode qu’il utilise.

Par exemple, pour un texte codé en iso-8859-5 (caractères cyrilliques) les langues possibles sont : Bulgare (bg), Biélorusse (be), Macédonien (mk), Russe (ru), Serbe (sr) et Ukrainien (uk). La seule langue que devrait donc nous proposer NGramJ si on lui demande de se retreindre à ces langes est le Russe. Ce n’est pas satisfaisant. En effet, je ne veux pas que NgramJ me dise qu’un texte Bulgare est du Russe. Plus loin dans cet article, on verra comment « appendre » de nouvelles langues à NgramJ.

Encore mieux, on peut sans même le demander à NgramJ connaitre la langue d’une texte. En effet, certains jeux de caractères permettent de coder une seule langue : iso-8859-15 (Estonien), iso-8859-9 (Turc), iso-8859-7 (Grec), …

En conclusion, même si on parvient à apprendre à NgramJ la totalité des langues existantes (et pourquoi pas), on pourra toujours lui indiquer de travailler sur un sous-ensemble réduit de deux à une dizaine de langues en fonction de l’encodage du texte.

Un point auquel il faut porter attention est qu’un même jeux de caractères peut avoir plusieurs noms voisins. On trouve sur le site de l’INIA, l’ensemble des jeux de caractères avec leur nom préféré et leurs alias.

Pour traiter cet aspect préliminaire à l’utilisation de NGramJ, j’ai développé une classe utilitaire CharsetLanguages qui permet de :

• Obtenir le nom préféré d’un jeux de caractères.
• Obtenir les blocs unicode utilisé pour l’écriture d’un texte
• Obtenir les langues associées à un jeu de caractères
• Obtenir les langues associées aux blocs unicode détectés dans un texte

Pour simplifier l’utilisation de NgramJ, j’ai également développé une classe LanguageRecognizerCngram qui permet de :

• Initialiser un contexte de détection en spécifiant le répertoire ou sont les fichiers de définitions des langues (fichiers modèles) et la liste des langues que l’on veut pouvoir détecter (si on sait à l’avance que les documents que l’on va traiter se limitent à ces langues)
• lancer la reconnaissance d’une langue dans un texte

Le code source de ces classes est fournie sous la forme d’un projet Eclipse. je fournie également la version compilée de NGramJ modifié. Ces modifications ont été transmises à l’auteur qui s’est proposé de les intégrer à la version officielle.

Voici un exemple de code pour l’utilisation de ces classes :

public static String getLanguage (String content, String charSet)
{
 
String language = null;
 
// Define the maximum length for the text to be analyzed
int languageDetectionLength = 2048;
 
// Define a list of candidate languages for the text
String languageDetectionList = "bg, ru, sr, uk";
 
content = content.substring(0, Math.min(content.length(), languageDetectionLength));
 
// Create the language detector
LanguageRecognizerCngram lrCnGram = new LanguageRecognizerCngram();
if (lrCnGram!=null)
{
    // Set the directory for the language models
    lrCnGram.setLanguageModelsDir("/Data/ngramj/ngp/ngp");
    if (languageDetectionList!=null && !"".equals(languageDetectionList))
    {
        // Create a list for the candidate languages
        String[] tab = languageDetectionList.split(",");
        ArrayList<String> arr = new ArrayList<String>(Arrays.asList(tab));
        for (int i=0;i<arr.size();i++) {
           arr.set(i, arr.get(i).trim());
        }
 
        // Set the candidate languages
        lrCnGram.setCandidateLanguages(arr);
    }
    else
    {
        // Try to get a candidate languages list according to the charset
        ArrayList<String> charSetCanditateLanguages;
        CharsetLanguages csu = new CharsetLanguages();
 
        if (charSet == null || "".equals(charSet))
            charSet ="utf-8";
        else
            charSet = csu.getCharsetCanonicalName(charSet);
 
        if ("utf-8".equals(charSet))
        {
            String s = csu.getUnicodeBlockDistribution (content);
            charSetCanditateLanguages = csu.getUnicodeBlockLanguages(s);
        }
        else
        {
            charSetCanditateLanguages = csu.getCharsetLanguages(charSet);
        }
 
        // Only one possible language so nothing else to do
        if (charSetCanditateLanguages!=null && charSetCanditateLanguages.size()==1)
            return charSetCanditateLanguages.get(0);
 
        // Set the candidate languages
        lrCnGram.setCandidateLanguages(charSetCanditateLanguages);
    }
 
    // Process the recognition
    language = lrCnGram.RecognizeLanguage( content, 0.5, null);
    return language;
}

Ajouter des langues à la liste de celles détectables par NGramJ

Pour ce travail, je me suis inspiré de l’article suivant « Generating a Plain Text Corpus from Wikipedia« .

Pour ajouter une nouvelle langue, les étapes sont :

• Récupérer un corpus significatif de texte écrit dans cette langue
• Nettoyer le texte
• Créer le fichier modèle avec NGramJ

Obtenir un corpus

Pour obtenir un corpus dans une langue donnée, il est possible de télécharger la totalité des articles de wikipedia dans cette langue. L’adresse dépend du code ISO de la langue :

http://download.wikimedia.org/<code iso>wiki/latest/<code iso>wiki-latest-pages-articles.xml.bz2

Par exemple, pour l’arabe, on récupère une archive et on la décompresse comme ceci :

curl -O http://download.wikimedia.org/arwiki/latest/arwiki-latest-pages-articles.xml.bz2
bunzip2 arwiki-latest-pages-articles.xml.bz2

Nettoyer le corpus

Pour nettoyer le fichier xml, je me suis inspiré de ce script.

Ma version est plus violent mais ne supprime pas ce qui n’est pas iso-8859-1.

wikicat2.sh :

#!/bin/sh
# http://wiki.apertium.org/wiki/Talk:Calculating_coverage#wikicat2.sh
# clean up wiki for running through apertium-destxt
# Use $ ./wikicat2.sh blah-pages-articles.xml.bz2
 
# awk prints full lines, make sure each html element has one
#bzcat "$@" | sed 's/&gt;/&gt;n/g' | sed 's/<!--n</g' |
cat "$@" | sed 's/-->/&gt;n/g' | sed 's/<!--n</g' |
# want only stuff between <text...--> and
awk '
//,/&lt;/text&gt;/ { print $0 }
' |
 
sed 's/[[([a-z]{2,3}):[^]]+]]//g' |
# Drop all transwiki links
 
sed 's/[[[^]|]*|//g' | sed 's/]]//g' | sed 's/[[//g' |
# wiki markup, retain bar and fie from [[foo|bar]] [[fie]]
 
sed 's/[http[^ ]*([^]]*)]/1/g' |
# wiki markup, retain `bar fie' from [http://foo bar fie]
 
sed 's/&amp;.*;/ /g' |
# remove entities greedily, so as to get rid of hidden html too
 
# Keep only lines starting with a capital letter, removing tables with style info etc.
# grep '^[ t]*[A-ZÆØÅ]' # Your alphabet here
grep -vE '^([|{=}!]|[a-z]{2,3}:)' |
 
# some other cleanup
grep -vE '^([a-z]{1,4}-[a-z]{1,4}:)' |
grep -vE '^([a-z]{1,4}-[a-z]{1,4}-[a-z]{1,4}:)' |
grep -vE '^s*[a-z]{0,2}s*$' |
grep -vE '^s*$' |
grep -vE "([|]|'{3})" |
 
# keep a raisonnable corpus size
head -n 2000

Et donc, pour générer un fichier nettoyé la commande est :

wikicat2.sh arwiki-latest-pages-articles.xml >ar.txt

Ce script peut être à améliorer en fonction de résultat obtenu. Quoi qu’il en soit, il faut tout faire pour nettoyer au mieux le texte et même terminer le travail à la main si nécessaire.

Créer le fichier model

Le fichier modèle est généré à partir du texte nettoyé avec la commande suivante :

java -jar cngram.jar -create ar ar.txt "UTF-8"

On peut enchainer automatiquement toutes ces taches en prenant soin de ne télécharger le corpus de wikipedia que si on ne l’a pas déjà. Voici comment préparer un environnement de travail et un script shell qui va enchainer toutes les opérations automatiquement pour une liste de langues.

1. dans un répertoire, on place cngram.jar et wikicat2.sh.

2. on y créer buildngp.sh

#!/bin/bash
 
mkdir data > /dev/null 2>&1
cd  data
mkdir ngp > /dev/null 2>&1
 
# for all these languages
for i in fr fa ar be mk sr uk; do
    echo $i
 
    # download file from wikipedia only if necessary
    if [ -f ${i}wiki-latest-pages-articles.xml ];
    then
        echo "${i}wiki-latest-pages-articles.xml exists in local"
    else
        # download
        curl -O http://download.wikimedia.org/${i}wiki/latest/${i}wiki-latest-pages-articles.xml.bz2
        # unzip the file
        bunzip2 ${i}wiki-latest-pages-articles.xml.bz2
    fi
 
    # cleanup the xml file to text file
    ../wikicat2.sh ${i}wiki-latest-pages-articles.xml > ${i}.txt
 
    # create cngram ngp file
    java -jar ../cngram.jar -create ${i} ${i}.txt "UTF-8"
    mv ${i}.ngp ngp/${i}.ngp
done

On lance le script ainsi en se positionnant dans le répertoire de travail :

./buildngp.sh

Les données sont téléchargées dans le sous-répertoire data et les fichiers ngp créés dans data/ngp. Dans le script, la ligne suivante permet de définir la liste des langues pour lesquels ont va générer un fichier NPG.

for i in fr fa ar be mk sr uk; do

Téléchargements

Télécharger le projet Eclipse CharsetLanguages

Télécharger les scripts de génération de fichier NGP pour NgramJ BuildNGP

Etape 1 : Récupérer les sources

Les sources sont disponibles à partir de la page http://lucene.apache.org/tika/download.html

Décompresser l’archive dans un répertoire de travail /tmp/tika-0.6

Etape 2 : Compilation.

Le moyen le plus simple est d’utiliser maven 2.

On se place dans le répertoire de travail

cd /tmp/tika-0.6

On positionne la variable d’environnement LC_ALL afin de ne pas avoir d’erreur durant la compilation (l’astuce) et on alloue par la même occasion suffisamment de mémoire de pour maven

export LC_ALL=en_US.UTF-8
export MAVEN_OPTS="-Xmx2048m"

On lance la compilation

mvn install

4 fichiers jar sont générés

find . -name *.jar -print

./tika-app/target/tika-app-0.6.jar
./tika-bundle/target/tika-bundle-0.6.jar
./tika-core/target/tika-core-0.6.jar
./tika-parsers/target/tika-parsers-0.6.jar

Pour utiliser Tika dans une application, seules les 2 jars suivants sont indispensables :

./tika-core/target/tika-core-0.6.jar
./tika-parsers/target/tika-parsers-0.6.jar

Par contre, tika-parser-0.6.jar requière un certain nombre de librairies tierces. Les récupérer est la troisième étape.

Etape 3 : Récupération des dépendances

On se place dans le répertoire des sources de tika-parser

cd tika-parsers

On demande à maven de récupérer les dépendances

mvn dependency:copy-dependencies

Les dépendances sont disponibles dans le sous-répertoire target/dependency et il s’agit de:

./target/dependency/asm-3.1.jar
./target/dependency/commons-compress-1.0.jar
./target/dependency/commons-logging-1.1.1.jar
./target/dependency/dom4j-1.6.1.jar
./target/dependency/fontbox-0.8.0-incubator.jar
./target/dependency/geronimo-stax-api_1.0_spec-1.0.1.jar
./target/dependency/hamcrest-core-1.1.jar
./target/dependency/jempbox-0.8.0-incubator.jar
./target/dependency/junit-3.8.1.jar
./target/dependency/log4j-1.2.14.jar
./target/dependency/metadata-extractor-2.4.0-beta-1.jar
./target/dependency/mockito-core-1.7.jar
./target/dependency/objenesis-1.0.jar
./target/dependency/pdfbox-0.8.0-incubating.jar
./target/dependency/poi-3.6.jar
./target/dependency/poi-ooxml-3.6.jar
./target/dependency/poi-ooxml-schemas-3.6.jar
./target/dependency/poi-scratchpad-3.6.jar
./target/dependency/tagsoup-1.2.jar
./target/dependency/xml-apis-1.0.b2.jar
./target/dependency/xmlbeans-2.3.0.jar