Building a Library Search Infrastructure with Elasticsearch

Resumen original

This article discusses our implementation of an Elastic cluster to address our search, search administration and indexing needs, how it integrates in our technology infrastructure, and finally takes a close look at the way that we built a reusable, dynamic search engine that powers our digital repository search. We cover the lessons learned with our early implementations and how to address them to lay the groundwork for a scalable, networked search environment that can also be applied to alternative search engines such as Solr.

Referencia del articulo

Pham, K., Reyes, F., Rynhart, J. (2020). Building a Library Search Infrastructure with Elasticsearch. Code(4)Lib Journal, (48). https://journal.code4lib.org/articles/15203

Resumen detallado

Introducción

La plataforma de búsqueda Elastic consiste en diferentes aplicaciones, como Elasticsearch (la más popular, conocida por su búsqueda a texto completo extremadamente rápida) o Kibana (que sirve de interfaz a los datos almacenados en Elasticsearch). Tiene una naturaleza distribuida, por la cual se usa para resolver multitud de situaciones como la búsqueda en aplicaciones, análisis de seguridad o métricas, funcionalidades, por otra parte, basadas en Apache Lucene, un software de recuperación de información de código abierto.

Nuestro "Elastic Stack"

Elasticsearch es una solución distribuida diseñada para ser escalada horizontalmente cuyo formato de documento básico es el JSON. Elasticsearch se basa en instancias llamadas nodos que, distribuidas entre varios ordenadores, ayudan a que la carga de trabajo derivada de las búsquedas y los análisis sea más manejable. Los nodos se agrupan en unidades mayores llamadas “cluster” y los datos que contienen estos cluster se almacenan en fragmentos, que pueden ser asignados a un nodo.

En nuestro sistema, hemos optado por servidores con 3 nodos, configurados para tener 3 fragmentos y 2 réplicas de cada fragmento, de forma que cada nodo dentro de los servidores contenga 1 fragmento y 2 réplicas no relacionadas con él. Además, el cluster hace de indexador principal para el ecosistema de colecciones, que contiene 4 sistemas principales: ArchivesSpace (descripción archivística), ArchivesDirect (preservación de microservicios y almacenamiento), Kaltura (administración de medios y servicio de streaming) y digitaldu (nuestro repositorio digital).

Se decidió este sistema debido a que trabajábamos con índices de datos relativamente pequeños (menos de 1GB).

Búsqueda en aplicaciones

Gracias a usar Elasticsearch, la función de búsqueda en nuestras aplicaciones ha sido integrada mejor y de forma mas simple, construyéndola como como un componente reusable donde el mismo código puede ser usado en varias aplicaciones.

Las búsquedas se realizan introduciendo datos de consulta en la API de Elasticsearch en un formato flexible y potente, lo que contribuye a que las búsquedas sean mas fáciles de usar y de personalizar. Este formato consiste en directivas del lenguaje específico de dominio de Elasticsearch, o DSL, en una estructura de JSON, construido dinámicamente usando los datos entregados por el usuario junto con los datos de configuración de la búsqueda en la aplicación. Es gracias a la elasticidad de esta estructura que se ha simplificado el desarrollo y la implementación de la búsqueda en nuestras aplicaciones.

Construyendo el objeto de búsqueda de Elasticsearch

Cuando un usuario realiza una búsqueda en una aplicación, los datos de dicha búsqueda son usados para construir un objeto de búsqueda, que se usa en el servidor de Elasticsearch para devolver resultados. Este objeto puede ser creado dinámicamente basándose en consultas a texto completo, como parámetros de búsqueda seleccionados por el usuario o caracteres de control en la ecuación de búsqueda.

El objeto creado tiene una estructura muy simple, por lo que puede ser construido y usado en los servidores muy rápido, permitiendo un amplio abanico de búsquedas sin que cada una requiera un objeto de búsqueda o función específica.

De consulta a objeto de búsqueda

Una petición de búsqueda incluye el campo que dice donde se buscara, una ecuación de búsqueda compuesta de los términos de la búsqueda, opciones de búsqueda (como buscar en un campo concreto o ignorar un campo) y facetas de filtrado de datos (como un autor especifico). Estos datos componen el objeto de búsqueda y determinaran que resultados devolverá la búsqueda.

Además, el objeto de búsqueda también puede contener subconsultas que funcionan junto a lo anterior.

Caracteres de control en la ecuación de búsqueda: comillas

Los términos dentro de las comillas deben aparecer en un documento en el orden exacto para que la búsqueda devuelva un documento, no vale que aparezcan pero en otro orden.

Caracteres de control en la ecuación de búsqueda: caracteres comodines

En una ecuación de búsqueda, un carácter comodín crea una búsqueda comodín, que devolverá resultados que contengan cualquier termino dentro de estos comodines. Esto habilita la utilización por parte de los usuarios de técnicas de búsqueda basadas en términos comunes.

Parámetros adicionales de búsqueda

Los parámetros establecidos en la búsqueda es otra forma de que el usuario personalice dicha búsqueda. El usuario puede seleccionar un campo concreto o, por el contrario, elegir un grupo de estos, que están predefinidos en la configuración de la aplicación, si se elige un grupo, los campos se recuperan de la configuración y se añaden al objeto de búsqueda, de forma que cualquier campo con los términos de la búsqueda será devuelto.

También se pueden incluir facetas en la búsqueda (que pueden ser ejecutadas sin necesidad de una ecuación de búsqueda que las acompañe), el resultado debe contener los datos introducidos y el orden de estos exactamente.

Objeto de búsqueda y consulta booleana

Para devolver los resultados de búsquedas, los documentos son cogidos de un índice que coincida con la consulta, que está dividida en subconsultas que contienen un conjunto de condiciones. Estas condiciones, en el objeto de búsqueda, se denominan objeto de búsqueda booleano, que consiste en un grupo matrices, cada una con un conjunto individual de consultas, donde cada conjunto impone una condición específica a la búsqueda para determinar si un documento se devolverá o no:

-“should”: es el equivalente al “or”, si un término de la consulta se encuentra en un documento, este será devuelto.

-“must”: es el equivalente del “and”, si todos los términos de una consulta se encuentran en un documento, este será devuelto.

-“must not”: es el equivalente del “not”, si ninguno de los términos de una consulta se encuentran en un documento, este será devuelto.

-“filter”: es igual que el must, solo que mientras que este asigna peso a sus resultados, filter simplemente devuelve los resultados, sin añadir un peso.

Se pueden combinar estos tipos en una búsqueda avanzada (que también podrá incluir operaciones como “contain” o “does not contain”).

Conclusiones

En definitiva, hemos podido usar Elasticsearch de múltiples maneras aprovechando su gran versatilidad.

De cara al futuro, uno de nuestros últimos proyectos es el desarrollo de un repositorio que, aunque actualmente está en beta, proporciona acceso a datos basados en consultas REST. Además, estamos barajando las posibilidades de otros proyectos, como mejorar nuestro indexador central para que recoja y actualice datos en un ciclo más frecuente o monitorizar el rendimiento de las aplicaciones.