elasticsearch深度分页问题

一、深度分页方式 from + size

es 默认采用的分页方式是from+size的形式，在深度分页的情况下，这种使用方式效率是非常低的，比如我们执行如下查询

1 GET /student/student/_search
2 {
   
   
3   "query":{
   
   
4     "match_all": {
   
   }
5   },
6   "from":5000,
7   "size":10
8 }

意味着 es 需要在各个分片上匹配排序并得到5010条数据，协调节点拿到这些数据再进行排序等处理，然后结果集中取最后10条数据返回。
我们会发现这样的深度分页将会使得效率非常低，因为我只需要查询10条数据，而es则需要执行from+size条数据然后处理后返回。
其次：es为了性能，限制了我们分页的深度，es目前支持的最大的 max_result_window = 10000；也就是说我们不能分页到10000条数据以上。

例如：

from + size <= 10000所以这个分页深度依然能够执行。

继续看上图，当size + from > 10000；es查询失败，并且提示

Result window is too large, from + size must be less than or equal to: [10000] but was [10001]

接下来看还有一个很重要的提示

See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting

有关请求大数据集的更有效方法，请参阅滚动api。这个限制可以通过改变[索引]来设置。哦呵，原来es给我们提供了另外的一个API scroll。难道这个 scroll 能解决深度分页问题？

二、深度分页之scroll

在es中如果我们分页要请求大数据集或者一次请求要获取较大的数据集，scroll都是一个非常好的解决方案。

使用scroll滚动搜索，可以先搜索一批数据，然后下次再搜索一批数据，以此类推，直到搜索出全部的数据来scroll搜索会在第一次搜索的时候，保存一个当时的视图快照，之后只会基于该旧的视图快照提供数据搜索，如果这个期间数据变更，是不会让用户看到的。每次发送scroll请求，我们还需要指定一个scroll参数，指定一个时间窗口，每次搜索请求只要在这个时间窗口内能完成就可以了。

一个滚屏搜索允许我们做一个初始阶段搜索并且持续批量从Elasticsearch里拉取结果直到没有结果剩下。这有点像传统数据库里的cursors（游标）。

滚屏搜索会及时制作快照。这个快照不会包含任何在初始阶段搜索请求后对index做的修改。它通过将旧的数据文件保存在手边，所以可以保护index的样子看起来像搜索开始时的样子。这样将使得我们无法得到用户最近的更新行为。

scroll的使用很简单
执行如下curl，每次请求两条。可以定制 scroll = 5m意味着该窗口过期时间为5分钟。

1 GET /student/student/_search?scroll=5m
2 {
   
   
3   "query": {
   
   
4     "match_all": {
   
   }
5   },
6   "size": 2
7 }

 1 {