分页一般有三种方式：
Es封装RestHighLevelClient和BulkProcessor的工具类
上面意味着es需要在各个分片上匹配排序并得到5010条数据，协调节点拿到这些数据再进行排序，然后结果集中取最后10条数据返回。
上述语句性能低的原因：我们只需要10条数据，而es每个分片都需要执行from+size条数据然后处理后返回。
es为了性能，会限制我们分页的深度，es目前支持最大的max_result_window = 10000，也就是from+size的大小不能超过10000。
在es中我们分页要请求大数据集或者一次请求要获取大的数据集，scroll [skrəʊl] 都是一种非常好的解决方案。
scroll也是滚动搜索。会在第一次搜索的时候，保存一个当时的快照。之后只会基于该旧的视图快照提供数据搜索。在这个期间发生变动，是不会让用户看到的。
官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。
可以在实时的情况下处理深度分页，在Es5.x版本后提供的功能，search_after缺点是不能够随机跳转分页，只能是一页一页的向后翻，并且需要至少指定一个唯一不重复字段来排序。
注意：search_after必须指定一个唯一不重复的字段来排序，此处我们指定了两个字段进行排序，
该例子：id是唯一不重复字段，publishTime可能会重复。
注意，结果返回的sort字段，存储的是最后一组的排序字段的值，而search_after在下次搜索时，需要携带该数据。
最终完成了滚动分页操作。
Elasticsearch 深入理解search After 处理深度分页问题
elasticsearch深度分页问题
Es封装RestHighLevelClient和BulkProcessor的工具类