2014-05-15 06:36:05 -04:00
|
|
|
[[java-aggs]]
|
|
|
|
|
== Aggregations
|
|
|
|
|
|
|
|
|
|
Elasticsearch provides a full Java API to play with aggregations. See the
|
|
|
|
|
{ref}/search-aggregations.html[Aggregations guide].
|
|
|
|
|
|
|
|
|
|
Use the factory for aggregation builders (`AggregationBuilders`) and add each aggregation
|
|
|
|
|
you want to compute when querying and add it to your search request:
|
|
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
SearchResponse sr = node.client().prepareSearch()
|
|
|
|
|
.setQuery( /* your query */ )
|
|
|
|
|
.addAggregation( /* add an aggregation */ )
|
|
|
|
|
.execute().actionGet();
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
|
|
Note that you can add more than one aggregation. See
|
|
|
|
|
{ref}/search-search.html[Search Java API] for details.
|
|
|
|
|
|
|
|
|
|
To build aggregation requests, use `AggregationBuilders` helpers. Just import them
|
|
|
|
|
in your class:
|
|
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
import org.elasticsearch.search.aggregations.AggregationBuilders;
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
|
|
=== Structuring aggregations
|
|
|
|
|
|
|
|
|
|
As explained in the
|
|
|
|
|
{ref}/search-aggregations.html[Aggregations guide], you can define
|
|
|
|
|
sub aggregations inside an aggregation.
|
|
|
|
|
|
|
|
|
|
An aggregation could be a metrics aggregation or a bucket aggregation.
|
|
|
|
|
|
|
|
|
|
For example, here is a 3 levels aggregation composed of:
|
|
|
|
|
|
|
|
|
|
* Terms aggregation (bucket)
|
|
|
|
|
* Date Histogram aggregation (bucket)
|
|
|
|
|
* Average aggregation (metric)
|
|
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
SearchResponse sr = node.client().prepareSearch()
|
|
|
|
|
.addAggregation(
|
|
|
|
|
AggregationBuilders.terms("by_country").field("country")
|
|
|
|
|
.subAggregation(AggregationBuilders.dateHistogram("by_year")
|
|
|
|
|
.field("dateOfBirth")
|
[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
|
|
|
.calendarInterval(DateHistogramInterval.YEAR)
|
2014-05-15 06:36:05 -04:00
|
|
|
.subAggregation(AggregationBuilders.avg("avg_children").field("children"))
|
|
|
|
|
)
|
|
|
|
|
)
|
|
|
|
|
.execute().actionGet();
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
|
|
=== Metrics aggregations
|
|
|
|
|
|
|
|
|
|
include::aggregations/metrics.asciidoc[]
|
|
|
|
|
|
|
|
|
|
=== Bucket aggregations
|
|
|
|
|
|
|
|
|
|
include::aggregations/bucket.asciidoc[]
|
