The following numeric types are supported:
|
|
A signed 64-bit integer with a minimum value of |
|
|
A signed 32-bit integer with a minimum value of |
|
|
A signed 16-bit integer with a minimum value of |
|
|
A signed 8-bit integer with a minimum value of |
|
|
A double-precision 64-bit IEEE 754 floating point number, restricted to finite values. |
|
|
A single-precision 32-bit IEEE 754 floating point number, restricted to finite values. |
|
|
A half-precision 16-bit IEEE 754 floating point number, restricted to finite values. |
|
|
A floating point number that is backed by a |
Below is an example of configuring a mapping with numeric fields:
PUT my_index
{
"mappings": {
"properties": {
"number_of_bytes": {
"type": "integer"
},
"time_in_seconds": {
"type": "float"
},
"price": {
"type": "scaled_float",
"scaling_factor": 100
}
}
}
}
The double, float and half_float types consider that -0.0 and
+0.0 are different values. As a consequence, doing a term query on
-0.0 will not match +0.0 and vice-versa. Same is true for range queries:
if the upper bound is -0.0 then +0.0 will not match, and if the lower
bound is +0.0 then -0.0 will not match.
As far as integer types (byte, short, integer and long) are concerned,
you should pick the smallest type which is enough for your use-case. This will
help indexing and searching be more efficient. Note however that storage is
optimized based on the actual values that are stored, so picking one type over
another one will have no impact on storage requirements.
For floating-point types, it is often more efficient to store floating-point
data into an integer using a scaling factor, which is what the scaled_float
type does under the hood. For instance, a price field could be stored in a
scaled_float with a scaling_factor of 100. All APIs would work as if
the field was stored as a double, but under the hood Elasticsearch would be
working with the number of cents, price*100, which is an integer. This is
mostly helpful to save disk space since integers are way easier to compress
than floating points. scaled_float is also fine to use in order to trade
accuracy for disk space. For instance imagine that you are tracking cpu
utilization as a number between 0 and 1. It usually does not matter much
whether cpu utilization is 12.7% or 13%, so you could use a scaled_float
with a scaling_factor of 100 in order to round cpu utilization to the
closest percent in order to save space.
If scaled_float is not a good fit, then you should pick the smallest type
that is enough for the use-case among the floating-point types: double,
float and half_float. Here is a table that compares these types in order
to help make a decision.
| Type | Minimum value | Maximum value | Significant bits / digits |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
The following parameters are accepted by numeric types:
|
Try to convert strings to numbers and truncate fractions for integers.
Accepts | |
|
Mapping field-level query time boosting. Accepts a floating point number, defaults
to | |
|
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 | |
|
If | |
|
Should the field be searchable? Accepts | |
|
Accepts a numeric value of the same | |
|
Whether the field value should be stored and retrievable separately from
the |
scaled_float accepts an additional parameter:
|
|
The scaling factor to use when encoding values. Values will be multiplied
by this factor at index time and rounded to the closest long value. For
instance, a |