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深分页。