ES 的 4种分页方案 - 文章 - 开发者社区

在 Elasticsearch 中，有 4种常见的分页方法，这篇文章，我们将分析每种方法的优缺点以及我们该如何选择。

使用 from 和 size =====================

使用 from 和 size是最常用的分页方式，通过设置 from 参数指定从结果集的哪个位置开始，size 参数指定返回多少条记录。使用语法如下：

  
GET /index/\_search  
{  
  "from": 10,  
  "size": 10,  
  "query": {  
    "match": {  
      "field": "value"  
    }  
  }  
}

优点

简单易用 ：实现起来非常直观，适用于大多数基本的分页需求。
广泛支持 ：Elasticsearch 搜索 API 默认支持这种分页方式。

缺点

性能问题 ：对于深页（高 from 值），性能会显著下降，因为 Elasticsearch 需要跳过前面的 from 条记录。这会导致查询时间增加，尤其是当 from 值较大时。
资源消耗 ：高 from 值会消耗更多的内存和CPU资源，可能影响集群性能。

适用场景

浅分页 ：适用于前几页的查询（例如，第1页到第10页）。
小数据集 ：当数据量较小且分页需求不复杂时。

使用 search\_after =====================

search\_after基于排序值实现深度分页，通过提供上一个页面的排序值来继续检索下一页的数据。使用语法如下：

  
GET /index/\_search  
{  
"size": 10,  
"query": {  
    "match": {  
      "field": "value"  
    }  
  },  
"sort": [  
    { "timestamp": "asc" },  
    { "\_id": "asc" }  
  ],  
"search\_after": [ "2023-01-01T00:00:00", "some\_id" ]  
}

优点

高效深度分页 ：相比 from/size ， search\_after 在处理深层分页时性能更好，不会随着页数增加而显著下降。
去重性强 ：结合唯一排序字段（如 \_id ），可以避免重复数据。

缺点

状态管理 ：需要在客户端保存上一次查询返回的排序值，增加了实现复杂度。
不可跳页 ：无法像传统分页那样直接跳转到任意页，只能顺序翻页。

适用场景

深度分页 ：适用于需要访问大量数据且需要高效性能的场景。
数据连续流 ：适合数据流式访问，如日志检索、实时数据分析等。

使用 Scroll API ================

Scroll API适用于处理大量数据的批量检索，通过保持一个在查询时刻的快照，允许用户遍历整个结果集。使用语法如下：

  
POST /index/\_search?scroll=1m  
{  
"size": 100,  
"query": {  
    "match\_all": {}  
  }  
}  
  
# 获取后续数据  
POST /\_search/scroll  
{  
"scroll": "1m",  
"scroll\_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA..."  
}

优点

处理大量数据 ：适合导出或批量处理大量数据，性能稳定。
避免跳页问题 ：通过持续的快照避免数据在检索过程中变化影响结果。

缺点

资源消耗 ：保持 scroll 上下文会占用集群资源，尤其是在并发请求较高时。
不适合实时搜索 ：Scroll API 主要用于一次性检索，不适合用户交互的分页需求。

适用场景

批量数据导出 ：如数据迁移、备份等。
大规模分析 ：需要一次性处理大量文档的场景。

使用 Point in Time ===================

使用 Point in Time (PIT)提供了一种基于时间点的查询方式，允许在多个分页请求中维持一致的视图。使用语法如下：

  
POST /index/\_search?pit=true&size=10  
{  
"sort": [...],  
"query": { ... }  
}  
  
# 后续请求使用 pit\_id  
POST /index/\_search  
{  
"pit": {  
    "id": "some\_pit\_id",  
    "keep\_alive": "1m"  
  },  
"sort": [...],  
"query": { ... },  
"search\_after": [ ... ]  
}

优点

一致性视图 ：在多个分页请求中保持数据的一致性，即使索引发生变化。
结合 search_after 使用 ：提高深度分页的效率和一致性。

缺点

复杂度增加 ：需要管理 PIT 会话，包括生命周期和资源释放。
资源消耗 ：维持 PIT 会话会占用集群资源。

适用场景

需要一致性分页 ：如多用户同时分页浏览数据，确保每个用户看到的数据一致。
结合 search_after ：需要高效的深度分页且保持一致视图的场景。

如何选择? ========

5.1 根据分页深度选择

浅分页（前几页） ：使用 from 和 size ，实现简单且性能可接受。
深度分页 ：使用 search\_after 或结合 Point in Time ，提高性能并避免资源浪费。

5.2 根据数据一致性要求

无需严格一致性 ： from 和 size 已足够，适用于数据不频繁变动的场景。
需要一致性视图 ：使用 Point in Time ，确保分页过程中数据的一致性。

5.3 根据使用场景

用户交互分页 ：通常使用 from 和 size ，适合大多数 Web 应用分页需求。
批量处理或导出 ：使用 Scroll API，适合一次性处理大量数据的任务。

5.4 根据资源和性能考虑

资源有限 ：避免使用 Scroll API，尤其是在高并发环境下。
性能优化 ：对于频繁的深度分页， search\_after 和 Point in Time 是更优的选择。

总结 =====

本文，我们介绍了 ES的4种分页方式：

from 和 size ：适用于浅分页，简单易用，但不适合深度分页。
search\_after ：适合深度分页，性能更优，但实现复杂度略高，且不支持随机跳页。
Scroll API ：适用于批量处理和导出，不适合实时用户交互的分页需求。
Point in Time (PIT) ：提供一致的分页视图，适合需要数据一致性的深度分页场景。

在实际开发中，我们需要根据具体的业务需求、数据量、分页深度和系统资源，选择最合适的分页方法，以达到最佳的性能和用户体验。

最后欢迎加入苏三的星球，你将获得：智能天气播报AI Agent、SaaS点餐系统（DDD+多租户）、100万QPS短链系统（超过并发）、复杂的商城微服务系统（分布式）、苏三商城系统、苏三AI项目、刷题吧小程序、秒杀系统、码猿简历网站、代码生成工具等10个项目的源代码、开发教程和技术答疑。系统设计、性能优化、技术选型、底层原理、Spring源码解读、工作经验分享、痛点问题、面试八股文等多个优质专栏。

还有1V1免费修改简历、技术答疑、职业规划、送书活动、技术交流。

扫描下方二维码，可以加入星球：

picture.image

数量有限，先到先得。目前星球已经更新了6100+篇优质内容，还在持续爆肝中.....

星球已经被官方推荐了3次，收到了小伙伴们的一致好评。戳我加入学习，已有2100+小伙伴加入学习。