Numeric field types in Elasticsearch - Step-by-Step Execution

Concept Flow - Numeric field types

Define Numeric Field Type

↓

Choose Specific Type: integer, long, float, double, etc.

↓

Index Numeric Data

↓

Store and Search Numeric Values Efficiently

↓

Use in Queries and Aggregations

↓

Results

This flow shows how numeric field types are defined, indexed, and used in Elasticsearch for efficient storage and querying.

Execution Sample

Elasticsearch

{
  "mappings": {
    "properties": {
      "age": { "type": "integer" }
    }
  }
}

Defines a numeric field 'age' of type integer in Elasticsearch mapping.

Execution Table

Step	Action	Field Type	Input Value	Stored Format	Query Behavior
1	Define field 'age'	integer	N/A	N/A	N/A
2	Index document with age=30	integer	30	Stored as 32-bit integer	Can be searched and aggregated numerically
3	Query for age > 25	integer	N/A	N/A	Matches documents where age is greater than 25
4	Index document with age=30.5	integer	30.5	Error or rounded	Rejected or rounded depending on settings
5	Define field 'price'	float	N/A	N/A	N/A
6	Index document with price=19.99	float	19.99	Stored as 32-bit float	Supports range queries and aggregations
7	Query for price < 20.0	float	N/A	N/A	Matches documents where price is less than 20.0
8	Exit	N/A	N/A	N/A	All numeric fields indexed and ready for queries

💡 All numeric fields are indexed and ready for numeric queries and aggregations.

Variable Tracker

Variable	Start	After Step 2	After Step 4	After Step 6
age	undefined	30	error or 30	30
price	undefined	undefined	undefined	19.99

Key Moments - 3 Insights

Why does indexing a decimal value into an integer field cause an error or rounding?

Integer fields only accept whole numbers. As shown in execution_table step 4, input 30.5 is invalid or rounded because integer type cannot store decimals.

How does Elasticsearch store numeric values internally?

As shown in steps 2 and 6, integers are stored as 32-bit integers, floats as 32-bit floats, enabling efficient storage and fast numeric queries.

Can numeric fields be used in range queries and aggregations?

Yes, as shown in steps 3 and 7, numeric fields support range queries and aggregations for filtering and summarizing data.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What happens when indexing 30.5 into an integer field?

A It stores 30.5 exactly

B It causes an error or rounds the value

C It stores 0

D It converts to string

💡 Hint

Check execution_table row 4 under Stored Format and Query Behavior

At which step does Elasticsearch index a float value?

A Step 2

B Step 4

C Step 6

D Step 3

💡 Hint

Look for 'float' in Field Type column in execution_table

If you want to store large whole numbers, which numeric type should you choose?

A long

B float

C integer

D double

💡 Hint

Consider numeric types that support larger ranges than integer

Concept Snapshot

Numeric field types in Elasticsearch define how numbers are stored and queried.
Common types: integer, long, float, double.
Integer types store whole numbers; float/double store decimals.
Numeric fields enable efficient range queries and aggregations.
Invalid data types cause errors or rounding.
Choose type based on value range and precision needed.

Full Transcript

This visual execution trace shows how numeric field types work in Elasticsearch. First, you define a numeric field like 'age' as integer. When you index a document with age=30, it stores the value as a 32-bit integer. Queries like age > 25 work efficiently. If you try to index a decimal like 30.5 into an integer field, it causes an error or rounds the value. For decimal numbers, you define fields as float or double, which store numbers with decimals and support range queries. Numeric fields enable fast searching and aggregations on numbers. Choosing the right numeric type depends on the range and precision of your data.

Practice

1.

Which numeric field type in Elasticsearch should you use to store whole numbers without decimals?

easy

A. double

B. integer

C. float

D. text

Solution

1. Step 1: Understand numeric field types

   Integer type stores whole numbers without decimals, suitable for counts or IDs.

2. Step 2: Compare with other types

   Float and double store decimal numbers; text is for strings, not numbers.

3. Final Answer:

   integer -> Option B

4. Quick Check:

   Whole numbers = integer [OK]

Hint: Whole numbers use integer type, decimals need float/double [OK]

Common Mistakes:

• Choosing float or double for whole numbers
• Using text type for numbers
• Confusing integer with long for small numbers

2.

Which of the following is the correct way to define a long numeric field in an Elasticsearch mapping?

{
  "mappings": {
    "properties": {
      "user_id": {
        "type": "_____"
      }
    }
  }
}

easy

A. "long"

B. "integer"

C. "float"

D. "keyword"

Solution

1. Step 1: Identify the field type for large whole numbers

   Long type stores larger whole numbers than integer, suitable for big IDs.

2. Step 2: Match the correct type string in mapping

   Use "long" as the type value in the mapping JSON for such fields.

3. Final Answer:

   "long" -> Option A

4. Quick Check:

   Big whole numbers = "long" [OK]

Hint: Use "long" for large whole numbers in mapping [OK]

Common Mistakes:

• Using "integer" for very large numbers
• Using "keyword" which is for text
• Using "float" for whole numbers

3.

Given this Elasticsearch mapping snippet, what type of number can price store?

{
  "mappings": {
    "properties": {
      "price": {
        "type": "float"
      }
    }
  }
}

medium

A. Boolean true/false values

B. Only whole numbers

C. Text values representing numbers

D. Decimal numbers with floating point

Solution

1. Step 1: Check the type assigned to price

   The type is "float", which stores decimal numbers with floating point precision.

2. Step 2: Understand what float means

   Float allows decimals, unlike integer or long which store whole numbers only.

3. Final Answer:

   Decimal numbers with floating point -> Option D

4. Quick Check:

   Float type = decimals allowed [OK]

Hint: Float type stores decimal numbers, not just whole numbers [OK]

Common Mistakes:

• Thinking float stores only whole numbers
• Confusing float with text or boolean
• Assuming float stores exact decimal precision always

4.

What is wrong with this Elasticsearch mapping for a numeric field?

{
  "mappings": {
    "properties": {
      "score": {
        "type": "integer",
        "index": "not_analyzed"
      }
    }
  }
}

medium

A. 'type' should be 'float' instead of 'integer'

B. 'score' field name is not allowed

C. 'index' parameter is invalid for numeric fields

D. Mapping syntax is missing a closing brace

Solution

1. Step 1: Review the 'index' parameter usage

   Numeric fields do not support 'index' with 'not_analyzed'; this is for text fields.

2. Step 2: Confirm correct mapping for numeric fields

   Numeric fields are indexed by default and do not use 'not_analyzed'.

3. Final Answer:

   'index' parameter is invalid for numeric fields -> Option C

4. Quick Check:

   Numeric fields don't use 'index': 'not_analyzed' [OK]

Hint: Don't use 'index':'not_analyzed' on numeric fields [OK]

Common Mistakes:

• Using text field options on numeric fields
• Changing type unnecessarily
• Ignoring Elasticsearch mapping syntax rules

5.

You want to store product weights that can be very large and may have decimals. Which Elasticsearch numeric field type is best?

hard

A. double

B. long

C. float

D. integer

Solution

1. Step 1: Analyze the requirements for product weights

   Weights can be very large and have decimals, so the type must support large range and decimals.

2. Step 2: Compare float and double types

   Float supports decimals but has less precision and smaller range than double.

3. Step 3: Choose the best type for large decimal numbers

   Double supports large decimal numbers with higher precision, suitable for weights.

4. Final Answer:

   double -> Option A

5. Quick Check:

   Large decimals = double type [OK]

Hint: Use double for large decimal numbers needing precision [OK]

Common Mistakes:

• Choosing integer or long which don't support decimals
• Using float which may lose precision
• Ignoring size and precision needs