A la hora de entender qué es Solr y cómo trabaja, conviene conocer algunos conceptos básicos. En este post explicamos como almacena Solr los campos, definidos con determinados field types, o tipos de campo, que a su vez están definidos en el llamado managed-schema de Solr.

Explicamos a continuación todos estos términos para que podamos entender y seguir con más facilidad los tutoriales, ya sea de esta web o de los ejemplos contenidos en la web oficial de Solr.

Archivos principales de un index de Solr

Si estamos trabajando en el modo Standalone, es decir, en un único ordenador, los archivos de configuración serían los siguientes:

  • server/solr/solr.xml – configuraciones del server.
  • server/solr/films/core.properties - configurations del core, tipo nombre, etc.
  • server/solr/films/conf/solrconfig.xml – archive solrconfig, en este caso del Core “films”
  • server/solr/films/conf/managed-schema – manage-schema, en este caso de Core “films”

Dada su importancia, veremos más en detalles los archivos solrconfig y managed-schema

¿Qué es y para qué sirve el archivo Solrconfig de Solr?

El archivo solrconfig.xml define la configuración del Core de Solr. Controla elementos tales como la creación del Index, los componentes disponibles para hacer una búsqueda (Query), manejo de solicitudes (request handling), la configuración de componentes, etc.

Solr nos proporciona un solrconfig llamado _default que nos sirve para gran parte de las eventualidades que nos podemos encontrar.

El propio Solr nos proporciona un segundo solrconfig más sofisticado que el que viene por defecto llamado sample_techproducts_configs. Este configset nos permite indexar documentos de un tipo más amplio y es en general más sofisticado que el _default.

¿Qué es y para qué sirve el managed-schema de Solr?

El managed-schema le indica a Solr los campos que creamos, qué tipo de campo son, y cuál es su comportamiento.

Veamos un ejemplo de un campo creado incluido en el managed-schema.xml.

En uno de los tutoriales de la guía Solr, creamos el Core films en la versión de Solr 8.4.1, y Solr nos creo por defecto el managed-schema asociado. Pues bien, si entramos en el archivo managed-schema.xml (la ruta concreta es: solr-8.4.1>server>solr>flms>conf>managed-schema.xml), podemos ver cómo ha sido creado un campo llamado “genre”, que tiene asociado un tipo de campo dado, con ‘Type=”text_general”’:

ejemplo de campo (field) de solr llamado genre

El tipo de campo nos dice como se comportará ese campo. El propio archivo managed-schema.xml indica el comportamiento que debe tener este “type=text_general”:

ejemplo del tipo de campo text general en el managed schema de solr

Veamos lo que está pasando en este caso concreto, y con un ejemplo muy sencillo. Uno de los parámetros (llamado filter dentro de los llamados “solr filters”, en este caso uno llamado solr.LowerCaseFilterFactory) le dice que convierta en minúscula cualquier palabra mayúscula del campo.

¿Cómo se crea el managed-schema?

El managed-schema lo crea Solr por defecto, y podemos modificarlo mediante la Interfaz de Usuario. Si hiciéramos el schema nosotros mismos a mano, le llamaríamos schema.xml

¿Podemos modificar los campos y los tipos de campo que nos ha creado el Solr por defecto a través del managed-schema?

Sí, lo podemos hacer. Veamos un ejemplo: siguiendo el caso incluido en uno de los tutoriales de ejemplo, imaginemos que queremos crear un campo llamado “name” que recoja las variables de cadena de texto. Abrimos la Interfaz de Usuario, vamos a la pestaña de Schema y tecleamos:

modificacion de un campo en el managed schema de solr

Si ahora vamos a la pestaña Files, y buscamos y abrimos el documento managed-schema, veremos el campo que acabamos de crear:

campo name como text_general en el managed-schema de Solr

Fijémonos en que el tipo de campo es “text_general”. Ya buscamos antes las características de este tipo de campo, y vimos lo siguiente:

field type de text-general en el managed-schema de solr

Aquí nos está diciendo cómo tratará Solr el fieldType "text_general", es decir, por qué filtros y tokens hará pasar este campo.

¿Cómo podemos saber qué hará Solr con un texto almacenado con el tipo de campo “text_general”?

Mediante el uso de la pantalla Analysis, Veamos qué pasa cuando en la pestaña Analysis escribimos una cadena de texto con este tipo de campo. Pongamos como ejemplo el verso de Quevedo “Este es el niño Amor, este es su abismo.”. Y estas son las transformaciones que hace:

pestaña de menu Analysis de la Interfaz de Usuario de Solr

Veamos que la primera transformación, la llamada StandardTokenizerFactory, ha quitado las comas y los puntos.

Y que el filtro LowerCaseFilterFactory ha convertido las mayúsculas en minúsculas

¿Qué es un “token”?¿En qué consiste la “tokenización”?

La “tokenización” es un proceso que convierte cadenas de texto en “tokens”, unidades más básicas cuyo equivalente aproximado sería "palabra clave".De manera que el “token” almacena esa palabra clave e información referida a la misma, llamados metadados.

Veamos un ejemplo del proceso de “tokenización” de Solr en la práctica

Vamos a la Interfaz de Usuario Administrador, a la pantalla de Analysis.

Tecleamos la frase de ejemplo “todos los caballos bellos” y observamos cómo los segmentaría en palabras clave si lo tratásemos como un tipo de campo "texto_es".

Observamos que Solr filtra la frase a través de una serie de etapas:

tokenizacion de Solr de una cadena de texto

Primero se le aplica un “tokenizador” y a continuación de filtrado, un proceso que hemos llamado globalmente “tokenización”.

Todo este proceso viene definido en el archivo managed-schema.xml bajo la etiqueta , que consiste de dos subprocesos: • Solr tokenization en sí, convertir la cadena en solr tokens • Solr filter, pasar los solr tokens por un filtrado

Podemos observarlo abriendo dicho documento, cosa que podemos hacer en la misma Interfaz, en la pestaña “Fields”, y yendo al documento en cuestión.

Si en dicho documento nos desplazamos hasta “fieldType name:text_es, esto es lo que vemos:

etiqueta analyzer de solr en el proceso de tokenizacion de una cadena de texto

Observamos que aplica una “solr tokenización” y 3 filtros más en el campo “text_es” que son precisamente los que vimos en la pestaña Analysis:

ST: tokenización estándar, llamada StandardTokenizerFactory

LCF: Convertir las mayúsculas en minúsculas

SF: Quitar las “stop words”, palabras que separan palabras que se estiman significativas

SLSF: Filtro que singulariza las llamadas “Stem Word”, las palabras “matriz”.

etapas en el proceso de tokenización Solr

En concreto ¿qué hace el tokenizador StandardTokenizerFactory?

Este “solr tokenizator” en particular hace lo siguiente:
• Trata los espacios en blanco y los signos de puntuación como delimitadores de los tokens
• Los puntos que no son seguidos por espacios en blanco se mantienen
• Los nombres de dominio se mantienen, pero no las direcciones de email
• Las palabras con guiones se dividen en dos tokens

¿Qué son y cuando se usan los campos dinámicos en Solr (dinamic fields)?

En algunos casos no sabemos por anticipado el nombre exacto del campo de los documentos que vamos a indexar.

Por ejemplo, estamos indexando una colección de documentos entre los cuales hay películas, y dependiendo del país de origen de la película, la terminación del tipo de documentos es distinta, por ejemplo:

“film_es”, correspondería a un film de origen español

“film_fr”, correspondería a un film de origen francés

Título Tipo documento
Les Quatre Cents Coups film_fr
Amanece que no es poco film_es

Supongamos que no sabemos todos los idiomas que nos podemos llegar a encontrar de las películas que vamos a indexar, con lo cual no podemos crear un “campo estático” para cada lengua, porque podría aparecer alguna en un lenguaje que no habíamos previsto.

Frente a este problema podemos emplear un campo dinámico. En un campo dinámico, no necesitamos saber el nombre concreto de cada campo sino su patrón característico. Creamos ese patrón, y sustituiremos por un asterisco la parte de los sucesivos nombres de campo que varíe.

En nuestro ejemplo, sabemos que el patrón es film_idioma, con los crearíamos un campo dinamico con este nombre:

film_*

Y podríamos definir nuestro campo dinámico, que lo que haría es crear un campo de tipo “text_general” cada vez que encuentre un campo con el patrón de nombre film_*, de esta manera:

dynamicField name="film_*" type="text_general" indexed="true" stored="true"