原文链接：http://blog.csdn.net/dm_vincent/article/details/41863015
以字段为中心的查询(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为我们提供了两个解决方案 - 一个在索引期间，一个在搜索期间。
自定义_all字段
在元数据：_all字段中，我们解释了特殊的_all字段会将其它所有字段中的值作为一个大字符串进行索引。尽管将所有字段的值作为一个字段进行索引并不是非常灵活。如果有一个自定义的_all字段用来索引人名，另外一个自定义的_all字段用来索引地址就更好了。
ES通过字段映射中的copy_to参数向我们提供了这一功能：
PUT /my_index
{
"mappings": {
"person": {
"properties": {
"first_name": {
"type": "string",
"copy_to": "full_name"
},
"last_name": {
"type": "string",
"copy_to": "full_name"
},
"full_name": {
"type": "string"
}
}
}
}
}
现在first_name和last_name字段中的值会被拷贝到full_name字段中。
有了这个映射，我们可以通过first_name字段查询名字，last_name字段查询姓氏，或者full_name字段查询姓氏和名字。
NOTE
first_name和last_name字段的映射和full_name字段的索引方式的无关。full_name字段会从其它两个字段中拷贝字符串的值，然后仅根据full_name字段自身的映射进行索引。
跨域查询(Cross-fields Queries)
如果你在索引文档前就能够自定义_all字段的话，那么使用_all字段就是一个不错的方法。但是，ES同时也提供了一个搜索期间的解决方案：使用类型为cross_fields的multi_match查询。cross_fields类型采用了一种以词条为中心(Term-centric)的方法，这种方法和best_fields及most_fields采用的以字段为中心(Field-centric)的方法有很大的区别。它将所有的字段视为一个大的字段，然后在任一字段中搜索每个词条。
为了阐述以字段为中心和以词条为中心的查询的区别，看看以字段为中心的most_fields查询的解释(译注：通过validate-query API得到)：
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "most_fields",
"operator": "and",
"fields": [ "first_name", "last_name" ]
}
}
}
operator设为了and，表示所有的词条都需要出现。
对于一份匹配的文档，peter和smith两个词条都需要出现在相同的字段中，要么是first_name字段，要么是last_name字段：
(+first_name:peter +first_name:smith) (+last_name:peter +last_name:smith)
而以词条为中心的方法则使用了下面这种逻辑：
(+first_name:peter +first_name:smith) (+last_name:peter +last_name:smith)
换言之，词条peter必须出现在任一字段中，同时词条smith也必须出现在任一字段中。
cross_fields类型首先会解析查询字符串来得到一个词条列表，然后在任一字段中搜索每个词条。仅这个区别就能够解决在以字段为中心的查询中提到的3个问题中的2个，只剩下倒排文档频度的不同这一问题。
幸运的是，cross_fields类型也解决了这个问题，从下面的validate-query请求中可以看到：
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "cross_fields",
"operator": "and",
"fields": [ "first_name", "last_name" ]
}
}
}
它通过混合(Blending)字段的倒排文档频度来解决词条频度的问题：
+blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name])
换言之，它会查找词条smith在first_name和last_name字段中的IDF值，然后使用两者中较小的作为两个字段最终的IDF值。因为smith是一个常见的姓氏，意味着它也会被当做一个常见的名字。
NOTE
为了让cross_fields查询类型能以最佳的方式工作，所有的字段都需要使用相同的解析器。使用了相同的解析器的字段会被组合在一起形成混合字段(Blended Fields)。
如果你包含了使用不同解析链(Analysis Chain)的字段，它们会以和best_fields相同的方被添加到查询中。比如，如果我们将title字段添加到之前的查询中(假设它使用了一个不同的解析器)，得到的解释如下所示：
(+title:peter +title:smith) ( +blended("peter", fields: [first_name, last_name]) +blended("smith", fields: [first_name, last_name]) )
当使用了minimum_should_match以及operator参数时，这一点尤为重要。
逐字段提升(Per-field Boosting)
使用cross_fields查询相比使用自定义_all字段的一个优点是你能够在查询期间对个别字段进行提升。
对于first_name和last_name这类拥有近似值的字段，也许提升是不必要的，但是如果你通过title和description字段来搜索书籍，那么你或许会给予title字段更多的权重。这可以通过前面介绍的caret(^)语法来完成：
GET /books/_search
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "cross_fields",
"fields": [ "title^2", "description" ]
}
}
}
能够对个别字段进行提升带来的优势应该和对多个字段执行查询伴随的代价进行权衡，因为如果使用自定义的_all字段，那么只需要要对一个字段进行查询。选择能够给你带来最大收益的方案。
精确值字段(Exact-value Fields)
在结束对于多字段查询的讨论之前的最后一个话题是作为not_analyzed类型的精确值字段。在multi_match查询中将not_analyzed字段混合到analyzed字段中是没有益处的。
原因可以通过validate-query进行简单地验证，假设我们将title字段设置为not_analyzed：
GET /_validate/query?explain
{
"query": {
"multi_match": {
"query": "peter smith",
"type": "cross_fields",
"fields": [ "title", "first_name", "last_name" ]
}
}
}
因为title字段时没有被解析的，它会以将整个查询字符串作为一个词条进行搜索！
title:peter smith ( blended("peter", fields: [first_name, last_name]) blended("smith", fields: [first_name, last_name]) )
很显然该词条在title字段的倒排索引中并不存在，因此永远不可能被找到。在multi_match查询中避免使用not_analyzed字段。