目录
From/Size
分布式系统中深度分页的问题
Search After 避免深度分页的问题
Search After是如何解决深度分页的问题
Scroll API
不同的搜索类型和使用场景
From/Size
- 默认情况下,查询按照相关度算分排序,返回前10条记录
- 容易理解的分页方案
- From: 开始位置
- Size:期望获取文档的总数
分布式系统中深度分页的问题
- ES天生就是分布式的.查询信息,但是数据分别保存在多个分片,多台机器上,ES天生就需要满足排序的需要(按照相关性算分)
- 当一个查询:From = 990 ,Size=10
- 会在每个分片上都先获取1000个文档,然后,通过Coordinating Node聚合所有的结果.最后再通过排序选取前1000个文档
- 页数越深,占用内存越多.为了避免深度分页带来的内存.ES中有一个规定,默认限定到10000个文档(超过10000个文档就会报错)
Search After 避免深度分页的问题
- 避免深度分页的性能问题,可以实时获取下一页文档信息
- 不支持指定页数(From)
- 只能往下翻
- 第一步搜索需要指定sort,并且保证值是唯一的(可以通过_id保证唯一性)
- 然后使用上一次,最后一个文档的sort值进行查询
- 第一步:先获取第一次数据
- 将sort中的数据放到search_after中
- 将sort的结果放到search_after中 依此类推可以实现分页
Search After是如何解决深度分页的问题
- 假定Size是10
- 当查询990-1000
- 通过 唯一排序值(search_after)定位,将每次要处理的文档数都控制在10
- Coordinating Node在每个分片上取10条文档,通过控制文档个数避免深度分页带来的开销
Scroll API
- scroll=5m:指定scroll存活的一个时间,创建快照
- 创建一个快照,在这个时间段内有新的数据写入以后,无法被查到
- 每次查询后,输入上一次的Scroll Id
- 查看当前索引的数目
- 第一次查询结果
- 将前一次的id写到scroll_id里面
不同的搜索类型和使用场景
- Regular
- 需要实时获取顶部的部分文档.例如查询最新的订单
- Scroll
- 需要全部文档,例如导出全部数据
- Pagination
- From和Size
- 如果需要深度分页,则选用Search After
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
