Prefácio
在分布式系统中深度分页
理解为什么深度分页是有问题的，我们可以假设在一个有 5 个主分片的索引中搜索。 当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。
现在假设我们请求第 1000 页--结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。 然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。
可以看到，在分布式系统中，对结果排序的成本随分页的深度成指数上升。这就是 web 搜索引擎对任何查询都不要返回超过 1000 个结果的原因。
Paginação
- from + size é um
método de paginação profunda comum. de significa começar na primeira linha e tamanho significa quantos documentos consultar. De é 0 por padrão, o tamanho é 10 por padrão e o tamanho do tamanho não pode exceder a configuração de index.max_result_window, que é 10.000 por padrão. - scroll
gerando um cursor para uma consulta específica scroll_id, uma consulta subsequente só precisa buscar dados do cursor, até que o campo de ocorrências retornado do conjunto de resultados esteja vazio, isso significa o fim do percurso. A geração de scroll_id pode ser entendida como o estabelecimento de um instantâneo histórico temporário, e adições, exclusões, alterações e outras operações subsequentes não afetarão os resultados deste instantâneo. - search_after
fornece um cursor ao vivo para evitar problemas de desempenho que consomem armazenamento e tempo. O último dado consultado na página anterior é usado como condição de pesquisa para o próximo dado. Deve haver um campo globalmente exclusivo para classificar, como o campo de identificação exclusivo da empresa ou o próprio elasticsearch campo _id.
É adequado para paginação + classificação profunda, porque os dados de cada página dependem dos últimos dados da página anterior, portanto, as solicitações de salto de página não podem ser feitas. E os dados retornados são sempre os mais recentes e a localização dos dados pode mudar durante o processo de paginação.
Análise de prós e contras
| Paginação | Existe um limite de páginas | Se pular página | desempenho | Resíduos de recursos | tempo real | Cenários comuns |
|---|---|---|---|---|---|---|
| de + tamanho | Sim, limitado por parâmetros, ajustável | sim | Quanto mais profunda a página, menor o índice de desempenho | Quanto mais profunda a página, o aumento exponencial no consumo de recursos | tempo real | Cenários de pesquisa comuns podem ser atendidos e o número de páginas deve ser limitado |
| rolagem | não | não | Alto | Armazenar em cache os resultados da consulta para a primeira consulta consome muitos recursos e basicamente não há custo nas consultas subsequentes | não em tempo real | Tarefas de exportação em lote em segundo plano, tarefas de migração de dados |
| search_after | não | não | no | Os resultados da consulta em cache para a primeira consulta consomem mais recursos e os dados subsequentes são recuperados de acordo com os resultados da última consulta | tempo real | Tarefas em lote com requisitos em tempo real |
A proposta final
Pensando: Que tipo de necessidades de negócios você precisa para pesquisar e visualizar mais de 10.000 dados com o elasticsearch? Considere tantas condições quanto possível para filtrar os dados que são realmente necessários
- A auto-investigação comercial limita o número de páginas. Use o máximo de condições de consulta possível, limite os resultados da consulta a menos de 10.000 e use from + size para consultar com flexibilidade
- Desempenho e seleção de negócios, o lado comercial restringe o método de paginação. Apenas a próxima página pode ser consultada e a página não pode ser ignorada. Desta forma, search_after pode ser usado para consultar