ElasticSearch - 结构化查询 2 - 《数据存储》

请求体查询
结构化查询
- 查询子句
查询与过滤
- 性能差异
- 什么情况下使用
过滤查询
查询与过滤条件的合并
验证查询
- 理解错误信息
- 理解查询语句
查询结果解析

请求体查询

GET /_search
{}
分页
GET /_search
{
    "from": 30,
    "size": 10
}
查询匹配多个index
GET /index_2014*/_search
{}
因为Get请求携带请求体数据，不被广泛接受，所以上面的用Post请求可ok。

结构化查询

使用结构化查询，你需要传递query参数：

GET /_search
{
    "query": YOUR_QUERY_HERE
}

空查询 - {} - 在功能上等同于使用match_all查询子句，正如其名字一样，匹配所有的文档：

GET /_search
{
    "query": {
        "match_all": {}
    }
}

查询子句

一个查询子句一般使用这种结构：

{
    QUERY_NAME: {
        ARGUMENT: VALUE,
        ARGUMENT: VALUE,...
    }
}

或指向一个指定的字段：

{
    QUERY_NAME: {
        FIELD_NAME: {
            ARGUMENT: VALUE,
            ARGUMENT: VALUE,...
        }
    }
}

例如，你可以使用match查询子句用来找寻在tweet字段中找寻包含elasticsearch的成员：

{
    "match": {
        "tweet": "elasticsearch"
    }
}

完整的查询请求会是这样：

GET /_search
{
    "query": {
        "match": {
            "tweet": "elasticsearch"
        }
    }
}

查询与过滤

可以使用两种结构化语句：结构化查询（Query DSL）和结构化过滤（Filter DSL）。查询与过滤语句非常相似，但是它们由于使用目的不同而稍有差异。
一条过滤语句会询问每个文档的字段值是否包含着特定值：

created 的日期范围是否在 2013 到 2014 ?
status 字段中是否包含单词 “published” ?
lat_lon 字段中的地理位置与目标点相距是否不超过10km ?

一条查询语句与过滤语句相似，但问法不同：
查询语句会询问每个文档的字段值与特定值的匹配程度如何？
查询语句的典型用法是为了找到文档：

查找与 full text search 这个词语最佳匹配的文档
查找包含单词 run ，但是也包含runs, running, jog 或 sprint的文档
同时包含着 quick, brown 和 fox —- 单词间离得越近，该文档的相关性越高
标识着 lucene, search 或 java —- 标识词越多，该文档的相关性越高

一条查询语句会计算每个文档与查询语句的相关性，会给出一个相关性评分 _score，并且按照相关性对匹配到的文档进行排序。这种评分方式非常适用于一个没有完全配置结果的全文本搜索。

性能差异

使用过滤语句得到的结果集 — 一个简单的文档列表，快速匹配运算并存入内存是十分方便的，每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
查询语句不仅要查找相匹配的文档，还需要计算每个文档的相关性，所以一般来说查询语句要比过滤语句更耗时，并且查询结果也不可缓存。
幸亏有了倒排索引，一个只匹配少量文档的简单查询语句在百万级文档中的查询效率会与一条经过缓存的过滤语句旗鼓相当，甚至略占上风。但是一般情况下，一条经过缓存的过滤查询要远胜一条查询语句的执行效率。
过滤语句的目的就是缩小匹配的文档结果集，所以需要仔细检查过滤条件。

什么情况下使用

原则上来说，使用查询语句做全文本搜索或其他需要进行相关性评分的时候，剩下的全部用过滤语句。

过滤查询

term过滤

term主要用于精确匹配哪些值，比如数字，日期，布尔值或 not_analyzed的字符串(未经分析的文本数据类型)：

{ "term": { "age":    26           }}
    { "term": { "date":   "2014-09-01" }}
    { "term": { "public": true         }}
    { "term": { "tag":    "full_text"  }}

terms 过滤

terms 跟 term 有点类似，但 terms 允许指定多个匹配条件。如果某个字段指定了多个值，那么文档需要一起去做匹配：

{
    "terms": {
        "tag": [ "search", "full_text", "nosql" ]
        }
}

range 过滤

range过滤允许我们按照指定范围查找一批数据：

{
    "range": {
        "age": {
            "gte":  20,
            "lt":   30
        }
    }
}

范围操作符包含：

gt :: 大于
gte:: 大于等于
lt :: 小于
lte:: 小于等于

exists 和 missing 过滤
exists 和 missing 过滤可以用于查找文档中是否包含指定字段或没有某个字段，类似于SQL语句中的IS_NULL条件
```
{
  "exists":   {
      "field":    "title"
  }
}
```
这两个过滤只是针对已经查出一批数据来，但是想区分出某个字段是否存在的时候使用。

bool 过滤
bool 过滤可以用来合并多个过滤条件查询结果的布尔逻辑，它包含一下操作符：
must :: 多个查询条件的完全匹配,相当于 and。
must_not :: 多个查询条件的相反匹配，相当于 not。
should :: 至少有一个查询条件匹配, 相当于 or。

这些参数可以分别继承一个过滤条件或者一个过滤条件的数组：

{
    "bool": {
        "must":     { "term": { "folder": "inbox" }},
        "must_not": { "term": { "tag":    "spam"  }},
        "should": [
                    { "term": { "starred": true   }},
                    { "term": { "unread":  true   }}
        ]
    }
}

match_all 查询

使用match_all 可以查询到所有文档，是没有查询条件下的默认语句。

{
    "match_all": {}
}

此查询常用于合并过滤条件。比如说你需要检索所有的邮箱,所有的文档相关性都是相同的，所以得到的_score为1

match 查询

match查询是一个标准查询，不管你需要全文本查询还是精确查询基本上都要用到它。
如果你使用 match 查询一个全文本字段，它会在真正查询之前用分析器先分析match一下查询字符：

{
    "match": {
        "tweet": "About Search"
    }
}

如果用match下指定了一个确切值，在遇到数字，日期，布尔值或者not_analyzed 的字符串时，它将为你搜索你给定的值：

{ "match": { "age":    26           }}
{ "match": { "date":   "2014-09-01" }}
{ "match": { "public": true         }}
{ "match": { "tag":    "full_text"  }}

提示：做精确匹配搜索时，你最好用过滤语句，因为过滤语句可以缓存数据。
match查询不可以用类似”+usid:2 +tweet:search”这样的语句。它只能就指定某个确切字段某个确切的值进行搜索，而你要做的就是为它指定正确的字段名以避免语法错误。

multi_match 查询

multi_match查询允许你做match查询的基础上同时搜索多个字段：

{
    "multi_match": {
        "query":    "full text search",
        "fields":   [ "title", "body" ]
    }
}

bool 查询

bool 查询与 bool 过滤相似，用于合并多个查询子句。不同的是，bool 过滤可以直接给出是否匹配成功，而bool 查询要计算每一个查询子句的 _score （相关性分值）。

must:: 查询指定文档一定要被包含。
must_not:: 查询指定文档一定不要被包含。
should:: 查询指定文档，有则可以为文档相关性加分。

以下查询将会找到 title 字段中包含 “how to make millions”，并且 “tag” 字段没有被标为 spam。如果有标识为 “starred” 或者发布日期为2014年之前，那么这些匹配的文档将比同类网站等级高：

{
    "bool": {
        "must":     { "match": { "title": "how to make millions" }},
        "must_not": { "match": { "tag":   "spam" }},
        "should": [
            { "match": { "tag": "starred" }},
            { "range": { "date": { "gte": "2014-01-01" }}}
        ]
    }
}

提示：如果bool查询下没有must子句，那至少应该有一个should子句。但是如果有must子句，那么没有should子句也可以进行查询。

查询与过滤条件的合并

查询语句和过滤语句可以放在各自的上下文中。在 ElasticSearch API 中我们会看到许多带有 query 或 filter 的语句。这些语句既可以包含单条 query 语句，也可以包含一条 filter 子句。换句话说，这些语句需要首先创建一个query或filter的上下文关系。
复合查询语句可以加入其他查询子句，复合过滤语句也可以加入其他过滤子句。通常情况下，一条查询语句需要过滤语句的辅助，全文本搜索除外。
所以说，查询语句可以包含过滤子句，反之亦然。以便于我们切换 query 或 filter 的上下文。这就要求我们在读懂需求的同时构造正确有效的语句。

带过滤的查询语句

过滤一条查询语句

比如说我们有这样一条查询语句:

{
    "match": {
        "email": "business opportunity"
    }
}

然后我们想要让这条语句加入 term 过滤，在收信箱中匹配邮件：

{
    "term": {
        "folder": "inbox"
    }
}

search API中只能包含 query 语句，所以我们需要用 filtered 来同时包含 “query” 和 “filter” 子句：

{
    "filtered": {
        "query":  { "match": { "email": "business opportunity" }},
        "filter": { "term":  { "folder": "inbox" }}
    }
}

我们在外层再加入 query 的上下文关系：

GET /_search
{
    "query": {
        "filtered": {
            "query":  { "match": { "email": "business opportunity" }},
            "filter": { "term": { "folder": "inbox" }}
        }
    }
}

单条过滤语句

在 query 上下文中，如果你只需要一条过滤语句，比如在匹配全部邮件的时候，你可以省略 query 子句：

GET /_search
{
    "query": {
        "filtered": {
            "filter":   { "term": { "folder": "inbox" }}
        }
    }
}

如果一条查询语句没有指定查询范围，那么它默认使用 match_all 查询，所以上面语句的完整形式如下：

GET /_search
{
    "query": {
        "filtered": {
            "query":    { "match_all": {}},
            "filter":   { "term": { "folder": "inbox" }}
        }
    }
}

查询语句中的过滤

有时候，你需要在 filter 的上下文中使用一个 query 子句。下面的语句就是一条带有查询功能的过滤语句，这条语句可以过滤掉看起来像垃圾邮件的文档：

GET /_search
{
    "query": {
        "filtered": {
            "filter":   {
                "bool": {
                    "must":     { "term":  { "folder": "inbox" }},
                    "must_not": {
                        "query": { <1>
                            "match": { "email": "urgent business proposal" }
                        }
                    }
                }
            }
        }
    }
}

<1> 过滤语句中可以使用query查询的方式代替 bool 过滤子句。
提示：我们很少用到的过滤语句中包含查询，保留这种用法只是为了语法的完整性。只有在过滤中用到全文本匹配的时候才会使用这种结构。

验证查询

查询语句可以变得非常复杂，特别是与不同的分析器和字段映射相结合后，就会有些难度。
validate API 可以验证一条查询语句是否合法。

GET /gb/_validate/query
{
   "query": {
      "tweet" : {
         "match" : "really powerful"
      }
   }
}

以上请求的返回值告诉我们这条语句是非法的：

{
  "valid" :         false
}

理解错误信息

想知道语句非法的具体错误信息，需要加上 explain 参数：

GET /gb/_validate/query?explain <1>
{
   "query": {
      "tweet" : {
         "match" : "really powerful"
      }
   }
}

<1> explain 参数可以提供语句错误的更多详情。
很显然，我们把 query 语句的 match 与字段名位置弄反了：

{
  "valid" : false,
  "error" : "org.elasticsearch.common.ParsingException: no [query] registered for [tweet]"
}

理解查询语句

如果是合法语句的话，使用 explain 参数可以返回一个带有查询语句的可阅读描述，可以帮助了解查询语句在ES中是如何执行的：

GET /gb/_validate/query?explain
{
   "query": {
      "match" : {
         "tweet": "really powerful"
      }
   }
}

explanation 会为每一个索引返回一段描述，因为每个索引会有不同的映射关系和分析器：

{
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "failed" : 0
  },
  "valid" : true,
  "explanations" : [
    {
      "index" : "gb",
      "valid" : true,
      "explanation" : "tweet:really tweet:powerful"
    }
  ]
}

从返回的 explanation 你会看到 match 是如何为查询字符串 “really powerful” 进行查询的，首先，它被拆分成两个独立的词分别在 tweet 字段中进行查询。
而且，在索引us中这两个词为”really”和”powerful”，在索引gb中被拆分成”really” 和 “power”。这是因为我们在索引gb中使用了english分析器。

参考链接: https://www.cnblogs.com/hanks/p/12046733.html

查询结果解析

{ 2 “took” : 48, 3 “timed_out” : false, 4 “_shards” : { 5 “total” : 1, 6 “successful” : 1, 7 “skipped” : 0, 8 “failed” : 0 9 }, 10 “hits” : { 11 “total” : { 12 “value” : 1000, 13 “relation” : “eq” 14 }, 15 “max_score” : null, 16 “hits” : [ 17 { 18 “_index” : “bank”, 19 “_type” : “_doc”, 20 “_id” : “0”, 21 “_score” : null, 22 “_source” : { 23 “account_number” : 0, 24 “balance” : 16623, 25 “firstname” : “Bradshaw”, 26 “lastname” : “Mckenzie”, 27 “age” : 29, 28 “gender” : “F”, 29 “address” : “244 Columbus Place”, 30 “employer” : “Euron”, 31 “email” : “bradshawmckenzie@euron.com”, 32 “city” : “Hobucken”, 33 “state” : “CO” 34 }, 35 “sort” : [ 36 0 37 ] 38 },

我们顺便简单了解下返回结果中几个主要字段的含义：
第2行，took表示Elasticsearch执行搜索所用的时间，单位是毫秒。
第3行，timed_out 用来指示搜索是否超时。
第4行，_shards 指示搜索了多少分片，以及搜索成功和失败的分片的计数。
第10行，hits 用来实际搜索结果集。
第11行，hits.total 是包含与搜索条件匹配的文档总数信息的对象。
第12行，hits.total.value 表示总命中计数的值（必须在hits.total.relation上下文中解释）。
第13行，确切来说默认情况下，hits.total.value是不确切的命中计数，在这种情况下，当hits.total.relation的值是eq时，hits.total.value的值是准确计数。当hits.total.relation的值是gte时，hits.total.value的值是不准确的。
第16行，hits.hits 是存储搜索结果的实际数组（默认为前10个文档）。
第35行，hits.sort 表示结果排序键（如果请求中没有指定，则默认按分数排序）。

现在我们来重点关注11~14行，参数track_total_hits可以控制total值的准确性，可以设为false、true或正整数。当为false时，不再返回total计数，total始终为1；当为正整数时，表示精确的命中文档计数，例如为1000时，返回如下结构 :

“total” : { “value” : 1, “relation” : “gte” }

此时如果命中结果小于或等于1000时，value是精确的计数，relation是eq，如果命中的结果数大于了1000时，此时value等于1000，relation是gte，如果需要精确统计结果数，这个值要设置的很大或者设为true，这个参数的设基更多的出于性能考虑。具体工程应用中，我们可以首先检查relation的值，如果是eq，则表示value的值真实代表了命中的结果数，如果为gte表示value的值是不准确的。
那么track_total_hits这个参数到底如何设置才是最合理的呢？这要结合具体的业务需求和应用场景。可以遵循如下三个原则：

保持默认值：10000，不变，这足以满足一般的业务需求，就算是淘宝、京东这样的大型电商网站，一页展示40个结果，10000个结果可以展示250页，相信没有用户会看250页后的商品，大多数情况下用户基本上都是浏览前10也的商品。
如果需要精确知道命中的文档数量，此时应把track_total_hits设置为true,但用户需要清楚的明白，如果命中的文档数量很大，会影响查询性能，而且会消耗大量的内存，甚至存在内存异常的风险。
如果你确切知道不需要知道命中的结果数，则把track_total_hits设为false,这会提升查询性能。

结构化查询 2