【ElasticSearch】查詢優化

1、背景

每週統計接口耗時，發現耗時較長的前幾個接口tp5個9都超過了1000ms。

通過分析慢查詢的緣由是ES查詢耗時太長致使的

2、設計方案

一、問題定位

查詢功能使用不當致使慢查詢

索引設計存在不合理的地方，致使慢查詢

二、方案概述

2.一、查詢Fetch Source優化

• 問題

業務查詢語句獲取的數據集比較大，而且從source中獲取了非必須的字段，致使查詢較慢。

舉例：只須要從es中查詢id這一個字段，卻把全部字段查詢了出來

• 分析

由於數據集較大，若每一個字段都去source中獲取所需字段，會致使耗時嚴重增長，須要避免這種操做，能夠大大下降es集羣，網絡和客戶端的壓力，提升程序的性能。

• 優化方法

查語句查詢時，將fetchSource設置爲false

2.二、查詢優化，調整filter過濾順序

• 問題

  過濾效果不明顯的條件放在了前面，致使查詢出大量不須要的數據，致使查詢變慢

• 優化方法

  把過濾效果明顯的條件提早，按照過濾效果把過濾條件排序

2.三、索引時間精度優化

• 分析

下降時間精度。研究Filter的工做原理能夠看出，它每次工做都是遍歷整個索引的，因此時間粒度越大，對比越快，搜索時間越短，在不影響功能的狀況下，時間精度越低越好，有時甚至犧牲一點精度也值得，固然最好的狀況是根本不做時間限制。

• 優化方法

  es從新刷索引，增長冗餘的時間字段，精確到天。

  帶有時間範圍的查詢使用該字段進行查詢

2.四、索引優化，合理使用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類型

三、reIndex索引

1. 先在管理平臺建立新索引模板。模板名：xxx_new，設置索引生成規則 

2. 在導數據以前將新索引副本數設爲0，這樣導數據速度較快，導完數據再改成1 便可

3. 經過腳本執行reIndex操做，須要記錄開始時間time​

4. 再次執行reIndex上次reIndex期間新寫入的增量數據(time減去時差8小時) ,這一步的寫入可能須要幾分鐘

5. 操做動態配置，中止寫入ES數據，而後再次reindex這幾分鐘內寫入的增量數據，命令同上（這一次的寫入可能就幾秒鐘了）

6. 刪除舊索引，並將新索引的別名設置爲舊索引的名稱

7. 開啓寫入ES開關，而且從新導入中止寫入ES期間的數據，並恢復各索引副本數爲1。