Elasticsearch hard
Why is a `script` query using 'Painless' significantly slower than a standard Lucene query (e.g., `match` or `range`)?
- A Painless scripts are interpreted line-by-line using a legacy Ruby engine.
- B Per-Document Execution: Lucene queries use pre-computed inverted index bitsets (O(1) lookups). Scripts must be executed for every single document that passes the initial filter, requiring expensive per-doc field loading and JVM execution cycles.
- C Scripts are required to travel to the Master node for validation before every execution.
- D Painless scripting is limited to only a single thread per cluster.
Answer: B. Per-Document Execution: Lucene queries use pre-computed inverted index bitsets (O(1) lookups). Scripts must be executed for every single document that passes the initial filter, requiring expensive per-doc field loading and JVM execution cycles.
Think of a script as a `for-loop` over your results. If 1 million documents pass your filter, the script runs 1 million times. Standard queries avoid this by using the 'Inverted Index' which is basically a pre-calculated answer key. Scripts should be a last resort for complex logic that cannot be modeled at index-time.
One system design question a day, with spaced repetition so the ones you miss come back.
Get the appRelated questions
- What are the two primary reasons for configuring one or more 'Replica Shards' for an index?
- When a String field is mapped as `text`, what process is performed to enable full-text search capability?
- What is the primary benefit of splitting an Elasticsearch index into multiple 'Primary Shards'?
- Every document stored in an Elasticsearch index is uniquely tracked by which mandatory metadata field?
- Elasticsearch search results include a metadata field called `_score`. What does this value primarily indicate?
- What is the primary architectural purpose of Elasticsearch in a modern software stack?