2015-05-21 05:39:38 -04:00
|
|
|
[[search-aggregations-pipeline-min-bucket-aggregation]]
|
2015-04-30 09:41:01 -04:00
|
|
|
=== Min Bucket Aggregation
|
2015-04-30 06:24:36 -04:00
|
|
|
|
2016-08-12 18:42:19 -04:00
|
|
|
A sibling pipeline aggregation which identifies the bucket(s) with the minimum value of a specified metric in a sibling aggregation
|
|
|
|
and outputs both the value and the key(s) of the bucket(s). The specified metric must be numeric and the sibling aggregation must
|
2015-04-30 06:24:36 -04:00
|
|
|
be a multi-bucket aggregation.
|
|
|
|
|
2015-05-01 16:04:55 -04:00
|
|
|
==== Syntax
|
|
|
|
|
2017-04-05 06:39:37 -04:00
|
|
|
A `min_bucket` aggregation looks like this in isolation:
|
2015-05-01 16:04:55 -04:00
|
|
|
|
|
|
|
[source,js]
|
|
|
|
--------------------------------------------------
|
|
|
|
{
|
|
|
|
"min_bucket": {
|
|
|
|
"buckets_path": "the_sum"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2017-05-01 13:30:51 -04:00
|
|
|
// NOTCONSOLE
|
2015-05-01 16:04:55 -04:00
|
|
|
|
2019-04-30 10:19:09 -04:00
|
|
|
[[min-bucket-params]]
|
2015-05-01 16:04:55 -04:00
|
|
|
.`min_bucket` Parameters
|
2019-04-30 10:19:09 -04:00
|
|
|
[options="header"]
|
2015-05-01 16:04:55 -04:00
|
|
|
|===
|
|
|
|
|Parameter Name |Description |Required |Default Value
|
2015-08-31 07:47:40 -04:00
|
|
|
|`buckets_path` |The path to the buckets we wish to find the minimum for (see <<buckets-path-syntax>> for more
|
2015-05-06 07:54:42 -04:00
|
|
|
details) |Required |
|
|
|
|
|`gap_policy` |The policy to apply when gaps are found in the data (see <<gap-policy>> for more
|
2017-03-01 08:46:49 -05:00
|
|
|
details)|Optional | `skip`
|
2017-04-05 06:39:37 -04:00
|
|
|
|`format` |format to apply to the output value of this aggregation |Optional |`null`
|
2015-05-01 16:04:55 -04:00
|
|
|
|===
|
|
|
|
|
2015-04-30 06:24:36 -04:00
|
|
|
The following snippet calculates the minimum of the total monthly `sales`:
|
|
|
|
|
2019-09-05 10:11:25 -04:00
|
|
|
[source,console]
|
2015-04-30 06:24:36 -04:00
|
|
|
--------------------------------------------------
|
2016-08-12 18:42:19 -04:00
|
|
|
POST /sales/_search
|
2015-04-30 06:24:36 -04:00
|
|
|
{
|
2016-08-12 18:42:19 -04:00
|
|
|
"size": 0,
|
2015-04-30 06:24:36 -04:00
|
|
|
"aggs" : {
|
|
|
|
"sales_per_month" : {
|
|
|
|
"date_histogram" : {
|
|
|
|
"field" : "date",
|
[7.x Backport] Force selection of calendar or fixed intervals (#41906)
The date_histogram accepts an interval which can be either a calendar
interval (DST-aware, leap seconds, arbitrary length of months, etc) or
fixed interval (strict multiples of SI units). Unfortunately this is inferred
by first trying to parse as a calendar interval, then falling back to fixed
if that fails.
This leads to confusing arrangement where `1d` == calendar, but
`2d` == fixed. And if you want a day of fixed time, you have to
specify `24h` (e.g. the next smallest unit). This arrangement is very
error-prone for users.
This PR adds `calendar_interval` and `fixed_interval` parameters to any
code that uses intervals (date_histogram, rollup, composite, datafeed, etc).
Calendar only accepts calendar intervals, fixed accepts any combination of
units (meaning `1d` can be used to specify `24h` in fixed time), and both
are mutually exclusive.
The old interval behavior is deprecated and will throw a deprecation warning.
It is also mutually exclusive with the two new parameters. In the future the
old dual-purpose interval will be removed.
The change applies to both REST and java clients.
2019-05-20 12:07:29 -04:00
|
|
|
"calendar_interval" : "month"
|
2015-04-30 06:24:36 -04:00
|
|
|
},
|
|
|
|
"aggs": {
|
|
|
|
"sales": {
|
|
|
|
"sum": {
|
|
|
|
"field": "price"
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
|
|
|
"min_monthly_sales": {
|
|
|
|
"min_bucket": {
|
2015-08-31 07:47:40 -04:00
|
|
|
"buckets_path": "sales_per_month>sales" <1>
|
2015-04-30 06:24:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2016-08-12 18:42:19 -04:00
|
|
|
// TEST[setup:sales]
|
2015-04-30 06:24:36 -04:00
|
|
|
|
2017-04-05 06:39:37 -04:00
|
|
|
<1> `buckets_path` instructs this min_bucket aggregation that we want the minimum value of the `sales` aggregation in the
|
2015-04-30 06:24:36 -04:00
|
|
|
`sales_per_month` date histogram.
|
|
|
|
|
|
|
|
And the following may be the response:
|
|
|
|
|
2019-09-06 16:09:09 -04:00
|
|
|
[source,console-result]
|
2015-04-30 06:24:36 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
{
|
2016-08-12 18:42:19 -04:00
|
|
|
"took": 11,
|
|
|
|
"timed_out": false,
|
|
|
|
"_shards": ...,
|
|
|
|
"hits": ...,
|
2015-04-30 06:24:36 -04:00
|
|
|
"aggregations": {
|
|
|
|
"sales_per_month": {
|
|
|
|
"buckets": [
|
|
|
|
{
|
|
|
|
"key_as_string": "2015/01/01 00:00:00",
|
|
|
|
"key": 1420070400000,
|
|
|
|
"doc_count": 3,
|
|
|
|
"sales": {
|
2016-08-12 18:42:19 -04:00
|
|
|
"value": 550.0
|
2015-04-30 06:24:36 -04:00
|
|
|
}
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"key_as_string": "2015/02/01 00:00:00",
|
|
|
|
"key": 1422748800000,
|
|
|
|
"doc_count": 2,
|
|
|
|
"sales": {
|
2016-08-12 18:42:19 -04:00
|
|
|
"value": 60.0
|
2015-04-30 06:24:36 -04:00
|
|
|
}
|
|
|
|
},
|
|
|
|
{
|
|
|
|
"key_as_string": "2015/03/01 00:00:00",
|
|
|
|
"key": 1425168000000,
|
|
|
|
"doc_count": 2,
|
|
|
|
"sales": {
|
2016-08-12 18:42:19 -04:00
|
|
|
"value": 375.0
|
2015-04-30 06:24:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
]
|
|
|
|
},
|
|
|
|
"min_monthly_sales": {
|
|
|
|
"keys": ["2015/02/01 00:00:00"], <1>
|
2016-08-12 18:42:19 -04:00
|
|
|
"value": 60.0
|
2015-04-30 06:24:36 -04:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
--------------------------------------------------
|
2016-08-12 18:42:19 -04:00
|
|
|
// TESTRESPONSE[s/"took": 11/"took": $body.took/]
|
|
|
|
// TESTRESPONSE[s/"_shards": \.\.\./"_shards": $body._shards/]
|
|
|
|
// TESTRESPONSE[s/"hits": \.\.\./"hits": $body.hits/]
|
2015-04-30 06:24:36 -04:00
|
|
|
|
|
|
|
<1> `keys` is an array of strings since the minimum value may be present in multiple buckets
|