ES 的 4种分页方式，如何选择？

发表于 分类于 阅读次数： 本文字数： 3k 阅读时长 ≈ 3 分钟

你好，我是猿java

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

1. 使用 from 和 size

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

1
2
3
4
5
6
7
8
9
10
GET /index/_search
{
  "from": 10,
  "size": 10,
  "query": {
    "match": {
      "field": "value"
    }
  }
}

优点

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

缺点

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

适用场景

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

2. 使用 search_after

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
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），可以避免重复数据。

缺点

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

适用场景

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

3. 使用 Scroll API

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
POST /index/_search?scroll=1m
{
  "size": 100,
  "query": {
    "match_all": {}
  }
}

# 获取后续数据
POST /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAA..."
}

优点

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

缺点

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

适用场景

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

4. 使用 Point in Time

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
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. 如何选择?

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 是更优的选择。

6. 总结

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

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

7. 交流学习

如果你觉得文章有帮助，请帮忙转发给更多的好友，或关注公众号：猿java，持续输出硬核文章。

drawing