#### 跨字段實體搜索(Cross-fields Entity Search) 現在讓我們看看一個常見的模式：跨字段實體搜索。類似person，product或者address這樣的實體，它們的信息會分散到多個字段中。我們或許有一個person實體被索引如下： ```Javascript { "firstname": "Peter", "lastname": "Smith" } ``` 而address實體則是像下面這樣： ```Javascript { "street": "5 Poland Street", "city": "London", "country": "United Kingdom", "postcode": "W1V 3DG" } ``` 這個例子也許很像在[多查詢字符串](../110_Multi_Field_Search/05_Multiple_query_strings.md)中描述的，但是有一個顯著的區別。在多查詢字符串中，我們對每個字段都使用了不同的查詢字符串。在這個例子中，我們希望使用一個查詢字符串來搜索多個字段。 用戶也許會搜索名為"Peter Smith"的人，或者名為"Poland Street W1V"的地址。每個查詢的單詞都出現在不同的字段中，因此使用dis_max/best_fields查詢來搜索單個最佳匹配字段顯然是不對的。 #### 一個簡單的方法 實際上，我們想要依次查詢每個字段然后將每個匹配字段的分值進行累加，這聽起來很像bool查詢能夠勝任的工作： ```Javascript { "query": { "bool": { "should": [ { "match": { "street": "Poland Street W1V" }}, { "match": { "city": "Poland Street W1V" }}, { "match": { "country": "Poland Street W1V" }}, { "match": { "postcode": "Poland Street W1V" }} ] } } } ``` 對每個字段重復查詢字符串很快就會顯得冗長。我們可以使用multi_match查詢進行替代，然后將type設置為most_fields來讓它將所有匹配字段的分值合并： ```Javascript { "query": { "multi_match": { "query": "Poland Street W1V", "type": "most_fields", "fields": [ "street", "city", "country", "postcode" ] } } } ``` #### 使用most_fields存在的問題 使用most_fields方法執行實體查詢有一些不那么明顯的問題： * 它被設計用來找到匹配任意單詞的多數字段，而不是找到跨越所有字段的最匹配的單詞。 * 它不能使用operator或者minimum_should_match參數來減少低相關度結果帶來的長尾效應。 * 每個字段的詞條頻度是不同的，會互相干擾最終得到較差的排序結果。 <!-- === Cross-fields Entity Search Now we come to a common pattern: cross-fields entity search. ((("cross-fields entity search")))((("multifield search", "cross-fields entity search"))) With entities like `person`, `product`, or `address`, the identifying information is spread across several fields. We may have a `person` indexed as follows: [source,js] -------------------------------------------------- { "firstname": "Peter", "lastname": "Smith" } -------------------------------------------------- Or an address like this: [source,js] -------------------------------------------------- { "street": "5 Poland Street", "city": "London", "country": "United Kingdom", "postcode": "W1V 3DG" } -------------------------------------------------- This sounds a lot like the example we described in <<multi-query-strings>>, but there is a big difference between these two scenarios. In <<multi-query-strings>>, we used a separate query string for each field. In this scenario, we want to search across multiple fields with a _single_ query string. Our user might search for the person ``Peter Smith'' or for the address ``Poland Street W1V.'' Each of those words appears in a different field, so using a `dis_max` / `best_fields` query to find the _single_ best-matching field is clearly the wrong approach. ==== A Naive Approach Really, we want to query each field in turn and add up the scores of every field that matches, which sounds like a job for the `bool` query: [source,js] -------------------------------------------------- { "query": { "bool": { "should": [ { "match": { "street": "Poland Street W1V" }}, { "match": { "city": "Poland Street W1V" }}, { "match": { "country": "Poland Street W1V" }}, { "match": { "postcode": "Poland Street W1V" }} ] } } } -------------------------------------------------- Repeating the query string for every field soon becomes tedious. We can use the `multi_match` query instead, ((("most fields queries", "problems for entity search")))((("multi_match queries", "most_fields type")))and set the `type` to `most_fields` to tell it to combine the scores of all matching fields: [source,js] -------------------------------------------------- { "query": { "multi_match": { "query": "Poland Street W1V", "type": "most_fields", "fields": [ "street", "city", "country", "postcode" ] } } } -------------------------------------------------- ==== Problems with the most_fields Approach The `most_fields` approach to entity search has some problems that are not immediately obvious: * It is designed to find the most fields matching _any_ words, rather than to find the most matching words _across all fields_. * It can't use the `operator` or `minimum_should_match` parameters to reduce the long tail of less-relevant results. * Term frequencies are different in each field and could interfere with each other to produce badly ordered results. -->