[Elasticsearch] 多欄位搜尋 (五),elasticsearch欄位

來源:互聯網
上載者:User

[Elasticsearch] 多欄位搜尋 (五),elasticsearch欄位
以欄位為中心的查詢(Field-centric Queries)

上述提到的三個問題都來源於most_fields是以欄位為中心(Field-centric),而不是以詞條為中心(Term-centric):它會查詢最多匹配的欄位(Most matching fields),而我們真正感興趣的最匹配的詞條(Most matching terms)。

NOTE

best_fields同樣是以欄位為中心的,因此它也存在相似的問題。

首先我們來看看為什麼存在這些問題,以及如何解決它們。

問題1:在多個欄位中匹配相同的單詞

考慮一下most_fields查詢是如何執行的:ES會為每個欄位產生一個match查詢,讓後將它們包含在一個bool查詢中。

我們可以將查詢傳入到validate-query API中進行查看:

GET /_validate/query?explain{  "query": {    "multi_match": {      "query":   "Poland Street W1V",      "type":    "most_fields",      "fields":  [ "street", "city", "country", "postcode" ]    }  }}

它會產生下面的解釋(explaination):

(street:poland street:street street:w1v) (city:poland city:street city:w1v) (country:poland country:street country:w1v) (postcode:poland postcode:street postcode:w1v)

你可以發現能夠在兩個欄位中匹配poland的文檔會比在一個欄位中匹配了poland和street的文檔的分值要高。

問題2:減少長尾

在精度控制(Controlling Precision)一節中,我們討論了如何使用and操作符和minimum_should_match參數來減少相關度低的文檔數量:

{    "query": {        "multi_match": {            "query":       "Poland Street W1V",            "type":        "most_fields",            "operator":    "and",             "fields":      [ "street", "city", "country", "postcode" ]        }    }}

但是,使用best_fields或者most_fields,這些參數會被傳遞到產生的match查詢中。該查詢的解釋如下(譯註:通過validate-query API):

(+street:poland +street:street +street:w1v) (+city:poland +city:street +city:w1v) (+country:poland +country:street +country:w1v) (+postcode:poland +postcode:street +postcode:w1v)

換言之,使用and操作符時,所有的單詞都需要出現在相同的欄位中,這顯然是錯的!這樣做可能不會有任何匹配的文檔。

問題3:詞條頻度

在什麼是相關度(What is Relevance)一節中,我們解釋了預設用來計算每個詞條的相關度分值的相似度演算法TF/IDF:

詞條頻度(Term Frequency)

在一份文檔中,一個詞條在一個欄位中出現的越頻繁,文檔的相關度就越高。

倒排文檔頻度(Inverse Document Frequency)

一個詞條在索引的所有文檔的欄位中出現的越頻繁,詞條的相關度就越低。

當通過多欄位進行搜尋時,TF/IDF會產生一些令人驚訝的結果。

考慮使用first_name和last_name欄位搜尋"Peter Smith"的例子。Peter是一個常見的名字,Smith是一個常見的姓氏 - 它們的IDF都較低。但是如果在索引中有另外一個名為Smith Williams的人呢?Smith作為名字是非常罕見的,因此它的IDF值會很高!

像下面這樣的一個簡單查詢會將Smith Williams放在Peter Smith前面(譯註:含有Smith Williams的文檔分值比含有Peter Smith的文檔分值高),儘管Peter Smith明顯是更好的匹配:

{    "query": {        "multi_match": {            "query":       "Peter Smith",            "type":        "most_fields",            "fields":      [ "*_name" ]        }    }}

smith在first_name欄位中的高IDF值會壓倒peter在first_name欄位和smith在last_name欄位中的兩個低IDF值。

解決方案

這個問題僅在我們處理多欄位時存在。如果我們將所有這些欄位合并到一個欄位中,該問題就不複存在了。我們可以向person文檔中添加一個full_name欄位來實現:

{    "first_name":  "Peter",    "last_name":   "Smith",    "full_name":   "Peter Smith"}

當我們只查詢full_name欄位時:

  • 擁有更多匹配單詞的文檔會勝過那些重複出現一個單詞的文檔。
  • minimum_should_match和operator參數能夠正常工作。
  • first_name和last_name的倒排文檔頻度會被合并,因此smith無論是first_name還是last_name都不再重要。

儘管這種方法能工作,可是我們並不想儲存冗餘資料。因此,ES為我們提供了兩個解決方案 - 一個在索引期間,一個在搜尋期間。下一節對它們進行討論。

相關文章

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

Tags Index: