Range field types
Range field types represent a continuous range of values between an upper and lower bound. For example, a range can represent any date in October or any integer from 0 to 9. They are defined using the operators gt
or gte
for the lower bound, and lt
or lte
for the upper bound. They can be used for querying, and have limited support for aggregations. The only supported aggregations are histogram, cardinality.
The following range types are supported:
integer_range
- A range of signed 32-bit integers with a minimum value of
-231
and maximum of231-1
. float_range
- A range of single-precision 32-bit IEEE 754 floating point values.
long_range
- A range of signed 64-bit integers with a minimum value of
-263
and maximum of263-1
. double_range
- A range of double-precision 64-bit IEEE 754 floating point values.
date_range
- A range of
date
values. Date ranges support various date formats through theformat
mapping parameter. Regardless of the format used, date values are parsed into an unsigned 64-bit integer representing milliseconds since the Unix epoch in UTC. Values containing thenow
date math expression are not supported. ip_range
- A range of ip values supporting either IPv4 or IPv6 (or mixed) addresses.
Below is an example of configuring a mapping with various range fields followed by an example that indexes several range types.
PUT range_index
{
"settings": {
"number_of_shards": 2
},
"mappings": {
"properties": {
"expected_attendees": {
"type": "integer_range"
},
"time_frame": {
"type": "date_range", 1
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
}
}
}
PUT range_index/_doc/1?refresh
{
"expected_attendees" : { 2
"gte" : 10,
"lt" : 20
},
"time_frame" : {
"gte" : "2015-10-31 12:00:00", 3
"lte" : "2015-11-01"
}
}
date_range
types accept the same field parameters defined by thedate
type.- Example indexing a meeting with 10 to 20 attendees, not including 20.
- Example date range using date time stamp.
The following is an example of a term query on the integer_range
field named "expected_attendees". 12 is a value inside the range, so it will match.
GET range_index/_search
{
"query" : {
"term" : {
"expected_attendees" : {
"value": 12
}
}
}
}
The result produced by the above query.
{
"took": 13,
"timed_out": false,
"_shards" : {
"total": 2,
"successful": 2,
"skipped" : 0,
"failed": 0
},
"hits" : {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "range_index",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"expected_attendees" : {
"gte" : 10, "lt" : 20
},
"time_frame" : {
"gte" : "2015-10-31 12:00:00", "lte" : "2015-11-01"
}
}
}
]
}
}
The following is an example of a date_range
query over the date_range
field named "time_frame".
GET range_index/_search
{
"query" : {
"range" : {
"time_frame" : { 1
"gte" : "2015-10-31",
"lte" : "2015-11-01",
"relation" : "within" 2
}
}
}
}
- Range queries work the same as described in range query.
- Range queries over range fields support a
relation
parameter which can be one ofWITHIN
,CONTAINS
,INTERSECTS
(default).
This query produces a similar result:
{
"took": 13,
"timed_out": false,
"_shards" : {
"total": 2,
"successful": 2,
"skipped" : 0,
"failed": 0
},
"hits" : {
"total" : {
"value": 1,
"relation": "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "range_index",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"expected_attendees" : {
"gte" : 10, "lt" : 20
},
"time_frame" : {
"gte" : "2015-10-31 12:00:00", "lte" : "2015-11-01"
}
}
}
]
}
}
In addition to the range format above, IP ranges can be provided in CIDR notation:
PUT range_index/_mapping
{
"properties": {
"ip_allowlist": {
"type": "ip_range"
}
}
}
PUT range_index/_doc/2
{
"ip_allowlist" : "192.168.0.0/16"
}
The following parameters are accepted by range types:
coerce
- Try to convert strings to numbers and truncate fractions for integers. Accepts
true
(default) andfalse
. doc_values
- Should the field be stored on disk in a column-stride fashion, so that it can later be used for sorting, aggregations, or scripting? Accepts
true
(default) orfalse
. index
- Should the field be searchable? Accepts
true
(default) andfalse
. store
- Whether the field value should be stored and retrievable separately from the
_source
field. Acceptstrue
orfalse
(default).
Synthetic _source
is Generally Available only for TSDB indices (indices that have index.mode
set to time_series
). For other indices synthetic _source
is in technical preview. Features in technical preview may be changed or removed in a future release. Elastic will work to fix any issues, but features in technical preview are not subject to the support SLA of official GA features.
range
fields support synthetic _source
in their default configuration.
Synthetic source may sort range
field values and remove duplicates for all range
fields except ip_range
. Ranges are sorted by their lower bound and then by upper bound. For example:
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"my_range": { "type": "long_range" }
}
}
}
PUT idx/_doc/1
{
"my_range": [
{
"gte": 200,
"lte": 300
},
{
"gte": 1,
"lte": 100
},
{
"gte": 200,
"lte": 300
},
{
"gte": 200,
"lte": 500
}
]
}
Will become:
{
"my_range": [
{
"gte": 1,
"lte": 100
},
{
"gte": 200,
"lte": 300
},
{
"gte": 200,
"lte": 500
}
]
}
Values of ip_range
fields are not sorted but original order is not preserved. Duplicate ranges are removed. If ip_range
field value is provided as a CIDR, it will be represented as a range of IP addresses in synthetic source.
For example:
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"my_range": { "type": "ip_range" }
}
}
}
PUT idx/_doc/1
{
"my_range": [
"10.0.0.0/24",
{
"gte": "10.0.0.0",
"lte": "10.0.0.255"
}
]
}
Will become:
{
"my_range": {
"gte": "10.0.0.0",
"lte": "10.0.0.255"
}
}
Range field values are always represented as inclusive on both sides with bounds adjusted accordingly. Default values for range bounds are represented as null
. This is true even if range bound was explicitly provided. For example:
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"my_range": { "type": "long_range" }
}
}
}
PUT idx/_doc/1
{
"my_range": {
"gt": 200,
"lt": 300
}
}
Will become:
{
"my_range": {
"gte": 201,
"lte": 299
}
}
Default values for range bounds are represented as null
in synthetic source. This is true even if range bound was explicitly provided with default value. For example:
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"my_range": { "type": "integer_range" }
}
}
}
PUT idx/_doc/1
{
"my_range": {
"lte": 2147483647
}
}
Will become:
{
"my_range": {
"gte": null,
"lte": null
}
}
date
ranges are formatted using provided format
or by default using yyyy-MM-dd'T'HH:mm:ss.SSSZ
format. For example:
PUT idx
{
"settings": {
"index": {
"mapping": {
"source": {
"mode": "synthetic"
}
}
}
},
"mappings": {
"properties": {
"my_range": { "type": "date_range" }
}
}
}
PUT idx/_doc/1
{
"my_range": [
{
"gte": 1504224000000,
"lte": 1504569600000
},
{
"gte": "2017-09-01",
"lte": "2017-09-10"
}
]
}
Will become:
{
"my_range": [
{
"gte": "2017-09-01T00:00:00.000Z",
"lte": "2017-09-05T00:00:00.000Z"
},
{
"gte": "2017-09-01T00:00:00.000Z",
"lte": "2017-09-10T23:59:59.999Z"
}
]
}