Numeric field typesedit
The following numeric types are supported:

A signed 64bit integer with a minimum value of 

A signed 32bit integer with a minimum value of 

A signed 16bit integer with a minimum value of 

A signed 8bit integer with a minimum value of 

A doubleprecision 64bit IEEE 754 floating point number, restricted to finite values. 

A singleprecision 32bit IEEE 754 floating point number, restricted to finite values. 

A halfprecision 16bit IEEE 754 floating point number, restricted to finite values. 

A floating point number that is backed by a 

An unsigned 64bit integer with a minimum value of 0 and a maximum value of 
Below is an example of configuring a mapping with numeric fields:
response = client.indices.create( index: 'myindex000001', body: { mappings: { properties: { number_of_bytes: { type: 'integer' }, time_in_seconds: { type: 'float' }, price: { type: 'scaled_float', scaling_factor: 100 } } } } ) puts response
res, err := es.Indices.Create( "myindex000001", es.Indices.Create.WithBody(strings.NewReader(`{ "mappings": { "properties": { "number_of_bytes": { "type": "integer" }, "time_in_seconds": { "type": "float" }, "price": { "type": "scaled_float", "scaling_factor": 100 } } } }`)), ) fmt.Println(res, err)
PUT myindex000001 { "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 viceversa. 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.
Which type should I use?edit
As far as integer types (byte
, short
, integer
and long
) are concerned,
you should pick the smallest type which is enough for your usecase. 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 floatingpoint types, it is often more efficient to store floatingpoint
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 usecase among the floatingpoint 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 













Mapping numeric identifiers
Not all numeric data should be mapped as a numeric field data type.
Elasticsearch optimizes numeric fields, such as integer
or long
, for
range
queries. However, keyword
fields
are better for term
and other
termlevel queries.
Identifiers, such as an ISBN or a product ID, are rarely used in range
queries. However, they are often retrieved using termlevel queries.
Consider mapping a numeric identifier as a keyword
if:

You don’t plan to search for the identifier data using
range
queries. 
Fast retrieval is important.
term
query searches onkeyword
fields are often faster thanterm
searches on numeric fields.
If you’re unsure which to use, you can use a multifield to map
the data as both a keyword
and a numeric data type.
Parameters for numeric fieldsedit
The following parameters are accepted by numeric types:
Try to convert strings to numbers and truncate fractions for integers.
Accepts 

Should the field be stored on disk in a columnstride 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 


Defines what to do if the script defined by the 

If this parameter is set, then the field will index values generated
by this script, rather than reading the values directly from the
source. If a value is set for this field on the input document, then
the document will be rejected with an error.
Scripts are in the same format as their
runtime equivalent. Scripts can only be
configured on 
Whether the field value should be stored and retrievable separately from
the 

Metadata about the field. 
Parameters for scaled_float
edit
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 