TL; DR: Le recomendamos que utilice la nueva funcionalidad de un momento específico en Elasticsearch si puede. La API de desplazamiento ya no se recomienda para la paginación profunda (aunque todavía funciona).

La mayoría de los datos cambian constantemente. Al consultar un índice en Elasticsearch, básicamente está buscando datos en un momento determinado. Con un índice que cambia constantemente, como en la mayoría de los casos de uso de seguridad y observabilidad, dos consultas idénticas realizadas en dos momentos diferentes arrojarán resultados diferentes porque los datos han cambiado con el tiempo. Entonces, ¿qué debe hacer si necesita eliminar esa variable de tiempo?

El lector de punto en el tiempo (PIT) , que se introdujo en Elasticsearch 7.10, le brinda la capacidad de consultar repetidamente un índice tal como estaba en un momento específico.

En un nivel alto, esto suena como la API de desplazamiento , que recupera el siguiente lote de resultados para una búsqueda de desplazamiento, pero hay una diferencia sutil que deja muy claro por qué PIT es un componente importante para futuras consultas con estado.

API de desplazamiento: una revisión rápida

La API de desplazamiento funciona así:

Una consulta de búsqueda normal se ejecuta con el scrollparámetro adjunto. Cada respuesta de búsqueda contiene un _scroll_idque debe usarse para la siguiente solicitud. Después de desplazarse por todas las respuestas, puede eliminarlo scroll_idpara liberar recursos.

The data returned is basically frozen the moment you start the initial search request. Write operations that took place after that scroll was initiated will not be part of the search response. This applies for delete, index, and update operations. This way the whole data set is guaranteed to be consistent at a certain point in time.

¿Qué sucede en segundo plano que requiere la liberación de recursos? La búsqueda de desplazamiento solo tiene en cuenta los datos en el momento en que se crea la búsqueda de desplazamiento inicial. Esto implica, en un nivel inferior, que ninguno de los recursos necesarios para devolver los datos de la solicitud inicial se modifica o elimina. Los segmentos se mantienen, aunque es posible que el segmento ya se haya fusionado y no sea necesario para el conjunto de datos en vivo. Tenga en cuenta que otras búsquedas que utilizan otro ID de desplazamiento o ningún desplazamiento se están realizando al mismo tiempo, mirando datos diferentes en comparación con la búsqueda de desplazamiento inicial. Esto da como resultado mantener más datos que solo el conjunto de datos en vivo. Más datos significa más segmentos, más identificadores de archivos y más montón para mantener los metadatos de los segmentos en el montón.

Mantener los segmentos que no son necesarios para los datos en vivo también significa que necesita más espacio en el disco para mantener esos segmentos activos, ya que no se pueden eliminar hasta que se elimine la identificación de desplazamiento. La forma en que esto funciona internamente es mediante el recuento de referencias. Siempre que haya un componente (como una búsqueda de desplazamiento) que contenga una referencia a los datos (por ejemplo, a través de un identificador de archivo abierto contra un inodo), no habrá una eliminación final de esos datos, aunque no formen parte del conjunto de datos en vivo. nunca más. Esta es también la razón por la que existe el ID de desplazamiento. Al especificarlo como parte de la consulta, está especificando qué estado desea consultar.

Para liberar recursos lo antes posible, recomendamos utilizar la API de desplazamiento transparente . También hay optimizaciones como el desplazamiento en rodajas disponibles para paralelizar la recuperación de datos.

Más información: Blog Elastic