II. Fonctionnement de Solr▲
II-A. Le concept▲
Un noyau (core en anglais) Solr est décrit par un schéma (schema.xml) et un fichier de configuration (solrconfig.xml). Le fichier schema.xml définit les types et les champs de données, tandis que le fichier solrconfig.xml définit les manières d’utiliser ce schéma (c’est-à -dire l’API du noyau). Nous détaillerons plus loin ces deux fichiers.
Chaque schéma est prévu pour enregistrer un ensemble de documents. Chaque document est un ensemble de champs à valeur unique ou à valeurs multiples. En effet, un champ peut avoir plusieurs valeurs si son attribut multiValued a la valeur true. À noter qu’un index Solr (c’est-à -dire un couple schema.xml + solrconfig.xml) est orienté vers un unique format de document. Si on définit un schéma pour le document « produit », il ne convient pas d’y enregistrer également des documents « fournisseur ». Pour cela, il faudra prévoir un deuxième index.
Un schéma est prévu pour retrouver un document à partir de diverses informations. Il est fréquent de dupliquer les informations texte secondaires dans chaque document, contrairement aux habitudes des bases relationnelles d’utiliser des clefs étrangères. Par exemple, le nom du fournisseur et celui de chaque client est recopié dans chaque document « produit » afin de pouvoir retrouver un produit grâce à ces noms. En revanche, un index Solr n’est pas prévu pour retrouver les informations dont un document dépend ; par exemple, à partir d’un document « produit », il n’est pas aisé de demander à Solr de renvoyer une liste structurée de clients.
Préparer un noyau Solr nécessite une configuration assez lourde, très orientée vers la méthodologie empirique. D’après mes essais, il est en revanche assez aisé de construire un document à partir de données SQL (c’est une forme de dé normalisation). J’insiste sur un point : vous ne pourrez pas produire un schéma efficace si vous n’effectuez pas dessus un grand nombre de tests et si vous ne le faites pas évoluer en fonction de la manière dont il est effectivement utilisé.
Le schéma définit obligatoirement un champ qui sert d’identifiant unique aux documents : uniqueKey.
Deux termes seront utilisés tour à tour dans cet article : « index » et « noyau ». Pour un noyau simple, ces deux termes désignent sensiblement la même chose, mais ils s’appliquent à des contextes sémantiques différents : tandis que le terme noyau désigne l’ensemble configuration + données, index désigne uniquement les données contenues dans le noyau. Pour être précis, nous verrons plus loin qu’il peut y avoir plusieurs « index » par « noyau » ; cependant, par souci de simplicité ou par abus de langage, un mot est souvent employé pour l’autre.
II-B. Serveur hôte (Tomcat)▲
Je ne m’étendrai pas sur le principe fondamental des serveurs Web. Un guide rapide d’installation de Tomcat est présenté au chapitre suivant.
Par défaut, Tomcat utilise le port 8080 en HTTP, c’est donc celui que nous utiliserons tout au long de cet article. Dans le vocabulaire de Tomcat, Solr est une « webapp ». Par souci de simplicité pour cet article, la webapp s’appelle « solr » à la racine du serveur. L’URL de Solr est ainsi :
http://localhost:8080/solr/, ce qui vous laisse l’opportunité d’installer d’autres applications à côté de Solr sur votre Tomcat. Et, croyez-moi, vous en aurez envie tôt ou tard.
La variable « solr/home » dans Tomcat fait référence au répertoire contenant :
- le fichier WAR de Solr (c’est la webapp à proprement parler), qui par défaut s’appelle « apache-solr-3.3.0.war » ;
- le fichier « solr.xml » de configuration de notre webapp ;
- un répertoire « cores » contenant la configuration et les données de nos divers index (ce nom de dossier est arbitraire, il est défini dans le fichier solr.xml que nous détaillerons dans le chapitre d’installation du serveur).
Si nous avons trois index « cores/produits », « cores/fournisseurs » et « cores/clients », nous obtenons les URL : http://localhost:8080/solr/produits/, http://localhost:8080/solr/fournisseurs/ et http://localhost:8080/solr/clients/.
Par la suite, j’utiliserai l’URL http://localhost:8080/solr/CORENAME/ pour évoquer la racine de votre index Solr.
II-C. Manipulation d’un index▲
Il existe différents handlers (SolrRequestHandler) pour prendre en charge une requête dans Solr.
Voici les plus importants dans cet article :
- XmlUpdateRequestHandler : Modifier l’index à partir de commandes et de documents formatés en XML ;
- SearchHandler : Rechercher dans l’index (anciennement StandardRequestHandler, mais, depuis Solr 1.3, les deux classes sont identiques).
II-C-1. Consultation▲
Un index Solr s’interroge par l’URL http://localhost:8080/solr/CORENAME/select?q=MOTS+RECHERCHÉS appelée avec la méthode HTTP GET.
La syntaxe d’interrogation, à savoir ici le contenu du paramètre « q », est une extension de celle de Lucene avec quelques différences. SearchHandler peut utiliser un ou plusieurs composants (SearchComponents) qui permettent d’en étendre les fonctionnalités. Chacun d’eux ajoute divers paramètres à ceux de SearchHandler. Voici les composants les plus courants :
|
Nom de classe Java |
Nom dans le XML |
Description |
|---|---|---|
|
QueryComponent |
query |
Paramètres de recherche |
|
FacetComponent |
facet |
Catégoriser et filtrer les résultats de recherche |
|
MoreLikeThisComponent |
mlt |
Proposer des documents similaires aux résultats de recherche |
|
StatsComponent |
stats |
Statistiques sur les champs numériques des résultats de recherche |
|
DebugComponent |
debug |
Outils pour déboguer les résultats de recherche |
À titre d’exemple, voici les paramètres les plus utiles pour un SearchHandler avec un QueryComponent :
- q : chaîne recherchée
- q.op : opérateur par défaut (« AND » ou « OR »)
- df : champ de recherche utilisé s’il n’est pas précisé dans « q » (default field)
- version : le jeu de résultats aura la structure dictée par ce numéro (évite qu’une mise à jour du WAR ne change la structure des résultats de recherche)
- start : les résultats sont renvoyés à partir de ce décalage numérique (offset)
- rows : le nombre maximum de résultats à renvoyer
- fl : la liste des champs à renvoyer pour chaque résultat (field list)
Puisque les requêtes sont écrites dans des URL, les valeurs ainsi que les opérateurs Solr doivent être échappés. Par exemple, le signe + utilisé dans des calculs sur un champ date doit être encodé en %2B. Votre langage de programmation dispose sans doute de fonctions pour vous y aider.
II-C-2. Maintenance▲
Un index Solr est maintenu par l’envoi de commandes XML avec la méthode HTTP POST à l’URL http://localhost:8080/solr/CORENAME/update
Ces commandes dépendent du nœud XML de premier niveau (« add » ou « delete ») :
- <add><doc>...</doc></add> : Ajouter ou modifier un document ;
- <delete><query>...</query></delete> : Supprimer un groupe de documents correspondant à une requête Solr ;
- <commit/> : Valider les dernières modifications ;
- <optimize/> : Valider les dernières modifications et opérer certaines optimisations ;
- <rollback/> : Annuler les dernières modifications.
Pour ceux qui connaissent CRUD, la commande XML update permet d’effectuer toutes les opérations de mise à jour de l’index : Create, Update et Delete. En particulier, la commande add indique à Solr que ce document doit être indexé. S’il existe déjà , il est mis à jour ; sinon, il est créé.
Solr répond toujours par un code HTTP adéquat. Par exemple, si la mise à jour a réussi, Solr renvoie un code 200. En revanche, si la mise à jour a échoué, Solr renvoie un code 500 en cas de problème de configuration du serveur, ou 400 si le document envoyé en POST n’est pas correct. Cela permet d’identifier facilement si la mise à jour doit être suivie d’une commande pour valider ou pour annuler les dernières modifications.
Si votre noyau contient plusieurs index, la maintenance s’effectue uniquement sur l’index de données. Les autres index se mettent à jour automatiquement d’après les règles définies dans la configuration du noyau.
II-C-3. Administration▲
Chaque noyau Solr dispose d’une interface minimaliste d’administration. Attention, elle ne permet pas de modifier le schéma, la configuration ou le contenu, mais d’en consulter les valeurs de configuration. Elle permet également d’effectuer des requêtes de sélection simples ou avancées, ou encore d’analyser le comportement de tel champ ou de telle requête. Cette interface est accessible à l’URL : http://localhost:8080/solr/CORENAME/admin/
Il existe plusieurs URL utiles dans l’admin :
- http://localhost:8080/solr/CORENAME/admin/file : les fichiers du dossier « conf » de ce noyau ;
- http://localhost:8080/solr/CORENAME/admin/luke : quelques statistiques sur ce noyau (Lucene Index Toolbox) ;
- http://localhost:8080/solr/CORENAME/admin/ping : déterminer si ce noyau est en ligne ;
- http://localhost:8080/solr/CORENAME/admin/plugins : informations sur les plugins chargés pour ce noyau ;
- http://localhost:8080/solr/CORENAME/admin/properties : lire quelques statistiques sur ce noyau ;
- http://localhost:8080/solr/CORENAME/admin/system : informations système relatives à ce noyau ;
- http://localhost:8080/solr/CORENAME/admin/threads : les threads lancés par Tomcat pour ce noyau ;
Si vous souhaitez construire un tableau de bord et qu’appeler toutes ces URL à la suite vous pose problème, rappelez-vous que l’URL suivante est elle-même au format XML : http://localhost:8080/solr/CORENAME/admin/stats.jsp. Votre navigateur utilise une feuille de style XSL pour afficher quelque chose de présentable et lisible, mais il s’agit bien d’un document au format XML (et donc lisible par programmation).
Le composant CoreAdminWiki Solr : Core Administration, accessible à l’adresse http://localhost:8080/solr/admin/cores, est également une source d’informations synthétiques sur un ou plusieurs noyaux. Ce composant est activé par le fichier de configuration de la webapp Solr que nous verrons au chapitre III-C-3. Il accepte le paramètre « wt » que nous allons voir ci-dessous.
Pour suivre cet article, vous allez avoir besoin de modifier fréquemment la configuration des noyaux. Plutôt que de redémarrer Tomcat pour valider ces modifications, je vous recommande d’utiliser l’action « RELOAD » du composant CoreAdmin : http://localhost:8080/solr/admin/cores?core=CORENAME&action=reload
II-D. Format de la réponse▲
Solr construit habituellement les réponses HTTP au format XML. Cependant, il est possible de spécifier un format de sortie alternatif à l’aide du paramètre « wt ».
Exemples :
- objets JavaScript : http://localhost:8080/solr/CORENAME/admin/ping?wt=json ;
- array PHP sérialisé : http://localhost:8080/solr/CORENAME/admin/ping?wt=phps ;
- javabin (utilisé par Solr lui-même pour la réplication) : http://localhost:8080/solr/CORENAME/admin/ping?wt=javabin ;
- etc.
La liste des formats par défaut est ici : http://wiki.apache.org/solr/QueryResponseWriter#List_of_Writers_AvailableSolr: List of Writers Available