Bird
Raised Fist0
Elasticsearchquery~5 mins

Runtime fields in Elasticsearch - Cheat Sheet & Quick Revision

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Recall & Review
beginner
What are runtime fields in Elasticsearch?
Runtime fields are fields that are computed on the fly during query time, without being stored on disk. They allow you to define new fields based on existing data without reindexing.
Click to reveal answer
beginner
How do runtime fields differ from stored fields in Elasticsearch?
Stored fields are saved on disk during indexing and retrieved during search. Runtime fields are calculated dynamically at query time and are not stored, which means no reindexing is needed to add or change them.
Click to reveal answer
beginner
Which scripting language is commonly used to define runtime fields in Elasticsearch?
Painless is the default and recommended scripting language used to define runtime fields in Elasticsearch because it is secure and optimized for performance.
Click to reveal answer
intermediate
Example: What does this runtime field script do?
emit(doc['price'].value * 1.2)
This script creates a runtime field that calculates a new value by multiplying the existing 'price' field by 1.2, effectively adding a 20% increase to the price at query time.
Click to reveal answer
intermediate
Can runtime fields be used for sorting and aggregations in Elasticsearch?
Yes, runtime fields can be used for sorting and aggregations, but because they are computed at query time, they may be slower than using stored fields.
Click to reveal answer
What is the main advantage of using runtime fields in Elasticsearch?
ANo need to reindex data to add or change fields
BThey are stored permanently on disk
CThey improve indexing speed
DThey replace all stored fields
Which language is used to write scripts for runtime fields?
AJavaScript
BPainless
CPython
DSQL
Runtime fields are computed when?
ADuring indexing
BOnly during cluster restart
CAt query time
DWhen data is stored
Which of these is a limitation of runtime fields?
AMay be slower than stored fields for queries
BCannot be used in aggregations
CRequire reindexing to change
DCannot access other fields
What does this runtime field script do?
emit(doc['age'].value + 5)
ASubtracts 5 from age
BMultiplies age by 5
CDivides age by 5
DAdds 5 to age
Explain what runtime fields are and why they are useful in Elasticsearch.
Think about how you can add new data views without changing stored data.
You got /4 concepts.
    Describe how you would create a runtime field that increases a numeric field by 10%.
    Consider a simple math operation inside the script.
    You got /4 concepts.

      Practice

      (1/5)
      1. What is the main purpose of runtime fields in Elasticsearch?
      easy
      A. To backup the index data automatically
      B. To create new fields dynamically during search without changing stored data
      C. To delete existing fields from documents
      D. To permanently add new fields to the index mapping

      Solution

      1. Step 1: Understand runtime fields concept

        Runtime fields are used to add fields dynamically at query time without modifying the stored data.
      2. Step 2: Compare options with concept

        Only To create new fields dynamically during search without changing stored data describes creating fields dynamically during search without changing stored data.
      3. Final Answer:

        To create new fields dynamically during search without changing stored data -> Option B
      4. Quick Check:

        Runtime fields = dynamic fields at search time [OK]
      Hint: Runtime fields add data on-the-fly, not stored permanently [OK]
      Common Mistakes:
      • Confusing runtime fields with permanent mapping changes
      • Thinking runtime fields modify stored documents
      • Assuming runtime fields delete data
      2. Which of the following is the correct syntax to define a runtime field named full_name that concatenates first_name and last_name using painless script?
      easy
      A. { "runtime_mappings": { "full_name": { "type": "keyword", "script": "return doc['first_name'] + ' ' + doc['last_name']" } } }
      B. { "mappings": { "full_name": { "type": "text" } } }
      C. { "runtime_fields": { "full_name": { "type": "keyword", "script": "emit(doc['first_name'].value + ' ' + doc['last_name'].value)" } } }
      D. { "runtime_mappings": { "full_name": { "type": "keyword", "script": { "source": "emit(doc['first_name'].value + ' ' + doc['last_name'].value)" } } } }

      Solution

      1. Step 1: Identify correct runtime field syntax

        Runtime fields are defined under runtime_mappings with a type and a script object containing source code.
      2. Step 2: Check script correctness

        { "runtime_mappings": { "full_name": { "type": "keyword", "script": { "source": "emit(doc['first_name'].value + ' ' + doc['last_name'].value)" } } } } uses emit() inside source string and accesses doc['field'].value correctly.
      3. Final Answer:

        { "runtime_mappings": { "full_name": { "type": "keyword", "script": { "source": "emit(doc['first_name'].value + ' ' + doc['last_name'].value)" } } } } -> Option D
      4. Quick Check:

        runtime_mappings + emit() + doc['field'].value = correct syntax [OK]
      Hint: Use runtime_mappings with script source and emit() for runtime fields [OK]
      Common Mistakes:
      • Using mappings instead of runtime_mappings
      • Missing emit() function in script
      • Incorrect script syntax without source object
      3. Given this runtime field definition in a search query:
      {
        "runtime_mappings": {
          "age_plus_ten": {
            "type": "long",
            "script": {
              "source": "emit(doc['age'].value + 10)"
            }
          }
        }
      }

      What will be the value of age_plus_ten for a document with age = 25?
      medium
      A. 35
      B. 15
      C. 25
      D. Error: field not found

      Solution

      1. Step 1: Understand the script logic

        The script emits the value of age field plus 10.
      2. Step 2: Calculate the result for age=25

        25 + 10 = 35.
      3. Final Answer:

        35 -> Option A
      4. Quick Check:

        age + 10 = 35 [OK]
      Hint: Add 10 to age field value as scripted [OK]
      Common Mistakes:
      • Confusing addition with subtraction
      • Assuming runtime fields modify stored data
      • Expecting syntax error instead of calculation
      4. You wrote this runtime field script:
      {
        "runtime_mappings": {
          "discounted_price": {
            "type": "double",
            "script": {
              "source": "emit(doc['price'].value * 0.9)"
            }
          }
        }
      }

      But the query fails with an error: Field [price] not found in doc. What is the likely cause?
      medium
      A. Runtime fields cannot use numeric types
      B. The script syntax is incorrect
      C. The price field is missing in some documents
      D. The discounted_price field must be defined in mappings

      Solution

      1. Step 1: Analyze error message

        Error says price field not found in document, meaning some docs lack this field.
      2. Step 2: Understand runtime field behavior

        Runtime scripts fail if they access missing fields without checks.
      3. Final Answer:

        The price field is missing in some documents -> Option C
      4. Quick Check:

        Missing field in doc causes runtime script error [OK]
      Hint: Check if all docs have fields used in runtime scripts [OK]
      Common Mistakes:
      • Assuming script syntax error without checking data
      • Thinking runtime fields require mapping changes
      • Ignoring missing field presence in documents
      5. You want to create a runtime field status that returns "adult" if age ≥ 18, otherwise "minor". Which painless script correctly implements this logic?
      hard
      A. "emit(doc['age'].value >= 18 ? 'adult' : 'minor')"
      B. "if (doc['age'].value >= 18) { return 'adult' } else { return 'minor' }"
      C. "emit(doc['age'] >= 18 ? 'adult' : 'minor')"
      D. "emit(doc['age'].value > 18 ? 'adult' : 'minor')"

      Solution

      1. Step 1: Check correct painless syntax for runtime fields

        Runtime fields use emit() to output values; accessing field value requires doc['age'].value.
      2. Step 2: Verify conditional logic

        "emit(doc['age'].value >= 18 ? 'adult' : 'minor')" uses ternary operator with >= 18 and emits 'adult' or 'minor' correctly.
      3. Final Answer:

        "emit(doc['age'].value >= 18 ? 'adult' : 'minor')" -> Option A
      4. Quick Check:

        emit() + ternary + doc['age'].value = correct [OK]
      Hint: Use emit() with ternary and doc['field'].value for conditions [OK]
      Common Mistakes:
      • Using return instead of emit() in runtime fields
      • Accessing doc['age'] without .value
      • Using > instead of >= changing logic