La Red de Conocimientos Pedagógicos - Currículum vitae - Traducción D4c

Traducción D4c

O cómo saber qué documentos oficiales faltan.

Si tuviera que describir Elasticsearch en una frase, diría:

Actualmente, Elasticsearch es una de las diez tecnologías de código abierto más populares. Para ser justos, combina muchas características clave que no son únicas por sí solas, pero cuando se usan juntas, puede ser el mejor motor de búsqueda/plataforma de análisis que existe.

Más precisamente, Elasticsearch se ha vuelto tan popular debido a su combinación de:

Puntuación de relevancia de búsqueda

Búsqueda de texto completo

Análisis (resumen)

Sin modelo (sin restricciones en el esquema de datos), NoSQL, orientado a documentos.

Selección enriquecida de tipos de datos

Escalabilidad horizontal

Tolerante a fallos

Al trabajar con Elasticsearch, rápidamente me di cuenta de que: El documento oficial Se parece más al llamado "exprimir" el documento. Tuve que buscar en Google y usar mucho stackowerflow, así que decidí recopilar toda la información en este artículo.

En este artículo, escribiré principalmente sobre consultas/búsquedas en un clúster de Elasticsearch. Puedes lograr aproximadamente el mismo resultado usando muchos métodos diferentes, así que intentaré explicar los pros y los contras de cada método.

Más importante aún, le presentaré dos conceptos importantes (consulta y contexto de filtro) que no están bien explicados en la documentación. Le daré un conjunto de reglas para decidir cuál enfoque es mejor.

Después de leer este artículo, si solo quiero que recuerdes una cosa, sería esto:

Cuando hablamos de Elasticsearch, siempre hay una puntuación de relevancia. La puntuación de relevancia es un número de punto flotante estrictamente positivo que representa qué tan bien cumple cada documento con los criterios de búsqueda. La puntuación es relativa a la puntuación más alta asignada, por lo que cuanto mayor sea la puntuación, más relevante será el documento para los criterios de búsqueda.

Sin embargo, los filtros y las consultas son dos conceptos diferentes y debería poder comprenderlos antes de escribir la consulta.

En general, un contexto de filtro es una opción de sí/no donde cada documento coincide o no con la consulta. Un buen ejemplo es SQL WHERE seguido de algunas condiciones. Las consultas SQL siempre devuelven filas estrictamente calificadas. Las consultas SQL no pueden devolver resultados ambiguos.

El contexto de consulta de Elasticsearch, por otro lado, muestra en qué medida cada documento coincide con sus requisitos. Para ello, la consulta utiliza un analizador para encontrar la mejor coincidencia.

La regla general es utilizar filtros para:

Sí/No búsqueda

Buscar valores exactos (números, rangos y palabras clave)

Utilice la consulta para:

Resultados poco claros (algunos documentos son más adecuados que otros)

Búsqueda de texto completo

Además, Elasticsearch automáticamente resultado de los filtros de caché.

En la Parte 1 y la Parte 2 analizaré las consultas (que se pueden convertir en filtros). No confunda texto estructurado y completo con consultas y filtros: son dos cosas diferentes.

La consulta estructurada, también conocida como consulta a nivel de término, es un conjunto de métodos de consulta que se utilizan para comprobar si se debe seleccionar un documento. Por lo tanto, en muchos casos no existe una puntuación de relevancia real necesaria: los documentos coinciden o no coinciden (especialmente numéricamente).

Las consultas a nivel de término siguen siendo consultas, por lo que devolverán puntuaciones.

Consulta nominal $Consulta de término

Devuelve documentos cuyos valores de campo coinciden exactamente con las condiciones. La consulta de palabras es SQL select * de la tabla _ nombre donde la columna _ nombre =...

La consulta sustantiva va directamente al índice invertido, lo que puede hacerla muy rápida. Cuando trabaje con datos de texto, es mejor usar $term solo para campos de palabras clave.

De forma predeterminada, se ejecuta una consulta de sustantivo dentro del contexto de la consulta, por lo que calculará la puntuación. Incluso si todos los documentos devueltos tienen la misma puntuación, se requiere potencia informática adicional.

Consulta de sustantivo con condiciones de filtro

Si queremos acelerar la consulta de sustantivo y almacenarla en caché, debemos envolverla en un filtro de puntuación constante.

¿Recuerdas la regla general? Utilice este método si no le importan las puntuaciones de relevancia.

Ahora, la consulta no calcula ninguna puntuación de relevancia, por lo que es más rápida. Además, se almacena en caché automáticamente.

Consejo rápido: utilice coincidencias en lugar de sustantivos en los campos de texto.

Recuerde, las consultas de sustantivos van directamente al índice invertido. Las consultas de sustantivos toman el valor que usted proporciona y lo buscan tal como está, por lo que es ideal para consultar campos de palabras clave que se almacenan sin ninguna conversión.

Consultas de varios sustantivos Consultas de términos

Como es de esperar, las consultas de varios sustantivos le permiten devolver documentos que coinciden con al menos un sustantivo exacto.

La consulta con varios nombres es una alternativa a la selección SQL * de nombre_tabla, donde se encuentra nombre_columna...

Lo que hay que entender es que el campo de consulta en Elasticsearch puede ser un Lista, como {"nombre": ["Odin", "Woden", "Wodan"]}. Se coincidirá con un registro si la consulta de términos que realiza contiene uno o más de los siguientes: no es necesario que coincida con todos los valores del campo, sino solo con un valor.

Igual que la consulta nominal, pero esta vez puede especificar cuántos términos exactos desea en el campo de consulta.

Tú especificas cuántos deben coincidir: uno, dos, tres o todos. Sin embargo, este número es otro campo numérico. Por lo que cada documento debe contener un número (específico del documento específico).

Devuelve documentos cuyos valores de campo de consulta se encuentran dentro del rango definido.

Equivalente a SQL seleccionar * de la tabla _ nombre, donde la columna _ nombre está entre ellas. ...

Las consultas de rango tienen su propia sintaxis:

Gt es mayor que

GTE es mayor o igual que

Es menor que

LTE menor o igual

Por ejemplo, el valor de este campo debe ser ≥4 y ≤17.

Las consultas de rango también funcionan bien con fechas.

Las consultas de expresiones regulares devuelven documentos cuyos campos coinciden con la expresión regular.

Si nunca has usado expresiones regulares, te recomiendo que al menos sepas qué es y cuándo puedes usarla.

Las expresiones regulares de Elasticsearch son expresiones regulares de Lucene. Tiene operadores y caracteres reservados estándar. Si ha utilizado el paquete re de Python, no debería ser un problema usarlo aquí. La única diferencia es que el motor de Lucene no admite operadores ancla, como y $.

Puedes encontrar la lista completa de expresiones regulares en la documentación oficial.

Además de las consultas de expresiones regulares, Elsticsearch también tiene consultas con comodines y prefijos. Lógicamente, estos dos son sólo casos especiales de expresiones regulares.

Desafortunadamente, no pude encontrar ninguna información sobre el rendimiento de estas tres consultas, así que decidí probarlas yo mismo para ver si notaba alguna diferencia significativa.

No encuentro ninguna diferencia de rendimiento al comparar consultas rehexp y comodín. Si sabes la diferencia, por favor envíame un mensaje.

Dado que Elasticsearch no es modal (o no tiene restricciones de modo estrictas), es muy común que diferentes documentos tengan diferentes campos. Por tanto, saber si un documento tiene determinados campos tiene muchas utilidades.

La consulta de texto completo es adecuada para datos de texto no estructurados. Analizador de utilización de consultas de texto completo. Por lo tanto, daré una breve descripción general de los analizadores de Elasticsearch para que podamos analizar mejor las consultas de texto completo.

Cada vez que se insertan datos de tipo texto en el índice de Elasticsearch, se analizan y luego se almacenan en el índice invertido. Dependiendo de la configuración del analizador, esto afectará su funcionalidad de búsqueda, ya que el analizador también funciona con búsquedas de texto completo.

El proceso del analizador consta de tres etapas:

Siempre hay un generador de tokens y cero o más filtros de caracteres y tokens.

1) El filtro de caracteres recibe los datos de texto tal como están y luego puede preprocesar los datos antes de etiquetarlos. Los filtros de caracteres se utilizan para:

Reemplazar caracteres que coincidan con la expresión regular dada

Reemplazar caracteres que coincidan con la cadena dada

Borrar texto HTML

p>

2) El generador de tokens divide los datos de texto recibidos después del filtro de caracteres (si corresponde) en tokens. Por ejemplo, el tokenizador de espacios en blanco simplemente separa el texto en espacios en blanco (lo cual no es estándar). Entonces, después de que el miércoles se llame Woden, se dividirá en [miércoles, se llama, después, Woden. ]. Hay muchas etiquetas integradas que se pueden utilizar para crear analizadores personalizados.

Después de eliminar la puntuación, el tokenizador estándar separa el texto con espacios. Para la mayoría de los idiomas, esta es la opción más neutral.

Además de la tokenización, el tokenizador hace lo siguiente:

Rastrea los pedidos de tokens,

nota el principio y el final de cada palabra.

Definir el tipo de token

3) El filtro de token realiza algunas transformaciones en el token. Puede optar por agregar varios filtros de tokens diferentes al analizador. Algunos de los más populares son:

Minúsculas

Lema (¡disponible en muchos idiomas!)

Eliminar duplicados

Convertir a etc. Código ASCII válido.

Solución para el patrón

Límite de número de tokens

Lista de tokens de parada (eliminar tokens de la lista de paradas)

El analizador estándar es el analizador predeterminado . Tiene 0 filtros de caracteres, un generador de tokens estándar, filtros de minúsculas y tokens de parada. Puede crear un analizador personalizado si es necesario, pero hay pocos analizadores integrados.

Los analizadores de idiomas son algunos de los analizadores listos para usar más eficientes y utilizan los detalles de cada idioma para realizar transformaciones más avanzadas. Por lo tanto, si conoce de antemano el idioma de sus datos, se recomienda que cambie del analizador estándar a uno de los idiomas de sus datos.

Las consultas de texto completo utilizarán el mismo analizador utilizado para indexar los datos. Más precisamente, el texto que consulta se transformará de la misma manera que los datos de texto en el campo de búsqueda, por lo que estarán al mismo nivel.

Las consultas de coincidencia son consultas estándar que se utilizan para consultar campos de texto.

Podemos llamar a la consulta de coincidencia el equivalente de la consulta de sustantivo, pero es adecuada para campos de tipo texto (mientras que los sustantivos solo deben usarse para campos de tipo palabra clave cuando se procesan datos de texto).

De forma predeterminada, las cadenas pasadas a los parámetros de consulta (parámetros obligatorios) serán procesadas por el analizador aplicado al campo de búsqueda. A menos que utilice el parámetro del analizador para especificar el analizador usted mismo.

Cuando especificas una frase a buscar, se analiza y el resultado es siempre un conjunto de etiquetas. De forma predeterminada, Elasticsearch utilizará el operador OR entre todas estas etiquetas. Esto significa que debe haber al menos un juego: cuantos más juegos, mayor será la puntuación. Puede cambiarlo a y en el argumento del operador. En este caso, todos los tokens deben encontrarse en el documento antes de poder devolverlos.

Si desea ingresar un valor entre OR y, puede especificar el parámetro minimal_should_match, que especifica el número de cláusulas que deben coincidir. Se puede especificar mediante números y porcentajes.

El parámetro difuso (opcional) le permite ignorar los errores de entrada. Para el cálculo se utiliza la distancia de Levenshtein.

Si se aplica una consulta de coincidencia a un campo de palabra clave, el efecto es el mismo que el de una consulta de entrada. Aún más interesante, si pasa el valor exacto del token almacenado en el índice inverso a la consulta $term, devolverá exactamente los mismos resultados que la consulta de coincidencia, pero devolverá el índice inverso mucho más rápido.

Igual que partido, pero importa el orden y la proximidad. Las consultas de concordancia desconocen el orden y la proximidad, por lo que la concordancia de frases solo se puede lograr con otros tipos de consultas.

La consulta match_phrase tiene un parámetro slop (el valor predeterminado es 0), que es responsable de omitir términos. Por lo tanto, si especifica una pendiente igual a 1, es posible que se omita una palabra de la frase.

Las consultas de coincidencias múltiples funcionan igual que las coincidencias, la única diferencia es que las coincidencias múltiples se aplican a múltiples campos.

Puedes utilizar comodines para especificar nombres de campos.

Por defecto, cada campo está ponderado.

Se puede aumentar la contribución de cada campo a la puntuación.

Si no se especifica ningún campo en el parámetro campos, se buscarán todos los campos que cumplan los requisitos.

Existen muchos tipos de multi_match. No los describiré en este artículo, pero explicaré los más comunes:

El tipo best_fields (el predeterminado) prefiere buscar resultados para un token a partir del valor de búsqueda de un campo en lugar del valor buscado. Los tokens se asignan a diferentes campos.

Most_fields es lo opuesto a best_fields.

El tipo de frase se comporta igual que best_fields, pero busca la frase completa de manera similar a match_phrase.

Te recomiendo encarecidamente que consultes la documentación oficial para comprobar la precisión de los cálculos de puntuación de cada área.

Las consultas compuestas engloban otras consultas. Consultas compuestas:

Combina puntuaciones

Cambiar el comportamiento de las consultas empaquetadas

Cambiar el contexto de la consulta para filtrar el contexto.

Cualquiera de las anteriores

Consultas booleanas combinadas con otras consultas. Esta es la consulta compuesta más importante.

Las consultas booleanas le permiten combinar búsquedas en un contexto de consulta con búsquedas en un contexto de filtro.

Las consultas booleanas tienen cuatro combinaciones (tipos) posibles:

Debe o "Debe cumplir con esta cláusula"

Debe o "Si se cumplen las condiciones, dé La puntuación de relevancia añade puntos extra"

Filtro de filtro o "Esta cláusula debe cumplirse, pero la puntuación de relevancia no se calcula"

No debe o "lo contrario de necesidad" no afectará la relevancia puntaje.

Debe y debería→contexto de consulta

Filtro y no debe →filtro de contexto

Para aquellos familiarizados con SQL, debe es AND, pero debe ser u operador. Por lo tanto, se deben satisfacer todas las consultas de la cláusula must.

Para la mayoría de las consultas, las consultas de impulso son similares a los parámetros de impulso, pero no son iguales. La consulta mejorada devolverá documentos que coincidan con cláusulas positivas y reducirá la puntuación de documentos que coincidan con cláusulas negativas.

Como vimos en el ejemplo de consulta de términos anterior, la consulta Constant_score convierte cualquier consulta en un contexto de filtro con una puntuación de relevancia igual al parámetro boost (el valor predeterminado es 1).

Si desea leer otro artículo que proporcione ejemplos de la vida real de todas las consultas, hágamelo saber.

Planeo publicar más artículos en Elasticsearch, no te lo pierdas.

Has leído mucho, así que si has leído hasta aquí:

Para resumir, Elasticsearch sirve para tantos propósitos hoy en día que a veces es difícil entender cuál es la mejor herramienta.

Si no se requieren puntuaciones de relevancia para recuperar datos, intente cambiar al contexto de filtro.

Además, es muy importante comprender cómo funciona Elasticsearch, por lo que recomiendo que siempre comprendas las capacidades del analizador.

Hay muchos otros tipos de consultas en Elasticsearch. Intenté describir los más utilizados. Espero que te guste.

(Este artículo está traducido del artículo "Deep-PE-Into-Query-Elastic Search-Filter-vs-" del autor kotartemiy. Query-Full-Text-Search-b 861 b 06 BD 4c 0 ).