兩小時 Elasticsearch 性能優化，直接把慢查詢干團滅了……
?問題：慢查詢
搜索平臺的公共集群，由于業務眾多，對業務的es查詢語法缺少約束，導致問題頻發。業務可能寫了一個巨大的查詢直接把集群打掛掉，但是我們平臺人力投入有限，也不可能一條條去審核業務的es查詢語法，只能通過后置的手段去保證整個集群的穩定性，通過slowlog分析等，下圖中cpu已經100%了。
?
昨天剛好手頭有一點點時間，就想著能不能針對這些情況，把影響最壞的業務抓出來，進行一些改善，于是昨天花了2小時分析了一下，找到了一些共性的問題，可以通過平臺來很好的改善這些情況。
首先通過slowlog抓到一些耗時比較長的查詢，例如下面這個索引的查詢耗時基本都在300ms以上：
{
"from": 0,
"size": 200,
"timeout": "60s",
"query": {
"bool": {
"must": \[
{
"match": {
"source": {
"query": "5",
"operator": "OR",
"prefix\_length": 0,
"fuzzy\_transpositions": true,
"lenient": false,
"zero\_terms\_query": "NONE",
"auto\_generate\_synonyms\_phrase\_query": "false",
"boost": 1
}
}
},
{
"terms": {
"type": \[
"21"
\],
"boost": 1
}
},
{
"match": {
"creator": {
"query": "0d754a8af3104e978c95eb955f6331be",
"operator": "OR",
"prefix\_length": 0,
"fuzzy\_transpositions": "true",
"lenient": false,
"zero\_terms\_query": "NONE",
"auto\_generate\_synonyms\_phrase\_query": "false",
"boost": 1
}
}
},
{
"terms": {
"status": \[
"0",
"3"
\],
"boost": 1
}
},
{
"match": {
"isDeleted": {
"query": "0",
"operator": "OR",
"prefix\_length": 0,
"fuzzy\_transpositions": "true",
"lenient": false,
"zero\_terms\_query": "NONE",
"auto\_generate\_synonyms\_phrase\_query": "false",
"boost": 1
}
}
}
\],
"adjust\_pure\_negative": true,
"boost": 1
}
},
"\_source": {
"includes": \[
\],
"excludes": \[\]
}
}
這個查詢比較簡單，翻譯一下就是：
SELECT guid FROM xxx WHERE source=5 AND type=21 AND creator='0d754a8af3104e978c95eb955f6331be' AND status in (0,3) AND isDeleted=0;
?慢查詢分析
這個查詢問題還挺多的，不過不是今天的重點。比如這里面不好的一點是還用了模糊查詢fuzzy_transpositions,也就是查詢ab的時候，ba也會被命中，其中的語法不是今天的重點，可以自行查詢，我估計這個是業務用了SDK自動生成的，里面很多都是默認值。
第一反應當然是用filter來代替match查詢，一來filter可以緩存，另外避免這種無意義的模糊匹配查詢，但是這個優化是有限的，并不是今天講解的關鍵點，先忽略。
1、錯用的數據類型
我們通過kibana的profile來進行分析，耗時到底在什么地方？es有一點就是開源社區很活躍，文檔齊全，配套的工具也非常的方便和齊全。
可以看到大部分的時間都花在了PointRangQuery里面去了，這個是什么查詢呢？為什么這么耗時呢？這里就涉及到一個es的知識點，那就是對于integer這種數字類型的處理。在es2.x的時代，所有的數字都是按keyword處理的，每個數字都會建一個倒排索引，這樣查詢雖然快了，但是一旦做范圍查詢的時候。比如 type>1 and type<5就需要轉成 type in (1,2,3,4,5)來進行，大大的增加了范圍查詢的難度和耗時。
之后es做了一個優化，在integer的時候設計了一種類似于b-tree的數據結構，加速范圍的查詢，詳細可以參考(https://elasticsearch.cn/article/446)
所以在這之后，所有的integer查詢都會被轉成范圍查詢，這就導致了上面看到的isDeleted的查詢的解釋。那么為什么范圍查詢在我們這個場景下，就這么慢呢？能不能優化。
明明我們這個場景是不需要走范圍查詢的，因為如果走倒排索引查詢就是O(1)的時間復雜度，將大大提升查詢效率。由于業務在創建索引的時候，isDeleted這種字段建成了Integer類型，導致最后走了范圍查詢，那么只需要我們將isDeleted類型改成keyword走term查詢，就能用上倒排索引了。
實際上這里還涉及到了es的一個查詢優化。類似于isDeleted這種字段，毫無區分度的倒排索引的時候，在查詢的時候，es是怎么優化的呢？
2、多個Term查詢的順序問題
實際上，如果有多個term查詢并列的時候，他的執行順序，既不是你查詢的時候，寫進去的順序。
?例如上面這個查詢，他既不是先執行source=5再執行type=21按照你代碼的順序執行過濾，也不是同時并發執行所有的過濾條件，然后再取交集。es很聰明，他會評估每個filter的條件的區分度，把高區分度的filter先執行，以此可以加速后面的filter循環速度。比如creator=0d754a8af3104e978c95eb955f6331be查出來之后10條記錄，他就會優先執行這一條。
怎么做到的呢？其實也很簡單，term建的時候，每一個term在寫入的時候都會記錄一個詞頻，也就是這個term在全部文檔里出現的次數，這樣我們就能判斷當前的這個term他的區分度高低了。
3、為什么PointRangeQuery在這個場景下非常慢
上面提到了這種查詢的數據結構類似于b-tree,他在做范圍查詢的時候，非常有優勢，Lucene將這顆B-tree的非葉子結點部分放在內存里，而葉子結點緊緊相鄰存放在磁盤上。當作range查詢的時候，內存里的B-tree可以幫助快速定位到滿足查詢條件的葉子結點塊在磁盤上的位置，之后對葉子結點塊的讀取幾乎都是順序的。
總結就是這種結構適合范圍查詢，且磁盤的讀取是順序讀取的。但是在我們這種場景之下，term查詢可就麻煩了，數值型字段的TermQuery被轉換為了PointRangeQuery。這個Query利用Block k-d tree進行范圍查找速度非常快，但是滿足查詢條件的docid集合在磁盤上并非向Postlings list那樣按照docid順序存放，也就無法實現postings list上借助跳表做蛙跳的操作。
要實現對docid集合的快速advance操作，只能將docid集合拿出來，做一些再處理。這個處理過程在org.apache.lucene.search.PointRangeQuery#createWeight這個方法里可以讀取到。這里就不貼冗長的代碼了，主要邏輯就是在創建scorer對象的時候，順帶先將滿足查詢條件的docid都選出來，然后構造成一個代表docid集合的bitset，這個過程和構造Query cache的過程非常類似。之后advance操作，就是在這個bitset上完成的。所有的耗時都在構建bitset上，因此可以看到耗時主要在build_scorer上了。
驗證
找到原因之后，就可以開始驗證了。將原來的integer類型全部改成keyword類型，如果業務真的有用到范圍查詢，應該會報錯。通過搜索平臺的平臺直接修改配置，修改完成之后，重建索引就生效了。
索引切換之后的效果也非常的明顯，通過kibana的profile分析可以看到，之前需要接近100ms的PointRangQuery現在走倒排索引，只需要0.5ms的時間。
之前這個索引的平均latency在100ms+，這個是es分片處理的耗時,從搜索行為開始，到搜索行為結束的打點，不包含網絡傳輸時間和連接建立時間，單純的分片內的函數的處理時間的平均值，正常情況在10ms左右。
經過調整之后的耗時降到了10ms內。
通過監控查看慢查詢的數量，立即減少到了0。
未來
后續將通過搜索平臺側的能力來保證業務的查詢，所有的integer我們會默認你記錄的是狀態值，不需要進行范圍查詢，默認將會修改為keyword類型，如果業務確實需要范圍查詢，則可以通過后臺再修改回integer類型，這樣可以保證在業務不了解es機制的情況下，也能擁有較好的性能，節省機器計算資源。
目前還遇到了很多問題需要優化。例如重建索引的時候，機器負載太高。公共集群的機器負載分布不均衡的問題，業務的查詢和流量不可控等各種各樣的問題，要節省機器資源就一定會面對這種各種各樣的問題，除非土豪式做法，每個業務都擁有自己的機器資源，這里面有很多很多頗具技術挑戰的事情。
實際上，在這一塊還是非常利于積累經驗，對于es的了解和成長也非常快，在查問題的過程中，對于搜索引擎的使用和了解會成長的非常快。不僅如此，很多時候，我們用心地看到生產的問題，持續的跟蹤，一定會有所收獲。大家遇到生產問題的時候，務必不要放過任何細節，這個就是你收獲的時候，比你寫100行的CRUD更有好處。
