Elasticsearch medium
Searching or aggregating on a `text` field often requires enabling `fielddata`. Why is this highly discouraged in production environments?
- A It requires the data to be unencrypted in the REST API response.
- B Heap Overflow Risk: Fielddata loads the entire inverted index for that field into the JVM Heap RAM. For high-cardinality data, this causes Garbage Collection (GC) thrashing and eventually crashes the node with an OutOfMemory (OOM) error.
- C It forces the index to be read-only while the fielddata is being built.
- D It prohibits the use of Replica shards for that index.
Answer: B. Heap Overflow Risk: Fielddata loads the entire inverted index for that field into the JVM Heap RAM. For high-cardinality data, this causes Garbage Collection (GC) thrashing and eventually crashes the node with an OutOfMemory (OOM) error.
Doc Values (used by keywords) are on-disk and don't affect the JVM Heap. Fielddata (used by text) is a legacy memory-hog. To aggregate on a 'Name' field, you should map it as a multi-field: `name` (text for search) and `name.keyword` (keyword for grouping).
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?