1、关于 Elasticsearch 分页查询,这几个问题经常被问到
2、 Elasticsearch 支持的三种分页查询方式
下面我就三种方式的联系与区别、优缺点、适用场景等展开进行解读。 2.1 From + size 分页查询2.1.1 From + size 分页查询定义与实战案例如下基础查询: GET kibana_sample_data_flights/_search 默认返回前10个匹配的匹配项。其中:
如下指定条件查询和排序: GET kibana_sample_data_flights/_search 共返回 20 条数据。 其中:from + size 两个参数定义了结果页面显示数据的内容。 2.1.2 From + size 查询优缺点及适用场景From + size 查询优点
From + size 查询缺点
From + size 查询适用场景第一:非常适合小型数据集或者大数据集返回 Top N(N <= 10000)结果集的业务场景。 第二:类似主流 PC 搜索引擎(谷歌、bing、百度、360、sogou等)支持随机跳转分页的业务场景。 2.1.3 深度翻页不推荐使用 From + sizeElasticsearch 会限制最大分页数,避免大数据量的召回导致性能低下。 Elasticsearch 的 max_result_window 默认值是:10000。也就意味着:如果每页有 10 条数据,会最大翻页至 1000 页。 实际主流搜索引擎都翻不了那么多页,举例:百度搜索“上海”,翻到第 76 页,就无法再往下翻页了,提示信息如下截图所示: 如下的分页查询 GET kibana_sample_data_flights/_search 报错如下: { 什么原因?超过了最大窗口的限制,index.max_result_window 默认值为10000。 报错信息还同时给出了两个解决方案:
后面会详细讲解。
PUT kibana_sample_data_flights/_settings 官方建议:避免过度使用 from 和 size 来分页或一次请求太多结果。 不推荐使用 from + size 做深度分页查询的核心原因:
什么意思呢? GET kibana_sample_data_flights/_search 共 10 条数据加载到内存吗?不是的! 共:10011 条数据加载到内存,然后经过后台处理后返回了最后 10 条我们想要的数据。 那也就意味着,越往后翻页(也就是深度翻页)需要加载的数据量越大,势必会越耗费 CPU + 内存资源,响应也会越慢! 2.2 search_after 查询2.2.1 search_after 查询定义与实战案例search_after 查询本质:使用前一页中的一组排序值来检索匹配的下一页。 前置条件:使用 search_after 要求后续的多个请求返回与第一次查询相同的排序结果序列。也就是说,即便在后续翻页的过程中,可能会有新数据写入等操作,但这些操作不会对原有结果集构成影响。 如何实现呢? 可以创建一个时间点 Point In Time(PIT)保障搜索过程中保留特定事件点的索引状态。 Point In Time(PIT)是 Elasticsearch 7.10 版本之后才有的新特性。 PIT的本质:存储索引数据状态的轻量级视图。 如下示例能很好的解读 PIT 视图的内涵。 # 创建 PIT 有了 PIT,search_after 的后续查询都是基于 PIT 视图进行,能有效保障数据的一致性。 search_after 分页查询可以简单概括为如下几个步骤。 步骤 1:创建 PIT 视图,这是前置条件不能省。# Step 1: 创建 PIT 返回结果如下: { keep_alive=5m,类似scroll的参数,代表视图保留时间是 5 分钟,超过 5 分钟执行会报错如下: "type" : "search_context_missing_exception", 步骤 2:创建基础查询语句,这里要设置翻页的条件。# Step 2: 创建基础查询
在每个返回文档的最后,会有两个结果值,如下所示: "sort" : [
而 4 代表什么含义呢?
官方文档把这种隐含的字段叫做:tiebreaker (决胜字段),tiebreaker 等价于_shard_doc。 tiebreaker 本质含义:每个文档的唯一值,确保分页不会丢失或者分页结果数据出现重复(相同页重复或跨页重复)。 步骤3:实现后续翻页。# step 3 : 开始翻页 后续翻页都需要借助 search_after 指定前一页的最后一个文档的 sort 字段值。 如下代码所示: "search_after": [ 显然,search_after 查询仅支持向后翻页。 2.2.2 search_after 查询优缺点及适用场景search_after 优点
ps:不严格含义:单次请求值不能超过 max_result_window;但总翻页结果集可以超过。 search_after 缺点
search_after 适用场景
不支持随机翻页,更适合手机端应用的场景。 2.3 Scroll 遍历查询2.3.1 Scroll 遍历查询定义与实战案例相比于 From + size 和 search_after 返回一页数据,Scroll API 可用于从单个搜索请求中检索大量结果(甚至所有结果),其方式与传统数据库中游标(cursor)类似。 如果把 From + size 和 search_after 两种请求看做近实时的请求处理方式,那么 scroll 滚动遍历查询显然是非实时的。数据量大的时候,响应时间可能会比较长。 scroll 核心执行步骤如下: 步骤 1:指定检索语句同时设置 scroll 上下文保留时间。实际上,scroll 已默认包含了 search_after 的PIT 的视图或快照功能。 从 Scroll 请求返回的结果反映了发出初始搜索请求时索引的状态,类似在那一个时刻做了快照。随后对文档的更改(写入、更新或删除)只会影响以后的搜索请求。 POST kibana_sample_data_logs/_search?scroll=3m 步骤 2:向后翻页继续获取数据,直到没有要返回的结果为止。POST _search/scroll scroll_id 值是步骤 1 返回的结果值。 2.3.2 Scroll 遍历查询优缺点及适用场景scroll 查询优点
ps:单次遍历的 size 值也不能超过 max_result_window 大小。scroll 查询缺点
scroll 查询适用场景
3、小结
本文说法有不严谨的地方,以官方文档为准。 欢迎大家就自己的分页实践进行留言讨论。 参考: 1. https:///log-analytics-blog/how-to-optimize-your-elasticsearch-queries-using-pagination 2. https://www./elasticsearch-pagination 3. https://www./guide/en/elasticsearch/reference/7.12/paginate-search-results.html |
|