No sólo copiar y pegar de Stack Overflow, sino entender lo que estás copiando.
Elasticsearch es el motor de búsqueda por excelencia en estos días, pero su DSL de consultas tiene una curva de aprendizaje empinada. Cuando empecé a escribir consultas de Elasticsearch, podía encadenar algo que funcionaba a través de una combinación de los docs de Elastic.co y Stack Overflow, pero no entendía completamente los conceptos subyacentes detrás de la sintaxis.
Este tutorial pretende ser lo que desearía haber leído primero. Asume que el lector está familiarizado con los conceptos básicos de Elasticsearch, puede escribir consultas simples y entiende la lógica booleana. Su objetivo es proporcionar al lector una base conceptual firme de Elasticsearch antes de tratar de entender la sintaxis.
Filtrado de valores exactos vs búsqueda analizada de texto completo
Un tema general en Elasticsearch es que todas las consultas se pueden clasificar en tres tipos:
1. Filtrado por valores exactos
2. Búsqueda en texto analizado
3. Una combinación de los dos
Cada campo de documento puede clasificarse como valores exactos o texto analizado (también llamado texto completo). Los valores exactos son campos como user_iddateemail_addresses, etc. El texto analizado son datos de texto como product_description o email_body. Como su nombre indica, estos datos de texto han sido analizados (más adelante). A menudo está en un lenguaje natural humano, pero no necesariamente.
La consulta de los documentos puede hacerse especificando filtros sobre valores exactos. En estos casos, la pregunta de si el documento se devuelve es un sí o un no binario. Por ejemplo, ¿es el user_id del documento igual a 174517 ? ¿Está la fecha del documento created_at dentro del rango del último mes?
Por otro lado, la consulta de documentos mediante la búsqueda de texto analizado devuelve resultados basados en la relevancia. Un documento se devuelve no por un criterio de sí/no, sino por lo relevante que es. Por ejemplo, si el texto analizado de un documento incluye a Johnny Depp, también debería ser devuelto en las búsquedas de John Depp o Johnnie Depp. Una búsqueda de cook también debería devolver resultados de cooking y cooked.
A partir de este comportamiento, podemos deducir que la búsqueda por texto analizado es una operación muy compleja e implica diferentes paquetes de analizadores dependiendo del tipo de datos de texto. Por ejemplo, algunos paquetes de analizadores son específicos del idioma que se utilizan para analizar el texto en un idioma determinado. El paquete analizador por defecto es el analizador estándar, que divide el texto según los límites de las palabras, las minúsculas y elimina la puntuación. Dado que la búsqueda por texto analizado es mucho más complicada que el filtrado por valores exactos, su rendimiento es mucho menor que el del filtrado por valores exactos. Nota, llamaremos a la búsqueda por texto analizado como búsqueda analizada para abreviar.
El DSL de consulta
Las consultas de Elasticsearch están compuestas por una o varias cláusulas de consulta. Las cláusulas de consulta pueden combinarse para crear otras cláusulas de consulta, llamadas cláusulas de consulta compuestas. Todas las cláusulas de consulta tienen uno de estos dos formatos:
{
QUERY_CLAUSE: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}{
QUERY_CLAUSE: {
FIELD_NAME: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}
}
La regla sintáctica es que las cláusulas de consulta pueden anidarse repetidamente dentro de otras cláusulas de consulta
{
QUERY_CLAUSE {
QUERY_CLAUSE: {
QUERY_CLAUSE: {
QUERY_CLAUSE: {
ARGUMENT: VALUE,
ARGUMENT: VALUE,...
}
}
}
}
}
Aquí hay algunas cláusulas de consulta comunes.
Cláusula de consulta match
La cláusula de consulta match es la más genérica y comúnmente utilizada. Es bastante inteligente en el sentido de que cuando se ejecuta sobre un campo de texto analizado, realiza una búsqueda analizada sobre el texto. Cuando se ejecuta en un campo de valor exacto, realiza un filtro.
En el ejemplo siguiente, la primera cláusula de consulta realizará una búsqueda analizada ya que description es un campo de texto analizado. Mientras que las 2 segundas consultas son filtros sobre campos de valor exacto.
{ "match": { "description": "Fourier analysis signals processing" }}
{ "match": { "date": "2014-09-01" }}
{ "match": { "visible": true }}
La cláusula de consulta Match All
La cláusula de consulta Match All devuelve todos los documentos. Es análoga a SELECT * FROM table en SQL.
{ "match_all": {} }
Cláusula de consulta de términos/términos
Las cláusulas de consulta de términos y términos se utilizan para filtrar por un campo de valor exacto por valores únicos o múltiples, respectivamente. En el caso de valores múltiples, la conexión lógica es OR .
Por ejemplo, la primera consulta encuentra todos los documentos con la etiqueta «math». La segunda consulta encuentra todos los documentos con las etiquetas «math» o «statistics».
{ "term": { "tag": "math" }}
{ "terms": { "tag": }}
Cláusula de consulta de coincidencia múltiple
La cláusula de consulta de coincidencia múltiple es una consulta de coincidencia que se ejecuta a través de múltiples campos en lugar de uno solo.
{
"multi_match": {
"query": "probability theory",
"fields":
}
}
Cláusula de consulta de filtros existentes y ausentes
El filtro existente comprueba que los documentos tienen un valor en un campo especificado. El filtro missing comprueba que los documentos no tienen un valor en un campo especificado. Son análogas a las cláusulas IS NULL y IS NOT NULL de SQL.
{
"exists" : {
"field" : "title"
}
}
y
{
"missing" : {
"field" : "title"
}
}
Cláusula de consulta de filtro de rango
La cláusula de consulta de filtro de rango se utiliza para filtrar campos de números y fechas en rangos, utilizando los operadores gtgteltlte corto para greater_thangreater_than_or_equalless_than y less_than_or_equal , respectivamente.
{ "range" : { "age" : { "gt" : 30 } } }{
"range": {
"born" : {
"gte": "01/01/2012",
"lte": "2013",
"format": "dd/MM/yyyy||yyyy"
}
}
}
Clausula de consulta de tipo bobo
Las cláusulas de consulta que se construyen a partir de otras cláusulas de consulta se denominan cláusulas de consulta compuestas. Tenga en cuenta que las cláusulas de consulta compuestas también pueden estar formadas por otras cláusulas de consulta compuestas, lo que permite el anidamiento de varios niveles.
La cláusula de consulta bool es un ejemplo de cláusula de consulta compuesta, ya que se utiliza para combinar múltiples cláusulas de consulta utilizando operadores booleanos. Los tres operadores booleanos soportados son mustmust_not y should , que corresponden a ANDNOT , y OR , respectivamente.
Por ejemplo, supongamos que tenemos un índice sobre el posts de una popular red social. Aquí tenemos una consulta para encontrar todos los posts sobre matemáticas que no son probables, en los que o bien no se han leído o se han favorecido.
{
"bool": {
"must": { "term": { "tag": "math" }},
"must_not": { "term": { "tag": "probability" }},
"should":
}
}
Combinando la búsqueda analizada con filtros
Hemos estado hablando de los filtros de campo exacto y de la búsqueda analizada en contextos separados, pero en aplicaciones del mundo real, a menudo queremos combinar los dos. Combinamos la búsqueda analizada y los filtros de campo exacto utilizando la cláusula filtered.
Por ejemplo, supongamos que tenemos un índice sobre el posts de un popular foro web sobre matemáticas. Aquí tenemos una consulta para encontrar todos los posts realizando una búsqueda analizada de «Teoría de la Probabilidad» pero sólo queremos posts con 20 o más upvotes y no los que tengan esa etiqueta de «frecuentista».
{
"filtered": {
"query": { "match": { "body": "Probability Theory" }},
"filter": {
"bool": {
"must": {
"range": { "upvotes" : { "gt" : 20 } }
},
"must_not": { "term": { "tag": "frequentist" } }
}
}
}
}
Resumen
El telón de fondo conceptual del DSL de consulta de Elasticsearch es esta dicotomía de filtrado de documentos vs búsqueda a través del texto analizado. Espero que os haya resultado útil.