2016-07-26 64 views
1

由於我的ES索引/集羣已經擴大(現在@ 20億個文檔),我注意到了更顯着的性能損失。所以我開始討論我的疑問,看看我是否可以從他們身上榨取一點點。彈性搜索過濾器的執行速度遠遠低於查詢

正如我這樣做,我注意到,當我在過濾器中使用布爾查詢時,我的結果大概需要3.5-4秒才能回來。但是,如果我做同樣的事情在我的查詢它更像是10-20ms

這裏有2個疑問:

使用過濾器

POST /backup/entity/_search?routing=39cd0b95-efc3-4eee-93d1-93e6f5837d6b 
{ 
    "query": {"bool":{"should":[],"must":[{"match_all":{}}]}}, 
    "filter": { 
    "bool": { 
     "must": [ 
     { 
      "term": { 
      "serviceId": "39cd0b95-efc3-4eee-93d1-93e6f5837d6b" 
      } 
     }, 
     { 
      "term": { 
      "subscriptionId": "3eb5021e-2f1d-4292-9fd5-95788ebfafa0" 
      } 
     }, 
     { 
      "term": { 
      "subscriptionType": 0 
      } 
     }, 
     { 
      "terms": { 
      "entityType": [ 
       "4" 
      ] 
      } 
     } 
     ] 
    } 
    } 
} 

使用查詢

POST /backup/entity/_search?routing=39cd0b95-efc3-4eee-93d1-93e6f5837d6b 
{ 
    "query": {"bool":{"should":[],"must":[ 
     { 
      "term": { 
      "serviceId": "39cd0b95-efc3-4eee-93d1-93e6f5837d6b" 
      } 
     }, 
     { 
      "term": { 
      "subscriptionId": "3eb5021e-2f1d-4292-9fd5-95788ebfafa0" 
      } 
     }, 
     { 
      "term": { 
      "subscriptionType": 0 
      } 
     }, 
     { 
      "terms": { 
      "entityType": [ 
       "4" 
      ] 
      } 
     } 
     ]}} 
} 

就像我說的,第二種方法,我根本不使用過濾器,只需要磨機秒,而第一個查詢需要將近4秒。這看起來完全是從文檔說的背後。他們說過濾器應該非常快,而查詢應該是需要更長時間的。那麼爲什麼我在這裏看到完全相反的情況?

它可能是我的索引映射的東西?如果任何人有任何想法爲什麼發生這種情況,我很樂意聽取建議。

感謝

+0

如果你是第一次執行與後續者相比,它不相關的。第一個可能會緩存過濾器(單個過濾器),而其他過濾器會使用緩存的過濾器。 –

+0

如果您多次運行**相同的**查詢(不是過濾器查詢),您是否獲得相同的3-4秒響應時間? –

+0

我比較大約10個後續電話的平均響應時間 –

回答

1

filter元素實際上是another name for post_filter element。不知何故,it was supposed to be removed (the filter) in ES 1.1但它滑過並存在於2.x版本中。

雖然它在ES 5中完全刪除。

因此,您的第一個查詢不是「過濾器」查詢。這是一個查詢,其結果將在聚合中使用(如果適用),然後對結果應用post_filter/filter。所以你基本上有兩個步驟的過程中有:https://www.elastic.co/guide/en/elasticsearch/reference/1.5/search-request-post-filter.html

更多關於它的性能here

雖然我們已經取得的標籤過濾器的緩存能力,我們可能增加顯著得分的成本。當您需要未經過濾的聚合時,過濾條件非常有用,但是要命令進行過濾。如果您沒有構面或聚合,則不應使用post_filter(或其棄用的頂級同義詞過濾器)。

一個適當的篩選查詢如下:

{ 
    "query": { 
    "filtered": { 
     "query": { 
     "bool": { 
      "should": [], 
      "must": [ 
      { 
       "match_all": {} 
      } 
      ] 
     } 
     }, 
     "filter": { 
     "bool": { 
      "must": [ 
      { 
       "term": { 
       "serviceId": "39cd0b95-efc3-4eee-93d1-93e6f5837d6b" 
       } 
      }, 
      { 
       "term": { 
       "subscriptionId": "3eb5021e-2f1d-4292-9fd5-95788ebfafa0" 
       } 
      }, 
      { 
       "term": { 
       "subscriptionType": 0 
       } 
      }, 
      { 
       "terms": { 
       "entityType": [ 
        "4" 
       ] 
       } 
      } 
      ] 
     } 
     } 
    } 
    } 
} 
-1

過濾更快。您的問題是,您在過濾器案例中包含match_all查詢。這匹配全部 20億的文件。然後必須對篩選器進行設置操作以剔除該設置。您的篩選器測試中省略了query部分,您會發現結果要快得多。

+0

我也這麼認爲,但是當我省略查詢時它仍然具有相同的性能 –

+0

這真的很奇怪。甚至完全忽略了過濾器的查詢部分?過濾器是一個沒有得分的查詢,因此它必須更快。它也被緩存。 – Haney

相關問題