当前位置: 首页 > news >正文

【Elasticsearch】深度分页及其替代方案

深度分页及其替代方案

  • 1.深度分页
  • 2.为什么不推荐深度分页
    • 2.1 性能问题(核心原因)
    • 2.2 资源消耗对比
    • 2.3 实际限制
  • 3.深度分页的替代方案
    • 3.1 方案一:Search After(推荐)
      • 3.1.1 为什么 Search After 性能更高
      • 3.1.2 技术原理简化
      • 3.1.3 关键区别
      • 3.1.4 适用场景
    • 3.2 方案二:Scroll API(适用于大批量导出)
      • 3.2.1 详细解释
      • 3.2.2 类比理解
      • 3.2.3 注意事项
    • 3.3 方案三:基于时间范围的分页
    • 3.4 总结:如何选择分页方式

1.深度分页

深度分页 指的是在 Elasticsearch 中查询结果集 非常靠后的页码(例如第 1000 1000 1000 页,每页 10 10 10 条数据,即 from=10000)。它通常表现为使用 from + size 参数组合来获取远端的分页数据。例如:

GET /my_index/_search
{"from": 10000,  // 跳过前10000条"size": 10,     // 取10条"query": { ... }
}

2.为什么不推荐深度分页

2.1 性能问题(核心原因)

Elasticsearch 的分页原理是:

  • 协调节点 需要从所有分片(shard)收集满足条件的文档。
  • 计算全局排序后,临时存储 from + size 范围内的所有文档。
  • 最后返回 size 条结果。

问题

  • from 值很大时(如 from=100000),每个分片需要 先查 100000+size 条数据 到内存,再汇总排序。
  • 数据量越大,内存和 CPU 消耗呈线性增长,可能导致 内存溢出

2.2 资源消耗对比

分页方式内存消耗响应时间适用场景
浅分页(from=0低(仅缓存 size 条)毫秒级前几页数据
深度分页(from=10000高(缓存 10000+size 条)秒级甚至超时不推荐直接使用

2.3 实际限制

  • Elasticsearch 默认限制:from + size ≤ 10,000(可通过 index.max_result_window 调整,但 调高会加剧风险)。
  • 即使调高限制,性能也会急剧下降。

3.深度分页的替代方案

3.1 方案一:Search After(推荐)

原理

  • 利用上一页的排序值(如 _shard_doc 或自定义字段)作为游标。
  • 不跳过记录,直接定位到下一页的起始点。

示例

// 第一页
GET /blog_posts/_search
{"size": 10,"sort": [  // 必须包含唯一性字段(如 _id){ "publish_date": "desc" },{ "_id": "asc" }]
}// 后续页(用上一页最后一条的排序值)
GET /blog_posts/_search
{"size": 10,"search_after": ["2023-04-05", "abc123"],  // 上一页最后记录的 publish_date 和 _id"sort": [{ "publish_date": "desc" },{ "_id": "asc" }]
}

优点

  • 性能稳定(不受页码影响)。
  • 适合无限滚动、批量导出等场景。

3.1.1 为什么 Search After 性能更高

用一个生活中的例子来理解:假设你要在图书馆的 100万本书 中,每次找 10本 符合特定条件的书,并按出版日期排序。

  • 传统分页(from/size)的做法
    • 你要第 1000 页(即第 9991-10000 本书)。
    • 图书管理员必须:
      1. 先取出前 10000 本书,堆在桌子上(内存)。
      2. 排序这 10000 本,扔掉前 9990 本。
      3. 最后给你第 9991-10000 本。
    • 问题:每次翻到深页码,都要重复 “取书 + 排序 + 扔书” 的过程,桌子(内存)可能堆不下!
  • Search After 的做法
    • 你记住 当前看到的最后一本书的出版日期和编号(例如:“2023-05-01, 编号ABC123”)。
    • 下次直接告诉图书管理员:“我要比【2023-05-01, ABC123】更早的10本书”。
    • 图书管理员:
      1. 直接定位到这本书的位置(通过索引)。
      2. 往后数 10 本给你。
    • 优势:不需要临时存储前面的 9990 本书!

🚀 简而言之:Search After 快是因为它 不傻乎乎地从头数,而是像书签一样 “记住位置”,直接跳到下一页开始的地方。

3.1.2 技术原理简化

分页方式工作方式性能消耗
from/size每次从头计算,临时存储 from+size 条数据from 增大 指数级上升
search_after像书签一样记住位置,直接跳转恒定(与页码无关)

3.1.3 关键区别

  • from/size
    • 类似 “每次从第一页开始翻”
    • 计算:(from + size) × 分片数 → 内存爆炸 💥
  • search_after
    • 类似 “记住看到哪里,接着往下读”
    • 计算:size × 分片数内存恒定 📊

3.1.4 适用场景

  • from/size
    • 前几页(如首页、搜索结果前 10 条)
  • search_after
    • 无限滚动(如微博、朋友圈)
    • 深度分页(如第 100 页+)

3.2 方案二:Scroll API(适用于大批量导出)

原理

  • 创建快照(snapshot),保持查询上下文。
  • 逐批获取数据,类似数据库游标。

示例

// 1. 初始化 Scroll(保留1分钟)
GET /blog_posts/_search?scroll=1m
{"size": 100,"query": { "match_all": {} }
}// 2. 后续获取(用返回的 scroll_id)
GET /_search/scroll
{"scroll": "1m", "scroll_id": "DXF1ZXJ5QW5kRmV0Y2gB..."
}// 3. 最后手动清理
DELETE /_search/scroll
{"scroll_id": "DXF1ZXJ5QW5kRmV0Y2gB..."
}

优点: 适合非实时、大数据量导出(如报表生成)。

缺点

  • 不支持实时数据(快照期间数据变化不会反映)。
  • 占用服务器资源,用完需手动清理(DELETE /_search/scroll)。

3.2.1 详细解释

  • scroll=1m 的含义
    • 1m = 1 分钟(时间单位,类似 30s = 30秒2h = 2小时
    • 表示 Elasticsearch 会保留这次 Scroll 查询的上下文(如排序结果、快照数据)1 分钟。
    • 超时后,Scroll 会自动失效,资源被释放。
  • 为什么需要设置超时?
    • Scroll 会占用服务器内存和资源,长时间不释放可能导致性能问题。
    • 设置超时(如 1m)是让 Elasticsearch 自动清理 不再使用的 Scroll 查询。
  • 如何调整超时?
    • 根据数据量调整,例如:
      • 大数据导出:scroll=5m 5 5 5 分钟)
      • 小批量查询:scroll=30s 30 30 30 秒)
  • 续期 Scroll
    如果处理时间较长,可以在每次请求时刷新超时时间:
    GET /_search/scroll
    {"scroll": "1m",  // 重新设置为1分钟"scroll_id": "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVY..."
    }
    

3.2.2 类比理解

把 Scroll 想象成图书馆的 “临时书架”

  • 你告诉图书管理员:“我需要 1 分钟(scroll=1m)来挑书”。
  • 1 分钟内,书架上的书(查询结果)保持不变,你可以慢慢选。
  • 超时后,图书管理员会把书架清空(释放资源)。
  • 如果你需要更多时间,可以喊:“再给我 1 分钟!”(续期 Scroll)。

3.2.3 注意事项

  • 不要滥用长超时(如 scroll=1h),否则可能导致集群内存压力。
  • 用完务必清理(即使未超时):
    DELETE /_search/scroll
    {"scroll_id": "DXF1ZXJ5QW5kRmV0Y2gB..."
    }
    
  • Scroll 适用于离线任务(如导出数据),不适用于实时分页。

3.3 方案三:基于时间范围的分页

原理

  • 用时间字段(如 publish_date)作为分页条件。
  • 每页查询限定时间范围。

示例

GET /blog_posts/_search
{"size": 10,"query": {"range": {"publish_date": { "lte": "2023-03-01" }  // 第二页改为 "lte": "上一页的最小日期"}},"sort": [ { "publish_date": "desc" } ]
}

适用场景

  • 按时间线分页(如新闻列表)。

3.4 总结:如何选择分页方式

场景推荐方案原因
用户前端分页(前几页)from + size简单易用,性能可接受
深度分页(如第 100 100 100 页)Search After避免内存爆炸,性能稳定
大数据量导出Scroll API适合离线处理,但需注意资源释放
按时间滚动时间范围查询利用业务字段天然分页

关键建议

  • 禁止生产环境使用大 from 值(如 from=100000)。
  • 若必须调整 index.max_result_window,需评估集群资源。
  • Search After 是深度分页的最佳实践,兼容大多数场景。
http://www.lryc.cn/news/580344.html

相关文章:

  • 【openp2p】 学习2:源码阅读P2PNetwork和P2PTunnel
  • 【STM32实践篇】:GPIO 详解
  • 网络资源模板--基于Android Studio 实现的极简天气App
  • Excel 数据透视表不够用时,如何处理来自多个数据源的数据?
  • 动手实践OpenHands系列学习笔记1:Docker基础与OpenHands容器结构
  • Softhub软件下载站实战开发(十三):软件管理前端分片上传实现
  • 用户中心Vue3网页开发(1.0版)
  • Java零基础笔记01(JKD及开发工具IDEA安装配置)
  • Linux进程管理:从基础到实战
  • 60天python训练计划----day59
  • 数据结构:数组:插入操作(Insert)与删除操作(Delete)
  • 深度学习4(浅层神经网络)
  • 【深度学习】神经网络剪枝方法的分类
  • 由coalesce(1)OOM引发的coalesce和repartition理解
  • C++ 网络编程(15) 利用asio协程搭建异步服务器
  • Linux——进程(下)
  • android studio 配置硬件加速 haxm
  • spring中 方法上@Transation实现原理
  • C++20中的counting_semaphore的应用
  • C++ 模板参数匹配、特化
  • AtCoder AT_abc413_c [ABC413C] Large Queue 题解
  • Oracle 数据库——企业级核心系统
  • MySQL(118)如何使用SSL进行加密连接?
  • mysql的备份与恢复(使用mysqldump)
  • pyinstaller打包教程
  • TCP数据的发送和接收
  • 闲庭信步使用SV搭建图像测试平台:第三十一课——基于神经网络的手写数字识别
  • Ubuntu基础(监控重启和查找程序)
  • 模块三:现代C++工程实践(4篇)第一篇《C++模块化开发:从Header-only到CMake模块化》
  • Redis的编译安装