【ElasticSearch】查询优化

一、背景

每周统计接口耗时，发现耗时较长的前几个接口tp5个9都超过了1000ms。

经过分析慢查询的原因是ES查询耗时太长导致的

二、设计方案

1、问题定位

查询功能使用不当导致慢查询

索引设计存在不合理的地方，导致慢查询

2、方案概述

2.1、查询Fetch Source优化

• 问题

业务查询语句获取的数据集比较大，并且从source中获取了非必须的字段，导致查询较慢。

举例：只需要从es中查询id这一个字段，却把所有字段查询了出来

• 分析

因为数据集较大，若每个字段都去source中获取所需字段，会导致耗时严重增加，需要避免这种操作，可以大大降低es集群，网络和客户端的压力，提高程序的性能。

• 优化方法

查语句查询时，将fetchSource设置为false

2.2、查询优化，调整filter过滤顺序

• 问题

  过滤效果不明显的条件放在了前面，导致查询出大量不需要的数据，导致查询变慢

• 优化方法

  把过滤效果明显的条件提前，按照过滤效果把过滤条件排序

2.3、索引时间精度优化

• 分析

降低时间精度。研究Filter的工作原理可以看出，它每次工作都是遍历整个索引的，所以时间粒度越大，对比越快，搜索时间越短，在不影响功能的情况下，时间精度越低越好，有时甚至牺牲一点精度也值得，当然最好的情况是根本不作时间限制。

• 优化方法

  es重新刷索引，增加冗余的时间字段，精确到天。

  带有时间范围的查询使用该字段进行查询

2.4、索引优化，合理使用keyword类型

• 分析

  ES5.x里对数值型字段做TermQuery可能会很慢。

  在ES5.x+里，一定要注意数值类型是否需要做范围查询，看似数值，但其实只用于Term或者Terms这类精确匹配的，应该定义为keyword类型。

  ES 2.x -> 5.x升级对于数值类型和Term Query有何重大变化？

  1. Lucene6.0引入了重新设计的数值类型的索引结构，不再采用倒排索，而是使用了更适合范围查找的Block K-d Tree。 ES从5.0开始引入这种新结构

  2. Term Query由于通常非常快，从5.1.1开始不再被缓存到Query Cache

  有兴趣的可以看一下详细分析：https://elasticsearch.cn/article/446

• 优化方法

  把不做范围查询的数值类型修改为keyword类型

3、reIndex索引

1. 先在管理平台创建新索引模板。模板名：xxx_new，设置索引生成规则 

2. 在导数据之前将新索引副本数设为0，这样导数据速度较快，导完数据再改为1 即可

3. 通过脚本执行reIndex操作，需要记录开始时间time​

4. 再次执行reIndex上次reIndex期间新写入的增量数据(time减去时差8小时) ,这一步的写入可能需要几分钟

5. 操作动态配置，停止写入ES数据，然后再次reindex这几分钟内写入的增量数据，命令同上（这一次的写入可能就几秒钟了）

6. 删除旧索引，并将新索引的别名设置为旧索引的名称

7. 开启写入ES开关，并且重新导入停止写入ES期间的数据，并恢复各索引副本数为1。