我们如果发出一个搜索请求的话,会拿到一堆搜索结果,这个搜索结果里的各种数据,都代表了什么含义
GET /_search { "took": 6, "timed_out": false, "_shards": { "total": 6, "successful": 6, "failed": 0 }, "hits": { "total": 10, "max_score": 1, "hits": [ { "_index": ".kibana", "_type": "config", "_id": "5.2.0", "_score": 1, "_source": { "buildNum": 14695 } } ] } }
具体解释如下:
字段 | 解释 |
---|---|
took | 整个搜索请求花费了多少毫秒。 |
hits.total | 本次搜索,返回了几条结果。 |
hits.max_score | 本次搜索的所有结果中,最大的相关度分数是多少,每一条 document 对于 search 的相关度,越相关,_score 分数越大,排位越靠前。 |
hits.hits | 默认查询前 10 条数据,完整数据,_score 降序排序。 |
shards | shards fail 的条件(primary 和 replica 全部挂掉),不影响其他 shard。默认情况下来说,一个搜索请求,会打到一个 index 的所有 primary shard 上去。 当然了,每个primary shard 都可能会有一个或多个 replic shard,所以请求也可以到 primary shard 的其中一个 replica shard 上去。 |
默认情况下,没有所谓的 timeout,比如说,如果你的搜索特别慢,每个 shared 都要花费好几分钟才能查询出来所有的数据,那么你的搜索请求也会等待好久分钟之后才会返回。
有些搜索应用,对时间是很敏感的,比如电商网站,你不能让用户等 10 分钟,才能等到一次搜索请求的数据,如果那样的话,用户体验就太差了。
timeout 机制,指定每个 shared,就只能在 timeout 时间范围内,将搜索到的部门数据(也可能使全部搜索到了),直接立刻返回给客户端,而不是等到所有的数据全部搜索出来以后再返回。
确切说,一次搜索请求可以在用户指定的 timeout 时长内完成,为一些时间敏感的搜索应用提供良好的支持。
默认无timeout,latency 平衡 completeness,手动指定 timeout,timeout 查询执行机制:
GET /_search?timeout=10m timeout=10ms,timeout=1s,timeout=1m