在使用 ElasticSearch 进行搜索时，很多小伙伴会遇到“深度分页”问题。当需要获取大量的分页数据时，查询性能会急剧下降，甚至导致集群负载过高。这篇文章将深入剖析 ElasticSearch 深度分页的成因、危害，并提供一些常用的优化方案。

---

一、什么是深度分页？

深度分页的定义

在 ElasticSearch 中，我们可以通过 from 和 size 参数进行分页控制：

GET /my_index/_search
{
  "from": 0,
  "size": 10
}

• from：跳过的记录数
• size：返回的记录数

例如，from=1000 和 size=10 表示跳过前 1000 条记录，从第 1001 条开始获取 10 条记录。

深度分页就是：

        当 from 参数的值很大时（如 from=10000 以上），ElasticSearch 需要跳过大量数据来获取指定页的内容，这种情况称为深度分页。

深度分页的危害

在 ElasticSearch 中，数据是存储在多个分片（Shard）上的，每个分片本质上是一个独立的 Lucene 索引。分页查询会在每个分片上独立执行查询，然后将结果合并和排序。理解深度分页的危害需要从 ElasticSearch 的分布式架构和分片查询流程入手。

分片查询的工作原理

• 分布式存储
  当一个索引被分配多个分片（例如，5 个分片）时，数据会被均匀分布到不同分片上。每个分片可以分布在不同的节点上。

• 并行查询
  当进行查询时，ElasticSearch 会将查询请求发送到所有分片，每个分片独立执行查询并返回结果。

• 结果合并
  收集每个分片返回的结果后，ElasticSearch 在协调节点上进行全局排序和合并，最终返回指定的 from 和 size 范围内的结果。

深度分页时分片的执行流程

GET /my_index/_search
{
  "from": 10000,
  "size": 10
}

• 每个分片分别查询
  每个分片都会独立查询出至少 from + size = 10010 条数据。

• 本地排序
  每个分片对这 10010 条数据进行排序。

• 返回数据
  每个分片返回排序后的前 10010 条数据到协调节点。

• 全局排序与裁剪
  协调节点将所有分片的结果合并，然后进行全局排序，并在这些结果中取第 10000 到 10010 条数据，最终返回给用户。

深度分页的危害剖析

我们分析一下上述过程，这会带来一些什么危害呢

内存消耗急剧增加

• 分片内存开销：
  每个分片需要在内存中加载 from + size 条数据（例如 10010 条）。如果分片较多且数据量庞大，这会导致每个分片消耗大量内存。

• 协调节点内存开销：
  协调节点需要收集所有分片返回的大量数据，并在内存中进行全局排序。这可能导致内存溢出（OOM）。

磁盘和 CPU 负载增加

• 分片读取开销：
  为了跳过大量数据，每个分片必须从磁盘中读取大量文档，增加了 I/O 开销。

• 排序计算开销：
  每个分片需要对大量数据进行排序，然后协调节点需要再进行全局排序，增加了 CPU 计算负担。

查询延迟显著增加

• 线性增长的延迟：
  随着 from 值增大，每个分片需要加载和处理的数据量增多，导致查询延迟线性增加。例如，从第 10000 条开始获取数据的延迟会远高于从第 100 条开始获取数据。

集群稳定性风险

• 节点压力：
  大量内存和 CPU 的消耗会增加分片所在节点的负载，严重时可能导致节点性能下降甚至崩溃。

• 全局影响：
  单个深度分页查询可能拖垮整个集群，影响其他正常查询的性能，降低服务可用性。

二、ES中的深度分页方式

如果使用from、size来实现ES的分页查询，我们将会面临深度分页问题，但是我们又想进行深度分页，ES如何解决呢，我们来看下面两种分页方式

Scroll滚动查询

如何解决深度分页

在 ElasticSearch 中，使用传统的分页方式（from + size）进行深度分页会导致性能急剧下降。比如，当你查询第 10000 页的数据时，from 设置为 999900，这意味着 ElasticSearch 需要扫描前 999900 条记录并将其加载到内存中，再丢弃这些记录，只保留最后 100 条。这种操作不仅浪费大量内存，而且延迟非常高。

Scroll 滚动查询通过引入游标机制和数据快照，有效地避免了这种大规模跳过数据带来的性能问题。

举个例子：

假设你需要从一张 100 万条记录的大表中导出所有数据。如果使用传统分页方法（from + size），当你查询第 10000 页时，ElasticSearch 需要先扫描和加载前 999900 条数据，再丢弃它们，仅返回你需要的 100 条数据。这就像每次找第 10000 本书，都要从第 1 本开始数到第 10000 本，既费时又耗力。

而使用 Scroll 滚动查询 就像拥有一个记忆书签，每次查询都会在你停下的地方做个标记，下次直接从这个标记处继续，不需要重新扫描前面的数据。它通过创建一个数据快照（Snapshot），固定查询时的数据状态，并维护一个滚动上下文，保证每次返回数据的同时保存位置，避免重复扫描。

使用方式

初始化滚动查询

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

• scroll=1m：滚动上下文有效期为 1 分钟。
• size=100：每次返回 100 条记录。

响应如下：

获取下一批数据

GET /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAA..."
}

响应也是和上面的响应结构相同，只是返回的scroll_id不同 

清理滚动上下文

完成查询后，及时清理滚动上下文以释放内存：

DELETE /_search/scroll
{
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoAwAAAAAAA..."
}

优缺点

• 优点：

  • 避免跳过大量数据，性能稳定。
  • 保持数据一致性，适合处理大量数据的场景。
  • 不受 max_result_window 限制，可以获取超过 10000 条的数据。

• 缺点：

  • 内存占用：滚动上下文会占用内存，需要及时释放。
  • 只适用于静态数据：动态更新的数据在滚动过程中不会反映最新变化。
  • 只能向前遍历，不支持随机跳转。

使用场景

• 数据导出：将索引中的数据批量导出到外部存储。
• 日志分析：批量分析和处理日志数据。
• 批处理任务：需要处理大量数据的离线任务，如数据迁移和备份。

滚动查询的工作原理

1. 创建快照：
   第一次查询时，ElasticSearch 为查询结果集创建一个快照，该快照保持数据的一致性，即使在滚动查询过程中有新的数据写入索引，查询结果依然基于快照的数据集，不受新数据影响。

2. 分批读取：
   每次滚动查询返回指定数量的数据（例如 100 条），并生成一个 _scroll_id，作为指向下一批数据的游标。ElasticSearch 会根据这个游标继续从上次结束的位置读取下一批数据，而无需重新扫描前面的数据。

3. 游标推进：
   每次查询会返回新的 _scroll_id，用于后续请求。你只需提供这个 _scroll_id，ElasticSearch 就能知道从哪里继续查找，而不必跳过大量记录。

search_after

如何解决深度分页

search_after 通过使用上一页最后一条记录的排序值来定位下一页的起始点，避免了传统分页需要跳过大量数据的问题。这种方法在需要实时展示大量数据时特别有效。

举个例子：
想象你在一个电子商城里查看商品，商品按价格升序排列。传统的分页就像数到第 10000 个商品，跳过前 9999 个才能展示出来。而 search_after 则是记住第 100 条商品的价格和编号，下次从这个位置直接继续展示第 101 条商品，不用重新扫描前面的商品。

使用方式

第一次查询

GET /my_index/_search
{
  "size": 10,
  "sort": [
    { "price": "asc" },
    { "_id": "asc" }
  ]
}

后续查询

使用上一页最后一条记录的排序值作为 search_after 参数，获取下一页数据。

GET /my_index/_search
{
  "size": 10,
  "sort": [
    { "price": "asc" },
    { "_id": "asc" }
  ],
  "search_after": [ 199.99, "product_12345" ]
}

优缺点

• 优点：

  • 高效分页：避免跳过大量数据，查询性能稳定。
  • 内存占用小：无状态查询，不需要维护上下文。
  • 实时性强：适合动态数据的实时分页。

• 缺点：

  • 只能向前分页：无法跳转到任意页，只能按顺序向前获取数据。
  • 排序要求：必须有唯一的排序字段组合，确保结果的唯一性。

使用场景

• 实时数据展示：新闻、商品、用户动态等实时数据的分页查询。
• 日志检索：按时间戳顺序查询和分析日志。
• 动态数据分析：需要连续获取新数据并按特定顺序排列的场景。

search_after的工作原理

1. 排序值标记位置：
   每次查询结果都会包含排序字段的值（例如 price 和 _id）。search_after 通过这些值标记当前位置，下次查询时从这个位置继续。

2. 避免跳过数据：
   不使用 from 来跳过记录，而是精确地从上次查询的最后位置开始读取。

3. 无状态查询：
   每次查询都是独立的，不需要在服务器上维持上下文，节省内存。

PIT与search_after结合

为什么 search_after 需要配合 PIT（Point in Time）？

直接使用 search_after 进行分页确实可行，但在某些场景下，它有显著的局限性，而引入 PIT（Point in Time） 可以有效解决这些问题。下面我们来详细解释为什么需要结合 PIT，以及它带来的优势。

直接使用 search_after 的问题

1. 数据不一致性
   如果在分页查询过程中，索引中的数据发生了变化（例如新增、更新或删除文档），每次查询返回的结果可能会受到这些变化的影响，导致数据不一致。

   示例场景：

   • 第一次查询：你获取了排序后第 100 条记录，排序字段的值是 timestamp: 2024-06-16T10:00:00。
   • 在第二次查询之前：有一条新的记录被插入，排序值正好在你上次获取的记录之前。
   • 第二次查询：当你使用 search_after 进行下一页查询时，结果集可能会跳过或重复某些记录，导致分页不连续。

2. 并发查询干扰
   当多个查询或数据写入操作并发进行时，直接使用 search_after 的分页请求很容易受到其他操作的干扰，导致分页结果不可预测。

3. 无法保证长时间分页
   在长时间的分页操作中，数据的变化可能越来越多，导致分页的连续性和完整性无法保证。

PIT（Point in Time）如何解决这些问题

PIT 通过在查询开始时创建一个固定数据视图来解决上述问题。具体来说：

1. 数据一致性保证

   • 固定视图：PIT 创建时会固定一个数据视图，即使索引中新增、更新或删除了数据，PIT 下的查询结果集不会受到这些变化的影响。
   • 这意味着所有的分页请求都会基于创建 PIT 时的数据快照进行，保证分页结果的连续性和一致性。

   举例说明：
   想象你正在看一张快照照片，这张照片捕捉了某一瞬间的所有信息。即使在现实中事物发生了变化，照片里的信息依然保持不变。PIT 就像这样一张数据的快照，让你在分页时始终看到快照时刻的结果。

2. 避免并发干扰

   • PIT 创建的数据视图是独立的，不会受到其他并发查询或写入操作的干扰。因此，即使在高并发场景下，你的分页查询也能保持稳定。

3. 长时间分页安全

   • 通过设置合适的 keep_alive 时间（如 1m、5m），PIT 可以保持长时间有效，支持长时间的分页操作而不会因为数据变化导致分页结果混乱。

PIT+search_after使用方式

1.创建 PIT 视图
创建一个固定的数据视图，并设置有效期（如 1 分钟）：

POST /my_index/_search?keep_alive=1m
{
  "size": 10,
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }
  ]
}

返回的 pit_id 用于后续分页请求。

2.分页查询
使用 pit_id 和 search_after 进行分页：

POST /_search
{
  "size": 10,
  "pit": {
    "id": "46ToAwMDaWR...ZmZjZTg",
    "keep_alive": "1m"
  },
  "sort": [
    { "timestamp": "asc" },
    { "_id": "asc" }
  ],
  "search_after": [ "2024-06-16T10:00:00", "record_123" ]
}

3.关闭 PIT 视图
分页完成后，关闭 PIT 释放资源：

DELETE /_pit
{
  "id": "46ToAwMDaWR...ZmZjZTg"
}