<!--秀川譯--> ### 多重查詢字符串 在明確的字段中的詞查詢是最容易處理的多字段查詢。如果我們知道War and Peace是標題，Leo Tolstoy是作者，可以很容易的用match查詢表達每個條件，并且用布爾查詢組合起來： ``` GET /_search { "query": { "bool": { "should": [ { "match": { "title": "War and Peace" }}, { "match": { "author": "Leo Tolstoy" }} ] } } } ``` 布爾查詢采用"匹配越多越好(More-matches-is-better)"的方法，所以每個match子句的得分會被加起來變成最后的每個文檔的得分。匹配兩個子句的文檔的得分會比只匹配了一個文檔的得分高。 當然，沒有限制你只能使用match子句：布爾查詢可以包裝任何其他的查詢類型，包含其他的布爾查詢，我們可以添加一個子句來指定我們更喜歡看被哪個特殊的翻譯者翻譯的那版書： ```Javascript GET /_search { "query": { "bool": { "should": [ { "match": { "title": "War and Peace" }}, { "match": { "author": "Leo Tolstoy" }}, { "bool": { "should": [ { "match": { "translator": "Constance Garnett" }}, { "match": { "translator": "Louise Maude" }} ] }} ] } } } ``` 為什么我們把翻譯者的子句放在一個獨立的布爾查詢中？所有的匹配查詢都是should子句，所以為什么不把翻譯者的子句放在和title以及作者的同一級？ 答案就在如何計算得分中。布爾查詢執行每個匹配查詢，把他們的得分加在一起，然后乘以匹配子句的數量，并且除以子句的總數。每個同級的子句權重是相同的。在前面的查詢中，包含翻譯者的布爾查詢占用總得分的三分之一。如果我們把翻譯者的子句放在和標題與作者同級的目錄中，我們會把標題與作者的作用減少的四分之一。 ### 設置子句優先級 在先前的查詢中我們可能不需要使每個子句都占用三分之一的權重。我們可能對標題以及作者比翻譯者更感興趣。我們需要調整查詢來使得標題和作者的子句相關性更重要。 最簡單的方法是使用boost參數。為了提高標題和作者字段的權重，我們給boost參數提供一個比1高的值： ```Javascript GET /_search { "query": { "bool": { "should": [ { "match": { <1> "title": { "query": "War and Peace", "boost": 2 }}}, { "match": { <1> "author": { "query": "Leo Tolstoy", "boost": 2 }}}, { "bool": { <2> "should": [ { "match": { "translator": "Constance Garnett" }}, { "match": { "translator": "Louise Maude" }} ] }} ] } } } ``` <1> 標題和作者的boost值為2。 <2> 嵌套的布爾查詢的boost值為默認的1。 通過試錯(Trial and Error)的方式可以確定"最佳"的boost值：設置一個boost值，執行測試查詢，重復這個過程。一個合理boost值的范圍在1和10之間，也可能是15。比它更高的值的影響不會起到很大的作用，因為分值會[被規范化(Normalized)](https://www.elastic.co/guide/en/elasticsearch/guide/current/_boosting_query_clauses.html#boost-normalization)。 <!-- [[multi-query-strings]] === Multiple Query Strings The simplest multifield query to deal with is the ((("multifield search", "multiple query strings")))one where we can _map search terms to specific fields_. If we know that _War and Peace_ is the title, and Leo Tolstoy is the author, it is easy to write each of these conditions as a `match` clause ((("match clause, mapping search terms to specific fields")))((("bool query", "mapping search terms to specific fields in match clause")))and to combine them with a <<bool-query,`bool` query>>: [source,js] -------------------------------------------------- GET /_search { "query": { "bool": { "should": [ { "match": { "title": "War and Peace" }}, { "match": { "author": "Leo Tolstoy" }} ] } } } -------------------------------------------------- // SENSE: 110_Multi_Field_Search/05_Multiple_query_strings.json The `bool` query takes a _more-matches-is-better_ approach, so the score from each `match` clause will be added together to provide the final `_score` for each document. Documents that match both clauses will score higher than documents that match just one clause. Of course, you're not restricted to using just `match` clauses: the `bool` query can wrap any other query type, ((("bool query", "nested bool query in")))including other `bool` queries. We could add a clause to specify that we prefer to see versions of the book that have been translated by specific translators: [source,js] -------------------------------------------------- GET /_search { "query": { "bool": { "should": [ { "match": { "title": "War and Peace" }}, { "match": { "author": "Leo Tolstoy" }}, { "bool": { "should": [ { "match": { "translator": "Constance Garnett" }}, { "match": { "translator": "Louise Maude" }} ] }} ] } } } -------------------------------------------------- // SENSE: 110_Multi_Field_Search/05_Multiple_query_strings.json Why did we put the translator clauses inside a separate `bool` query? All four `match` queries are `should` clauses, so why didn't we just put the translator clauses at the same level as the title and author clauses? The answer lies in how the score is calculated.((("relevance scores", "calculation in bool queries"))) The `bool` query runs each `match` query, adds their scores together, then multiplies by the number of matching clauses, and divides by the total number of clauses. Each clause at the same level has the same weight. In the preceding query, the `bool` query containing the translator clauses counts for one-third of the total score. If we had put the translator clauses at the same level as title and author, they would have reduced the contribution of the title and author clauses to one-quarter each. [[prioritising-clauses]] ==== Prioritizing Clauses It is likely that an even one-third split between clauses is not what we need for the preceding query. ((("multifield search", "multiple query strings", "prioritizing query clauses")))((("bool query", "prioritizing clauses"))) Probably we're more interested in the title and author clauses then we are in the translator clauses. We need to tune the query to make the title and author clauses relatively more important. The simplest weapon in our tuning arsenal is the `boost` parameter. To increase the weight of the `title` and `author` fields, give ((("boost parameter", "using to prioritize query clauses")))((("weight", "using boost parameter to prioritize query clauses")))them a `boost` value higher than `1`: [source,js] -------------------------------------------------- GET /_search { "query": { "bool": { "should": [ { "match": { <1> "title": { "query": "War and Peace", "boost": 2 }}}, { "match": { <1> "author": { "query": "Leo Tolstoy", "boost": 2 }}}, { "bool": { <2> "should": [ { "match": { "translator": "Constance Garnett" }}, { "match": { "translator": "Louise Maude" }} ] }} ] } } } -------------------------------------------------- // SENSE: 110_Multi_Field_Search/05_Multiple_query_strings.json <1> The `title` and `author` clauses have a `boost` value of `2`. <2> The nested `bool` clause has the default `boost` of `1`. The ``best'' value for the `boost` parameter is most easily determined by trial and error: set a `boost` value, run test queries, repeat. A reasonable range for `boost` lies between `1` and `10`, maybe `15`. Boosts higher than that have little more impact because scores are <<boost-normalization,normalized>>. -->