La recherche Full Text avec Solr

Chaque fieldType est décrit au moins par deux attributs name et class. Le premier permet de faire référence à ce type dans le reste du fichier XML ; l'autre décrit la classe Java utilisée pour construire le type en mémoire.

Les champs de notre document devront être définis soit avec un type simple, soit avec un type complexe. Les types dits "simples" sont pour des données brutes, c'est-à-dire des chaînes sans signification sémantique, des valeurs numériques ou des dates. Les types dits "complexes" sont prévus pour décomposer la valeur et pour l'analyser de manière très précise. Nous allons commencer par les types simples, que tout développeur a rencontrés maintes fois dans ses projets, puis nous verrons les types complexes, qui constituent la majorité de la valeur ajoutée de Solr.

La plupart des attributs suivants sont disponibles à la fois dans les définitions fieldType et field. L'expérience vous dira à quel endroit chaque attribut est le plus utile.

Vous trouverez ci-dessous une liste des attributs recommandés ou obligatoires pour chaque cas d'utilisation ⁽¹⁾. Une étoile bleue (*) marque les valeurs recommandées mais non obligatoires.

Certains cas d'utilisation sont incompatibles. Il est par exemple impossible de trier les résultats sur un champ pouvant avoir plusieurs valeurs, dans la mesure où son attribut multiValued devrait avoir à la fois les valeurs true et false.

Je ne présente ci-dessus que les types utiles avec la version de Solr choisie. En effet, les versions antérieures de schema.xml avaient plusieurs versions de chaque type de base. Ces types continuent d'exister afin de permettre la compatibilité avec d'anciens schémas mais, pour un schéma nouvellement défini, ils sont obsolètes.

À titre d'exemple, voici les trois versions du type entier (int). Remarquons l'utilisation d'un préfixe selon le principe de la notation hongroiseArticle Wikipédia sur la notation hongroise (cf. notation hongroise Apps) afin de décrire le contexte de chaque type : pint, sint, tint.

Le seul avantage des types "plain" sur les autres est un gain de place pour l'index, mais ce n'est habituellement pas l'argument qui oriente le projet vers Solr ; de plus, dans la mesure où ces valeurs sont stockées telles quelles par Solr, elles ne sont pas utilisables pour des tris naturels.

Les types "sortable" sont meilleurs que les types "plain" car ils représentent les valeurs sous forme d'une chaîne, manipulée de manière à permettre les tris naturels.

Enfin, les types "trie" sont mieux optimisés que les types "sortable" pour les requêtes d'intervalles car Solr passe par des analyses et des filtres pour indexer ces valeurs (plutôt que de les représenter sous forme de texte).

Dans la mesure où nous n'avons pas besoin de conserver la compatibilité avec un ancien index, nous ne choisirons pas les types "plain" pour lesquels nous avons une alternative : un type "sortable" chaque fois que nous aurons besoin de sortMissingLast ou sortMissingFirst, ou "trie" le reste du temps. Nous allons donc ajouter les déclarations suivantes dans le nœud <types></types> de notre fichier schema.xml (ces déclarations ont peu de chances de différer d'un noyau à l'autre) :

<!-- Types de base -->
<fieldType name="string" class="solr.StrField"
    sortMissingLast="true" omitNorms="true"/>

<fieldType name="boolean" class="solr.BoolField"
    sortMissingLast="true" omitNorms="true"/>

<fieldtype name="binary" class="solr.BinaryField"/>

<fieldType name="random" class="solr.RandomSortField"
    indexed="true" />

<!-- Types numériques permettant d'utiliser sortMissingLast ou sortMissingFirst -->
<fieldType name="sint" class="solr.SortableIntField"
    sortMissingLast="true" omitNorms="true"/>

<fieldType name="sfloat" class="solr.SortableFloatField"
    sortMissingLast="true" omitNorms="true"/>

<fieldType name="slong" class="solr.SortableLongField"
    sortMissingLast="true" omitNorms="true"/>

<fieldType name="sdouble" class="solr.SortableDoubleField"
    sortMissingLast="true" omitNorms="true"/>

<!-- Types numériques optimisés pour les requêtes par intervalles -->
<fieldType name="tint" class="solr.TrieIntField"
    precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

<fieldType name="tfloat" class="solr.TrieFloatField"
    precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

<fieldType name="tlong" class="solr.TrieLongField"
    precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

<fieldType name="tdouble" class="solr.TrieDoubleField"
    precisionStep="8" omitNorms="true" positionIncrementGap="0"/>

<fieldType name="tdate" class="solr.TrieDateField"
    precisionStep="6" omitNorms="true" positionIncrementGap="0"/>

Les champs de type StrField ne sont pas analysés par Solr, ils sont stockés tels quels. Aucune optimisation n'est apportée sur ces valeurs pour le tri, la recherche ou les requêtes par intervalles. Ainsi, il ne faut pas utiliser ce type de données pour les champs sur lesquels on souhaite effectuer des tris ou des recherches.

Les noms de classes commençant par "solr" sont directement liés aux classes Java du paquetage org.apache.solr.schema (même si le fichier schema.xml par défaut indique org.apache.solr.analysis : il s'agit sans doute d'une erreur). Par exemple, un type solr.StrField instancie des objets de la classe Java org.apache.solr.schema.StrFieldClass StrField. N'ayez crainte, il n'est pas nécessaire de connaître l'API Java pour configurer un noyau Solr performant. Je ne donne ce lien qu'à titre indicatif.

Il ne faut pas confondre les types de données que nous manipulons en tant qu'utilisateurs de la webapp (StrField, BoolField etc.) et la "représentation interne" que j'évoque par moments.

IV-A-1-c-i. Description d'un type complexe▲

<fieldType name="text" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.WordDelimiterFilterFactory"
            generateWordParts="1" generateNumberParts="1"
            catenateWords="1" catenateNumbers="1" catenateAll="0"
            splitOnCaseChange="1"/>
        <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
    <analyzer type="query">
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.WordDelimiterFilterFactory"
            generateWordParts="1" generateNumberParts="1"
            catenateWords="0" catenateNumbers="0" catenateAll="0"
            splitOnCaseChange="1"/>
        <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
</fieldType>

IV-A-1-c-ii. Filtrer les caractères : les CharFilterFactories▲

# Syntaxe (la source ne peut pas être vide, la cible peut être vide) :
#   "source" => "cible"

# Exemples :
#   "À" => "A"
#   "\u00C0" => "A"
#   "\u00C0" => "\u0041"
#   "ß" => "ss"
#   "\t" => " "
#   "\n" => ""

<charFilter class="solr.HTMLStripCharFilterFactory"/>

IV-A-1-c-iii. Décomposer la chaîne : les TokenizerFactories▲

<tokenizer class="solr.StandardTokenizerFactory"/>

IV-A-1-c-iv. Manipuler les termes : les TokenFilterFactories▲

# Les lignes vides et les lignes commençant par dièse sont des commentaires
# Les séquences équivalentes de termes sont séparées par des virgules

# Les règles explicites prennent chaque séquence de termes du côté gauche de "=>"
# et les remplacent par chacune des alternatives du côté droit
# Ces types de règles ignorent le paramètre "expand" du schéma
# Exemples :
i-pod, i pod => ipod
sea biscuit, sea biscit => seabiscuit

# Les règles implicites ne prennent pas de "=>"
# En ce cas, le comportement est défini par le paramètre "expand" du schéma
# Cela permet d'utiliser le même fichier de synonymes pour différentes stratégies
# Exemples :
ipod, i-pod, i pod
foozball, foosball
universe, cosmos

# Si "expand" est à VRAI, alors la règle "ipod, i-pod, i pod" est équivalente à :
ipod, i-pod, i pod => ipod, i-pod, i pod
# Si "expand" est à FAUX, alors la règle "ipod, i-pod, i pod" est équivalente à :
ipod, i-pod, i pod => ipod

# Les règles multiples sont combinées
# Exemple :
foo => foo bar
foo => baz
# Devient :
foo => foo bar, baz

<filter class="solr.SnowballPorterFilterFactory" language="French"/>
<filter class="solr.RemoveDuplicatesTokenFilterFactory"/>

Ne prenez l'exemple ci-dessous qu'à des fins d'étude, ne l'utilisez pas tel quel dans votre application finale.

• Affichage : le seul traitement effectué sur la chaîne est un nettoyage cosmétique, ce type est donc adapté pour toutes les langues ;
• Auto complétion : les seuls traitements effectués sur la chaîne sont un nettoyage cosmétique et une segmentation en "n-grams", ce type est donc adapté pour toutes les langues ;
• Recherche en anglais : optimisation (index + requêtes) pour la recherche en langue anglaise ;
• Recherche en français : optimisation (index + requêtes) pour la recherche en langue française.

Cela se traduit par le nœud XML types suivant :

<!-- Type texte pour l'affichage : très peu de traitements -->
<fieldType name="rawText" class="solr.TextField">
    <analyzer>
        <charFilter class="solr.HTMLStripCharFilterFactory"/>
        <tokenizer class="solr.KeywordTokenizerFactory"/>
    </analyzer>
</fieldType>

<!-- Type texte pour l'auto complétion -->
<!-- Le filtre EdgeNGram n'est adapté qu'à l'analyzer "index" -->
<fieldType name="grammedText" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
        <charFilter class="solr.HTMLStripCharFilterFactory"/>
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.ASCIIFoldingFilterFactory"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.EdgeNGramFilterFactory" minGramSize="2" maxGramSize="10"/>
    </analyzer>
    <analyzer type="query">
        <charFilter class="solr.HTMLStripCharFilterFactory"/>
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.ASCIIFoldingFilterFactory"/>
        <filter class="solr.LowerCaseFilterFactory"/>
    </analyzer>
</fieldType>

<!-- Type texte pour la recherche, avec traitements spécifiques à l'anglais -->
<fieldType name="englishText" class="solr.TextField" positionIncrementGap="100">
    <analyzer>
        <charFilter class="solr.HTMLStripCharFilterFactory"/>
        <tokenizer class="solr.StandardTokenizerFactory"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.SnowballPorterFilterFactory" language="English"/>
    </analyzer>
</fieldType>

<!-- Type texte pour la recherche, avec traitements spécifiques au français -->
<fieldType name="frenchText" class="solr.TextField" positionIncrementGap="100">
    <analyzer>
        <charFilter class="solr.HTMLStripCharFilterFactory"/>
        <tokenizer class="solr.WhitespaceTokenizerFactory"/>
        <filter class="solr.LowerCaseFilterFactory"/>
        <filter class="solr.SnowballPorterFilterFactory" language="French"/>
    </analyzer>
</fieldType>

Après avoir défini les types de champs nécessaires à votre noyau, vous pouvez passer à la définition des champs utilisant ces types de données. C'est ce que nous allons voir ici.

Cette partie dépend majoritairement des besoins de votre application. Nous allons voir quelques exemples mais c'est à vous de construire les champs de données adaptés à votre cas d'utilisation.

<field name="uuid" type="string"/>

Il faut penser à créer un champ unique de type string pour chaque noyau. Pour ma part, j'utilise généralement un hash (sha1, md5 ou autre) de la clef primaire de ma table source (SQL) et j'appelle ce champ "uuid" (cela facilite les traitements avec certains plugins de Solr) :

<field name="uuid" type="string" stored="true" required="true"/>

Solr permet de copier la valeur d'un champ vers d'autres champs (nous verrons à la fin de cette section comment nous y prendre). Cela permet de faciliter l'import de données vers Solr puisqu'un <doc> contient les informations extraites directement de la source de données (par exemple votre base de données) sans se soucier de combien de variantes de chaque valeur le noyau a besoin (à l'identique, en minuscules, sans espaces, sans HTML, phonétique, etc.). Ainsi, la plupart des champs de votre schéma seront sans doute définis en plusieurs déclinaisons sans que cela ne complique d'aucune manière le procédé d'import de données vers votre noyau.

Une stratégie courante est de définir plusieurs versions de chaque champ de données : une copie exacte de l'original (dans chaque langue) et une copie supplémentaire pour chaque cas d'utilisation.

Une autre stratégie courante, et de surcroît compatible avec la précédente, est de définir un champ permettant de rassembler toutes les valeurs "texte" du document afin de faciliter les recherches.

Comme nous l'avons dit précédemment, les attributs d'un nœud field sont les mêmes que pour un nœud fieldType. C'est dû au fait que la classe Java utilisée pour instancier l'objet field est la même que celle utilisée pour instancier l'objet fieldType ; elle en prend donc les propriétés et les méthodes. C'est pour cette raison qu'il est possible de définir une surcharge pour chacun des attributs au niveau du field par rapport aux valeurs définies pour les mêmes attributs au niveau du fieldType, qui peuvent elles-mêmes surcharger les valeurs par défaut de Solr pour cette classe Java.

Les types (nœuds fieldType) montrés plus haut en exemple sont à répartir de la manière suivante dans les champs (nœuds field) de notre schéma :

Ainsi, nous pouvons effectuer nos recherches sur le champ productNameFrSearch ou productNameEnSearch suivant la langue de notre utilisateur, et afficher en réponse le nom canonique du produit (non altéré) dans la même langue. Voici les définitions de champs pour notre schéma :

<field name="uuid" type="string" stored="true" required="true"/>

<field name="productNameEnDisplay" type="rawText"/>
<field name="productNameFrDisplay" type="rawText"/>
<field name="productNameEnAutoComplete" type="grammedText"/>
<field name="productNameFrAutoComplete" type="grammedText"/>
<field name="productNameEnSearch" type="englishText"/>
<field name="productNameFrSearch" type="frenchText"/>

<!-- Un nom de constructeur n'est pas traduisible
    il n'y a donc pas de version internationalisée -->
<field name="manufacturerNameDisplay" type="rawText"/>
<field name="manufacturerNameAutoComplete" type="grammedText"/>
<!-- Un utilisateur peut cependant chercher
    un nom de constructeur dans sa langue favorite -->
<field name="manufacturerNameEnSearch" type="englishText"/>
<field name="manufacturerNameFrSearch" type="frenchText"/>

<field name="allEnAutoComplete" type="grammedText"/>
<field name="allFrAutoComplete" type="grammedText"/>
<field name="allEnSearch" type="englishText" multiValued="true"/>
<field name="allFrSearch" type="frenchText" multiValued="true"/>