实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

这篇具有很好参考价值的文章主要介绍了实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

问题引入

我们在平常使用ElasticSearch构建查询条件的时候一般用的都是from+size的方式进行分页查询，但是如果我们的页数太深/页面大小太大(from*size)>10000就会引发一个错误，我们将会得到一个错误
实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页
这是为什么呢？
因为ES的分页查询其实是这样来的
因为ElasticSeach的天生分布式的原因，我们的数据是分散在几个分片中的，而我们设置了from+size需要对全部数据进行查询，ES就以下面这种方式进行了查询

Query阶段

实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

Client 发送一次搜索请求，node1 接收到请求，然后，node1 创建一个大小为 from + size的优先级队列用来存结果，我们管 node1 叫 coordinating node。
coordinating node将请求广播到涉及到的 shards，每个 shard 在内部执行搜索请求，然后，将结果存到内部的大小同样为 from + size 的优先级队列里，可以把优先级队列理解为一个包含 top N结果的列表。
每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node，coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并，产生一个全局的优先级队列，存到自身的优先级队列里。

在上面的例子中，coordinating node 拿到(from + size) * 6条数据，然后合并并排序后选择前面的from + size条数据存到优先级队列，以便 fetch 阶段使用。

Fetch阶段

query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。
实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

coordinating node 发送 GET 请求到相关shards。
shard 根据 doc 的 _id取到数据详情，然后返回给 coordinating node。
coordinating node 返回数据给 Client。

coordinating node 的优先级队列里有from + size 个_doc _id，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前100条数据是不需要取的，只需要取优先级队列里的第101到110条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用「multi-get」来避免多次去同一分片取数据，从而提高性能。

这种方式请求深度分页是有问题的：

我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页—结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

对结果排序的成本随分页的深度成指数上升。

实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

如何解决深度分页

分页方式 scorll

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

使用 curl 进行分页读取过程如下：

先获取第一个 scroll_id，url 参数包括 /index/_type/ 和 scroll，scroll 字段指定了scroll_id 的有效生存期，以分钟为单位，过期之后会被es 自动清理。如果文档不需要特定排序，可以指定按照文档创建的时间返回会使迭代更高效。

#返回结果
{
    "_scroll_id": "cXVlcnlBbmRGZXRjaDsxOzk1ODg3NDpTQzRmWWkwQ1Q1bUlwMjc0WmdIX2ZnOzA7",
    "took": 106,
    "_shards": {
        "total": 1,
        "successful": 1,
        "failed": 0
    },
    "hits": {
        "total": 22424,
        "max_score": 1.0,
        "hits": [{
                "_index": "product",
                "_type": "info",
                "_id": "did-519392_pdid-2010",
                "_score": 1.0,
                "_routing": "519392",
                "_source": {
                    ....
                }
            }
        ]
    }
}

后续的文档读取上一次查询返回的scroll_id 来不断的取下一页，如果srcoll_id 的生存期很长，那么每次返回的 scroll_id 都是一样的，直到该 scroll_id 过期，才会返回一个新的 scroll_id。请求指定的 scroll_id 时就不需要 /index/_type 等信息了。每读取一页都会重新设置 scroll_id 的生存时间，所以这个时间只需要满足读取当前页就可以，不需要满足读取所有的数据的时间，1 分钟就够了
所有文档获取完毕之后，需要手动清理掉 scroll_id 。虽然es 会有自动清理机制，但是 srcoll_id 的存在会耗费大量的资源来保存一份当前查询结果集映像，并且会占用文件描述符。所以用完之后要及时清理。使用 es 提供的 CLEAR_API 来删除指定的 scroll_id

scroll + scan
当 scroll 的文档不需要排序时，es 为了提高检索的效率，在 2.0 版本提供了 scroll + scan 的方式。随后又在 2.1.0 版本去掉了 scan 的使用，直接将该优化合入了 scroll 中。由于moa 线上的 es 版本是2.3 的，所以只简单提一下。使用的 scan 的方式是指定 search_type=scan

# 2.0-beta 版本禁用 scroll 的排序，使遍历更加高效
[root@dnsserver ~]# curl 'xxx.xxx.xxx.xxx:9200/order/info/_search?scroll=1m&search_type=scan'  -d '{"query":{"match_all":{}}'

缺点：滚动aapi的方式不适合实时查询，其根本还是因为他的快照机制限制了实时性，你可以理解成他是mysql某一时刻的快照，后续的改动在这个scroll存活的时间里是不可见的

search_after 的方式

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

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

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

第一页的请求和正常的请求一样，

curl -XGET xxx.xxx.xxx.xxx:9200/order/info/_search
{
    "size": 10,
    "query": {
        "term" : {
            "did" : 519390
        }
    },
    "sort": [
        {"uid": "desc"}
    ]
}

第二页的请求，使用第一页返回结果的最后一个数据的值，加上 search_after 字段来取下一页。注意，使用 search_after 的时候要将 from 置为 0 或 -1

curl -XGET xxx.xxx.xxx.xxx:9200/order/info/_search
{
    "size": 10,
    "query": {
        "term" : {
            "did" : 519390
        }
    },
    "search_after": [1463538857],  //加上了这个 
    "sort": [
        {"_uid": "desc"}
    ]
}

优点：实时性高，但是无法跳页，较为复杂

是否能用Redis来维护这个uid

实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

存在什么问题

1.多人操作下导致的并发写问题：
实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页
2. 无法进行跳页

如何解决

多人操作下导致的并发写问题：我们可以静态维护/加一个独立字段/使用主键id，不在redis里面维护
跳页问题：如果我们的数据的顺序不会改变的话，其实我们是可以根据分页大小和分页数去计算出来我们的上一页的最后一条数据的uid/主键id的

但是这种情况基本没有可能出现，因为我们现在的大多数业务都是经过不同的查询条件（名字是否包含）/（修改时间倒序）/（按照男女筛选）因为各种筛选机制，或者如果你是Sass服务的话，不同公司的数据其实是放在一张表的，数据的id可能是交叉的，因此你不能动态的去计算这个uid/主键id作为下一页申请的srot字段，这就是深度分页中跳页的问题，也是search_after方法无法解决的问题