from+size分页
按照一般的查询流程来说,如果我想查询前10条数据:
- 1 客户端请求发给某个节点
- 2 节点转发给个个分片,查询每个分片上的前10条
- 3 结果返回给节点,整合数据,提取前10条
- 4 返回给请求客户端
该分页方式可以通过from+size的方式来进行实现。
from定义了目标数据的偏移值,size定义当前返回的事件数目。
GET /fs/_search?pretty
{
"from" : 0 , "size" : 10
}
GET /fs/_search?pretty
{
"from" : 10 , "size" : 10
}
这种分页方式只适合少量数据,因为随from增大,查询的时间就会越大,而且数据量越大,查询的效率指数下降
优点:from+size在数据量不大的情况下,效率比较高
缺点:在数据量非常大的情况下,from+size分页会把全部记录加载到内存中,这样做不但运行速递特别慢,而且容易让es出现内存不足而挂掉
比如要取第5001页的数据,在分页的时候,elasticsearch需要首先在每一个节点上取出50020的数据,然后和每一个节点的所有数据进行排序,取出排序后在50010到50020的数据,然后返回。这样随着数据量的增大,每次分页时排序的开销会越来越大。
scroll深分页
为了解决上面的问题,elasticsearch提出了一个scroll滚动的方式,这个滚动的方式原理就是通过每次查询后,返回一个scroll_id。根据这个scroll_id 进行下一页的查询。可以把这个scroll_id理解为通常关系型数据库中的游标。
scroll就是维护了当前索引段的一份快照信息–缓存(这个快照信息是你执行这个scroll查询时的快照)
可以把 scroll 分为初始化和遍历两步:
1、初始化时将所有符合搜索条件的搜索结果缓存起来,可以想象成快照;
GET fs/_search?scroll=3m
{
"query": {"match_all": {}},
"size": 3
}
初始化的时候就像是普通的search一样
其中的scroll=3m代表当前查询的数据缓存3分钟
Size:3 代表当前查询3条数据
2、遍历时,从这个快照里取数据;
在遍历时候,拿到上一次遍历中的_scroll_id,然后带scroll参数,重复上一次的遍历步骤,直到返回的数据为空,表示遍历完成。
每次都要传参数scroll,刷新搜索结果的缓存时间,另外不需要指定index和type(不要把缓存的时时间设置太长,占用内存)。
对比
from+size分页,每次查询都会去索引库(本地文件夹)中查询pageNum*page条数据,然后截取掉前面的数据,留下最后的数据。 这样的操作在每个分片上都会执行,最后会将多个分片的数据合并到一起,再次排序,截取需要的。
一般冷词用这种方式进行分页。
深分页,可以一次性将所有满足查询条件的数据,都放到内存中。分页的时候,在内存中查询。相对浅分页,就可以避免多次读取磁盘。
一般热词用scroll深分页。