衡阳县专业做淘宝网站,食品品牌网站策划,上海三大设计院,中国互联网排名一、前言
ElasticSearch是一个基于Lucene的搜索引擎#xff0c;它支持复杂的全文搜索和实时数据分析。在实际应用中#xff0c;我们经常需要对大量数据进行分页查询#xff0c;但是传统的分页方式在处理大量数据时会遇到性能瓶颈。本文将介绍ElasticSearch分页工作原理、深…一、前言
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 阶段确定要取哪些docfetch 阶段取出具体的 doc。
query阶段
如上图所示描述了一次搜索请求的 query 阶段: Client 发送一次搜索请求node1 接收到请求然后node1 创建一个大小为from size的优先级队列用来存结果我们管 node1 叫 coordinating node。 coordinating node将请求广播到涉及到的 shards每个 shard 在内部执行搜索请求然后将结果存到内部的大小同样为from size 的优先级队列里可以把优先级队列理解为一个包含top N结果的列表。 每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating nodecoordinating node 拿到各个 shards 返回的结果后对结果进行一次合并产生一个全局的优先级队列存到自身的优先级队列里。
在上面的例子中coordinating node 拿到(from size) * 6条数据然后合并并排序后选择前面的from size条数据存到优先级队列以便 fetch 阶段使用。
另外各个分片返回给 coordinating node 的数据用于选出前from size条数据所以只需要返回唯一标记 doc 的_id以及用于排序的_score即可这样也可以保证返回的数据量足够小。
coordinating node 计算好自己的优先级队列后query 阶段结束进入 fetch 阶段。
fetch 阶段 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」 来避免多次去同一分片取数据从而提高性能。 三、深度分页问题 内存占用高当查询结果集很大时使用scroll API会导致内存占用过高甚至出现OOM异常。 响应时间慢由于需要将所有数据加载到内存中所以scroll API的响应时间相对较慢。 游标管理复杂使用scroll API时需要手动管理游标包括创建、删除和滚动游标等操作这会增加开发难度和维护成本。
Elasticsearch 的From/Size方式提供了分页的功能同时也有相应的限制。
举个例子一个索引有10亿数据分10个 shards然后一个搜索请求from1000000size100这时候会带来严重的性能问题CPU内存IO网络带宽。
在 query 阶段每个shards需要返回 1000100 条数据给 coordinating node而 coordinating node 需要接收10 * 1000100 条数据即使每条数据只有 _doc _id 和 _score这数据量就很大了。 四、解决方案
1. 使用scroll API进行深度分页
scroll API可以获取大量数据并且可以在内存中缓存这些数据。通过scroll API我们可以在一次查询中获取所有满足条件的文档然后根据需要对它们进行排序和过滤。这种方式适用于需要处理大量数据的场景。
Scroll可以把scroll理解为关系型数据库里的cursor因此scroll并不适合用来做实时搜索而更适合用于后台批处理任务比如群发。scroll可以分为初始化和遍历两部初始化时将「所有符合搜索条件的搜索结果缓存起来注意这里只是缓存的doc_id而并不是真的缓存了所有的文档数据取数据是在fetch阶段完成的」可以想象成快照。支持排序。
Scroll ScanES提供了scroll scan方式进一步提高遍历性能但是scroll scan不支持排序因此scroll scan适合不需要排序的场景。
POST /twitter/tweet/_search?scroll1m
{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}]
} 五、总结
如果数据量小fromsize在10000条内或者只关注结果集的TopN数据可以使用from/size 分页简单粗暴
数据量大深度翻页后台批处理任务数据迁移之类的任务使用 scroll 方式
数据量大深度翻页用户实时、高并发查询需求使用 search after 方式
ElasticSearch深度分页解决方案有很多种不同的场景需要选择不同的方案。在使用ElasticSearch进行深度分页查询时我们需要了解其分页原理以及各种分页方案的优缺点以便根据实际情况选择合适的方案。
