使用 from / size 分页
from - 表示起始位置,size - 表示每页数量;类似与 MySQL 的 limit + offset。
示例:
GET /_search
{
"from" : 10, "size" : 10,
"query" : {
"term" : { "user" : "kimchy" }
}
}
需要注意的是,from + size 不能超过10000,也就是说在前10000条之内,可以随意翻页,10000条之后就不行了。
实际上,通过设置 index.max_result_window 可以修改这个限制,但是不建议这么做,因为这种方式翻页越深效率越低。
原理:
Query阶段:
当一个请求发送到某个ES节点时,该节点(Node1)会根据from和size,建立一个结果集窗口,窗口大小为from+size。假如from=10000,size=100,则窗口大小为10100。
此节点将请求广播到其他相关节点上,从每个Shards中取Top 10100条的score和id。
所有Shards获取的结果汇聚到Node1,假如有5个Shards,则一共会取到5 * 10100 = 50500条数据。
Node1进行归并排序,并选择Top 10100条,存入结果集窗口。
Fetch阶段:
根据Query阶段得到的排序结果,从 from 位置取 size 条数据,抓取文档详细内容返回。
从此过程中可以看出,翻页越靠后,需要参与排序的文档就越多,效率也就越低。所以,如果结果集很大,不建议用这种分页方式。
关于ES搜索请求过程,推荐一篇博文:https://blog.csdn.net/caipeichao2/article/details/46418413(其中query_and_fetch已经在对外接口中去掉了,所以只需了解query_then_fetch过程即可。)
使用 scroll 分页
使用scroll就像传统数据库中的游标一样,方式如下:
第一步
POST /twitter/_search?scroll=1m
{
"size": 100,
"query": {
"match" : {
"title" : "elasticsearch"
}
}
}
scroll=1m,表示“search context”存活时间1分钟。返回结果中会带有一个“_scroll_id”,这个值在后续的翻页过程中使用。
第二步
POST /_search/scroll
{
"scroll" : "1m",
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}
不用指定index和type,也不用其他查询条件,只要把上一步的_scroll_id即可。
之后翻页一直如此,每次执行会自动滚动100条数据,直到返回的结果为空为止。
每次执行间隔不要超过1分钟,否则“search context”会释放掉。
第三步
DELETE /_search/scroll
{
"scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAAAD4WYm9laVYtZndUQlNsdDcwakFMNjU1QQ=="
}
结果遍历完成后,删除scroll_id。这一步也可以不做,等1分钟后没有继续翻页请求,“search context”会自动释放掉,不过建议还是手动清除,节省资源。
优化:
如果目的是为了遍历所有结果,而不关心结果的顺序,那么可以按“_doc”排序来提高性能
POST /twitter/_search?scroll=1m
{
"size": 100,
"query": {
"match" : {
"title" : "elasticsearch"
}
},
"sort": ["_doc"]
}
与 from/size 分页方式不同,使用 scroll 分页只能单向顺序翻页,不能随机翻页,适用于遍历结果集的场景。
scroll 翻页能够深度翻页,但是翻页期间需要维护“search context”,这是需要占用一定资源的。
所以对于用户高并发访问的场景,不推荐用这种方式,scroll 更适用于批处理类的后台任务。
使用 search after 分页
这种方式同样可以深度翻页,但是弥补了 scroll 方式的不足。其思想是:用前一次的查询结果作为下一次的查询条件。
示例:
首次查询
GET /user_model/_search
{
"size": 10,
"query": {"match_all": {}},
"sort": [
{"_id": "asc"}
]
}
返回结果:
{
"took" : 4379,
"timed_out" : false,
"_shards" : {
"total" : 6,
"successful" : 6,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 38213940,
"max_score" : null,
"hits" : [
...
{
"_index" : "user_model",
"_type" : "_doc",
"_id" : "00000f78f59644b1967783986c35496c",
"_score" : null,
"_source" : {
...
},
"sort" : [
"00000f78f59644b1967783986c35496c"
]
}
]
}}
后续查询
GET /user_model/_search
{
"size": 10,
"query": {"match_all": {}},
"sort": [
{"_id": "asc"}
],
"search_after": ["00000f78f59644b1967783986c35496c"]
}
其中,search_after 为上次查询结果中最后一条记录的 sort 值。
总结:
-
如果数据量小(10000条内),或者只关注结果集的TopN数据,可以使用from / size 分页,简单粗暴
-
数据量大,深度翻页,后台批处理任务(数据迁移)之类的任务,使用 scroll 方式
-
数据量大,深度翻页,用户实时、高并发查询需求,使用 search after 方式