Index Boost
当搜索多个索引时，允许为每个索引配置不同的boost级别。当来自一个索引的点击率比来自另一个索引的点击率更重要时，这是非常方便的。
警告: 在5.2.0弃用。
这种格式是不推荐的。请使用数组格式。
GET /_search
{
"indices_boost" : {
"index1" : 1.4,
"index2" : 1.3
}
}还可以将其指定为数组来控制增强的顺序。
GET /_search
{
"indices_boost" : [
{ "alias1" : 1.4 },
{ "index*" : 1.3 }
]
}这在使用别名或通配符表达式时非常重要。如果找到多个匹配项，将使用第一个匹配项。例如，如果一个索引同时包含在alias1和index*中，则应用boost值1.4。
Inner hits
父连接和嵌套特性允许返回在不同范围内具有匹配项的文档。在父/子案例中，父文档是基于子文档中的匹配返回的，或者子文档是基于父文档中的匹配返回的。在嵌套情况下，将根据嵌套内部对象中的匹配返回文档。
在这两种情况下，导致返回文档的不同范围内的实际匹配都是隐藏的。在许多情况下，知道哪些内嵌套对象(在嵌套的情况下)或子/父文档(在父/子文档的情况下)导致某些信息返回是非常有用的。内部hits特性可以用于此目的。该特性在搜索响应中每次搜索命中都会返回额外的嵌套命中，这些嵌套命中导致搜索命中在不同的范围内匹配。
可以定义一个inner_hits,定义于nested,has_child或has_parent查询或过滤上来使用内部hits,该结构类似如下:
"<query>" : {
"inner_hits" : {
<inner_hits_options>
}
}如果inner_hits定义在一个支持它的查询上，那么每个搜索命中都包含一个inner_hits json对象，结构如下:
"hits": [
{
"_index": ...,
"_type": ...,
"_id": ...,
"inner_hits": {
"<inner_hits_name>": {
"hits": {
"total": ...,
"hits": [
{
"_type": ...,
"_id": ...,
...
},
...
]
}
}
},
...
},
...
]Options
内部点击支持以下选项:
From
为返回的常规搜索命中中的每个inner_hits获取第一个命中的偏移量。
Size
每个inner_hits返回的最大命中数。默认情况下，返回前三个匹配的命中。
Sort
如何按inner_hits对内部命中排序。默认情况下，按分数排序。
Name
用于响应中特定的内部hit定义的名称。当在一个搜索请求中定义了多个内部命中时非常有用。默认值取决于定义内部命中的查询。对于has_child查询和过滤器，这是子类型，has_parent查询和过滤器，这是父类型，嵌套查询和过滤器，这是嵌套路径。
内部点击也支持以下每个文件的功能:
- Highlighting
- Explain
- Source filtering
- Script fields
- Doc value fields
- Include versions
- Include Sequence Numbers and Primary Terms
Nested inner hits
嵌套inner_hits可用于将嵌套内部对象包含为搜索命中的内部命中。
PUT test
{
"mappings": {
"properties": {
"comments": {
"type": "nested"
}
}
}
}
PUT test/_doc/1?refresh
{
"title": "Test title",
"comments": [
{
"author": "kimchy",
"number": 1
},
{
"author": "nik9000",
"number": 2
}
]
}
POST test/_search
{
"query": {
"nested": {
"path": "comments",
"query": {
"match": {"comments.number" : 2}
},
"inner_hits": {} ----------1
}
}
}1: 嵌套查询中的内部hit定义。不需要定义其他选项。
可由上述搜寻要求产生的回应片段的例子:
{
...,
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 1.0,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "1",
"_score": 1.0,
"_source": ...,
"inner_hits": {
"comments": { ----------1
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 1.0,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "1",
"_nested": {
"field": "comments",
"offset": 1
},
"_score": 1.0,
"_source": {
"author": "nik9000",
"number": 2
}
}
]
}
}
}
}
]
}
}在搜索请求的内部hit定义中使用的名称。可以通过name选项使用自定义密钥。
_nested元数据在上面的例子中非常重要，因为它定义了这个内嵌套对象的内命中来自何处。field定义嵌套命中的对象数组字段的来自和相对于其在_source中的位置的偏移量。由于在inner_hits中对命中对象的实际位置进行排序和打分，通常与定义嵌套内对象的位置不同。
默认情况下，inner_hits中的hit对象也会返回_source，但这是可以更改的。可以通过_source过滤功能返回或禁用部分源代码。如果在嵌套级别定义了存储字段，那么还可以通过字段特性返回这些字段。
一个重要的默认值是_source在inner_hits中的命中返回是相对于_nested元数据的。因此，在上面的示例中，每次嵌套命中只返回注释部分，而不返回包含注释的顶层文档的整个源代码。
Nested inner hits and _source
嵌套文档没有_source字段，因为整个文档源都存储在根文档的_source字段下。要仅包含嵌套文档的源，将解析根文档的源，并将嵌套文档的相关位作为源包含在内部hit中。对每个匹配的嵌套文档执行此操作将影响执行整个搜索请求所需的时间，特别是当大小和内部命中的大小设置为高于默认值时。为了避免对嵌套的内部命中进行相对昂贵的源提取，可以禁用包含源并仅依赖于doc values字段。就像这样:
PUT test
{
"mappings": {
"properties": {
"comments": {
"type": "nested"
}
}
}
}
PUT test/_doc/1?refresh
{
"title": "Test title",
"comments": [
{
"author": "kimchy",
"text": "comment text"
},
{
"author": "nik9000",
"text": "words words words"
}
]
}
POST test/_search
{
"query": {
"nested": {
"path": "comments",
"query": {
"match": {"comments.text" : "words"}
},
"inner_hits": {
"_source" : false,
"docvalue_fields" : [
"comments.text.keyword"
]
}
}
}
}Hierarchical levels of nested object fields and inner hits
如果映射具有多个层次嵌套对象字段，则可以通过点标记路径访问每个层次嵌套对象字段。例如，如果有一个comments嵌套字段包含一个选票嵌套字段，并且选票应该与根点击一起直接返回，那么可以定义以下路径:
PUT test
{
"mappings": {
"properties": {
"comments": {
"type": "nested",
"properties": {
"votes": {
"type": "nested"
}
}
}
}
}
}
PUT test/_doc/1?refresh
{
"title": "Test title",
"comments": [
{
"author": "kimchy",
"text": "comment text",
"votes": []
},
{
"author": "nik9000",
"text": "words words words",
"votes": [
{"value": 1 , "voter": "kimchy"},
{"value": -1, "voter": "other"}
]
}
]
}
POST test/_search
{
"query": {
"nested": {
"path": "comments.votes",
"query": {
"match": {
"comments.votes.voter": "kimchy"
}
},
"inner_hits" : {}
}
}
}这看起来像:
{
...,
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 0.6931472,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "1",
"_score": 0.6931472,
"_source": ...,
"inner_hits": {
"comments.votes": { ----------------1
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 0.6931472,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "1",
"_nested": {
"field": "comments",
"offset": 1,
"_nested": {
"field": "votes",
"offset": 0
}
},
"_score": 0.6931472,
"_source": {
"value": 1,
"voter": "kimchy"
}
}
]
}
}
}
}
]
}
}
这种间接引用只支持嵌套的内部命中。
Parent/child inner hits
父/子inner_hits可用于包含父或子:
PUT test
{
"mappings": {
"properties": {
"my_join_field": {
"type": "join",
"relations": {
"my_parent": "my_child"
}
}
}
}
}
PUT test/_doc/1?refresh
{
"number": 1,
"my_join_field": "my_parent"
}
PUT test/_doc/2?routing=1&refresh
{
"number": 1,
"my_join_field": {
"name": "my_child",
"parent": "1"
}
}
POST test/_search
{
"query": {
"has_child": {
"type": "my_child",
"query": {
"match": {
"number": 1
}
},
"inner_hits": {} ----------------1
}
}
}1: 内部hit定义类似于嵌套示例。
可由上述搜寻要求产生的回应片段的例子:
{
...,
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 1.0,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "1",
"_score": 1.0,
"_source": {
"number": 1,
"my_join_field": "my_parent"
},
"inner_hits": {
"my_child": {
"hits": {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score": 1.0,
"hits": [
{
"_index": "test",
"_type": "_doc",
"_id": "2",
"_score": 1.0,
"_routing": "1",
"_source": {
"number": 1,
"my_join_field": {
"name": "my_child",
"parent": "1"
}
}
}
]
}
}
}
}
]
}
}min_score
排除_score小于min_score中指定的最小值的文档:
GET /_search
{
"min_score": 0.5,
"query" : {
"term" : { "user" : "kimchy" }
}
}注意，在大多数情况下，这没有多大意义，但是它是为高级用例提供的。
889
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
