Numeric field types

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.

scaled_float accepts an additional parameter:

scaled_float is stored as a single long value, which is the product of multiplying the original value by the scaling factor. If the multiplication results in a value that is outside the range of a long, the value is saturated to the minimum or maximum value of a long. For example, if the scaling factor is 100 and the value is 92233720368547758.08, the expected value is 9223372036854775808. However, the value that is stored is 9223372036854775807, the maximum value for a long.

This can lead to unexpected results with range queries when the scaling factor or provided float value are exceptionally large.

All numeric fields except unsigned_long support synthetic _source in their default configuration. Synthetic _source cannot be used together with ignore_malformed, copy_to, or with doc_values disabled.

Synthetic source always sorts numeric fields. For example:

response = client.indices.create(
  index: 'idx',
  body: {
    mappings: {
      _source: {
        mode: 'synthetic'
      },
      properties: {
        long: {
          type: 'long'
        }
      }
    }
  }
)
puts response

response = client.indices.create(
  index: 'idx',
  id: 1,
  body: {
    long: [
      0,
      0,
      -123_466,
      87_612
    ]
  }
)
puts response

PUT idx
{
  "mappings": {
    "_source": { "mode": "synthetic" },
    "properties": {
      "long": { "type": "long" }
    }
  }
}
PUT idx/_doc/1
{
  "long": [0, 0, -123466, 87612]
}

Will become:

{
  "long": [-123466, 0, 0, 87612]
}

Scaled floats will always apply their scaling factor so:

response = client.indices.create(
  index: 'idx',
  body: {
    mappings: {
      _source: {
        mode: 'synthetic'
      },
      properties: {
        f: {
          type: 'scaled_float',
          scaling_factor: 0.01
        }
      }
    }
  }
)
puts response

response = client.indices.create(
  index: 'idx',
  id: 1,
  body: {
    f: 123
  }
)
puts response

PUT idx
{
  "mappings": {
    "_source": { "mode": "synthetic" },
    "properties": {
      "f": { "type": "scaled_float", "scaling_factor": 0.01 }
    }
  }
}
PUT idx/_doc/1
{
  "f": 123
}

Will become:

{
  "f": 100.0
}