Elasticsearch Java滚动查询实现大数据分批检索

这段代码是使用 Elasticsearch Java 客户端进行滚动查询 的典型操作。它分为两个步骤：

第一段代码：初始化滚动查询

SearchRequest searchRequest = SearchRequest.of(r -> r
        .index(EsProhibitionPushData.INDEX_NAME) // 指定要搜索的索引
        .scroll(Time.of(t -> t.time("5m")))      // 开启滚动，设置游标存活时间为5分钟
        .sort(s -> s.field(f -> f.field("_id").order(SortOrder.Asc))) // 按_id排序，保证滚动顺序一致
        .size(pageSize));                        // 设置每次滚动返回的文档数量

这行代码的作用是创建初始搜索请求。它执行一次搜索，但不同于普通搜索，它告诉 Elasticsearch 准备一个持续5分钟的“游标”（scroll），并按照_id排序后，返回第一批（pageSize条）数据。这次调用会返回一个重要的 scrollId。

第二段代码：获取后续批次

SearchResponse<JsonNode> scrollResponse = esService.scrollSearch(scrollId);

这行代码的作用是使用上一步得到的 scrollId，去获取下一批数据。在得到第一段的响应后，取出其中的 scrollId，然后循环调用这个 scrollSearch 方法，Elasticsearch 就会基于之前的游标，返回下一批 pageSize 条数据，直到所有匹配的文档都被取完。

简单总结： 这是一个分批读取大量数据的标准方法。

1. 第一段：发起搜索，建立通道，拿到第一批数据和通行证（scrollId）。
2. 第二段：使用通行证（scrollId），反复调用，一批一批地获取所有剩余数据，直到取完为止。

完全一样，并且必须一样。

这正是滚动查询的核心设计：scrollId 就是您“之前所有查询条件”的封装和代表。

详细解释如下：

1. scrollId 的本质：当您发送第一个包含 scroll=5m 的搜索请求时，Elasticsearch 会做两件事：

   • 执行您定义的查询（包括索引、排序、过滤条件、分页大小等）。
   • 在服务端为这次特定的查询会话创建一个临时的、带状态的上下文（快照视图），并生成一个唯一的 scrollId 来指向这个上下文。

2. 后续请求的作用：后续的 scrollSearch(scrollId) 请求只需要这个 scrollId。您不再需要，也不应该再次传递 index、query、sort、size 等任何初始条件。

   • Elasticsearch 收到 scrollId 后，就能找到之前创建的那个上下文，并从中取出“下一页”数据。
   • 这意味着，后续所有通过同一个 scrollId 获取的数据批次，都严格遵循最初的那个查询条件。您无法通过同一个 scrollId 中途改变查询。

一个比喻：

• 初始化请求：像在图书馆办一张特定主题的借阅卡（例如“所有历史书，按出版日期排序，一次最多借5本”）。这张卡（scrollId）就代表了这个完整的请求。
• 后续 scrollSearch 请求：您每次拿着这张卡（scrollId）去柜台，管理员就会按当初的约定（历史书、按日期排序、每次5本），给您下一批5本书。您不需要每次都重复说明要什么书、怎么排序。

重要注意事项：

• 排序一致性：您的代码中显式指定了按 _id 排序，这非常好。滚动查询必须有一个确定的排序规则，否则在多次请求中，数据的顺序可能发生变化，导致遗漏或重复。
• 资源释放：scroll 上下文在服务端会消耗资源。获取完所有数据后，应主动清除它（使用 ClearScrollRequest），或者等待其超时（代码中设置的5m）后由ES自动清理。

所以，请放心，scrollId 已经包含了全部初始查询信息，后续调用只需要传递这个ID即可，保证您得到的是同一查询条件下的后续数据批次。

是的，滚动查询正是 Elasticsearch 解决“深分页”问题的经典方案。它的原理是：避免重复计算和跳过，改用“游标”连续遍历。

为什么传统分页有“深分页”问题？

当使用 from 和 size 进行分页时（例如 from=10000, size=10）：

1. 协调节点必须向所有相关分片请求数据。
2. 每个分片都需要在自己的数据中，构建一个长度为 from + size 的优先队列，找出本分片的前 (from + size) 条记录，然后返回给协调节点。
3. 协调节点汇总所有分片的结果，再进行全局排序，最终才能取出第 10000 到 10010 条记录。

问题：随着 from 值增大，每个分片需要构建的队列越来越大，消耗的内存、CPU 和网络带宽急剧上升，性能会指数级下降，甚至导致节点崩溃。

Scroll 如何规避这个问题？（原理）

Scroll 不进行跳跃计算，而是顺序流式读取，其核心机制如下：

1. 创建快照和上下文：

   • 在第一次查询时，Elasticsearch 会为当前查询条件创建一个数据快照视图（search context）。这个视图会冻结索引在那一刻的状态，后续的数据变更不会影响这次滚动查询的结果。
   • 该上下文维护了每个分片当前的读取位置（类似于一个游标）。

2. 基于游标的顺序读取：

   • 初始查询返回第一批数据（例如 size=100 条）。
   • 当您拿着返回的 scrollId 请求下一批时，Elasticsearch 会根据这个ID找到对应的上下文，然后直接在每个分片上游标的位置，继续往后读取下 size 条数据。
   • *它不需要为了获取第N批数据而重新排序、跳过前面的 (N-1)size 条记录。每次请求只是在上次停止的地方继续拿下一批。

类比：

• 传统深分页：像看书时，每次想知道第100页的内容，都必须从第1页数到第100页。
• 滚动查询：在第一次请求时放一个书签在第一页末尾。之后每次说“下一页”，就直接从书签处开始读。书签（scrollId）帮你记住了每个分片的阅读进度。

总结对比

因此，您的代码使用 scroll 来批量获取数据，正是避开了“深分页”的性能陷阱，适合大数据量的批处理场景。

您的问题问到了滚动查询最核心的机制。答案是：是的，完全正确。 其有序性和数据确定性正是通过您提到的两点来保证的。

下面详细解释这个过程：

1. 如何保证“有序”？

原理：排序条件在第一次请求时被锁定，并在整个滚动过程中被严格遵守。

• 首次确定排序规则：在您的代码中，sort(s -> s.field(f -> f.field(“_id”).order(SortOrder.Asc))) 这个排序条件在第一次请求时就已经被定义，并成为整个滚动会话的“宪法”。
• 分片级别的有序遍历：每个分片接收到这个请求后，会根据 _id 对自己的那部分数据进行排序。滚动上下文会为每个分片维护一个指向其已排序数据列表的“游标”。
• 全局归并有序输出：当您请求下一批数据时，协调节点会向所有相关分片询问：“在你们已排序的列表上，从各自当前的游标位置开始，再给我接下来的N条。” 协调节点收集到所有分片返回的这一小段有序数据后，会再次执行全局归并排序（按照首次设定的 _id 规则），然后将最终有序的一批数据返回给您。

所以，有序的保证是：全局排序规则 + 分片局部游标 + 协调节点的归并。

2. 第一次就确定所有的数据了吗？

是的，完全正确。这是滚动查询的另一个基石：数据快照。

• 创建快照：在您执行第一个包含 scroll=5m 的搜索请求的那一刻，Elasticsearch 会为这次查询创建一个搜索上下文。这个上下文会冻结索引在那一刻的视图。
• 快照的效果：这意味着，即使后续滚动查询持续了5分钟，在这5分钟内，有新的文档写入、旧的文档被删除或更新，都不会影响到您这次滚动查询所遍历到的结果集。您遍历的始终是第一次请求那个时间点的数据状态。
• 为什么需要快照？ 这保证了数据一致性。如果没有快照，在您分批读取数据的过程中，如果数据发生变更，您可能会遇到：
  • 重复数据：某条记录在上一批被读取后，因为更新而排序值改变，又出现在下一批。
  • 丢失数据：某条记录本应出现在下一批，但在读取前被删除了。

整个过程模拟（结合您的代码）

1. 初始化请求 (SearchRequest):

   • 时刻 T0：请求到达。ES 为索引 EsProhibitionPushData.INDEX_NAME 在 T0 时刻创建快照。
   • 确定数据集：对所有符合条件的数据，按 _id 升序排列，并确定总数。
   • 返回：全局排序后的前 pageSize 条数据 + 一个 scrollId（此ID编码了：快照信息、排序规则、各分片当前游标位置）。

2. 后续滚动请求 (esService.scrollSearch(scrollId)):

   • 将 scrollId 发给 ES。
   • ES 解码出快照、规则和游标，指挥各分片：“从你们上次停止的游标位置开始，在T0时刻的快照数据中，按_id排序，再取接下来 pageSize 条。”
   • 协调节点汇总、归并排序，返回下一批全局有序的数据，并更新 scrollId 中的游标位置。
   • 重复此过程，直到数据被取完。

总结： 滚动查询通过 “首次锁定排序规则” 来保证遍历的有序性，通过 “首次创建数据快照” 来保证遍历数据集的确定性。这两者结合，使得它能够高效、一致地顺序遍历大量数据，从而完美避开了深分页的性能陷阱。它就像为第一次查询的结果集拍了一张有序的照片，然后拿着这张照片一行一行地读取。

这是一个非常关键的问题。答案是：会慢，但通常比使用传统分页 (from/size) 获取深页数据要快得多，并且这个“慢”是一次性的成本。

我们来具体分析一下：

为什么第一次查询可能“感觉”慢？

1. 全局排序与收集： 在第一次查询时，Elasticsearch 需要从所有相关分片上收集满足条件的数据，并在协调节点上进行全局归并排序，以生成一个全局有序的结果列表。当数据量巨大（例如数千万条）时，这个排序和收集过程本身就需要时间和资源。

2. 创建快照的成本： 为了保持数据一致性，ES 需要为这次滚动查询创建一个“快照视图”。虽然现代版本的 ES 对此进行了优化，但在涉及大量分段的情况下，仍然存在一些开销。

3. 返回第一批数据： 无论您的 pageSize 设置得多小（比如100），第一次查询本质上是在说：“请为我准备好所有符合条件的有序数据，但我先只取前100条。” 所以，准备“所有数据”的这个过程，是第一次请求的主要工作。

与传统深分页 (from=1000000) 的对比

虽然第一次请求有成本，但滚动查询的方案在整体上仍然高效得多：

核心区别在于：滚动查询的“慢”是一次性的初始化成本，而传统深分页的“慢”是每次翻页都要支付的重复性成本，且随着 from 增大而剧增。

如何优化和正确看待？

1. 接受初始化成本：对于需要完整遍历海量数据的场景（如数据导出、重建索引、批量计算），支付一次性的初始化成本以换取后续高效的批量流式读取，是完全值得的。
2. 优化查询条件：尽量在第一次查询中添加高效的过滤条件（如时间范围 range、精确匹配 term）。这能极大地减少需要参与全局排序的文档总数，从而显著加快第一次查询的速度。这是最重要的优化手段。
3. 硬件与索引设计：更多的CPU和内存有助于加快全局排序；合理的分片数量（避免过多或过少）也能影响性能。

结论： 是的，在数据量极大时，滚动查询的第一次请求确实会比较慢，因为它需要完成全局排序和上下文创建的全部工作。但这是**“把最重的活儿一次干完”**的策略。之后的每一次滚动请求都会非常轻快。相比之下，传统深分页是 “每次翻页都要把最重的活儿重新干一遍”，在深度分页时是完全不可行的。

因此，您的代码采用 scroll 是正确的选择。如果发现首次查询过慢，首先应该检查是否可以增加更精确的查询条件来缩减初始数据集。

是的，MySQL 和 MongoDB 都有类似的机制来处理大数据量的遍历/分页，它们的核心思想与 Elasticsearch 的 Scroll 高度相似，但实现细节和名称不同。下面分别说明：

MySQL 的“游标”遍历

1. 传统分页的问题

MySQL 使用 LIMIT offset, size 分页时，同样有深分页问题：

SELECT * FROM table ORDER BY id LIMIT 10000, 100;

随着 offset 增大，MySQL 需要扫描并跳过前 N 条记录，性能线性下降。

2. 优化方案：Keyset Pagination（基于值/游标的分页）

这是 MySQL 中最接近 Scroll 思想的解决方案：

-- 第一次查询
SELECT * FROM table ORDER BY id LIMIT 100;

-- 后续查询，记住上次最后一条记录的 id
SELECT * FROM table WHERE id > last_id ORDER BY id LIMIT 100;

原理对比：

• 相似点：都避免使用 OFFSET 跳过记录，通过“记住位置”连续读取
• 差异点：
  • MySQL 方案无服务器端状态，靠客户端传递条件
  • 需要有序且唯一的字段（通常是自增主键或时间戳）
  • 没有快照，遍历过程中数据变更会影响后续结果

3. MySQL 真正的游标

在存储过程中使用的游标，是逐行处理数据的编程构造：

DECLARE cur CURSOR FOR SELECT * FROM large_table;
OPEN cur;
FETCH cur INTO ...;
-- 逐行处理
CLOSE cur;

但这主要用于存储过程内的编程，不常用于应用程序的分页遍历。

MongoDB 的游标遍历

1. MongoDB 的游标机制

MongoDB 天生就是基于游标的查询系统：

// 查询返回游标
const cursor = db.collection.find({}).sort({_id: 1}).batchSize(100);

// 遍历游标
while (cursor.hasNext()) {
    const doc = cursor.next();
    // 处理文档
}

MongoDB 游标特性：

• 批处理：默认 101 个文档或 16MB 一批
• 可配置超时：默认 10 分钟不活动后超时
• 快照模式：可用 .snapshot() 保证一致性（但有限制）

2. 分页方案：Range-based Queries

与 MySQL 类似，MongoDB 也推荐使用基于值的分页：

// 第一页
db.collection.find().sort({_id: 1}).limit(100);

// 后续页，使用最后一条记录的 _id
db.collection.find({_id: {$gt: last_id}})
            .sort({_id: 1})
            .limit(100);

3. 服务器端游标

MongoDB 驱动程序会自动管理服务器端游标：

• 驱动程序会缓存当前批次的数据
• 当缓存耗尽时，自动发送 getMore 命令获取下一批
• 服务器会为每个游标维护状态（包括排序位置）

三者的对比

重要区别总结

1. 状态管理：

   • ES Scroll：有明确的服务器端状态，需主动清理
   • MySQL：通常无状态，靠查询条件模拟
   • MongoDB：有服务器端状态，但驱动程序自动管理

2. 数据一致性：

   • ES Scroll：强制快照一致性
   • MySQL/MongoDB：默认实时，可能看到数据变更

3. 实现方式：

   • ES Scroll：专门设计的API，scrollId 封装所有状态
   • MySQL：通过 WHERE 条件模拟，需客户端记录最后值
   • MongoDB：原生游标支持，驱动程序透明处理

实际选择建议

1. Elasticsearch Scroll：最适合需要强一致性快照的全量数据导出场景
2. MySQL Keyset：最适合实时应用分页，性能好且实现简单
3. MongoDB 游标：最适合大数据遍历，兼顾性能和易用性

您使用的 Elasticsearch Scroll 方案是三者中数据一致性最强的，适合对数据一致性要求严格的批处理任务。其他数据库的类似方案在实现上略有不同，但核心思想一致：避免深分页，通过"记住位置"来连续读取。