Prefacio
在分布式系统中深度分页
理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。
Paginación
- from + size es un
método de paginación profunda común. desde significa comenzar desde la primera línea y tamaño significa cuántos documentos consultar. De los valores predeterminados a 0, el tamaño predeterminado es 10 y el tamaño no puede exceder la configuración de index.max_result_window, que tiene un valor predeterminado de 10,000. - scroll
generando un cursor para una consulta particular scroll_id, una consulta subsiguiente solo necesita obtener datos del cursor, hasta que el campo de hits devuelto por el conjunto de resultados esté vacío, significa el final del recorrido. La generación de scroll_id puede entenderse como el establecimiento de una instantánea histórica temporal, y las operaciones posteriores, como la adición, eliminación, modificación y verificación, no afectarán el resultado de esta instantánea. - search_after
proporciona un cursor activo para evitar problemas de rendimiento que consumen almacenamiento y tiempo. El último dato consultado en la página anterior se utiliza como condición de búsqueda para el siguiente dato. Debe haber un campo único global para ordenar, como el campo de identificación única de la empresa o el propio elasticsearch. campo _id.
Es adecuado para paginación profunda + clasificación, porque los datos de cada página dependen de los últimos datos de la página anterior, por lo que no se pueden realizar solicitudes de salto de página. Y los datos devueltos son siempre los más recientes, y la ubicación de los datos puede cambiar durante el proceso de paginación.
Análisis de pros y contras
| Paginación | ¿Hay un límite de páginas? | Ya sea para saltar de página | actuación | Recursos de desperdicio | tiempo real | Escenarios comunes |
|---|---|---|---|---|---|---|
| desde + tamaño | Sí, limitado por parámetros, ajustable | si | Cuanto más profunda sea la página, menor será el índice de rendimiento. | Cuanto más profunda sea la página, mayor será el aumento exponencial del consumo de recursos. | tiempo real | Se pueden cumplir escenarios de búsqueda comunes y el número de páginas debe ser limitado |
| Desplazarse | No | No | alto | El almacenamiento en caché de los resultados de la consulta para la primera consulta consume una gran cantidad de recursos, pero básicamente no tiene costo en las siguientes | no en tiempo real | Tareas de exportación por lotes en segundo plano, tareas de migración de datos |
| search_after | No | No | en | Los resultados de la consulta en caché para la primera consulta consumen más recursos y los datos posteriores se recuperan de acuerdo con los resultados de la última consulta | tiempo real | Lote de tareas con requisitos en tiempo real |
La propuesta final
Pensando: ¿Qué tipo de necesidades comerciales necesita para buscar y ver más de 10,000 datos con elasticsearch? Considere tantas condiciones como sea posible para filtrar los datos que realmente se necesitan
- La autoconsulta empresarial limita el número de páginas. Use tantas condiciones de consulta como sea posible, limite los resultados de la consulta a menos de 10,000 y use from + size para consultar de manera flexible
- Rendimiento y selección de negocios, el lado comercial restringe el método de paginación. Solo se puede consultar la página siguiente y la página no se puede omitir. De esta manera, search_after se puede utilizar para consultar