La agregación date_histogram de Elasticsearch es la piedra angular de Discover de Kibana . Y la interfaz de usuario de supervisión de registros . ¡Cuatro segundos para graficar todas las fallas de alguna prueba durante los últimos seis meses!  ¿Quién me va a devolver mis cuatro segundos? Así que pasé los últimos seis meses acelerándolo. Encendido y apagado.

Ronda con nuestras manos desnudas

En los albores del tiempo (2018) había un error, "la opción time_zone hace que los histogramas de fecha sean mucho más lentos ". Las zonas horarias que tenían una transición de horario de verano eran cuatro veces más lentas. @jpountz lo solucionó al interpretar la hora ignorando el horario de verano en fragmentos que no contienen ninguna transición de horario de verano. ¡Fue bueno porque las zonas horarias sin transición son fáciles! Simplemente reste su compensación de UTC, redondee, agregue la compensación nuevamente y haga su agregación. Bueno, no lo haces. La CPU lo hace. Pero aún. Sucede. Entiendes la idea.

Así que date_histogramfue rápido. ¡Pero cada seis meses se ralentizaba! Es bastante común tener aproximadamente el valor de un día de datos en un índice. Si tiene que ejecutar date_histogramuno de los índices con la transición del horario de verano, sería lento. En el momento en que me enteré, el redondeo de la fecha era aproximadamente un 1400% más lento que en los fragmentos con una transición de horario de verano.

Resulta que estábamos usando las java.util.timeAPI que son hermosas y precisas y cubren todo, pero asignan objetos. Y realmente desea evitar crear nuevos objetos para cada valor en una agregación. Así que nos quitamos los guantes e implementamos nuestro propio código de conversión de horario de verano personalizado específicamente para redondear los tiempos de la forma en que lo date_histogramhace. Ahora, en lugar de asignar, podemos construir una matriz con todas las transiciones del horario de verano visibles para el fragmento y solo realizar una búsqueda binaria. ¡Eso es rápido! Incluso cuando el fragmento tiene miles de transiciones. El tiempo logarítmico es algo maravilloso.

Deja de redondear

Pero si va a precalcular todas las transiciones del horario de verano en todos los datos del fragmento, ¿por qué no podría precalcular todos los "puntos de redondeo"? Todas las claves para cada balde que date_histogrampueda producir. Cuando estábamos haciendo nuestra API de redondeo de "guantes fuera", hicimos todo el trabajo para hacer fluir las fechas mínima y máxima en el índice en todos los lugares correctos, de modo que pudiera comenzar con el mínimo y luego obtener el siguiente valor de redondeo hasta has pasado el máximo, mételo en una matriz y busca binaria * eso *. Entonces no necesitaría llamar al código de redondeo de fecha en absoluto. Que resultaque esto siempre es más rápido. Bueno, casi siempre. Si tiene una mano llena de documentos en un intervalo de tiempo enorme, entonces no lo es. Pero también es bastante rápido. Una vez más, el tiempo logarítmico es algo maravilloso.

Empezar a filtrar

Ligera tangente: @polyfractal tenía la idea de que se podía acelerar la agregación del rango mirando el índice de búsqueda en lugar de los valores del documento. Mostró un aumento de velocidad bastante convincente, pero no queríamos fusionar el prototipo porque sería costoso de mantener y la gente no usa mucho la agregación de rango.

Pero nos dimos cuenta de que si ha calculado previamente todos los "puntos de redondeo" de un date_histogram, puede convertirlo en una agregación de rango . Y si usa el índice de búsqueda para esa agregación de rango tal como el prototipo de @ polyfractal, obtuvo un aumento de velocidad 8x. Y vale la pena mantener la optimización para la agregación de rango ahora que está impulsando una optimización para la date_histogramagregación.

Esta es la primera vez que convertimos una agregación en otra para ejecutarla de manera más eficiente. Y de hecho lo estamos haciendo dos veces. Convertimos el date_histogram en una agregación de rango y luego convertimos la agregación de rango en una agregación de filtros . La agregación de filtros nunca ha sido tan rápida. Así que escribimos un modo de ejecución "filtro por filtro" que produce los resultados correctos en algunos casos y simplemente no lo usamos en los otros casos. Entonces, la secuencia de eventos es la siguiente:

 

Por que esto funciona

Lo bueno de esto es que puede subirse al "tren de optimización" en cualquier parada del camino. las agregaciones de rango comprobarán si pueden ejecutar "filtro por filtro". También filtrará las agregaciones.

No tiene la carga de mantenimiento que tuvo la optimización específica de rango porque solo tenemos que mantener el nuevo mecanismo de ejecución "filtro por filtro" y la agregación se reescribe. Y probablemente podamos acelerar más aggs con otras reescrituras. ¿Podríamos reescribir agregaciones de términos en agregaciones de filtros y obtener la misma optimización? ¡Probablemente! ¿Podemos optimizar una agregación de términos dentro de una date_histogramagregación pensando en ella como una agregación de filtros en lugar de otra agregación de filtros? Tal vez. ¿Podríamos hacer la agregación de geo-distancias como filtros en forma de anillo ? Probablemente, pero puede que no sea más rápido. ¿Valdría la pena hacerlo incluso si no es intrínsecamente más rápido solo para reducir el conjunto de trabajo? Será divertido descubrirlo.

Así que este mundo feliz necesita nuevos puntos de referencia . Confiamos en JMH para los microbenchmarks y en Rally para nuestros macrobenchmarks . Realizamos Rally todas las noches y publicamos los resultados. Pero esa es una historia para otra publicación de blog.

Además, es divertido ver que su trabajo hace que los gráficos se vean mejor. Ha sido un viaje divertido en general. He leído más montaje en el último año que en los últimos 15 años juntos. Siempre damos la bienvenida a las contribuciones y si desea que le paguen para contribuir a tiempo completo, estamos contratando . Y usted también puede experimentar la excitante velocidad de las agregaciones "filtro por filtro" en Elastic Cloud el día que se lanza Elasticsearch 7.11.0.