?問(wèn)題：慢查詢

搜索平臺(tái)的公共集群，由于業(yè)務(wù)眾多，對(duì)業(yè)務(wù)的es查詢語(yǔ)法缺少約束，導(dǎo)致問(wèn)題頻發(fā)。業(yè)務(wù)可能寫了一個(gè)巨大的查詢直接把集群打掛掉，但是我們平臺(tái)人力投入有限，也不可能一條條去審核業(yè)務(wù)的es查詢語(yǔ)法，只能通過(guò)后置的手段去保證整個(gè)集群的穩(wěn)定性，通過(guò)slowlog分析等，下圖中cpu已經(jīng)100%了。

?

昨天剛好手頭有一點(diǎn)點(diǎn)時(shí)間，就想著能不能針對(duì)這些情況，把影響最壞的業(yè)務(wù)抓出來(lái)，進(jìn)行一些改善，于是昨天花了2小時(shí)分析了一下，找到了一些共性的問(wèn)題，可以通過(guò)平臺(tái)來(lái)很好的改善這些情況。

首先通過(guò)slowlog抓到一些耗時(shí)比較長(zhǎng)的查詢，例如下面這個(gè)索引的查詢耗時(shí)基本都在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": \[\]
  }
}

這個(gè)查詢比較簡(jiǎn)單，翻譯一下就是：

SELECT guid FROM xxx WHERE source=5 AND type=21 AND creator='0d754a8af3104e978c95eb955f6331be' AND status in (0,3) AND isDeleted=0;

?慢查詢分析

這個(gè)查詢問(wèn)題還挺多的，不過(guò)不是今天的重點(diǎn)。比如這里面不好的一點(diǎn)是還用了模糊查詢fuzzy_transpositions,也就是查詢ab的時(shí)候，ba也會(huì)被命中，其中的語(yǔ)法不是今天的重點(diǎn)，可以自行查詢，我估計(jì)這個(gè)是業(yè)務(wù)用了SDK自動(dòng)生成的，里面很多都是默認(rèn)值。

第一反應(yīng)當(dāng)然是用filter來(lái)代替match查詢，一來(lái)filter可以緩存，另外避免這種無(wú)意義的模糊匹配查詢，但是這個(gè)優(yōu)化是有限的，并不是今天講解的關(guān)鍵點(diǎn)，先忽略。

1、錯(cuò)用的數(shù)據(jù)類型

我們通過(guò)kibana的profile來(lái)進(jìn)行分析，耗時(shí)到底在什么地方？es有一點(diǎn)就是開源社區(qū)很活躍，文檔齊全，配套的工具也非常的方便和齊全。

可以看到大部分的時(shí)間都花在了PointRangQuery里面去了，這個(gè)是什么查詢呢？為什么這么耗時(shí)呢？這里就涉及到一個(gè)es的知識(shí)點(diǎn)，那就是對(duì)于integer這種數(shù)字類型的處理。在es2.x的時(shí)代，所有的數(shù)字都是按keyword處理的，每個(gè)數(shù)字都會(huì)建一個(gè)倒排索引，這樣查詢雖然快了，但是一旦做范圍查詢的時(shí)候。比如 type>1 and type<5就需要轉(zhuǎn)成 type in (1,2,3,4,5)來(lái)進(jìn)行，大大的增加了范圍查詢的難度和耗時(shí)。

之后es做了一個(gè)優(yōu)化，在integer的時(shí)候設(shè)計(jì)了一種類似于b-tree的數(shù)據(jù)結(jié)構(gòu)，加速范圍的查詢，詳細(xì)可以參考(https://elasticsearch.cn/article/446)

所以在這之后，所有的integer查詢都會(huì)被轉(zhuǎn)成范圍查詢，這就導(dǎo)致了上面看到的isDeleted的查詢的解釋。那么為什么范圍查詢?cè)谖覀冞@個(gè)場(chǎng)景下，就這么慢呢？能不能優(yōu)化。

明明我們這個(gè)場(chǎng)景是不需要走范圍查詢的，因?yàn)槿绻叩古潘饕樵兙褪荗(1)的時(shí)間復(fù)雜度，將大大提升查詢效率。由于業(yè)務(wù)在創(chuàng)建索引的時(shí)候，isDeleted這種字段建成了Integer類型，導(dǎo)致最后走了范圍查詢，那么只需要我們將isDeleted類型改成keyword走term查詢，就能用上倒排索引了。

實(shí)際上這里還涉及到了es的一個(gè)查詢優(yōu)化。類似于isDeleted這種字段，毫無(wú)區(qū)分度的倒排索引的時(shí)候，在查詢的時(shí)候，es是怎么優(yōu)化的呢？

2、多個(gè)Term查詢的順序問(wèn)題

實(shí)際上，如果有多個(gè)term查詢并列的時(shí)候，他的執(zhí)行順序，既不是你查詢的時(shí)候，寫進(jìn)去的順序。

?例如上面這個(gè)查詢，他既不是先執(zhí)行source=5再執(zhí)行type=21按照你代碼的順序執(zhí)行過(guò)濾，也不是同時(shí)并發(fā)執(zhí)行所有的過(guò)濾條件，然后再取交集。es很聰明，他會(huì)評(píng)估每個(gè)filter的條件的區(qū)分度，把高區(qū)分度的filter先執(zhí)行，以此可以加速后面的filter循環(huán)速度。比如creator=0d754a8af3104e978c95eb955f6331be查出來(lái)之后10條記錄，他就會(huì)優(yōu)先執(zhí)行這一條。

怎么做到的呢？其實(shí)也很簡(jiǎn)單，term建的時(shí)候，每一個(gè)term在寫入的時(shí)候都會(huì)記錄一個(gè)詞頻，也就是這個(gè)term在全部文檔里出現(xiàn)的次數(shù)，這樣我們就能判斷當(dāng)前的這個(gè)term他的區(qū)分度高低了。

3、為什么PointRangeQuery在這個(gè)場(chǎng)景下非常慢

上面提到了這種查詢的數(shù)據(jù)結(jié)構(gòu)類似于b-tree,他在做范圍查詢的時(shí)候，非常有優(yōu)勢(shì)，Lucene將這顆B-tree的非葉子結(jié)點(diǎn)部分放在內(nèi)存里，而葉子結(jié)點(diǎn)緊緊相鄰存放在磁盤上。當(dāng)作range查詢的時(shí)候，內(nèi)存里的B-tree可以幫助快速定位到滿足查詢條件的葉子結(jié)點(diǎn)塊在磁盤上的位置，之后對(duì)葉子結(jié)點(diǎn)塊的讀取幾乎都是順序的。

總結(jié)就是這種結(jié)構(gòu)適合范圍查詢，且磁盤的讀取是順序讀取的。但是在我們這種場(chǎng)景之下，term查詢可就麻煩了，數(shù)值型字段的TermQuery被轉(zhuǎn)換為了PointRangeQuery。這個(gè)Query利用Block k-d tree進(jìn)行范圍查找速度非常快，但是滿足查詢條件的docid集合在磁盤上并非向Postlings list那樣按照docid順序存放，也就無(wú)法實(shí)現(xiàn)postings list上借助跳表做蛙跳的操作。

要實(shí)現(xiàn)對(duì)docid集合的快速advance操作，只能將docid集合拿出來(lái)，做一些再處理。這個(gè)處理過(guò)程在org.apache.lucene.search.PointRangeQuery#createWeight這個(gè)方法里可以讀取到。這里就不貼冗長(zhǎng)的代碼了，主要邏輯就是在創(chuàng)建scorer對(duì)象的時(shí)候，順帶先將滿足查詢條件的docid都選出來(lái)，然后構(gòu)造成一個(gè)代表docid集合的bitset，這個(gè)過(guò)程和構(gòu)造Query cache的過(guò)程非常類似。之后advance操作，就是在這個(gè)bitset上完成的。所有的耗時(shí)都在構(gòu)建bitset上，因此可以看到耗時(shí)主要在build_scorer上了。

驗(yàn)證

找到原因之后，就可以開始驗(yàn)證了。將原來(lái)的integer類型全部改成keyword類型，如果業(yè)務(wù)真的有用到范圍查詢，應(yīng)該會(huì)報(bào)錯(cuò)。通過(guò)搜索平臺(tái)的平臺(tái)直接修改配置，修改完成之后，重建索引就生效了。

索引切換之后的效果也非常的明顯，通過(guò)kibana的profile分析可以看到，之前需要接近100ms的PointRangQuery現(xiàn)在走倒排索引，只需要0.5ms的時(shí)間。

之前這個(gè)索引的平均latency在100ms+，這個(gè)是es分片處理的耗時(shí),從搜索行為開始，到搜索行為結(jié)束的打點(diǎn)，不包含網(wǎng)絡(luò)傳輸時(shí)間和連接建立時(shí)間，單純的分片內(nèi)的函數(shù)的處理時(shí)間的平均值，正常情況在10ms左右。

經(jīng)過(guò)調(diào)整之后的耗時(shí)降到了10ms內(nèi)。

通過(guò)監(jiān)控查看慢查詢的數(shù)量，立即減少到了0。

未來(lái)

后續(xù)將通過(guò)搜索平臺(tái)側(cè)的能力來(lái)保證業(yè)務(wù)的查詢，所有的integer我們會(huì)默認(rèn)你記錄的是狀態(tài)值，不需要進(jìn)行范圍查詢，默認(rèn)將會(huì)修改為keyword類型，如果業(yè)務(wù)確實(shí)需要范圍查詢，則可以通過(guò)后臺(tái)再修改回integer類型，這樣可以保證在業(yè)務(wù)不了解es機(jī)制的情況下，也能擁有較好的性能，節(jié)省機(jī)器計(jì)算資源。

目前還遇到了很多問(wèn)題需要優(yōu)化。例如重建索引的時(shí)候，機(jī)器負(fù)載太高。公共集群的機(jī)器負(fù)載分布不均衡的問(wèn)題，業(yè)務(wù)的查詢和流量不可控等各種各樣的問(wèn)題，要節(jié)省機(jī)器資源就一定會(huì)面對(duì)這種各種各樣的問(wèn)題，除非土豪式做法，每個(gè)業(yè)務(wù)都擁有自己的機(jī)器資源，這里面有很多很多頗具技術(shù)挑戰(zhàn)的事情。

實(shí)際上，在這一塊還是非常利于積累經(jīng)驗(yàn)，對(duì)于es的了解和成長(zhǎng)也非常快，在查問(wèn)題的過(guò)程中，對(duì)于搜索引擎的使用和了解會(huì)成長(zhǎng)的非?？臁２粌H如此，很多時(shí)候，我們用心地看到生產(chǎn)的問(wèn)題，持續(xù)的跟蹤，一定會(huì)有所收獲。大家遇到生產(chǎn)問(wèn)題的時(shí)候，務(wù)必不要放過(guò)任何細(xì)節(jié)，這個(gè)就是你收獲的時(shí)候，比你寫100行的CRUD更有好處。