parent
f9c19dba56
commit
93930d6dc7
|
@ -1,8 +1,6 @@
|
|||
[[cluster-stats]]
|
||||
== Cluster Stats
|
||||
|
||||
added[0.90.8]
|
||||
|
||||
The Cluster Stats API allows to retrieve statistics from a cluster wide perspective.
|
||||
The API returns basic index metrics (shard numbers, store size, memory usage) and
|
||||
information about the current nodes that form the cluster (number, roles, os, jvm
|
||||
|
|
|
@ -28,7 +28,7 @@ Alternatively, `compound_format` can be set to a number between `0` and
|
|||
`1`, where `0` means `false`, `1` means `true` and a number inbetween
|
||||
represents a percentage: if the merged segment is less than this
|
||||
percentage of the total index, then it is written in compound format,
|
||||
otherwise it is written in non-compound format. added[0.90.2]
|
||||
otherwise it is written in non-compound format.
|
||||
|
||||
[[index-compound-on-flush]]`index.compound_on_flush`::
|
||||
|
||||
|
|
|
@ -99,8 +99,6 @@ settings API.
|
|||
[[disk]]
|
||||
=== Disk-based Shard Allocation
|
||||
|
||||
added[0.90.4]
|
||||
|
||||
Elasticsearch con be configured to prevent shard
|
||||
allocation on nodes depending on disk usage for the node. This
|
||||
functionality is disabled by default, and can be changed either in the
|
||||
|
|
|
@ -63,7 +63,7 @@ To get list of all index templates you can use
|
|||
<<cluster-state,Cluster State>> API
|
||||
and check for the metadata/templates section of the response.
|
||||
|
||||
added[0.90.4] Or run:
|
||||
Or run:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -237,7 +237,6 @@ defaults to `true` or to the parent `object` type setting.
|
|||
[float]
|
||||
[[token_count]]
|
||||
==== Token Count
|
||||
added[0.90.8]
|
||||
The `token_count` type maps to the JSON string type but indexes and stores
|
||||
the number of tokens in the string rather than the string itself. For
|
||||
example:
|
||||
|
|
|
@ -71,8 +71,6 @@ users from running arbitrary scripts via the API.
|
|||
[float]
|
||||
=== Automatic Script Reloading
|
||||
|
||||
added[0.90.6]
|
||||
|
||||
The `config/scripts` directory is scanned periodically for changes.
|
||||
New and changed scripts are reloaded and deleted script are removed
|
||||
from preloaded scripts cache. The reload frequency can be specified
|
||||
|
|
|
@ -32,7 +32,6 @@ memory, are not cached by default. Those filters are already very fast,
|
|||
and the process of caching them requires extra processing in order to
|
||||
allow the filter result to be used with different queries than the one
|
||||
executed. These filters, including the geo,
|
||||
<<query-dsl-numeric-range-filter,numeric_range>>,
|
||||
and <<query-dsl-script-filter,script>> filters
|
||||
are not cached by default.
|
||||
|
||||
|
@ -83,8 +82,6 @@ include::filters/nested-filter.asciidoc[]
|
|||
|
||||
include::filters/not-filter.asciidoc[]
|
||||
|
||||
include::filters/numeric-range-filter.asciidoc[]
|
||||
|
||||
include::filters/or-filter.asciidoc[]
|
||||
|
||||
include::filters/prefix-filter.asciidoc[]
|
||||
|
|
|
@ -28,7 +28,6 @@ documents), and `all` (to match all). Defaults to `all`.
|
|||
|
||||
`filter` is mandatory, as well as `indices` (or `index`).
|
||||
|
||||
added[0.90.8]
|
||||
[TIP]
|
||||
===================================================================
|
||||
The fields order is important: if the `indices` are provided before `filter`
|
||||
|
|
|
@ -1,61 +0,0 @@
|
|||
[[query-dsl-numeric-range-filter]]
|
||||
=== Numeric Range Filter
|
||||
|
||||
deprecated[0.90.8,Use the <<query-dsl-range-filter,range filter>> with the `fielddata` execution mode instead]
|
||||
|
||||
Filters documents with fields that have values within a certain numeric
|
||||
range. Similar to
|
||||
<<query-dsl-range-filter,range filter>>, except
|
||||
that it works only with numeric values, and the filter execution works
|
||||
differently.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"constant_score" : {
|
||||
"filter" : {
|
||||
"numeric_range" : {
|
||||
"age" : {
|
||||
"gte": 10,
|
||||
"lte": 20
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
The numeric range filter works by loading all the relevant field values
|
||||
into memory, and checking for the relevant docs if they satisfy the
|
||||
range requirements. This requires more memory since the numeric range
|
||||
data are loaded to memory, but can provide a significant increase in
|
||||
performance. Note, if the relevant field values have already been loaded
|
||||
to memory, for example because it was used in facets or was sorted on,
|
||||
then this filter should be used.
|
||||
|
||||
The `numeric_range` filter accepts the following parameters:
|
||||
|
||||
[horizontal]
|
||||
`gte`:: Greater-than or equal to
|
||||
`gt`:: Greater-than
|
||||
`lte`:: Less-than or equal to
|
||||
`lt`:: Less-than
|
||||
|
||||
deprecated[0.90.4,The `from`, `to`, `include_lower` and `include_upper` parameters have been deprecated in favour of `gt`,`gte`,`lt`,`lte`]
|
||||
|
||||
[float]
|
||||
==== Caching
|
||||
|
||||
The result of the filter is not cached by default. The `_cache` can be
|
||||
set to `true` to cache the *result* of the filter. This is handy when
|
||||
the same points parameters are used on several (many) other queries.
|
||||
Note, the process of caching the first execution is higher when caching
|
||||
(since it needs to satisfy different queries).
|
||||
|
||||
If caching the *result* of the filter is desired (for example, using the
|
||||
same "teen" filter with ages between 10 and 20), then it is advisable to
|
||||
simply use the <<query-dsl-range-filter,range>>
|
||||
filter.
|
||||
|
||||
If the `now` date math expression is used without rounding then a range numeric filter will never be cached even
|
||||
if `_cache` is set to `true`. Also any filter that wraps this filter will never be cached.
|
|
@ -30,13 +30,9 @@ The `range` filter accepts the following parameters:
|
|||
`lte`:: Less-than or equal to
|
||||
`lt`:: Less-than
|
||||
|
||||
deprecated[0.90.4,The `from`, `to`, `include_lower` and `include_upper` parameters have been deprecated in favour of `gt`,`gte`,`lt`,`lte`]
|
||||
|
||||
[float]
|
||||
==== Execution
|
||||
|
||||
added[0.90.8]
|
||||
|
||||
The `execution` option controls how the range filter internally executes. The `execution` option accepts the following values:
|
||||
|
||||
[horizontal]
|
||||
|
|
|
@ -16,12 +16,6 @@ include::queries/boosting-query.asciidoc[]
|
|||
|
||||
include::queries/common-terms-query.asciidoc[]
|
||||
|
||||
include::queries/custom-filters-score-query.asciidoc[]
|
||||
|
||||
include::queries/custom-score-query.asciidoc[]
|
||||
|
||||
include::queries/custom-boost-factor-query.asciidoc[]
|
||||
|
||||
include::queries/constant-score-query.asciidoc[]
|
||||
|
||||
include::queries/dis-max-query.asciidoc[]
|
||||
|
|
|
@ -1,19 +0,0 @@
|
|||
[[query-dsl-custom-boost-factor-query]]
|
||||
=== Custom Boost Factor Query
|
||||
|
||||
deprecated[0.90.4,Replaced by <<query-dsl-function-score-query>>]
|
||||
|
||||
`custom_boost_factor` query allows to wrap another query and multiply
|
||||
its score by the provided `boost_factor`. This can sometimes be desired
|
||||
since `boost` value set on specific queries gets normalized, while this
|
||||
query boost factor does not.
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
"custom_boost_factor" : {
|
||||
"query" : {
|
||||
....
|
||||
},
|
||||
"boost_factor" : 5.2
|
||||
}
|
||||
--------------------------------------------------
|
|
@ -1,55 +0,0 @@
|
|||
[[query-dsl-custom-filters-score-query]]
|
||||
=== Custom Filters Score Query
|
||||
|
||||
deprecated[0.90.4,Replaced by <<query-dsl-function-score-query>>]
|
||||
|
||||
A `custom_filters_score` query allows to execute a query, and if the hit
|
||||
matches a provided filter (ordered), use either a boost or a script
|
||||
associated with it to compute the score. Here is an example:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
{
|
||||
"custom_filters_score" : {
|
||||
"query" : {
|
||||
"match_all" : {}
|
||||
},
|
||||
"filters" : [
|
||||
{
|
||||
"filter" : { "range" : { "age" : {"from" : 0, "to" : 10} } },
|
||||
"boost" : "3"
|
||||
},
|
||||
{
|
||||
"filter" : { "range" : { "age" : {"from" : 10, "to" : 20} } },
|
||||
"boost" : "2"
|
||||
}
|
||||
],
|
||||
"score_mode" : "first"
|
||||
}
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
This can considerably simplify and increase performance for
|
||||
parameterized based scoring since filters are easily cached for faster
|
||||
performance, and boosting / script is considerably simpler.
|
||||
|
||||
[float]
|
||||
==== Score Mode
|
||||
|
||||
A `score_mode` can be defined to control how multiple matching filters
|
||||
control the score. By default, it is set to `first` which means the
|
||||
first matching filter will control the score of the result. It can also
|
||||
be set to `min`/`max`/`total`/`avg`/`multiply` which will aggregate the
|
||||
result from all matching filters based on the aggregation type.
|
||||
|
||||
[float]
|
||||
==== max_boost
|
||||
|
||||
An option to cap the boost value computed.
|
||||
|
||||
[float]
|
||||
==== Script
|
||||
|
||||
A `script` can be used instead of `boost` for more complex score
|
||||
calculations. With optional `params` and `lang` (on the same level as
|
||||
`query` and `filters`).
|
|
@ -1,45 +0,0 @@
|
|||
[[query-dsl-custom-score-query]]
|
||||
=== Custom Score Query
|
||||
|
||||
deprecated[0.90.4,Replaced by <<query-dsl-function-score-query>>]
|
||||
|
||||
`custom_score` query allows to wrap another query and customize the
|
||||
scoring of it optionally with a computation derived from other field
|
||||
values in the doc (numeric ones) using
|
||||
<<modules-scripting,script expression>>. Here is
|
||||
a simple sample:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
"custom_score" : {
|
||||
"query" : {
|
||||
....
|
||||
},
|
||||
"script" : "_score * doc['my_numeric_field'].value"
|
||||
}
|
||||
--------------------------------------------------
|
||||
|
||||
On top of the different scripting field values and expression, the
|
||||
`_score` script parameter can be used to retrieve the score based on the
|
||||
wrapped query.
|
||||
|
||||
[float]
|
||||
==== Script Parameters
|
||||
|
||||
Scripts are cached for faster execution. If the script has parameters
|
||||
that it needs to take into account, it is preferable to use the same
|
||||
script, and provide parameters to it:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
"custom_score" : {
|
||||
"query" : {
|
||||
....
|
||||
},
|
||||
"params" : {
|
||||
"param1" : 2,
|
||||
"param2" : 3.1
|
||||
},
|
||||
"script" : "_score * doc['my_numeric_field'].value / pow(param1, param2)"
|
||||
}
|
||||
--------------------------------------------------
|
|
@ -1,17 +1,14 @@
|
|||
[[query-dsl-function-score-query]]
|
||||
=== Function Score Query
|
||||
|
||||
added[0.90.4]
|
||||
|
||||
The `function_score` allows you to modify the score of documents that are
|
||||
retrieved by a query. This can be useful if, for example, a score
|
||||
function is computationally expensive and it is sufficient to compute
|
||||
the score on a filtered set of documents.
|
||||
|
||||
`function_score` provides the same functionality that
|
||||
<<query-dsl-custom-boost-factor-query>>,
|
||||
<<query-dsl-custom-score-query>> and
|
||||
<<query-dsl-custom-filters-score-query>> provided
|
||||
`custom_boost_factor`, `custom_score` and
|
||||
`custom_filters_score` provided
|
||||
but furthermore adds futher scoring functionality such as
|
||||
distance and recency scoring (see description below).
|
||||
|
||||
|
@ -125,7 +122,7 @@ script, and provide parameters to it:
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
Note that unlike the <<query-dsl-custom-score-query>>, the
|
||||
Note that unlike the `custom_score` query, the
|
||||
score of the query is multiplied with the result of the script scoring. If
|
||||
you wish to inhibit this, set `"boost_mode": "replace"`
|
||||
|
||||
|
@ -178,7 +175,7 @@ decay function is specified as
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
where `DECAY_FUNCTION` can be "linear", "exp" and "gauss" (see below). The specified field must be a numeric field. In the above example, the field is a <<mapping-geo-point-type>> and origin can be provided in geo format. `scale` and `offset` must be given with a unit in this case. If your field is a date field, you can set `scale` and `offset` as days, weeks, and so on. Example:
|
||||
where `DECAY_FUNCTION` can be "linear", "exp" and "gauss" (see below). The specified field must be a numeric field. In the above example, the field is a <<mapping-geo-point-type>> and origin can be provided in geo format. `scale` and `offset` must be given with a unit in this case. If your field is a date field, you can set `scale` and `offset` as days, weeks, and so on. Example:
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -193,9 +190,9 @@ where `DECAY_FUNCTION` can be "linear", "exp" and "gauss" (see below). The speci
|
|||
--------------------------------------------------
|
||||
|
||||
|
||||
The format of the origin depends on the <<mapping-date-format>> defined in your mapping. If you do not define the origin, the current time is used.
|
||||
The format of the origin depends on the <<mapping-date-format>> defined in your mapping. If you do not define the origin, the current time is used.
|
||||
|
||||
|
||||
|
||||
The `offset` and `decay` parameters are optional.
|
||||
|
||||
[horizontal]
|
||||
|
@ -220,7 +217,7 @@ the score function computes a score of 0.5 for hotels that are 2km away
|
|||
from the desired location.
|
||||
|
||||
|
||||
In the second example, documents with a field value between 2013-09-12 and 2013-09-22 would get a weight of 1.0 and documents which are 15 days from that date a weight of 0.5.
|
||||
In the second example, documents with a field value between 2013-09-12 and 2013-09-22 would get a weight of 1.0 and documents which are 15 days from that date a weight of 0.5.
|
||||
|
||||
|
||||
|
||||
|
@ -390,7 +387,7 @@ return 1.
|
|||
|
||||
==== Relation to `custom_boost`, `custom_score` and `custom_filters_score`
|
||||
|
||||
The <<query-dsl-custom-boost-factor-query>>
|
||||
The `custom_boost_factor` query
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -410,7 +407,7 @@ becomes
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
The <<query-dsl-custom-score-query>>
|
||||
The `custom_score` query
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
@ -441,7 +438,7 @@ becomes
|
|||
}
|
||||
--------------------------------------------------
|
||||
|
||||
and the <<query-dsl-custom-filters-score-query>>
|
||||
and the `custom_filters_score`
|
||||
|
||||
[source,js]
|
||||
--------------------------------------------------
|
||||
|
|
|
@ -28,7 +28,6 @@ documents), and `all` (to match all). Defaults to `all`.
|
|||
|
||||
`query` is mandatory, as well as `indices` (or `index`).
|
||||
|
||||
added[0.90.8]
|
||||
[TIP]
|
||||
===================================================================
|
||||
The fields order is important: if the `indices` are provided before `query`
|
||||
|
|
|
@ -29,4 +29,3 @@ The `range` query accepts the following parameters:
|
|||
`lt`:: Less-than
|
||||
`boost`:: Sets the bool value of the query, defaults to `1.0`
|
||||
|
||||
deprecated[0.90.4,The `from`, `to`, `include_lower` and `include_upper` parameters have been deprecated in favour of `gt`,`gte`,`lt`,`lte`]
|
||||
|
|
|
@ -26,8 +26,6 @@ field, or a field without a large number of terms it breaks to.
|
|||
|
||||
==== Accuracy Control
|
||||
|
||||
added[0.90.6]
|
||||
|
||||
The `size` parameter defines how many top terms should be returned out
|
||||
of the overall terms list. By default, the node coordinating the
|
||||
search process will ask each shard to provide its own top `size` terms
|
||||
|
|
|
@ -410,7 +410,6 @@ The `boundary_max_scan` allows to control how far to look for boundary
|
|||
characters, and defaults to `20`.
|
||||
|
||||
|
||||
added[0.90.8]
|
||||
[[matched-fields]]
|
||||
==== Matched Fields
|
||||
The Fast Vector Highlighter can combine matches on multiple fields to
|
||||
|
@ -530,7 +529,6 @@ to
|
|||
--------------------------------------------------
|
||||
===================================================================
|
||||
|
||||
added[0.90.10]
|
||||
[[phrase-limit]]
|
||||
==== Phrase Limit
|
||||
The `fast-vector-highlighter` has a `phrase_limit` parameter that prevents
|
||||
|
|
|
@ -53,7 +53,5 @@ query (just so there will be a place to set a name for it), for example:
|
|||
|
||||
==== Named queries
|
||||
|
||||
added[0.90.4]
|
||||
|
||||
The support for the `_name` option on queries as available from version `0.90.4` and the support on filters is available
|
||||
also in versions before `0.90.4`.
|
||||
|
|
|
@ -88,4 +88,3 @@ And now, we get only 1 hit back, but the facets remain the same.
|
|||
Note, if additional filters are required on specific facets, they can be
|
||||
added as a `facet_filter` to the relevant facets.
|
||||
|
||||
deprecated[0.90.8, The top level `filter` has been renamed to `post_filter`]
|
|
@ -137,8 +137,6 @@ field) or faceting.
|
|||
[[clear-scroll]]
|
||||
===== Clear scroll api
|
||||
|
||||
added[0.90.4]
|
||||
|
||||
Besides consuming the scroll search until no hits has been returned a scroll
|
||||
search can also be aborted by deleting the `scroll_id`. This can be done via
|
||||
the clear scroll api. When the the `scroll_id` has been deleted also all the
|
||||
|
|
Loading…
Reference in New Issue