Lecciones aprendidas al mejorar la búsqueda de texto completo en Snyk con Elasticsearch

Elasticsearch es un motor de búsqueda de código abierto muy popular. Gracias a su velocidad en tiempo real y a su API robusta, es una opción frecuente entre los desarrolladores que necesitan agregar capacidades de búsqueda de texto completo a sus proyectos. Además de su popularidad general, también es el motor al que estamos migrando actualmente la funcionalidad de informes de Snyk para issues. Cuando terminemos de ajustar todo en issues, empezaremos a usar Elasticsearch en otras áreas de informes.

Aunque Elasticsearch es potente, al principio también puede parecer complicado (a menos que tengas experiencia con motores de búsqueda). Pero como hace poco aprendí mucho sobre esta herramienta al implementarla en Snyk, pensé en compartir algunos conocimientos contigo, ¡de desarrollador a desarrollador!

A veces, un analizador estándar no es suficiente

Elasticsearch es rápido porque trata los distintos datos de manera distinta. Entre la gran variedad de tipos de campos, Elasticsearch cuenta con campos de texto, es decir, campos habituales para contenido textual (como cadenas de caracteres). Para que la información almacenada en esos campos se pueda buscar, Elasticsearch analiza el texto al ingerirlo y convierte los datos en tokens (términos). Luego almacena esos tokens y otra información relevante, como la longitud y la posición, en el índice. De forma predeterminada, usa un analizador estándar para analizar el texto.

Según la documentación oficial: «El analizador estándar ofrece compatibilidad inmediata con la mayoría de los idiomas naturales y casos de uso. Si eliges usar el analizador estándar tal como está, no necesitas ninguna configuración adicional».

En casos básicos, el análisis estándar puede ser suficiente. Veamos cómo funciona. Al ejecutar el siguiente comando, podremos ver el análisis generado para cualquier texto que proporcionemos:

1POST _analyze
2{
3  "analyzer": "standard",
4  "text": "Regular Expression Denial of Service (ReDoS)"
5}
6
7And the result will look like:
8
9{
10  "tokens" : [
11    {
12      "token" : "regular",
13      "start_offset" : 0,
14      "end_offset" : 7,
15      "type" : "<ALPHANUM>",
16      "position" : 0
17    },
18    {
19      "token" : "expression",
20      "start_offset" : 8,
21      "end_offset" : 18,
22      "type" : "<ALPHANUM>",
23      "position" : 1
24    },
25    {
26      "token" : "denial",
27      "start_offset" : 19,
28      "end_offset" : 25,
29      "type" : "<ALPHANUM>",
30      "position" : 2
31    },
32    {
33      "token" : "of",
34      "start_offset" : 26,
35      "end_offset" : 28,
36      "type" : "<ALPHANUM>",
37      "position" : 3
38    },
39    {
40      "token" : "service",
41      "start_offset" : 29,
42      "end_offset" : 36,
43      "type" : "<ALPHANUM>",
44      "position" : 4
45    },
46    {
47      "token" : "redos",
48      "start_offset" : 38,
49      "end_offset" : 43,
50      "type" : "<ALPHANUM>",
51      "position" : 5
52    }
53  ]
54}

Aquí podemos ver exactamente qué hace el analizador estándar: divide el texto en tokens y genera información de servicio para cada segmento, que luego almacena en el índice.

Buscar en el texto indexado

Una vez indexado el contenido, podemos probar la búsqueda de texto completo con un analizador estándar. Crearemos un documento de ejemplo con dos campos: title y description. Elasticsearch asignará automáticamente el mapeo del documento y detectará los campos de texto.

1PUT text-search-index/_doc/1
2{
3  "title": "Regular Expression Denial of Service (ReDoS)",
4  "description": "The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren'\''t very intuitive and can ultimately end up making it easy for attackers to take your site down."
5}

Ahora busquemos «express» con la siguiente consulta:

1GET text-search-index/_search
2{
3  "query": {
4    "match": {
5      "title": {
6    "query": "express"
7      }
8    }
9  }
10}

No se devolverá ningún documento, aunque tengamos «expression» en el título. Este resultado es el esperado (bueno, era de esperarse porque ya me había topado con esto), ya que el analizador no creó ningún token «express» (como podemos ver en los tokens generados que obtuvimos antes).

Si cambiamos la consulta de búsqueda a «expression», se devolverá el documento:

1GET text-search-index/_search
2{
3  "query": {
4    "match": {
5      "title": {
6    "query": "expression"
7      }
8    }
9  }
10}

Hay consultas más costosas que permiten resolver este problema de coincidencia de tokens, como las consultas difusas y de comodín, pero consumen muchos recursos de procesamiento. Así que, en lugar de gastar ciclos de CPU en el problema, debemos reevaluar nuestro analizador.

Está claro que un analizador estándar puede no ser suficiente si queremos resultados de búsqueda mejores y más flexibles. Para lograrlo, configuraremos un analizador personalizado. Estos serán nuestros requisitos:

• Usar consultas más cortas

• Búsqueda que no distinga entre mayúsculas y minúsculas

Para lograrlo, seguiremos estos pasos:

1. Crear un analizador personalizado

2. Configurar un tokenizador más adecuado para este caso de uso

3. Habilitar el nuevo analizador personalizado para los campos elegidos en el índice de Elasticsearch

Profundizar en los analizadores

Con el analizador estándar, nos facilitamos el trabajo al evitar tener que entender realmente qué hacía el analizador. Ahora que vamos a crear uno personalizado, necesitamos entender qué ocurre durante el análisis de texto:

1. Los filtros de caracteres (opcionales) se aplican al texto que se analiza para eliminar caracteres.

2. Un tokenizador divide el texto en tokens o términos. Esto puede hacerse de distintas maneras: generar tokens por espacios en blanco, por letras, etc.

3. Los filtros de tokens (opcionales) realizan cambios adicionales en los tokens, como convertirlos a minúsculas, eliminar ciertos tokens y más.

Un analizador es una combinación de tokenizadores y filtros. Analiza el texto y lo prepara para la búsqueda. Todo analizador debe tener un solo tokenizador, pero puede tener pocos o muchos filtros de ambos tipos. El orden de las operaciones nunca cambia: filtro de caracteres > tokenizador > filtro de tokens.

Crear nuestro primer analizador personalizado

Como vimos antes, de forma predeterminada todos los campos de texto usan el analizador estándar. Elasticsearch ofrece una gran variedad de analizadores integrados que se pueden usar en cualquier índice sin necesidad de configurarlos, y también puedes crear los tuyos. Para este caso de uso, tendremos que crear uno propio.

Los analizadores se pueden configurar en distintos niveles: índice, campo o consulta. Crearemos un analizador personalizado y lo especificaremos para un campo. Así se configura un analizador personalizado. Nota:Las configuraciones se almacenan en los ajustes del índice:

1PUT text-search-index
2{
3  "settings":{
4     "analysis":{
5        "analyzer":{
6           "my_analyzer":{
7              "type":"custom",
8              "tokenizer":"standard"
9           }
10        }
11     }
12  },
13  "mappings":{
14      "properties":{
15         "title": {
16            "type":"text",
17            "analyzer":"my_analyzer"
18         },
19         "text": {
20           "type": "text"
21         }
22      }
23   }
24}

Esto es lo que hicimos:

1. Se especifica un nuevo analizador personalizado llamado my_analyzer para el índice

2. my_analyzer usa el tokenizador standard y el filtro lowercase

3. my_analyzer se habilita como analizador de la propiedad title en el mapeo del índice

Este ejemplo es bastante sencillo y no cambia el comportamiento del analizador estándar. Ahora podemos probar algunos ajustes para que sea posible buscar palabras incompletas sin distinguir entre mayúsculas y minúsculas.

Elegir y configurar un tokenizador mejor

En el ejemplo anterior usamos el tokenizador estándar; ahora es momento de reemplazarlo por edge_ngram, que divide los tokens según su longitud (no por los espacios en blanco). Y si te preguntas por qué uso edge_ngram en lugar de stemmer, ¡sigue leyendo!

1...
2"analysis":{
3  "analyzer":{
4    "my_analyzer":{
5      "type":"custom",
6      "tokenizer":"my_tokenizer"
7    }
8  },
9  "tokenizer": {
10    "my_tokenizer": {
11      "type": "edge_ngram",
12      "min": 3,
13      "max": 8,
14      "token_chars": ["letter", "digit"]
15    }
16  }
17}
18...

Esto es lo que hicimos:

1. my_tokenizer usa el tokenizador edge_ngram

2. Creará tokens de entre 3 y 8 caracteres

3. Los tokens incluirán solo letras y dígitos

Elegir y configurar un filtro de tokens mejor

El analizador que creamos antes ahora permite buscar con palabras incompletas de entre 3 y 8 caracteres. Lo último que falta es hacer que la búsqueda no distinga entre mayúsculas y minúsculas. Para lograrlo, hay que agregar el filtro de tokens lowercase adecuado a my_analyzer:

1...
2"analysis":{
3  "analyzer":{
4    "my_analyzer":{
5      "type":"custom",
6      "tokenizer":"my_tokenizer",
7      "filter":[
8        "lowercase"
9      ]
10    }
11  },
12  "tokenizer": {
13    "my_tokenizer": {
14      "type": "edge_ngram",
15      "min": 3,
16      "max": 8,
17      "token_chars": ["letter", "digit"]
18    }
19  }
20}
21...

Resultado final

Después de todos los cambios, ya podemos crear un índice nuevo con un analizador personalizado. Antes de cambiar el analizador, vale la pena tener en cuenta que no se puede actualizar su configuración en campos existentes mediante la API de actualización de mapeos.

Así se verán los ajustes y los mapeos de nuestro índice de prueba básico:

1PUT text-search-index
2{
3  "settings":{
4    "analysis":{
5      "analyzer":{
6        "my_analyzer":{
7          "type":"custom",
8          "tokenizer":"my_tokenizer",
9          "filter":[
10            "lowercase"
11          ]
12        }
13      },
14      "tokenizer": {
15        "my_tokenizer": {
16          "type": "edge_ngram",
17          "min": 3,
18          "max": 8,
19          "token_chars": ["letter", "digit"]
20        }
21      }
22    }
23  },
24  "mappings":{
25    "properties":{
26      "title": {
27        "type":"text",
28        "analyzer":"my_analyzer"
29      },
30      "text": {
31        "type": "text"
32      }
33    }
34  }
35}

Ahora podemos agregar un documento y ejecutar distintas consultas para verificar que la búsqueda funcione como esperamos:

1PUT text-search-index/_doc/1
2{
3  "title": "Regular Expression Denial of Service (ReDoS)",
4  "description": "The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren'\''t very intuitive and can ultimately end up making it easy for attackers to take your site down."
5}

Buscar títulos que contengan «express» u otros tokens incompletos, sin distinguir entre mayúsculas y minúsculas:

1GET text-search-index/_search
2{
3  "query": {
4    "match": {
5      "title": {
6    "query": "express" // try: EXPRESS, exp, expression
7      }
8    }
9  }
10}

Ten en cuenta que no configuramos un analizador personalizado para la propiedad text de nuestro índice, así que ahí seguimos usando la búsqueda de siempre con un analizador estándar.

¿Qué sigue?

En este artículo sencillo, configuramos un analizador personalizado para lograr una búsqueda de texto más flexible en Elasticsearch y vimos algunos ajustes y configuraciones básicos y específicos. Elasticsearch ofrece una gran variedad de analizadores, tokenizadores, filtros y normalizadores integrados, opciones de búsqueda para excluir términos y mucho más.

Al combinarlos, podemos lograr excelentes resultados de búsqueda personalizados. Si estás empezando con Elasticsearch, espero que esto te haya resultado útil. No te pierdas las próximas novedades: tenemos pensado compartir más sobre nuestro recorrido con la búsqueda. ¡Lo próximo serán las agregaciones! (Puedes contar con eso...)

Si te gustaría formar parte de Snyk y crear excelentes herramientas de seguridad para desarrolladores, consulta nuestras vacantes abiertas en ingeniería.