Nuestros mejores desarrolladores han agotado sus reservas de café, en su búsqueda noche y día por la solución, hasta que Gloria halló la respuesta en Gitea por lo tanto hoy la comparte con nosotros.
Solución:
También hay consultas de términos que deberían ahorrarle algo de trabajo. Aquí un ejemplo de documentos:
"terms" :
"tags" : [ "blue", "pill" ],
"minimum_should_match" : 1
Bajo el capó, construye boolean should. Entonces es básicamente lo mismo que el anterior pero más corto.
También hay un filtro de términos correspondiente.
Entonces, para resumir, su consulta podría verse así:
"filtered":
"query":
"match": "title": "hello world"
,
"filter":
"terms":
"tags": ["c", "d"]
Con una mayor cantidad de etiquetas, esto podría marcar una gran diferencia en la longitud.
Editar: El material de bitset a continuación es quizás una lectura interesante, pero la respuesta en sí es un poco anticuada. Algunas de estas funciones están cambiando en 2.x. También Slawek señala en otra respuesta que el terms
La consulta es una forma fácil de SECAR la búsqueda en este caso. Refactorizado al final para las mejores prácticas actuales. -Nueva Zelanda
Probablemente querrá una consulta bool (o más probablemente un filtro junto con otra consulta), con una should
cláusula.
los bool consulta tiene tres propiedades principales: must
, should
, y must_not
. Cada uno de estos acepta otra consulta, o array de consultas. Los nombres de las cláusulas se explican por sí mismos; en tu caso, el should
La cláusula puede especificar una lista de filtros, una coincidencia con cualquiera de los cuales devolverá el documento que está buscando.
De los documentos:
En una consulta booleana sin
must
cláusulas, una o másshould
las cláusulas deben coincidir con un documento. El número mínimo de cláusulas should a coincidir se puede establecer utilizando elminimum_should_match
parámetro.
A continuación, se muestra un ejemplo de cómo podría verse esa consulta Bool de forma aislada:
"bool":
"should": [
"term": "tag": "c" ,
"term": "tag": "d"
]
Y aquí hay otro ejemplo de esa consulta Bool como un filtro dentro de una Consulta filtrada de propósito más general:
"filtered":
"query":
"match": "title": "hello world"
,
"filter":
"bool":
"should": [
"term": "tag": "c" ,
"term": "tag": "d"
]
Si utiliza Bool como una consulta (p. Ej., Para influir en la puntuación de coincidencias) o como un filtro (p. Ej., Para reducir los resultados que luego se puntúan o se filtran posteriormente) es subjetivo, según sus requisitos.
Por lo general, es preferible usar Bool a favor de un filtro O, a menos que tenga una razón para usar Y / O / No (tales razones existen). El blog Elasticsearch tiene más información sobre las diferentes implementaciones de cada uno y buenos ejemplos de cuándo puede preferir Bool sobre And / Or / Not, y viceversa.
Blog de Elasticsearch: Todo sobre los conjuntos de bits de filtros de Elasticsearch
Actualizar con una consulta refactorizada …
Ahora, con todo ese fuera del camino, el terms
query es una versión DRYer de todo lo anterior. Hace lo correcto con respecto al tipo de consulta bajo el capó, se comporta igual que el bool
+ should
utilizando el minimum_should_match
opciones, y en general es un poco más conciso.
Aquí está la última consulta refactorizada un poco:
"filtered":
"query":
"match": "title": "hello world"
,
"filter":
"terms":
"tag": [ "c", "d" ],
"minimum_should_match": 1
Si bien esta es una pregunta anterior, me encontré con este problema recientemente y algunas de las respuestas aquí ahora están en desuso (como señalan los comentarios). Entonces, en beneficio de otros que pueden haber tropezado aquí:
A term
La consulta se puede utilizar para encontrar el término exacto especificado en el índice inverso:
{
"query":
"term" : "tags" : "a"
De la documentación https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-term-query.html
Alternativamente, puede utilizar un terms
consulta, que hará coincidir todos los documentos con cualquiera de los elementos especificados en el array:
{
"query":
"terms" : "tags" : ["a", "c"]
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-terms-query.html
Hay que tener en cuenta (lo que me sorprendió): la forma en que define el documento también marca la diferencia. Si el campo en el que está buscando se ha indexado como text
escriba, Elasticsearch realizará una búsqueda de texto completo (es decir, utilizando un analyzed
string).
Si ha indexado el campo como keyword
luego una búsqueda por palabra clave con un “no analizado” string es interpretado. Esto puede tener un impacto práctico masivo ya que las cadenas analizadas están preprocesadas (en minúsculas, puntuación eliminada, etc.) Ver (https://www.elastic.co/guide/en/elasticsearch/guide/master/term-vs-full- text.html)
Para evitar estos problemas, el string El campo se ha dividido en dos nuevos tipos: texto, que debe usarse para la búsqueda de texto completo, y palabra clave, que debe usarse para la búsqueda de palabras clave. (https://www.elastic.co/blog/strings-are-dead-long-live-strings)