es的深度分页性能问题

一、什么叫做deep paging

简单来说，就是检索的特别深。比如说总共有60000条数据，每个shard上分了20000条数据。每页是10条数据，你要检索到1000页，实际上要拿到的是10001-10010。

其实每个shard都要返回10010条数据给coordinate node，coordinate node会收到总共30030条数据，然后在这些数据中进行排序，_socre，相关度分数，然后取到排位最靠前的10条数据，其实就是我们要的最后的第1000页的10条数据。

缺点：搜索过深的时候，就需要在coordinate node上保存大量的数据，还要进行大量数据的排序，排序之后再取出对应的那一页。所以这个过程，既耗费网络带宽、耗费内存、还耗费cpu。这就是deep paging性能问题。

二、常见深度分页方式 from+size

es 默认采用的分页方式是 from+ size 的形式，在深度分页的情况下，这种使用方式效率是非常低的，比如from = 5000, size=10， es 需要在各个分片上匹配排序并得到5000*10条有效数据，然后在结果集中取最后10条数据返回，这种方式类似于mongo的 skip + size。

除了效率上的问题，还有一个无法解决的问题是，es 目前支持最大的 skip 值是 max_result_window ，默认为 10000 。也就是当 from + size > max_result_window 时，es 将返回错误。

最开始的时候是线上客户的es数据出现问题，当分页到几百页的时候，es 无法返回数据，此时为了恢复正常使用，我们采用了紧急规避方案，就是将 max_result_window 的值调至 50000

curl -XPUT "127.0.0.1:9200/custm/_settings" -d
{ 
    "index" : { 
        "max_result_window" : 50000 
    }
}

然后这种方式只能暂时解决问题，当es 的使用越来越多，数据量越来越大，深度分页的场景越来越复杂时，如何解决这种问题呢？

三、另一种分页方式 scroll

为了满足深度分页的场景，es 提供了 scroll 的方式进行分页读取。原理上是对某次查询生成一个游标 scroll_id ， 后续的查询只需要根据这个游标去取数据，直到结果集中返回的 hits 字段为空，就表示遍历结束。scroll_id 的生成可以理解为建立了一个临时的历史快照，在此之后的增删改查等操作不会影响到这个快照的结果

所有文档获取完毕之后，需要手动清理掉 scroll_id 。虽然es 会有自动清理机制，但是 srcoll_id 的存在会耗费大量的资源来保存一份当前查询结果集映像，并且会占用文件描述符。所以用完之后要及时清理。使用 es 提供的 CLEAR_API 来删除指定的 scroll_id

四、search_after 的方式

上述的 scroll search 的方式，官方的建议并不是用于实时的请求，因为每一个 scroll_id 不仅会占用大量的资源（特别是排序的请求），而且是生成的历史快照，对于数据的变更不会反映到快照上。这种方式往往用于非实时处理大量数据的情况，比如要进行数据迁移或者索引变更之类的。那么在实时情况下如果处理深度分页的问题呢？es 给出了 search_after 的方式，这是在 >= 5.0 版本才提供的功能。

search_after 分页的方式和 scroll 有一些显著的区别，首先它是根据上一页的最后一条数据来确定下一页的位置，同时在分页请求的过程中，如果有索引数据的增删改查，这些变更也会实时的反映到游标上

为了找到每一页最后一条数据，每个文档必须有一个全局唯一值，这种分页方式其实和目前 moa 内存中使用rbtree 分页的原理一样，官方推荐使用 _uid 作为全局唯一值，其实使用业务层的 id 也可以。

总结：search_after 适用于深度分页+ 排序，因为每一页的数据依赖于上一页最后一条数据，所以无法跳页请求。