Mapping tells Elasticsearch how to understand and store your data. Dynamic mapping guesses the data type automatically, while explicit mapping means you tell Elasticsearch exactly what each field is.
Dynamic vs explicit mapping in Elasticsearch
PUT /my_index
{
"mappings": {
"dynamic": true | false | "strict",
"properties": {
"field_name": { "type": "text" | "keyword" | "date" | ... }
}
}
}dynamic can be true (default), false, or strict.
properties defines explicit fields and their types.
PUT /my_index
{
"mappings": {
"dynamic": true
}
}name and age fields are allowed.PUT /my_index
{
"mappings": {
"dynamic": false,
"properties": {
"name": { "type": "text" },
"age": { "type": "integer" }
}
}
}PUT /my_index
{
"mappings": {
"dynamic": "strict",
"properties": {
"email": { "type": "keyword" }
}
}
}This creates an index with explicit mapping. The pages field is not defined and dynamic mapping is strict, so it causes an error.
PUT /library
{
"mappings": {
"dynamic": "strict",
"properties": {
"title": { "type": "text" },
"author": { "type": "keyword" },
"published_year": { "type": "integer" }
}
}
}
POST /library/_doc/1
{
"title": "Learn Elasticsearch",
"author": "Jane Doe",
"published_year": 2023,
"pages": 250
}Dynamic mapping is convenient but can cause unexpected fields to be added.
Explicit mapping gives you control and can improve search speed and accuracy.
Use dynamic: strict to prevent any new fields from being added by mistake.
Dynamic mapping lets Elasticsearch guess field types automatically.
Explicit mapping means you define each field and its type yourself.
Choosing between them depends on how much control and safety you want.
Practice
Solution
Step 1: Understand dynamic mapping
Dynamic mapping lets Elasticsearch guess the data type of fields automatically when new data arrives.Step 2: Understand explicit mapping
Explicit mapping means you define each field's type and settings manually before indexing data.Final Answer:
Dynamic mapping automatically detects field types, explicit mapping requires manual definition. -> Option AQuick Check:
Dynamic = auto detect, Explicit = manual define [OK]
- Confusing which mapping guesses types
- Thinking dynamic disables indexing
- Assuming explicit mapping is only for numbers
age as an integer?Solution
Step 1: Check correct mapping structure
Explicit mapping requires "mappings" with "properties" and field name with type inside.Step 2: Verify field type for age
"age" field must have "type": "integer" to define it as integer.Final Answer:
{"mappings": {"properties": {"age": {"type": "integer"}}}} -> Option DQuick Check:
Correct JSON structure with integer type [OK]
- Missing 'properties' level in JSON
- Using wrong type names like 'number' instead of 'integer'
- Placing fields outside 'mappings'
price field after indexing?{"mappings": {"properties": {"price": {"type": "float"}}}}Solution
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.Step 2: Understand type assignment
Explicit mapping overrides dynamic guessing, so price will be float regardless of input data.Final Answer:
float -> Option CQuick Check:
Explicit float mapping means price = float [OK]
- Assuming price becomes integer automatically
- Thinking dynamic mapping applies here
- Confusing float with text or keyword
{"mappings": {"properties": {"date": {"type": "date"}}}}After indexing a document with
"date": "not-a-date", what error will occur?Solution
Step 1: Check mapping type for date
The field "date" is explicitly mapped as "date" type, so Elasticsearch expects a valid date format.Step 2: Indexing invalid date string
Indexing "not-a-date" will cause a parsing exception because it cannot convert the string to a date.Final Answer:
Document rejected with parsing exception -> Option BQuick Check:
Invalid date string causes parsing error [OK]
- Thinking field stores as text automatically
- Assuming no error occurs
- Believing field is ignored silently
Solution
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.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.Final Answer:
"dynamic": "strict" -> Option AQuick Check:
Use strict to block new fields, allow existing [OK]
- Using dynamic: false which ignores new fields silently
- Using dynamic: true which allows new fields
- Confusing runtime with dynamic setting
Ready to prove it?
Pass the test and this pattern moves unknown
