Dynamic vs explicit mapping in Elasticsearch - Performance Comparison

Time Complexity: Dynamic vs explicit mapping

O(n x f)

Understanding Time Complexity

When Elasticsearch indexes data, it decides how to store each field using mapping. This can happen automatically (dynamic) or by predefined rules (explicit).

We want to understand how the time to process data grows depending on which mapping method is used.

Scenario Under Consideration

Analyze the time complexity of this mapping setup:

PUT /my_index
{
  "mappings": {
    "dynamic": true,
    "properties": {
      "name": { "type": "text" },
      "age": { "type": "integer" }
    }
  }
}

// vs explicit mapping with dynamic disabled
PUT /my_index_explicit
{
  "mappings": {
    "dynamic": false,
    "properties": {
      "name": { "type": "text" },
      "age": { "type": "integer" }
    }
  }
}

This shows two index setups: one lets Elasticsearch guess new fields dynamically, the other only accepts predefined fields.

Identify Repeating Operations

Look at what happens when documents are indexed:

• Primary operation: Checking each field in the document against the mapping rules.
• How many times: For every field in every document indexed.

Dynamic mapping adds extra checks to detect new fields, while explicit mapping skips this step.

How Execution Grows With Input

As the number of fields and documents grows, the work to check and update mappings changes:

Input Size (fields x docs)	Approx. Operations
10 x 10	Low, quick checks for new fields
100 x 100	More checks, some new fields trigger mapping updates
1000 x 1000	Many checks, frequent mapping updates slow indexing

With dynamic mapping, the time grows faster because it must inspect and possibly update mappings for new fields. Explicit mapping keeps this steady by skipping new field checks.

Final Time Complexity

Time Complexity: O(n × f)

This means the time grows with the number of documents (n) times the number of fields (f) because each field in each document is checked.

Common Mistake

[X] Wrong: "Dynamic mapping has no impact on indexing speed because it just happens once."

[OK] Correct: Dynamic mapping checks every field in every document to see if it is new, which adds work each time, slowing down indexing as data grows.

Interview Connect

Understanding how dynamic and explicit mappings affect indexing time shows you can think about how Elasticsearch handles data behind the scenes. This skill helps you design better data models and explain trade-offs clearly.

Self-Check

"What if we indexed documents with many nested objects? How would dynamic mapping affect the time complexity then?"

Practice

1. What is the main difference between dynamic mapping and explicit mapping in Elasticsearch?

easy

A. Dynamic mapping automatically detects field types, explicit mapping requires manual definition.

B. Dynamic mapping requires manual field type definition, explicit mapping guesses types automatically.

C. Dynamic mapping disables indexing, explicit mapping enables indexing.

D. Dynamic mapping is only for text fields, explicit mapping is only for numeric fields.

Solution

1. Step 1: Understand dynamic mapping

   Dynamic mapping lets Elasticsearch guess the data type of fields automatically when new data arrives.

2. Step 2: Understand explicit mapping

   Explicit mapping means you define each field's type and settings manually before indexing data.

3. Final Answer:

   Dynamic mapping automatically detects field types, explicit mapping requires manual definition. -> Option A

4. Quick Check:

   Dynamic = auto detect, Explicit = manual define [OK]

Hint: Dynamic guesses types; explicit means you set types yourself [OK]

Common Mistakes:

• Confusing which mapping guesses types
• Thinking dynamic disables indexing
• Assuming explicit mapping is only for numbers

2. Which JSON snippet correctly defines an explicit mapping for a field age as an integer?

easy

A. {"mappings": {"properties": {"age": "number"}}}

B. {"mappings": {"age": {"type": "text"}}}

C. {"properties": {"age": "integer"}}

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

Solution

1. Step 1: Check correct mapping structure

   Explicit mapping requires "mappings" with "properties" and field name with type inside.

2. Step 2: Verify field type for age

   "age" field must have "type": "integer" to define it as integer.

3. Final Answer:

   {"mappings": {"properties": {"age": {"type": "integer"}}}} -> Option D

4. Quick Check:

   Correct JSON structure with integer type [OK]

Hint: Explicit mapping needs mappings > properties > field > type [OK]

Common Mistakes:

• Missing 'properties' level in JSON
• Using wrong type names like 'number' instead of 'integer'
• Placing fields outside 'mappings'

3. Given this explicit mapping, what will be the type of the price field after indexing?

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

medium

A. integer

B. text

C. float

D. keyword

Solution

1. Step 1: Read the explicit mapping for price

   The mapping defines "price" with "type": "float", so Elasticsearch will store it as a floating-point number.

2. Step 2: Understand type assignment

   Explicit mapping overrides dynamic guessing, so price will be float regardless of input data.

3. Final Answer:

   float -> Option C

4. Quick Check:

   Explicit float mapping means price = float [OK]

Hint: Explicit mapping sets exact type, here float for price [OK]

Common Mistakes:

• Assuming price becomes integer automatically
• Thinking dynamic mapping applies here
• Confusing float with text or keyword

4. You have this mapping snippet:

{"mappings": {"properties": {"date": {"type": "date"}}}}

After indexing a document with "date": "not-a-date", what error will occur?

medium

A. No error, field stored as text

B. Document rejected with parsing exception

C. Field ignored silently

D. Mapping conflict error due to wrong type

Solution

1. Step 1: Check mapping type for date

   The field "date" is explicitly mapped as "date" type, so Elasticsearch expects a valid date format.

2. Step 2: Indexing invalid date string

   Indexing "not-a-date" will cause a parsing exception because it cannot convert the string to a date.

3. Final Answer:

   Document rejected with parsing exception -> Option B

4. Quick Check:

   Invalid date string causes parsing error [OK]

Hint: Invalid date string causes parsing error, not silent ignore [OK]

Common Mistakes:

• Thinking field stores as text automatically
• Assuming no error occurs
• Believing field is ignored silently

5. You want to prevent Elasticsearch from automatically adding new fields to your index but still allow existing fields to be indexed. Which mapping setting should you use?

hard

A. "dynamic": "strict"

B. "dynamic": "true"

C. "dynamic": "false"

D. "dynamic": "runtime"

Solution

1. Step 1: Understand dynamic mapping options

   "dynamic": "true" allows new fields to be added automatically, "false" ignores new fields, "strict" rejects documents with unknown fields.

2. Step 2: Choose setting to prevent new fields but allow existing

   "strict" rejects documents with new fields, so only existing fields are indexed, preventing unwanted additions.

3. Final Answer:

   "dynamic": "strict" -> Option A

4. Quick Check:

   Use strict to block new fields, allow existing [OK]

Hint: Use dynamic: strict to block new fields but keep existing [OK]

Common Mistakes:

• Using dynamic: false which ignores new fields silently
• Using dynamic: true which allows new fields
• Confusing runtime with dynamic setting