一、from + size 浅分页
\"浅\"分页可以理解为简单意义上的分页。
它的原理很简单,就是查询前20条数据,然后截断前10条,只返回10-20的数据。这样其实白白浪费了前10条的查询。
GET test_dev/_search
{
\"query\": {
\"bool\": {
\"filter\": [
{
\"term\": {
\"age\": 28
}
}
]
}
},
\"size\": 10,
\"from\": 20,
\"sort\": [
{
\"timestamp\": {
\"order\": \"desc\"
},
\"_id\": {
\"order\": \"desc\"
}
}
]
}
其中,from定义了目标数据的偏移值,size定义当前返回的数目。默认from为0,size为10,即所有的查询默认仅仅返回前10条数据。
在这里有必要了解一下from/size的原理:
因为es是基于分片的,假设有5个分片,from=100,size=10。则会根据排序规则从5个分片中各取回100条数据数据,然后汇总成500条数据后选择最后面的10条数据。
做过测试,越往后的分页,执行的效率越低。总体上会随着from的增加,消耗时间也会增加。而且数据量越大,就越明显!
二、scroll 深分页
from+size查询在10000-50000条数据(1000到5000页)以内的时候还是可以的,但是如果数据过多的话,就会出现深分页问题。
为了解决上面的问题,elasticsearch提出了一个scroll滚动的方式。
scroll 类似于sql中的cursor,使用scroll,每次只能获取一页的内容,然后会返回一个scroll_id
。根据返回的这个scroll_id
可以不断地获取下一页的内容,所以scroll并不适用于有跳页的情景。
GET test_dev/_search?scroll=5m
{
\"query\": {
\"bool\": {
\"filter\": [
{
\"term\": {
\"age\": 28
}
}
]
}
},
\"size\": 10,
\"from\": 0,
\"sort\": [
{
\"timestamp\": {
\"order\": \"desc\"
},
\"_id\": {
\"order\": \"desc\"
}
}
]
}
scroll=5m
表示设置scroll_id
保留5分钟可用。- 使用scroll必须要将from设置为0。
- size决定后面每次调用
_search
搜索返回的数量
然后我们可以通过数据返回的_scroll_id
读取下一页内容,每次请求将会读取下10条数据,直到数据读取完毕或者scroll_id
保留时间截止:
GET _search/scroll
{
\"scroll_id\": \"DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAJZ9Fnk1d......\",
\"scroll\": \"5m\"
}
注意:请求的接口不再使用索引名了,而是 _search/scroll
,其中GET和POST方法都可以使用。
scroll删除
根据官方文档的说法,scroll的搜索上下文会在scroll的保留时间截止后自动清除,但是我们知道scroll是非常消耗资源的,所以一个建议就是当不需要了scroll数据的时候,尽可能快的把scroll_id
显式删除掉。
清除指定的scroll_id
:
DELETE _search/scroll/DnF1ZXJ5VGhlbkZldGNo.....
清除所有的scroll:
DELETE _search/scroll/_all
三、search_after 深分页
scroll 的方式,官方的建议不用于实时的请求(一般用于数据导出),因为每一个 scroll_id
不仅会占用大量的资源,而且会生成历史快照,对于数据的变更不会反映到快照上。
search_after
分页的方式是根据上一页的最后一条数据来确定下一页的位置,同时在分页请求的过程中,如果有索引数据的增删改查,这些变更也会实时的反映到游标上。但是需要注意,因为每一页的数据依赖于上一页最后一条数据,所以无法跳页请求。
为了找到每一页最后一条数据,每个文档必须有一个全局唯一值,官方推荐使用 _uid
作为全局唯一值,其实使用业务层的 id 也可以。
GET test_dev/_search
{
\"query\": {
\"bool\": {
\"filter\": [
{
\"term\": {
\"age\": 28
}
}
]
}
},
\"size\": 20,
\"from\": 0,
\"sort\": [
{
\"timestamp\": {
\"order\": \"desc\"
},
\"_id\": {
\"order\": \"desc\"
}
}
]
}
- 使用
search_after
必须要设置from=0
。 - 这里我使用timestamp和
_id
作为唯一值排序。 - 我们在返回的最后一条数据里拿到sort属性的值传入到
search_after
。
使用sort返回的值搜索下一页:
GET test_dev/_search
{
\"query\": {
\"bool\": {
\"filter\": [
{
\"term\": {
\"age\": 28
}
}
]
}
},
\"size\": 10,
\"from\": 0,
\"search_after\": [
1541495312521,
\"d0xH6GYBBtbwbQSP0j1A\"
],
\"sort\": [
{
\"timestamp\": {
\"order\": \"desc\"
},
\"_id\": {
\"order\": \"desc\"
}
}
]
}
你都学会了吗?
版权声明:本文为CSDN博主「zhexiao27」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。原文链接:https://blog.csdn.net/andybegin/article/details/83864171
近期热文推荐:
1.1,000+ 道 Java面试题及答案整理(2022最新版)
2.劲爆!Java 协程要来了。。。
3.Spring Boot 2.x 教程,太全了!
4.别再写满屏的爆爆爆炸类了,试试装饰器模式,这才是优雅的方式!!
5.《Java开发手册(嵩山版)》最新发布,速速下载!
觉得不错,别忘了随手点赞+转发哦!
来源:https://www.cnblogs.com/javastack/p/16435081.html
本站部分图文来源于网络,如有侵权请联系删除。