ElasticSearch深度分页解决方案

2024-01-09 06:47:33

一、前言

ElasticSearch是一个基于Lucene的搜索引擎,它支持复杂的全文搜索和实时数据分析。在实际应用中,我们经常需要对大量数据进行分页查询,但是传统的分页方式在处理大量数据时会遇到性能瓶颈。本文将介绍ElasticSearch分页工作原理、深度分页存在的问题以及深度分页解决方案。

二、分页执行原理

ElasticSearch的分页原理是基于游标的。当我们执行一个分页查询时,ElasticSearch会返回当前页面的数据以及一个游标(_scroll_id)。游标是一个唯一标识符,用于记录当前查询位置。当我们需要获取下一页数据时,只需要将游标传递给下一次查询即可。

From/Size参数

在ES中,分页查询默认返回最顶端的10条匹配hits。

如果需要分页,需要使用from和size参数。

from参数定义了需要跳过的hits数,默认为0;

size参数定义了需要返回的hits数目的最大值。

一个基本的ES查询语句是这样的:

POST /my_index/my_type/_search
{
    "query": { "match_all": {}},
    "from": 100,
    "size":  10
}

上面的查询表示从搜索结果中取第100条开始的10条数据。

图片

在ES中,搜索一般包括两个阶段,query 和 fetch 阶段,可以简单的理解,query 阶段确定要取哪些doc,fetch 阶段取出具体的 doc。

query阶段:

如上图所示,描述了一次搜索请求的 query 阶段:

  1. Client 发送一次搜索请求,node1 接收到请求,然后,node1 创建一个大小为from + size的优先级队列用来存结果,我们管 node1 叫 coordinating node。

  2. coordinating node将请求广播到涉及到的 shards,每个 shard 在内部执行搜索请求,然后,将结果存到内部的大小同样为from + size 的优先级队列里,可以把优先级队列理解为一个包含top N结果的列表。

  3. 每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node,coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并,产生一个全局的优先级队列,存到自身的优先级队列里。

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

另外,各个分片返回给 coordinating node 的数据用于选出前from + size条数据,所以,只需要返回唯一标记 doc 的_id以及用于排序的_score即可,这样也可以保证返回的数据量足够小。

coordinating node 计算好自己的优先级队列后,query 阶段结束,进入 fetch 阶段。

fetch 阶段:

  1. coordinating node 发送 GET 请求到相关shards。

  2. shard 根据 doc 的_id取到数据详情,然后返回给 coordinating node。

  3. coordinating node 返回数据给 Client。

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

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

三、深度分页问题

  1. 内存占用高:当查询结果集很大时,使用scroll API会导致内存占用过高,甚至出现OOM异常。

  2. 响应时间慢:由于需要将所有数据加载到内存中,所以scroll API的响应时间相对较慢。

  3. 游标管理复杂:使用scroll API时,需要手动管理游标,包括创建、删除和滚动游标等操作,这会增加开发难度和维护成本。

Elasticsearch 的From/Size方式提供了分页的功能,同时,也有相应的限制。

举个例子,一个索引,有10亿数据,分10个 shards,然后,一个搜索请求,from=1000000,size=100,这时候,会带来严重的性能问题:CPU,内存,IO,网络带宽。

在 query 阶段,每个shards需要返回 1000100 条数据给 coordinating node,而 coordinating node 需要接收10 * 1000,100 条数据,即使每条数据只有 _doc _id 和 _score,这数据量就很大了。

四、解决方案

1. 使用scroll API进行深度分页

scroll API可以获取大量数据,并且可以在内存中缓存这些数据。通过scroll API,我们可以在一次查询中获取所有满足条件的文档,然后根据需要对它们进行排序和过滤。这种方式适用于需要处理大量数据的场景。

Scroll,可以把scroll理解为关系型数据库里的cursor,因此,scroll并不适合用来做实时搜索,而更适合用于后台批处理任务,比如群发。scroll可以分为初始化和遍历两部,初始化时将「所有符合搜索条件的搜索结果缓存起来(注意,这里只是缓存的doc_id,而并不是真的缓存了所有的文档数据,取数据是在fetch阶段完成的)」,可以想象成快照。支持排序。

Scroll Scan,ES提供了scroll scan方式进一步提高遍历性能,但是scroll scan不支持排序,因此scroll scan适合不需要排序的场景。

POST /twitter/tweet/_search?scroll=1m
{
    "size": 100,
    "query": {
        "match" : {
            "title" : "elasticsearch"
        }
    }
}

2. 使用搜索后的游标进行深度分页

在Elasticsearch中,每个分页结果都有一个游标(_scroll_id),用于标识当前分页的最后一个文档的位置。当需要获取下一页数据时,只需要将游标传递给下一次查询即可。这种方式适用于需要频繁进行分页查询的场景。

3. 使用Search After进行深度分页

Search After是Elasticsearch提供的一种分页方式,它可以根据上一次查询的结果来获取下一页的数据。Search After的原理是在上一次查询结果的基础上,跳过指定数量的文档,然后返回剩余的文档。这种方式适用于需要快速获取下一页数据的场景。

GET twitter/_search
{
    "size": 10,
    "query": {
        "match" : {
            "title" : "es"
        }
    },
    "search_after": [20000000, "50000"],
    "sort": [
        {"date": "asc"},
        {"_id": "desc"}
    ]
}

五、总结

如果数据量小(from+size在10000条内),或者只关注结果集的TopN数据,可以使用from/size 分页,简单粗暴;

数据量大,深度翻页,后台批处理任务(数据迁移)之类的任务,使用 scroll 方式;

数据量大,深度翻页,用户实时、高并发查询需求,使用 search after 方式;

ElasticSearch深度分页解决方案有很多种,不同的场景需要选择不同的方案。在使用ElasticSearch进行深度分页查询时,我们需要了解其分页原理以及各种分页方案的优缺点,以便根据实际情况选择合适的方案。

图片

文章来源:https://blog.csdn.net/weixin_40381772/article/details/135377647
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。