如何分析Elasticsearch中奇怪的查詢命中數問題

這期內容當中小編將會給大家帶來有關如何分析Elasticsearch中奇怪的查詢命中數問題，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

業務部門反饋，在某個月份的索引中，當查詢條件不變，僅添加一個索引前綴到請求中后，搜索返回的命中數量反而降低，如下圖所示，從索引 skylay*_alarm-2020.02* 中查詢時，命中結果總數 total為49條

?

但是當添加了一個索引前綴 skylar*_alarm-2020.01* ，從 skylay*_alarm-2020.02*,skylar*_alarm-2020.01* 兩組索引一起查詢時，命中結果總數居然降低為15條了：

?

按照常規理解，添加一個索引到查詢條件中，命中結果集只可能更多，不應該降低，仔細觀察返回結果，發現 _shards 中的 skipped 非常多，這點很可疑，感覺多半與他有關。

分析

分析查詢問題，首先想到的就是 profile 一把，在請求體中添加 "profile": true, 可惜沒看到有價值的東西，然后 google 一把，看有沒有其他人遇到 skipped 問題，發現在社區中很多人問到 skipped相關問題，基本沒有人回復，唯一有價值的答復如下：

Are shards skipped when a range query does not create hits

Yes, there is a pre-flight search phase called the can match search phase that removes all shards from a search request that a query can not match (e.g., if a range query does not overlap with the range of values for a shard). This feature exists since 5.6.

這段內容大致是說從5.6版本開始，在真正的查詢開始之前根據某些條件跳過不會匹配到的分片，例如范圍查詢過程中，某些分片的值不在查詢區間。

除此之外再無更多內容，只能從源碼層面繼續分析。函數AbstractSearchAsyncAction#buildSearchResponse 負責構建查詢返回結果，skipped數量取決于這個類中的一個計數器，繼續向上翻，找到將分片標記為 skip 的地方CanMatchPreFilterSearchPhase#getIterator:

private GroupShardsIterator<SearchShardIterator> getIterator(...) {
    for (SearchShardIterator iter : shardsIts) {
        if (possibleMatches.get(i++)) {
            iter.reset();
        } else {
            //標記為 skip，查詢的時候不會去查
            iter.resetAndSkip();
        }
    }
    return shardsIts;
}

由于需要優先解決線上問題，暫時先不分析分片被設置為 skip 都會有哪些條件，CanMatchPreFilterSearchPhase這個階段只有滿足一定條件時才會執行，也就是說如果不走這個階段就不會去檢查分片要不要被 skip。檢查條件在 TransportSearchAction#shouldPreFilterSearchShards中實現，在此不再貼代碼，總結起來常見條件包括下面幾個，滿足下列條件之一時，不走 CanMatchPreFilterSearchPhase （暫且稱為“預過濾”）流程。

• 查詢中帶有 Global Aggregation 

• 查詢中帶有聚合，并且聚合中設置了："min_doc_count": 0

• 待查詢的分片數小于 128，由查詢參數 pre_filter_shard_size指定。

• 查詢中使用了 Suggester

解決

找到了可以跳過“預過濾”的條件，問題解決問題就比較簡單，有兩種方式不影響現有業務：

• 對于含有聚合請求的查詢，可以在聚合請求中添加 "min_doc_count": 0

• 對于不含聚合請求的查詢，可以在請求中調整pre_filter_shard_size參數，讓他大于待查詢的分片數，

  例如:_search?pre_filter_shard_size=1000

當然，也可以統一使用 pre_filter_shard_size 參數。到此問題解決了，skipped 分片消失：

在 ES 使用過程中需要看代碼才能解決問題的時候比較少，但是關于查詢過程中分片 skipped 的原理在官方文檔中沒有具體說明，甚至在手冊中沒有解釋這個字段的含義。這次業務方使用的 ES 版本為5.6.12，不確定新版本的 ES 是否也存在類似問題，未來抽時間在新版本上分析一下“預過濾”的原理。

上述就是小編為大家分享的如何分析Elasticsearch中奇怪的查詢命中數問題了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。