这个问题确实戳中了Elasticsearch分页的几个痛点——实时性和快照性的矛盾，还有scroll只能单向翻页的局限。结合你的需求，我整理了几个可行的方案，你可以根据数据量和业务场景来选：

当用户发起第一次查询时，先把符合条件的数据同步到一个临时索引里，这个索引就是你要的查询时刻快照，之后所有分页操作都在这个临时索引上进行。

• 具体操作：
  1. 发起查询时，先用_reindex API把目标索引中符合查询条件的数据复制到临时索引，比如：

     POST _reindex
     {
       "source": {
         "index": "your-timeline-index",
         "query": {
           # 这里放你的查询条件
         }
       },
       "dest": {
         "index": "snapshot-temp-123" # 用唯一标识命名，比如用户ID+时间戳
       }
     }
     

  2. 同步完成后，就可以在这个临时索引上用from/size或者search_after进行正常的前后翻页了——因为数据已经固定，不会有新写入的干扰。
  3. 别忘了给临时索引设置生命周期策略（ILM），比如24小时后自动删除，避免磁盘资源浪费。
• 优缺点：
  • ✅ 完全隔离新数据，快照100%准确；支持任意前后翻页，操作逻辑简单。
  • ❌ 数据量大时，_reindex会有性能开销，同步时间可能较长；需要额外的存储资源。

Elasticsearch 7.10+引入的Point-in-Time（PIT）可以保留某个时刻的数据快照，而且比scroll更灵活，结合search_after可以实现双向翻页。

• 具体操作：
  1. 第一步，创建PIT，指定要快照的索引和存活时间（比如5分钟）：

     POST /your-timeline-index/_pit?keep_alive=5m
     

     这个请求会返回一个pit_id，后续所有查询都要带上它。
  2. 第一次查询时，带上PIT和唯一排序条件（比如@timestamp+_id，避免排序冲突），获取第一页数据，同时记录下第一页第一个文档和最后一个文档的sort值：

     GET _search
     {
       "size": 10,
       "query": { # 你的查询条件 },
       "sort": [{"@timestamp": "asc"}, {"_id": "asc"}],
       "pit": {"id": "your-pit-id", "keep_alive": "5m"}
     }
     

  3. 翻下一页：用最后一个文档的sort值作为search_after参数，继续查询：

     GET _search
     {
       "size": 10,
       "query": { # 你的查询条件 },
       "sort": [{"@timestamp": "asc"}, {"_id": "asc"}],
       "pit": {"id": "your-pit-id", "keep_alive": "5m"},
       "search_after": ["2024-05-20T10:00:00Z", "doc-123"]
     }
     

  4. 回退上一页：用前一页第一个文档的sort值，反向排序查询，然后在应用层把结果倒序返回给用户，保证顺序和之前一致：

     GET _search
     {
       "size": 10,
       "query": { # 你的查询条件 },
       "sort": [{"@timestamp": "desc"}, {"_id": "desc"}],
       "pit": {"id": "your-pit-id", "keep_alive": "5m"},
       "search_after": ["2024-05-20T10:00:00Z", "doc-456"] # 上一页第一个文档的sort值
     }
     

  5. 所有分页操作完成后，记得关闭PIT释放资源：

     POST _pit/_close
     {
       "id": "your-pit-id"
     }
     

• 优缺点：
  • ✅ 无需额外复制数据，性能开销小；快照准确，支持双向翻页；官方原生方案，维护成本低。
  • ❌ 需要维护PIT的生命周期，超时会导致快照失效；实现逻辑比临时索引复杂一点，要处理排序和结果反转。

如果你的查询结果集不大（比如几千条以内），可以在第一次查询时把所有符合条件的文档ID缓存起来（比如存Redis），之后分页直接从缓存的ID列表里取对应范围的ID，再用ids查询获取数据。

• 具体操作：
  1. 第一次查询时，用_search获取所有符合条件的文档，只返回_id和排序字段：

     GET your-timeline-index/_search
     {
       "size": 10000, # 注意ES默认max_result_window是10000，超过的话需要调整或者用scroll获取全部ID
       "query": { # 你的查询条件 },
       "sort": [{"@timestamp": "asc"}, {"_id": "asc"}],
       "_source": false,
       "fields": ["@timestamp"]
     }
     

  2. 把返回的hits里的_id和排序值按顺序存入缓存（比如Redis的List或者Sorted Set），并生成一个唯一的快照ID关联这个缓存。
  3. 用户翻页时，根据页码计算要取的ID范围，从缓存里取出这些ID，然后用ids查询获取完整数据：

     GET your-timeline-index/_search
     {
       "query": {
         "ids": {
           "values": ["doc-1", "doc-2", ...] # 从缓存取的ID列表
         }
       },
       "sort": [{"@timestamp": "asc"}, {"_id": "asc"}]
     }
     

• 优缺点：
  • ✅ 实现简单，应用层可控；支持任意前后翻页。
  • ❌ 数据量超过max_result_window时需要额外处理（比如用scroll拉取全部ID）；缓存占用内存，不适合大数据量场景；缓存过期后快照失效。

内容的提问来源于stack exchange，提问作者Shashwat Kumar