es 多条件查询_ES6.3版本踩坑之路整型字段慢查询导致CPU负载飙升-CSDN博客

“ 最近在做用户ES数据合并，将之前多个类型的索引数据合并成一个大的宽表索引，测试环境没有问题，切到线上环境就崩溃了，究竟是什么原因呢？” 01 — 事件起因 场景描述： 旧的用户ES索引，将用户信息分为基础信息与扩展信息两个索引。不少请求会同时请求两个索引的字段进行检索，这样就只能进行跨索引搜索，这样非常影响性能，所以这次重构就准备重新创建一张宽表索引包含用户目前所有维度的数据。

注：合并后索引总大小148GB左右  4.31亿文档

解决方案： 1、根据用户表定义新索引的字段并进行创建。 2、增量数据消费MQ：用户信息新增与更新会发送对应MQ消息，异步消费MQ并写入ES新的索引。 3、存量数据自定义脚本：从DB消费到ES。 4、灰度切读到新的索引。 5、完全切读到新的索引。 6、观察一段时间，停止旧索引的数据同步。 7、观察一段时间，删掉旧索引释放空间。其中问题就是出在第四步灰度切读的时候，测试环境一切正常，在正式环境QPS600，五台16C64GB的机器节点，瞬间有两台节点的CPU直接冲到99%，吓得我立马回滚项目，冷静分析导致出现的问题..... 02 — ES6.3整型值检索超时问题 场景描述： ES集群机器CPU瞬间飙升可能是由于慢查询导致请求处理不及时排队消耗大量CPU资源，立马查询ES慢日志发现大量请求耗时从原本的5ms瞬间上升到700ms-2s之间，这下心里一块大石头总算落下，因为找到了事故原因。

#数据已做脱敏处理 [2020-10-21T10:49:29,101][DEBUG][index.search.slowlog.query] [test-user-201905141120-3] [test_v2][2] took[743.1ms], took_millis[743], total_hits[0], types[test_info], stats[], search_type[QUERY_THEN_FETCH], total_shards[5], source[{"from":0,"size":20,"query":{"bool":{"must":[{"terms":{"appId":["1"],"boost":1.0}},{"match_phrase":{"nickName.keyword":{"query":"jxzy4nkxvb","slop":0,"zero_terms_query":"NONE","boost":1.0}}}],"adjust_pure_negative":true,"boost":1.0}},"sort":[{"uid":{"order":"desc"}}]}]#ES慢日志的配置方式，后续专门出一篇文章介绍

然后用慢SQL直接请求ES，发现的确耗时非常大(700ms-2s左右)，然后去掉appId条件，发现只有昵称查询的时候耗时在5ms左右，反复测试定位是appId的问题，而且在切换appId值的时候速度也会不一样。最后在张同学的帮助下，定位到了 ES6.3版本整型值如果这个字段值比较少的时候，且这个值的文档数比较多的时候会导致查询异常缓慢。在es中文社区也找到了类似问题的小伙伴，其总结了两点：

#ES整型检索具体慢的原因https://elasticsearch.cn/article/446

其一: 5.0以后number类型改为block k-d tree索引，对于低cardinality的number类型字段做conjuntion性能差。其二: Build cache的逻辑 https://elasticsearch.cn/question/3253

解决办法就是将字段值比较少的字段比如像status只有0和1的这样字段直接设置为keyword类型即可结束，那如何平滑迁移ES的索引呢，可以查询之前的文章有详细操作：实战-elasticsearch索引平滑迁移方案。还有一个解决办法就是可以升级es版本，升级到6.8即可解决该问题。解决问题切莫自己一直闷头研究，如果一个问题超过2个小时没有解决，就可以马上咨询身边有相关经验的同事朋友，一起研究解决。喵~-~ 精彩推荐