ElasticSearch中Scroll与Search After深度分页技术对比

在ElasticSearch中，深度分页是一个常见的需求，特别是在处理大量数据时。然而，传统的from和size方式在深度分页时会导致性能问题，因为ElasticSearch需要维护大量的排序状态。为了解决这一问题，ElasticSearch提供了两种替代方案：Scroll和Search After。本文将对这两种技术进行深入解析，并对比它们的适用场景。

1. Scroll API

基本概念

Scroll API是一种用于高效遍历大规模数据集的技术。它通过创建一个快照（snapshot）来保存当前索引的状态，并允许用户逐步获取数据，而无需一次性加载所有结果。

使用步骤

以下是使用Scroll API的基本步骤：

1. 初始化Scroll
   首先，执行一次搜索请求并指定scroll参数，例如1m表示快照的有效时间为1分钟。

   POST /my_index/_search?scroll=1m
   {
     "query": { "match_all": {} },
     "size": 100
   }
   

2. 获取Scroll ID
   在响应中会返回一个_scroll_id，用于后续的滚动操作。

3. 继续滚动
   使用_scroll_id向_search/scroll端点发送请求以获取下一批数据。

   POST /_search/scroll
   {
     "scroll": "1m",
     "scroll_id": "your_scroll_id"
   }
   

4. 清理Scroll
   完成数据处理后，记得清除快照以释放资源。

   DELETE /_search/scroll/{scroll_id}
   

优点

• 适合大批量数据的导出或离线分析。
• 不依赖于文档的排序顺序。

缺点

• 快照机制会占用内存，不适合长时间运行的任务。
• 数据可能会因快照而变得陈旧。

2. Search After API

基本概念

Search After是一种基于游标的分页技术，它通过使用上一批结果中的排序值作为起点，逐步获取下一批数据。

使用步骤

以下是使用Search After的基本步骤：

1. 初始化搜索
   执行第一次搜索请求时，指定排序字段和方向。

   POST /my_index/_search
   {
     "query": { "match_all": {} },
     "sort": [
       { "timestamp": "asc" },
       { "_id": "asc" }
     ],
     "size": 100
   }
   

2. 提取游标值
   从响应的hits.hits中提取最后一个文档的排序值（即游标）。

3. 继续搜索
   使用提取的游标值发起下一次搜索请求。

   POST /my_index/_search
   {
     "query": { "match_all": {} },
     "search_after": [1609459200000, "AWaX..."],
     "sort": [
       { "timestamp": "asc" },
       { "_id": "asc" }
     ],
     "size": 100
   }
   

优点

• 不需要创建快照，因此对内存的消耗较小。
• 数据始终保持最新。

缺点

• 需要明确的排序规则，且排序字段必须是数值型或日期型。
• 如果排序字段有重复值，可能需要额外的字段（如_id）来确保唯一性。

3. Scroll与Search After对比

4. 示例代码对比

Scroll示例

// 初始化Scroll
POST /my_index/_search?scroll=1m
{
  "query": { "match_all": {} },
  "size": 100
}

// 滚动下一批数据
POST /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "your_scroll_id"
}

Search After示例

// 第一次搜索
POST /my_index/_search
{
  "query": { "match_all": {} },
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }
  ],
  "size": 100
}

// 下一次搜索
POST /my_index/_search
{
  "query": { "match_all": {} },
  "search_after": [1609459200000, "AWaX..."],
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }
  ],
  "size": 100
}

5. 性能优化建议

• Scroll

  • 尽量缩短快照的有效时间，减少内存占用。
  • 在任务完成后立即清理快照。

• Search After

  • 确保排序字段具有良好的分布性，避免过多重复值。
  • 结合pit（Point In Time）功能进一步提升性能。