Numeric field types in Elasticsearch - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Predict Output

intermediate

What is the output of this mapping for a numeric field?

Given this Elasticsearch mapping snippet, what is the type of the field age and what is its default behavior?

Elasticsearch

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

A The field <code>age</code> is a 32-bit signed integer and supports range queries.

B The field <code>age</code> is a floating-point number and supports decimal values.

C The field <code>age</code> is a string and does not support numeric operations.

D The field <code>age</code> is a 64-bit unsigned integer.

💡 Hint

Think about the standard integer type in Elasticsearch and what it supports.

In Elasticsearch, the integer type is a 32-bit signed integer. It supports numeric operations like range queries. It does not support decimals or unsigned values.

❓ Predict Output

intermediate

What happens when you index a decimal number into a field of type long?

Consider this mapping and document indexing: Mapping: { "mappings": { "properties": { "price": { "type": "long" } } } } Document: { "price": 19.99 } What will Elasticsearch do?

A It will round the decimal 19.99 to 20 and store it as a long integer.

B It will store the decimal 19.99 exactly as a long integer without rounding.

C It will convert the decimal to a string and store it as text.

D It will reject the document and throw a mapping exception error.

💡 Hint

Think about how Elasticsearch handles decimal values for integer types.

Elasticsearch expects integer types like long to receive whole numbers. Indexing a decimal into a long field causes a mapping exception error.

🔧 Debug

advanced

Why does this mapping cause an error?

This mapping snippet causes an error when applied. Identify the cause: { "mappings": { "properties": { "score": { "type": "unsigned_long" } } } }

A The field name <code>score</code> is a reserved keyword and cannot be used.

B Elasticsearch does not support the <code>unsigned_long</code> type; only <code>long</code> is valid.

C The mapping is missing the <code>index</code> property which is required for numeric fields.

D The <code>unsigned_long</code> type requires a <code>coerce</code> property to be set.

💡 Hint

Check the official Elasticsearch numeric types supported.

Elasticsearch does not have an unsigned_long type. The valid integer types are byte, short, integer, and long. Using an unsupported type causes an error.

📝 Syntax

advanced

Which mapping snippet correctly defines a scaled_float field with a scaling factor of 100?

Choose the correct Elasticsearch mapping for a scaled_float field named rating with a scaling factor of 100.

A { "mappings": { "properties": { "rating": { "type": "float", "scaling_factor": 100 } } } }

B { "mappings": { "properties": { "rating": { "type": "scaled_float", "scale_factor": 100 } } } }

C { "mappings": { "properties": { "rating": { "type": "scaled_float", "scaling_factor": 100 } } } }

D { "mappings": { "properties": { "rating": { "type": "scaled_float", "scaling": 100 } } } }

💡 Hint

Check the exact property name for scaling factor in the official docs.

The correct property name is scaling_factor. Option C uses the correct type and property name. Other options have wrong property names or types.

🚀 Application

expert

How many numeric fields are created by this mapping?

Given this Elasticsearch mapping, how many numeric fields are defined? { "mappings": { "properties": { "id": { "type": "keyword" }, "count": { "type": "integer" }, "price": { "type": "scaled_float", "scaling_factor": 100 }, "rating": { "type": "float" }, "timestamp": { "type": "date" } } } }

A 3

B 2

C 5

D 4

💡 Hint

Count only fields with numeric types like integer, float, scaled_float.

The numeric fields are count (integer), price (scaled_float), and rating (float). The id is keyword and timestamp is date, so they are not numeric.

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