mirror of
https://github.com/honeymoose/OpenSearch.git
synced 2025-02-07 05:28:34 +00:00
4b1c116461
Adds infrastructure so `gradle :docs:check` will extract tests from snippets in the documentation and execute the tests. This is included in `gradle check` so it should happen on CI and during a normal build. By default each `// AUTOSENSE` snippet creates a unique REST test. These tests are executed in a random order and the cluster is wiped between each one. If multiple snippets chain together into a test you can annotate all snippets after the first with `// TEST[continued]` to have the generated tests for both snippets joined. Snippets marked as `// TESTRESPONSE` are checked against the response of the last action. See docs/README.asciidoc for lots more. Closes #12583. That issue is about catching bugs in the docs during build. This catches *some* bugs in the docs during build which is a good start.
94 lines
2.7 KiB
Plaintext
94 lines
2.7 KiB
Plaintext
[[mapping-boost]]
|
|
=== `boost`
|
|
|
|
Individual fields can be _boosted_ automatically -- count more towards the relevance score
|
|
-- at query time, with the `boost` parameter as follows:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
PUT my_index
|
|
{
|
|
"mappings": {
|
|
"my_type": {
|
|
"properties": {
|
|
"title": {
|
|
"type": "text",
|
|
"boost": 2 <1>
|
|
},
|
|
"content": {
|
|
"type": "text"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// AUTOSENSE
|
|
|
|
<1> Matches on the `title` field will have twice the weight as those on the
|
|
`content` field, which has the default `boost` of `1.0`.
|
|
|
|
NOTE: The boost is applied only for term queries (prefix, range and fuzzy queries are not _boosted_).
|
|
|
|
You can achieve the same effect by using the boost parameter directly in the query, for instance the following query (with field time boost):
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
POST _search
|
|
{
|
|
"query": {
|
|
"match" : {
|
|
"title": {
|
|
"query": "quick brown fox"
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// AUTOSENSE
|
|
|
|
is equivalent to:
|
|
|
|
[source,js]
|
|
--------------------------------------------------
|
|
POST _search
|
|
{
|
|
"query": {
|
|
"match" : {
|
|
"title": {
|
|
"query": "quick brown fox",
|
|
"boost": 2
|
|
}
|
|
}
|
|
}
|
|
}
|
|
--------------------------------------------------
|
|
// AUTOSENSE
|
|
|
|
|
|
The boost is also applied when it is copied with the
|
|
value in the <<mapping-all-field,`_all`>> field. This means that, when
|
|
querying the `_all` field, words that originated from the `title` field will
|
|
have a higher score than words that originated in the `content` field.
|
|
This functionality comes at a cost: queries on the `_all` field are slower
|
|
when field boosting is used.
|
|
|
|
deprecated[5.0.0, index time boost is deprecated. Instead, the field mapping boost is applied at query time. For indices created before 5.0.0 the boost will still be applied at index time.]
|
|
[WARNING]
|
|
.Why index time boosting is a bad idea
|
|
==================================================
|
|
|
|
We advise against using index time boosting for the following reasons:
|
|
|
|
* You cannot change index-time `boost` values without reindexing all of your
|
|
documents.
|
|
|
|
* Every query supports query-time boosting which achieves the same effect. The
|
|
difference is that you can tweak the `boost` value without having to reindex.
|
|
|
|
* Index-time boosts are stored as part of the <<norms,`norm`>>, which is only one
|
|
byte. This reduces the resolution of the field length normalization factor
|
|
which can lead to lower quality relevance calculations.
|
|
|
|
==================================================
|