Búsqueda asíncrona
Las API de búsqueda asíncrona han aterrizado en master. Todavía están en la fase de incubación, ya que abordamos algunas pruebas escamosas descubierto en nuestro CI después de la fusión, pero la característica sigue orientada a un primer lanzamiento en 7.7. El equipo de Kibana ahora puede trabajar en la integración de estas nuevas API desde la rama de desarrollo principal. Lukas del equipo de Kibana está trabajando estrechamente con nosotros para mover todas las solicitudes de búsqueda de bloqueo en Kibana a llamadas asincrónicas. Esto revelará su poder gradualmente. A partir de 7.7, los usuarios podrán omitir el tiempo de espera predeterminado de 30 segundos para visualizar paneles. En 7.8 y más allá, Kibana usará esta API para permitir la creación de paneles en segundo plano; las consultas continuarán ejecutándose incluso si el usuario se aleja o cierra el navegador. También proporcionaremos una API de administración para que Kibana pueda acceder y visualizar estas tareas en segundo plano.
Flujos de datos
Los flujos de datos son una formalización del concepto de datos de series temporales en Elasticsearch. Pueden considerarse como una agrupación o contenedor de primera clase para índices basados en el tiempo que generalmente compartirán una fuente común. En lugar de aprovechar los alias y las convenciones de nomenclatura para agrupar datos similares como lo hacemos hoy con ILM e índices, presentaremos nuevas configuraciones, API y estructuras internas para administrar mejor estos flujos de datos. La nueva configuración y API orientadas al usuario serán mínimas, familiares y ayudarán enormemente a los usuarios a comenzar a ingerir flujos de datos. Todos los datos del flujo de datos vivirán en índices ocultos, y las estructuras internas del flujo de datos permitirán realizar operaciones en el conjunto de índices que componen el flujo de datos. ILM también verá algunas modificaciones para trabajar sin problemas con los flujos de datos.
La promoción del concepto de datos de series temporales a un concepto de primera clase tiene muchos beneficios tanto ahora como en el futuro. Por ejemplo, si conocemos el campo de marca de tiempo para un conjunto de índices, podemos ordenar automáticamente los resultados de la consulta, configurar los segmentos de fragmentos que se ordenarán o exponer esta información a Kibana para su filtro de tiempo. Podemos hacer ciertas suposiciones y abstracciones que no requieren el uso de un alias que pueda evitar muchas configuraciones erróneas. Un flujo de datos puede corresponder directamente a un concepto que el usuario comprende (por ejemplo, su flujo de registros de errores de MySQL) que el usuario o el sistema pueden usar para tomar decisiones. Hay muchas opciones abiertas al tratar esto como un concepto de primera clase en Elasticsearch.
Plantillas de índice v2
Index templates v2 es una evolución de las plantillas de índice , una característica de larga duración de Elasticsearch. Las plantillas de índice existentes tienen un comportamiento no deseado, principalmente en torno a cómo se pueden fusionar varias plantillas. El mayor factor de diferenciación de las plantillas de índice v2 será cómo se compondrán varias plantillas juntas.
Se introducirá un nuevo concepto de "plantillas de componentes". Una plantilla de componente contiene configuraciones, asignaciones y alias y no está directamente asociada con un patrón de índice. Una plantilla de índice (v2) podrá componer múltiples plantillas de componentes juntas para formar un solo conjunto de configuraciones, asignaciones y configuraciones de alias. El orden en que se fusionan se define por el orden en que se especifican. Esto permite un patrón para crear bibliotecas de pequeñas plantillas de componentes y luego componerlas juntas de formas nuevas y diferentes para diferentes patrones de índice. Los flujos de datos aprovecharán las plantillas de índice v2 permitiendo la configuración específica del flujo de datos.
Análisis de regresión de desempeño
Nuestro equipo de rendimiento detectó varias regresiones en nuestros puntos de referencia nocturnos que luego de la división en bisectos se vincularon con cambios recientes en Apache Lucene y en la cancelación de solicitudes en Elasticsearch.
La introducción de la compresión en los valores de documentación binarios tuvo efectos negativos en el rendimiento de los campos de rango de búsqueda. Esto es algo que esperábamos al desarrollar la función, ya que los campos de rango usan campos binarios internamente, pero es realmente bueno tener confirmación a través de nuestros puntos de referencia nocturnos. Los nightlies también confirmaron las ganancias, que es que el tamaño en disco del índice disminuyó ligeramente con la introducción de la compresión.
La segunda regresión se debe a nuestras mejoras en torno a la cancelación de consultas. Las consultas que usan puntos (consulta de rango) y diccionario de términos (términos y consultas de varios términos) ahora verifican si la consulta se cancela con más entusiasmo. Este cambio afectó la latencia del 99% de nuestro índice de referencia de búsqueda, por lo que ahora estamos trabajando para reducir este impacto y mantener el beneficio de las comprobaciones periódicas.
Apache Lucene
Consultas de geometría
Hemos estado trabajando en algunas aceleraciones para LatLonShapeese trabajo especializándonos en cómo las diferentes formas calculan sus relaciones entre sí. Anteriormente, se suponía que todas las formas eran triángulos y se decodificaban en consecuencia. Ahora, las líneas y los puntos pueden ahorrar algo de tiempo de CPU al decodificar solo las dimensiones que usan.
Despreciativo SimpleFSDirectory
Notamos que SimpleFSDirectoryesencialmente duplica el comportamiento de NIOFSDirectory, pero con sincronización adicional debido a la forma en que usa el estado interno. Históricamente, este estado estaba allí para manejar correctamente las lecturas concurrentes en máquinas con Windows. Sin embargo, la sincronización en Windows ahora es manejada directamente por el JDK, por lo que no hay diferencia de rendimiento entre las dos Directoryimplementaciones en Windows, y NIOFSDirectorysiempre funcionará mejor en sistemas Mac y Linux. Dada esta disparidad de rendimiento, y el hecho de que SimpleFSDirectoryno es, de hecho, simple, hemos decidido desaprobarlo y eliminarlo.
Cambios
Rompiendo cambios en Elasticsearch
Últimos cambios en 8.0:
Linware Bolivia ⯈