Archivo de esquema de Solr (schema.xml)

Solr organiza los datos en documentos, que constan de campos. En HCL Commerce, un documento consta de todas las descripciones de un producto.

El archivo schema.xml contiene información sobre los campos Solr y sobre cómo éstos se analizan y filtran durante las búsquedas. Diferentes tipos de campo pueden contener diferentes tipos de datos. Solr utiliza el archivo schema.xml para determinar cómo crear índices de los documentos de entrada y cómo realizar el proceso de tiempo de consulta e índice.

El archivo schema.xml contiene los siguientes campos y opciones:

Tipo de campo

Los tipos de campos definen una lista de tipos de datos diferentes para los valores. Puede definir series, tipos numéricos o tipos nuevos. Por ejemplo:


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

Una definición de campo más complicada es similar al ejemplo siguiente:


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

Donde wc_text fieldType lo procesan los analizadores, simbolizadores y filtros y se utiliza para influir en la relevancia de la búsqueda.

Analizadores de texto

Los analizadores de texto correlacionan la serie de origen de texto y la lista final de señales. Este proceso se produce durante la indexación y la consulta. Puede tener diferentes cadenas de analizadores la indexación y la consulta, en función de las necesidades de negocio. Por ejemplo, EdgeNGramFilterFactory es más adecuado para la indexación, en lugar de la sección de consulta. Sin embargo, normalmente se utilizan las mismas cadenas de analizador para la indexación y las consultas, porque las búsquedas necesitan que las señales de consulta coincidan con las señales indexadas.

Distintos analizadores devuelven resultados diferentes. Por ejemplo, puede utilizar algunos analizadores para devolver el término Flash cuando se utiliza flash.

Simbolizadores

Los simbolizadores desglosan los datos de campo en señales. El ejemplo siguiente muestra cómo se señala una entrada de la O'Reilly's Wi-Fi Guide:

Simbolizador de ejemplo
Simbolizador	Salida
Simbolizador estándar (standardTokenizerFactory)	`O Reilly s wi fi guide`
Simbolizador de palabra clave	`O'Reilly's wi-fi guide`
Simbolizador de espacio en blanco	`O'Reilly's wi-fi guide`
WordDelimiterFilterFactory	`o Reilly s oReillys Wi Fi WiFi guide`

Al utilizar WordDelimiterFilterFactory, puede hacer que las búsquedas de sacacorchos coincidan con las búsquedas de saca corchos o saca-corchos.

Filtros

Los filtros se utilizan después de los simbolizadores para examinar una corriente de señales y mantenerlos tal cual, transformarlos o descartarlos o crear otros nuevos. Los simbolizadores y filtros pueden combinarse para formar interconexiones o cadenas, donde la salida de uno se convierte en la entrada del siguiente. Una secuencia de simbolizadores y filtros se denomina analizador y la salida resultante de un analizador se utiliza para comparar resultados de la consulta o crear índices.

snowballPorterFilterFactory se utiliza para la lematización, donde la lematización se utiliza para reducir una palabra a una forma más corta. Por ejemplo, incrementado, incrementando e incrementa tienen como raíz la palabra incremento.

Solr utiliza Porter y KStem de forma predeterminada cuando se emplea la lematización. Porter deriva la palabra a un formato de base que no tiene que ser necesariamente una palabra del diccionario. En cambio, KStem deriva la palabra a un formato de base que coincide con una palabra del diccionario. Normalmente, Porter produce más coincidencias con menos precisión.

Por ejemplo, Porter puede identificar territorial al buscar territorio (KStem no puede), pero también identifica visuales al buscar visualización (de nuevo, KStem no lo hace).

SnowballPorterFilterFactory es un algoritmo de lematización Snowball Porter que se aplicará a cada palabra (token). Es la implementación del algoritmo de lematización Porter2 (snowball). El algoritmo Porter2 presenta una leve mejora respecto al algoritmo Porter.

Los algoritmos de lematización más habituales que se utilizan son Porter, Snowball (Porter2) y Lancaster, donde Porter es el menos agresivo y Lancaster el más agresivo (algunas palabras más cortas quedarán totalmente enmascaradas después de Lancaster). Porter es el más lento y Lancaster el más rápido. Para obtener más información sobre el algoritmo snowball, consulte The English (Porter2) stemming algorithm. Porter y Porter2 derivan aproximadamente el 5% de las palabras a formas diferentes.

Salida de snowballPorterFilterFactory: o Reilli s oReilli Wi Fi WiFi guid

Campo

Cada campo debe declarar un número exclusivo y asociarlo con uno de los tipos definidos anteriormente. Por ejemplo:


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

Cada campo puede definir tres atributos importantes:

multiValued: Cuando se establece en true, un campo puede contener tantos valores como se le asignen, separados por caracteres definidos en el archivo wc-data-config.xml.
indexed: Cuando se establece en true, el campo se utiliza en el índice de búsqueda y se puede utilizar para la búsqueda, la ordenación y la creación de facetas en el escaparate.
stored: Cuando se establece en true, el campo puede incluirse en el conjunto de resultados de búsqueda. Se utiliza para guardar permanentemente el valor de datos original de un campo, tanto si se indexa (y se utiliza para búsquedas) como si no.; El texto almacenado no se utiliza para la búsqueda. Se almacenan por separado y sólo se devuelve cuando se solicite. Es decir, si un campo determinado se utiliza para la búsqueda pero no se visualiza nunca a los compradores, se puede establecer en false.

Por ejemplo, en el archivo schema.xml, categoryname está establecido para que contenga varios valores:


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

A continuación, en el archivo wc-data-config.xml:


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

Campos de copia

Los campos de copia se utilizan cuando el contenido de un campo de origen debe añadirse e indexarse en campos de destino diferentes. El ejemplo siguiente copia el campo name en el campo de destino name_suggest:


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

Campos dinámicos

Los campos dinámicos le permiten indexar datos sin definir el nombre del campo. En su lugar, el nombre del campo se define mediante un carácter comodín (*). Puede utilizar prefijos y sufijos de modo que se acepte el nombre real del campo en el tiempo de ejecución. Sin embargo, se debe definir el tipo de campo. Por ejemplo, el campo dinámico siguiente acepta nombres como price_USD= "100" o price_EUR= "120".


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

Este ejemplo es ideal, ya que puede trabajar con la API de Solr sin definir un esquema final para los datos.

Clave exclusiva

Las claves exclusivas asignan una identidad exclusiva a un documento Solr específico, de forma similar a las claves primarias en las bases de datos. En el archivo schema.xml del índice CategoryEntry, uniqueKey se define como catentry_id.

Campo de búsqueda predeterminado

Este campo se utiliza cuando la solicitud no contiene un campo específico.

Operador predeterminado

El operador predeterminado indica el comportamiento predeterminado al manejar varias señales en la búsqueda. El operador OR está definido de forma predeterminada y no se puede cambiar. Se utilizan los siguientes convenios de denominación en el archivo schema.xml:

fieldName: Simbolizado y no sensible a mayúsculas y minúsculas. Por ejemplo, mfName.
fieldName_cs: Simbolizado y sensible a mayúsculas y minúsculas. Por ejemplo, mfName_cs.
fieldName_ntk: No simbolizado y no sensible a mayúsculas y minúsculas. Por ejemplo, mfName_ntk.
fieldName_ntk_cs: No simbolizado y sensible a mayúsculas y minúsculas. Por ejemplo, catenttype_id_ntk_cs.

Utilice campos no simbolizados cuando desee buscar coincidencias exactas. Por ejemplo, utilice el campo no simbolizado para nombres de marca, de modo que cuando un comprador busca productos Econo Sense, aparecen productos de Econo Sense en los resultados de búsqueda, en lugar de productos de Sense.

Utilice búsquedas sensibles a las mayúsculas y minúsculas para obtener coincidencias más exactas. Por ejemplo, para campos como número de pieza.