1.传统分页（from&size）
按照一般的查询流程来说，如果我们想查询前10条数据：
- 客户端请求发送给某个节点；
- 节点转发给各个分片，查询每个分片上的前10条数据；
- 查询结果返回给节点，并将数据进行整合，提取前10条数据；
- 将查询结果返回给客户端。
其原理就是当我们需要查询第10条到第20条数据时，节点从各个分片上获取10条数据并进行数据整合，然后从整合的数据中获取第10条到第20条数据作为请求的结果。
其中from定义了目标数据的偏移值，size定义了当前返回的事件数目。默认from为0，size为10，即所有的查询默认返回前10条数据。
在实际测试过程中，当此方式的访问页码越高，其执行的查询效率就越低。假设我们现在需要获取第20页的数据，ElasticSearch不得不取出所有分片上的第1页到第20页的所有文档，并对其进行合并排序，最终再取出from后的size条作为最终的返回结果；假设我们现在服务器上有16个分片，则我们需要汇总到shards*（from+size）条记录，即需要16*（20+10）条记录后，对其进行整合再做一次全局排序。
因此，当索引非常大时，我们是无法使用from+size方式做深分页的，分页越深越容易OOM或者消耗内存，所以ES使用index.max_result_window:10000作为保护措施来避免这种情况的发生。但实际上当访问数据非常大时，我们采用scroll游标的方式来获取数据是更好地一种选择。
2. 大数据量的快照分页（scroll）
相对于from&size的分页来说，使用scroll可以模拟一个传统的游标来记录当前读取的文档信息位置。采用此分页方法，不是为了实时查询数据，而是为了查询大量甚至全部的数据。此方式相对于维护了一份当前索引的快照信息，在执行数据查询时，scroll将会从这个快照信息中获取数据。它相对于传统的分页方式来说，不是查询所有数据再剔除掉不需要的部分，而是记录一个读取的位置来保证下次对数据的继续获取。
访问数据过程
在使用scroll方式进行数据请求的过程中，主要分为四步：
- 首先通过设置访问地址和端口号等信息获取到客户端对象；
- 设置请求的索引名称、类型值、分页大小以及每次请求的scroll游标存活时间等信息，然后向服务器发送数据查询请求，并保存返回结果中的scroll_id值，此id值作为下次访问的必要内容；
- 获取到第一次请求的scroll_id值，再次设置数据请求的scroll游标存活时间，即可访问下一组size大小的索引数据，依次循环直到数据请求完毕；
- 清除滚屏的scroll_id值，释放内存资源。
缺点
scroll是对数据的一种快照，当数据发生任何变化的情况下（比如新增、更新和删除操作），是不会被感知到的，且维护scroll上下文也是非常昂贵的，因此不适用于实时和高并发的场景；
因为采用scroll方式，每次的数据请求都需要上一次请求结果中的scroll_id值来作为下次访问时的标志，因此采用此方式无法进行页面的随机跳转功能，只能进行滚动式数据浏览（类似于微博）；
3. search_after
search_after分页的方式是根据上一页的最后一条数据来确定下一页的位置，同时再分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上。但是需要注意，因为每一页的数据依赖于上一页的最后一条数据，所以没法跳页请求。
为了找到每一页最后一条数据，每个文档那个必须有一个全局唯一值，官方推荐使用_uuid作为全局唯一值，当然在业务上的id也可以。