elasticsearch搜索<六>

1.空搜索

　　格式：GET /_search --返回集群索引中的所有文档

{
   "took": 122,
   "timed_out": false,
   "_shards": {
      "total": 10,
      "successful": 10,
      "failed": 0
   },
   "hits": {
      "total": 6,
      "max_score": 1,
      "hits": [
         {
            "_index": "website",
            "_type": "blog",
            "_id": "123",
            "_score": 1,
            "_source": {
               "title": "My first blog entry",
               "text": "Just trying this out...",
               "date": "2014/01/01"
            }
         },
         {
            "_index": "twitter",
            "_type": "tweet",
            "_id": "AVPPjd4yzpW3aISqWsE3",
            "_score": 1,
            "_source": {
               "catIds": [
                  1699757992,
                  700619805,
                  1020589950,
                  1438781534,
                  1380879409
               ],
               "desc": "中文e36f8983-3feb-428b-ab50-909265d8f273",
               "host": "10.0.0.1",
               "id": 1838426079906181600,
               "subId": 424706847,
               "systemName": "oa"
            }
         },
         {
            "_index": "twitter",
            "_type": "tweet",
            "_id": "AVPPizRozpW3aISqWsE2",
            "_score": 1,
            "_source": {
               "catIds": [
                  635362879,
                  301982142,
                  1107991748,
                  493667395,
                  961438391
               ],
               "desc": "中文2db4bb45-3fee-4222-af69-f434bc8f50c3",
               "host": "10.0.0.1",
               "id": 7629139951060159000,
               "subId": 748720365,
               "systemName": "oa"
            }
         },
         {
            "_index": "twitter",
            "_type": "tweet",
            "_id": "1",
            "_score": 1,
            "_source": {
               "catIds": [
                  736859617,
                  590506844,
                  346375851,
                  631586821,
                  1410677813
               ],
               "desc": "中文c5d04210-22bf-424f-b8e6-4d2fccbe0949",
               "host": "10.0.0.1",
               "id": 1270697100843934500,
               "subId": 1597165534,
               "systemName": "oa"
            }
         },
         {
            "_index": "website",
            "_type": "blog",
            "_id": "124",
            "_score": 1,
            "_source": {
               "title": "My first blog entry",
               "text": "Just trying this out...",
               "date": "2014/01/02"
            }
         },
         {
            "_index": "twitter",
            "_type": "tweet",
            "_id": "AVPPismjzpW3aISqWsE1",
            "_score": 1,
            "_source": {
               "catIds": [
                  166212596,
                  718863022,
                  2049461651,
                  937747198,
                  1707921613
               ],
               "desc": "中文521ef93d-72aa-48d3-bd42-9a0d051962e2",
               "host": "10.0.0.1",
               "id": 5058007303376531000,
               "subId": 1473518256,
               "systemName": "oa"
            }
         }
      ]
   }
}

响应内容

hits

响应中最重要的部分是hits，它包含了total字段来表示匹配到的文档总数，hits数组还包含了匹配到的前10条数据。
hits数组中的每个结果都包含_index、_type和文档的_id字段，被加入到_source字段中这意味着在搜索结果中我们将可以直接使用全部文档。这不像其他搜索引擎只返回文档ID，需要你单独去获取文档。
每个节点都有一个_score字段，这是相关性得分(relevance score)，它衡量了文档与查询的匹配程度。默认的，返回的结果中关联性最大的文档排在首位；这意味着，它是按照_score降序排列的。这种情况下，我们没有指定任何查询，所以所有文档的相关性是一样的，因此所有结果的_score都是取得一个中间值1
max_score指的是所有文档匹配查询中_score的最大值。
took

took告诉我们整个搜索请求花费的毫秒数。
shards

_shards节点告诉我们参与查询的分片数（total字段），有多少是成功的（successful字段），有多少的是失败的（failed字段）。通常我们不希望分片失败，不过这个有可能发生。如果我们遭受一些重大的故障导致主分片和复制分片都故障，那这个分片的数据将无法响应给搜索请求。这种情况下，Elasticsearch将报告分片failed，但仍将继续返回剩余分片上的结果。
timeout

time_out值告诉我们查询超时与否。一般的，搜索请求不会超时。如果响应速度比完整的结果更重要，你可以定义timeout参数为10或者10ms（10毫秒），或者1s（1秒）
GET /_search?timeout=10ms
Elasticsearch将返回在请求超时前收集到的结果。
超时不是一个断路器（circuit breaker）（译者注：关于断路器的理解请看警告）。
警告

需要注意的是timeout不会停止执行查询，它仅仅告诉你目前顺利返回结果的节点然后关闭连接。在后台，其他分片可能依旧执行查询，尽管结果已经被发送。
使用超时是因为对于你的业务需求（译者注：SLA，Service-Level Agreement服务等级协议，在此我翻译为业务需求）来说非常重要，而不是因为你想中断执行长时间运行的查询。

解释

2.搜索：

`/_search`

在所有索引的所有类型中搜索

`/gb/_search`

在索引gb的所有类型中搜索

`/gb,us/_search`

在索引gb和us的所有类型中搜索

`/g,u/_search`

在以g或u开头的索引的所有类型中搜索

注意：只有index可以*号匹配，type不可以

`/gb/user/_search`

在索引gb的类型user中搜索

`/gb,us/user,tweet/_search`

在索引gb和us的类型为user和tweet中搜索

`/_all/user,tweet/_search`

在所有索引的user和tweet中搜索 search types user and tweet in all indices

当你搜索包含单一索引时，Elasticsearch转发搜索请求到这个索引的主分片或每个分片的复制分片上，然后聚集每个分片的结果。搜索包含多个索引也是同样的方式——只不过或有更多的分片被关联。

重要

搜索一个索引有5个主分片和5个索引各有一个分片事实上是一样的。

3.分页

《空搜索》一节告诉我们在集群中有14个文档匹配我们的（空）搜索语句。但是只有10个文档在hits数组中。我们如何看到其他文档？

和SQL使用LIMIT关键字返回只有一页的结果一样，Elasticsearch接受from和size参数：

size: 结果数，默认10

from: 跳过开始的结果数，默认0

如果你想每页显示5个结果，页码从1到3，那请求如下：

GET /_search?size=5
GET /_search?size=5&from=5
GET /_search?size=5&from=10

应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。但是记住一个搜索请求常常涉及多个分片。每个分片生成自己排好序的结果，它们接着需要集中起来排序以确保整体排序正确。

在集群系统中深度分页

为了理解为什么深度分页是有问题的，让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页（结果1到10）时，每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node)，它再排序这所有的50个结果以选出顶端的10个结果。

现在假设我们请求第1000页——结果10001到10010。工作方式都相同，不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个！

你可以看到在分布式系统中，排序结果的花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。

4.简易搜索

　　这个语句查询所有类型为tweet并在tweet字段中包含elasticsearch字符的文档：

　　GET /_all/tweet/_search?q=tweet:elasticsearch

　　格式：GET /{index}/{type}/{id}/_search?q=字段名：字段value

　多个字段查询：

　　例子：GET /_all/tweet/_search?q=subId:424706847+systemName:oa

　　注意：上边的这个例子是subId=424706847的结果加上systemName=oa的结果

　　"+"前缀表示语句匹配条件必须被满足。类似的"-"前缀表示条件必须不被满足。所有条件如果没有+或-表示是可选的——匹配越多，相关的文档就越多。

但是百分比编码(percent encoding)（译者注：就是url编码）需要将查询字符串参数变得更加神秘：

　　GET /_search?q=%2Bname%3Ajohn+%2Btweet%3Amary
　　格式：GET /_search?q=%2B字段名+%3A字段值。。。

`_all`字段

返回包含"mary"字符的所有文档的简单搜索：

GET /_search?q=mary

在前一个例子中，我们搜索tweet或name字段中包含某个字符的结果。然而，这个语句返回的结果在三个不同的字段中包含"mary"：

用户的名字是“Mary”
“Mary”发的六个推文
针对“@mary”的一个推文

Elasticsearch是如何设法找到三个不同字段的结果的？

当你索引一个文档，Elasticsearch把所有字符串字段值连接起来放在一个大字符串中，它被索引为一个特殊的字段_all。例如，当索引这个文档：

{
    "tweet":    "However did I manage before Elasticsearch?",
    "date":     "2014-09-14",
    "name":     "Mary Jones",
    "user_id":  1
}

这好比我们增加了一个叫做_all的额外字段值：

"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"

查询字符串在其他字段被定以前使用_all字段搜索。

TIP

_all字段对于开始一个新应用时是一个有用的特性。之后，如果你定义字段来代替_all字段，你的搜索结果将更加可控。当_all字段不再使用，你可以停用它，这个会在《全字段》章节阐述。

更复杂的语句

下一个搜索推特的语句：

_all field

name字段包含"mary"或"john"
date晚于2014-09-10
_all字段包含"aggregations"或"geo"

+name:(mary john) +date:>2014-09-10 +(aggregations geo)

编码后的查询字符串变得不太容易阅读：

?q=%2Bname%3A(mary+john)+%2Bdate%3A%3E2014-09-10+%2B(aggregations+geo)

就像你上面看到的例子，简单(lite)查询字符串搜索惊人的强大。它的查询语法，会在《查询字符串语法》章节阐述。参考文档允许我们简洁明快的表示复杂的查询。这对于命令行下一次性查询或者开发模式下非常有用。

然而，你可以看到简洁带来了隐晦和调试困难。而且它很脆弱——查询字符串中一个细小的语法错误，像-、:、/或"错位就会导致返回错误而不是结果。

最后，查询字符串搜索允许任意用户在索引中任何一个字段上运行潜在的慢查询语句，可能暴露私有信息甚至使你的集群瘫痪。

TIP

因为这些原因，我们不建议直接暴露查询字符串搜索给用户，除非这些用户对于你的数据和集群可信。

取而代之的，生产环境我们一般依赖全功能的请求体搜索API，它能完成前面所有的事情，甚至更多。在了解它们之前，我们首先需要看看数据是如何在Elasticsearch中被索引的。

posted @ 2016-04-05 17:17 刘尊礼阅读(262) 评论(0) 收藏举报

刷新页面返回顶部

elasticsearch搜索<六>

/_search

/gb/_search

/gb,us/_search

/g*,u*/_search

/gb/user/_search

/gb,us/user,tweet/_search

/_all/user,tweet/_search

重要

在集群系统中深度分页

_all字段

TIP