Fichier de schéma Solr (schema.xml)

Solr organise ses données en documents, qui se composent de zones. Dans HCL Commerce, un document se compose de toutes les descriptions d'un produit.

Le fichier schema.xml contient des informations sur les zones Solr et sur la manière dont elles sont analysées et filtrées lors des recherches. Différents types de zones peuvent contenir différents types de données. Solr utilise le fichier schema.xml pour déterminer comment générer des index à partir des documents d'entrée et comment effectuer le traitement des temps d'indexation et d'interrogation.

Le fichier schema.xml contient les zones et options suivantes :

Type de zone

Les types de zones définissent une liste de différents types de données pour les valeurs. Vous pouvez définir des chaînes, des types numériques ou de nouveaux types. Par exemple :


<fieldType name="int" class="solr.TrieIntField" precisionStep="0" omitNorms="true" positionIncrementGap="0"/>

Une définition de zone plus compliquée ressemble à l'exemple suivant :


<fieldType name="wc_text" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
      <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" 
                catenateWords="1" catenateNumbers="1" catenateAll="0" splitOnCaseChange="0" preserveOriginal="1"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.SnowballPorterFilterFactory" language="English" protected="protwords.txt" />
      <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.WhitespaceTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt" enablePositionIncrements="true" />
      <filter class="solr.WordDelimiterFilterFactory" generateWordParts="1" generateNumberParts="1" 
                catenateWords="0" catenateNumbers="0" catenateAll="0" splitOnCaseChange="0" preserveOriginal="1"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.SnowballPorterFilterFactory" language="English" protected="protwords.txt" />
      <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
    </analyzer>
   </fieldType>

Lorsque wc_text fieldType est traité par les analyseurs, les outils de segmentations et les filtres sont utilisés pour influencer la pertinence de recherche.

Analyseurs de texte

Les analyseurs de texte mappent la chaîne source de texte et la liste finale des jetons. Ce processus se produit lors de l'indexation et de l'interrogation. Vous pouvez disposer de différentes chaînes d'analyseur pour l'indexation et l'interrogation, en fonction de vos besoins métier. Par exemple, la section EdgeNGramFilterFactory est mieux adaptée à l'indexation que la section de requête. Toutefois, généralement, les mêmes chaînes d'analyseur sont utilisées pour l'indexation et les requêtes, car les recherches nécessitent les jetons de requête correspondant aux jetons indexés.

Différents analyseurs renvoient des résultats différents. Par exemple, vous pouvez utiliser certains analyseurs pour renvoyer le terme Flash, lorsque flash est utilisé.

Outils de segmentation

Les outils de segmentation divisent les données de zone en jetons. L'exemple suivant montre comment une entrée Guide Wi-Fi O'Reilly est segmentée :

Exemple d'outils de segmentation
Outil de segmentation	Cible
Outil de segmentation standard (standardTokenizerFactory)	`Guide Wi-Fi O Reilly`
Outil de segmentation de mot clé	`Guide Wi-Fi O'Reilly`
Outil de segmentation d'espace blanc	`Guide Wi-Fi O Reilly`
WordDelimiterFilterFactory	`Guide Wi-Fi WiFi O Reilly oReilly`

En utilisant le paramètre WordDelimiterFilterFactory, vous pouvez faire en sorte que les recherches de correspondance pour sailboat recherchent sail boat ou sail-boat.

Filtres

Les filtres sont utilisés après les outils de segmentation pour examiner un flux de jetons et les conserver tels quels, les transformer ou les jeter, ou en créer de nouveaux. Les outils de segmentation et les filtres peuvent être combinés pour former des pipelines ou des chaînes, où la sortie de l'un devient l'entrée pour l'autre. Une séquence d'outils de segmentation et de filtres est appelée analyseur, et la sortie résultante d'un analyseur est utilisée pour faire correspondre les résultats de la requête ou générer des index.

snowballPorterFilterFactory est utilisé pour la recherche du radical, où le radical est utilisé pour réduire un mot à une forme plus courte. Par exemple, augmenté, augmentation et augmente ont tous comme radical commun augment.

Solr utilise Porter et KStem par défaut lors de la recherche du radical. Porter radicalise le mot en une forme de base qui ne doit pas nécessairement être un mot du dictionnaire. En revanche, KStem radicalise le mot en une forme de base qui correspond à un mot de dictionnaire. En règle générale, Porter donne plus de correspondances avec moins de précision.

Par exemple, Porter peut identifier le territorial lors de la recherche de territoire (alors que KStem non), mais il identifie également visuels lors de la recherche de visualisation (encore une fois, ce n'est pas le cas de KStem).

SnowballPorterFilterFactory est l'algorithme Snowball Porter Stemming qui sera appliqué à chaque mot (jeton). Il s'agit de la mise en œuvre de l'algorithme de recherche du radical porter2 (Snowball). L'algorithme Porter2 présente une légère amélioration par rapport à l'algorithme Porter.

Les algorithmes de recherche du radical les plus courants sont Porter, Snowball (Porter2) et Lancaster, où Porter est le moins agressif, et Lancaster le plus agressif (certains mots plus courts deviendront totalement obscurcis après Lancaster). Porter est le plus lent et Lancaster le plus rapide. Pour plus d'informations sur l'algorithme Snowball, reportez-vous à The English (Porter2) stemming algorithm. Porter et Porter2 radicalisent environ 5 % des mots sous différentes formes.

Sortie de snowballPorterFilterFactory : Guide Wi-Fi WiFi O Reilli oReilli

Zone

Chaque zone doit déclarer un nom unique et l'associer à l'un des types précédemment définis. Par exemple :


<field name="buyable" type="int" indexed="true" stored="true" multiValued="false"/>
<field name="mfName" type="wc_text" indexed="true" stored="true"  multiValued="false"/>

Chaque zone peut définir trois attributs importants :

multiValued: Lorsqu'elle est définie sur true, une zone peut contenir autant de valeurs que celle auxquelles elle est assignée, séparées par des caractères définis dans le fichier wc-data-config.xml.
indexé: Lorsqu'elle est définie sur true, la zone est utilisée dans l'index de recherche et peut être utilisée pour la recherche, le tri et la création de facettes dans la vitrine.
stored: Lorsqu'elle est définie sur true, la zone peut être incluse dans le jeu de résultats de recherche. Elle est utilisée pour enregistrer en permanence la valeur des données d'origine d'une zone, qu'elle soit indexée (et utilisée pour les recherches) ou non.; Le texte stocké n'est pas utilisé pour la recherche. Il est stocké séparément et n'est renvoyé que sur demande. Autrement dit, si une zone spécifique est utilisée pour la recherche, mais n'est jamais affichée aux clients, elle peut être définie sur false.

Par exemple, dans le fichier schema.xml, le fichier categoryname est défini pour contenir plusieurs valeurs :


<field name="categoryname" type="wc_text" indexed="true" stored="false" multiValued="true" />

Ensuite, dans le fichier wc-data-config.xml :


<field column="categoryname" splitBy=";" sourceColName="CATGRPNAME" />

Copiez les zones

Les zones de copie sont utilisées lorsque le contenu d'une zone source doit être ajouté et indexé sur différentes zones de destination. L'exemple suivant copie la zone name dans la zone de destination name_suggest :


<copyField source="name" dest="name_suggest"/>

Zones dynamiques

Les zones dynamiques vous permettent d'indexer des données sans définir le nom de la zone. Au lieu de cela, le nom de la zone est défini par un caractère générique (*). Vous pouvez utiliser des préfixes et des suffixes pour que le nom réel de la zone soit accepté au moment de l'exécution. Toutefois, le type de zone doit être défini. Par exemple, la zone dynamique suivante accepte des noms tels que price_USD= "100" ou price_EUR= "120".


<dynamicField name="price_*" type="wc_price" indexed="true" stored="true" multiValued="false"/>

Cet exemple est idéal, car vous pouvez utiliser l'API Solr sans définir de schéma final pour les données.

Clé unique

Les clés uniques attribuent une identité unique à un document Solr spécifique, et sont similaires aux clés primaires des bases de données. Dans le fichier schema.xml de l'index CategoryEntry, uniqueKey est défini sur catentry_id.

Zone de recherche par défaut

Cette zone est utilisée lorsque la requête ne contient pas de zone spécifique.

Opérateur par défaut.

L'opérateur par défaut indique le comportement par défaut lors de la manipulation de plusieurs jetons dans la recherche. L'opérateur OR est défini par défaut et ne peut pas être modifié. Les conventions de dénomination suivantes sont utilisées dans le fichier schema.xml :

fieldName: Segmenté et non sensible à la casse. Par exemple, mfName.
fieldName_cs: Segmenté et sensible à la casse. Par exemple, mfName_cs.
fieldName_ntk: Non segmenté et non sensible à la casse. Par exemple, mfName_ntk.
fieldName_ntk_cs: Non segmenté et sensible à la casse. Par exemple, catenttype_id_ntk_cs.

Utilisez des zones non segmentées lorsque vous souhaitez rechercher des correspondances exactes. Par exemple, utilisez une zone non segmentée pour les noms de marque, de sorte que lorsqu'un client recherche Econo Sense, les produits de Econo Sense apparaissent dans les résultats de recherche, à la place des produits de Sense.

Utilisez des recherches sensibles à la casse pour trouver des correspondances plus précises. Par exemple, pour les zones telles que le numéro de pièce.