2014-05-15 06:36:05 -04:00
|
|
|
[[java-aggs-bucket-datehistogram]]
|
|
|
|
==== Date Histogram Aggregation
|
|
|
|
|
|
|
|
Here is how you can use
|
|
|
|
{ref}/search-aggregations-bucket-datehistogram-aggregation.html[Date Histogram Aggregation]
|
|
|
|
with Java API.
|
|
|
|
|
|
|
|
|
|
|
|
===== Prepare aggregation request
|
|
|
|
|
|
|
|
Here is an example on how to create the aggregation request:
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
AggregationBuilder aggregation =
|
|
|
|
AggregationBuilders
|
|
|
|
.dateHistogram("agg")
|
|
|
|
.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
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Or if you want to set an interval of 10 days:
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
AggregationBuilder aggregation =
|
|
|
|
AggregationBuilders
|
|
|
|
.dateHistogram("agg")
|
|
|
|
.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
|
|
|
.fixedInterval(DateHistogramInterval.days(10));
|
2014-05-15 06:36:05 -04:00
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
|
|
|
|
===== Use aggregation response
|
|
|
|
|
|
|
|
Import Aggregation definition classes:
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
import org.elasticsearch.search.aggregations.bucket.histogram.Histogram;
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
[source,java]
|
|
|
|
--------------------------------------------------
|
|
|
|
// sr is here your SearchResponse object
|
2015-03-05 05:56:13 -05:00
|
|
|
Histogram agg = sr.getAggregations().get("agg");
|
2014-05-15 06:36:05 -04:00
|
|
|
|
|
|
|
// For each entry
|
2015-03-05 05:56:13 -05:00
|
|
|
for (Histogram.Bucket entry : agg.getBuckets()) {
|
2015-06-03 11:08:32 -04:00
|
|
|
DateTime key = (DateTime) entry.getKey(); // Key
|
|
|
|
String keyAsString = entry.getKeyAsString(); // Key as String
|
|
|
|
long docCount = entry.getDocCount(); // Doc count
|
2014-05-15 06:36:05 -04:00
|
|
|
|
2015-06-03 11:08:32 -04:00
|
|
|
logger.info("key [{}], date [{}], doc_count [{}]", keyAsString, key.getYear(), docCount);
|
2014-05-15 06:36:05 -04:00
|
|
|
}
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
This will basically produce for the first example:
|
|
|
|
|
|
|
|
[source,text]
|
|
|
|
--------------------------------------------------
|
|
|
|
key [1942-01-01T00:00:00.000Z], date [1942], doc_count [1]
|
|
|
|
key [1945-01-01T00:00:00.000Z], date [1945], doc_count [1]
|
|
|
|
key [1946-01-01T00:00:00.000Z], date [1946], doc_count [1]
|
|
|
|
...
|
|
|
|
key [2005-01-01T00:00:00.000Z], date [2005], doc_count [1]
|
|
|
|
key [2007-01-01T00:00:00.000Z], date [2007], doc_count [2]
|
|
|
|
key [2008-01-01T00:00:00.000Z], date [2008], doc_count [3]
|
|
|
|
--------------------------------------------------
|
2017-05-11 13:06:26 -04:00
|
|
|
|
|
|
|
===== Order
|
|
|
|
|
|
|
|
Supports the same order functionality as the <<java-aggs-bucket-terms,`Terms Aggregation`>>.
|