【Elasticsearch】优秀实践-你的ES怎么查的慢了？

前言

经常会有人吐槽，Elasticsearch为什么查着查着突然就慢了？
笔者总结了常见的一些导致查询慢的场景，供大家排查。

go go go

Elasticsearch查询慢问题排查思路

Elasticsearch的查询慢的问题往往是由多种因素造成的，同时我们也需要遵循Elasticsearch的查询准则：ES适合top N的查询，不适合大数据量返回的查询。

场景1 内存参数配置不合理，文件系统缓存不足。

记得给你的Elasticsearch预留一定的内存给Lucene文件缓存使用哦。

场景2 查询范围过大，一次查询过多的分片，如全表扫描查询。

一次查询过多的分片，容易把内存撑爆，so，最好分批次查询，温柔点嘛。

场景3 进行深度翻页查询，如查询10000之后的结果。

进行深度翻页查询，如查询10000-10010的结果，这时候需要使用scroll查询了。

场景4 查询返回的结果集过大，如10w。

同样，这种查询太暴力了，建议使用scroll查询分批次返回，Elasticsearch没你想象的坚强。

场景5 查询语句不是最优，如过滤查询可以使用filter。

根据具体的业务场景去优化查询语句，过滤查询使用filter，不需要评分，减少很多计算。

场景6 使用模糊匹配查询造成内存溢出的问题。

千万不要尝试使用*等通配符的暴力做法，内存很脆弱的。

场景7 聚合查询返回的结果集过大，聚合的范围过大。

聚合更加是耗费内存的操作了，所以你懂的。

场景8 聚合查询N多唯一值引起的高内存使用率。

同上，慎重。

场景9 用text字段进行排序，造成fielddata占用大量的内存。

排序请用keyword字段，谢谢。

场景10 索引段文件过多，需要定时的进行索引段合并。

查询的底层文件是lucene段文件，减少段文件个数一定程度上可以减少并发查询的段文件个数。

场景11 分片分布不均衡，未能充分利用机器资源。

尽量让分片均匀分片，查询的时候才能充分发挥分布式的优势。

场景12 磁盘IO瓶颈。

没办法，加钱吧？

场景13 索引数据结构mapping设计不合理，如不需要分词的keyword。

mapping设置超关键的，建立索引之前慎之又慎，切记。。。

场景14 分词器设计不合理，如存在过度分词的问题。

是的，如果你的字段分的越多，需要遍历的term就更多，查询肯定就更慢了呀。

场景15 索引分片过大，如单个分片达到100GB+。

单个分片这么大，你考虑过机器的感受吗，建议单个分片20-50GB大小。

小结

列举了一些常见的会造成写入慢的场景，更多的查询调优手段点这里。

写入慢排查思路在这里，等你来，老弟。