ES 分页查询缓慢或全量查询慢问题
背景
前段时间因为数据量越来越大,导致数据库的查询压力越来越大。所以决定将数据刷入到ES中进行查询,以提高查询速度。想法是好的,测试环境也没有仔细测。心想ES查询总不会慢了。再慢能慢到哪里去。放心大胆的上了生产环境,结果给我好好的上了一课。
因为有全量查询数据的业务,而在我们自己封装的包里只有封装好的分页查询方法。按写SQL的思维形式来想,既然封装好的ES的基础包中没有全量查询数据的方式,那就分页查询呗,直到全部查询完毕。应该也不会太慢。再慢能慢过数据库吗?
一旦喜欢上谁就别无所求,只要每天能见到他就已经觉得很庆幸,一辈子很短,如白驹过隙,转瞬即逝。可这种心情很长,如高山大川,绵延不绝。 ——《武林外传》
发现问题
就在上线之后的第二天。突然有人反馈说用到了全量查询的业务特别的慢。创建好的任务要两三个小时以后才执行。而在此之前,这个任务最多也就是5分钟也开始执行了,我先是心头一紧,心想完了,难道是做了个负优化。难道查询ES 真没有数据库快吗?是不是网络问题?是不是查询语句我写的有问题影响效率了?
定位问题
带着关键字去生产上查了日志。先查到的是一个查询语句的日志。看到以后吃惊了。语句之大,五六屏放不下。吃惊之后就想,会不会是这个查询条件放的太多了?导致查询速率瞬间下降。一方面反思查询的时候不应该这么查询,代码不能这么写。一方面将查询语句拿出来,放到ES Head 里面查一下,看看到底有多慢。
查了以后,结果还是很出乎我的意料的。尽管条件贼老长,可是ES不愧是ES,还是匹配的很快。200ms左右。这结果让我瞬间麻爪,不知该如何继续了。可是日志里面打印的确实是两三分钟之后才返回了查询结果。
突然没了方向。那就先查查ES如何来实现分页或者全量数据的查询。通过 这篇文章 查到了三种方式:
- from size 查询方式
- scroll 深分页查询
- searchAfter 深分页查询
三种方式简单来说一下区别:
分页方式 | 特性 |
---|---|
from size 查询 | 适合小数据量的情况(10000-50000的数据左右)越往后时间越长,性能越差 |
scroll 查询 | 能解决深分页问题,但是生成了数据快照,比较耗费资源。由于快照,不支持增量数据查询,不支持跳页 |
searchAfter查询 | 能解决深分页问题,且能实时反应增删的数据,不支持跳页,数据需要有唯一的标识 |
你是藏在云层里的月亮🌙,也是我穷极一生寻找的宝藏
三种方式的区别大致如此,详细一些,上面的文章 或者 这篇文章 写的还是蛮详细的。
看到这里已经看到了实现方式以及区别,接下来就是看包里封装的分页查询逻辑是如何实现的。
从图中可以看到,参数中的from参数 并没有使用,查询的时候只是设置了 offset参数。那猜测一下,应该是用了 第一种 from size 的查询方式 不过默认from 应该设置了0。这样看的话,选择了性能最差的一种,确实是慢的应该了。继续往下看,
如果有searchAfter 那么,会使用searchAfter查询。否则使用了Scroll查询。看来使用from size 方式 的同时就已经在为scroll方式打基础了。那么我们传入的from参数 是什么时候使用的呢?
继续读代码,发现逻辑是,如果第一次 使用 from size 方式 查询的数据满足偏移量,那么就直接返回,否则使用scroll方式继续查询,直到满足条件为止。
也许是不懂想要的爱,才会一再受到伤害。也许是背负很多次失败,才能妥善的窥见未来。那些被心酸辜负劫走的小幸福,希望他还能认识路,早点回来
破案了
通过上面的分析来看,虽然包里封装的确实是,能通过分页查询到我们需要的数据,但是再来看一下我调用的地方:
为了查询到全部的数据,我是每次查询5000条,然后通过第一次返回的总数,来计算总共要查询多少次,接着就是循环修改 页码并且调用包封装好的方法。结果可想而知,慢的原因就出来了。
- 当我查询第二页的时候,由于第一页的数据已经不满足了,也就是用from size 方式查询的数据不够了,那么就会使用scroll的方式来查询第二页。查到之后满足返回数据
- 当我查询第三页的时候,还是第一页的数据无法满足,那么会使用scroll的方式来查询第二页,第二页不是想要的,也丢弃了,则用scroll的形式查询第三页。
- 当我查询第四页的时候 …
所以时间就是这么变长的。假如说我查询第10页的数据,那么前9次的查询都是无效的,但是确实真实的查询了。而且越到后面无效查询就越多。如果我分页分了几万次,想象一下,那得浪费多少次查询。根本就是指数级的增长浪费。这么来看ES没有挂掉已经是万幸了。
你像风来了又走,我心满了又空。—《半生缘》
解决办法
既然找到了问题所在,那就是打开的方式不对了。所以不能直接使用这样的分页方法。既然想获取全量的数据,那就要么直接使用scroll的方式查询,要么直接使用searchAfter的形式查询。经过上面的对比,我决定使用searchAfter的方式来实现全量数据查询。因为这个看起来性能更好一些。
当使用searchAfter的时候,就不需要传递from属性了,只需要传入偏移量。这样当达到偏移量的时候,返回对应偏移量的ID
if (offset == curHit) {
searchAfterStr = myGson.toJson(hit.getSortValues());
result.setSearchAfter(searchAfterStr);
break;
}
使用searchAftere需要注意的点:
- 查询的数据要有唯一的主键,如果没有业务主键,用ES自己生成的主键也可以。
- 查询的时候要指定排序规则
- 不支持跳页查询
- 查询要返回最后一条记录的排序字段的值
- 下次查询的searchAfter 要带上上次查到的最后一条记录的排序字段的值
示例:(示例并非是我的代码,是从 此文章 复制而来)
TermQueryBuilder queryBuilder = QueryBuilders.termQuery("age", 24);
Object[] objects= new Object[]{"14"};
//第二次请求,携带sort字段的值进行查询。
SearchRequest searchRequest = new SearchRequest();
SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();
searchSourceBuilder.query(queryBuilder).sort("id",SortOrder.ASC).searchAfter(objects);
searchSourceBuilder.from(0).size(3);
searchRequest.source(searchSourceBuilder);
SearchResponse search = client.search(searchRequest, RequestOptions.DEFAULT);
写在最后
遇到生产问题还是要一步一步的排查。其实最难的是在定位问题,找到问题所在,问题也就自然有了解决的办法。 最后一句话:一般离奇的问题,都是由于小的问题导致的
你知道什么东西最灿烂吗?是你的笑容。文章来源:https://www.toymoban.com/news/detail-744099.html
参考文章文章来源地址https://www.toymoban.com/news/detail-744099.html
- ES(elasticsearch) - 三种姿势进行分页查询
- java实现es的search after查询(三种方式详解)
- ElasticSearch分页search_after和scroll的区别以及用法
- elasticsearch restHighLevelClient 游标查询全量数据示例
- Elasticsearch Search Scroll API 查询全量数据
到了这里,关于ElasticSearch分页查询缓慢问题记录的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!