Esta semana en Elasticsearch y Apache Lucene – 2019-12-02

Desde el blog de Elastic, se publico una nota relacionado a Apache Lucene. Compartimos algunos fragmentos de la misma; como asi tambien enlazamos si sitio web para quien desea conocer más información de la misma. 

La función de resumen está experimentando algunos cambios con el objetivo de mejorar la experiencia del usuario para que los índices de resumen se puedan usar mucho más que los índices regulares. Los principales cambios que estamos planeando hacer son:

  • Elimine los trabajos acumulativos a favor de una acción ILM para acumular un índice . Esto significará que acumular un índice funcionará de manera similar a reducir un índice. La acumulación se realizará cuando se complete la indexación y la acción acumulará todo el índice al mismo tiempo.
  • Agregue nuevos tipos de campo específicamente para datos de resumen . Habrá dos nuevos tipos de campo:
    1. Tupla de agrupamiento: el pensamiento actual es que esto sería análogo a los grupos en los paquetes acumulativos actuales y define las reducciones que desea usar en sus documentos acumulativos
    2. El paquete acumulativo de métrica – Este tipo de campo se utiliza para las métricas que desea rollup dentro de cada grupo, es decir, la métrica para calcular el avgminmaxetc.
  • Elimine el _rollup_searchpunto final a favor de implementar la búsqueda en los índices de resumen dentro de la _searchAPI . Esto significará que tendremos que modificar la agregación para poder trabajar en los campos de resumen así como en los tipos de campo existentes actualmente.

API de lenguajes de scripting y contextos

Hemos abierto un  RP que  agrega una nueva API que expone los tipos de scripts permitidos (en línea / almacenados), el idioma y los contextos en los que se puede usar cada idioma. Esta API permitirá a Kibana  detener la codificación de los lenguajes de scripting  para proporcionar un selector al crear campos con script.

Reindex

La reindexación flexible se ordena _seq_nopara poder reanudar en caso de falla. Estamos  agregando un desafío de Rally para reindexar  para determinar el impacto en el rendimiento del género. Los resultados actuales muestran que la reindexación resiliente es más lenta que la reindexación no resiliente, y estamos investigando las causas fundamentales.

Modificamos la documentación de reindex para  aclarar que los tipos de origen no se tienen en cuenta en reindex en 7.0+ .

Además, hay una nueva configuración  para permitir que X-Pack anule los encabezados de seguridad necesarios para la reindexación, cuyo código es OSS.

Consultas ordenadas más rápidas

En Elasticsearch 7.0 presentamos una optimización que permite omitir documentos no competitivos al ordenar documentos por relevancia. Esta optimización está expuesta de forma predeterminada y no requiere ninguna configuración. También hemos agregado nuevas consultas que tienen en cuenta esta optimización para dar más peso a los documentos más cercanos a una determinada fecha o ubicación. Sin embargo, esta optimización solo funciona si los documentos están ordenados por puntuación (relevancia), por lo que si necesita ordenar sus documentos por fecha o por un campo numérico, tenemos que cambiar a la ejecución lenta que requiere visitar todos los documentos, incluso si no lo hace. necesita el recuento total de aciertos de documentos que coinciden con la consulta.

Hoy, nos complace anunciar que hemos fusionado un  cambio que permite a Elasticsearch exponer la optimización a consultas ordenadas por un campo numérico indexado. La idea es traducir automáticamente la ordenación numérica en una consulta de entidad de distancia que sea capaz de podar eficientemente los documentos que están demasiado lejos de la N. superior actual. muy eficiente como se muestra en nuestro punto de referencia nocturno donde la clasificación por marca de tiempo ahora es hasta 35 veces más rápida que antes.

Ahora estamos trabajando en aplicar esta optimización cuando usamos search_after o durante un desplazamiento. Esperamos que esto permita más casos de uso que requieran recuperar una secuencia de documentos de Elasticsearch de manera ordenada.

También queremos trabajar en otro cambio relacionado que tenga en cuenta el rango de tiempo mínimo y máximo en los fragmentos y los compare con el valor de clasificación en el último golpe competitivo. Si el fragmento no puede contener un éxito competitivo, puede omitirse para mejorar aún más el rendimiento de las búsquedas ordenadas por campos de fecha. Esto debería significar que incluso cuando se incluyen índices congelados en la solicitud de búsqueda, podemos descartarlos de manera eficiente, tanto mejorando el rendimiento de la búsqueda como permitiendo que Elasticsearch libere recursos ya que sabemos que estos fragmentos son innecesarios para la búsqueda.

Comparte este Artículo!