Elasticsearch hard
What is the primary architectural trade-off of a 'Frozen Index' (part of the Cold/Frozen data tier)?
- A Extreme Heap efficiency: They reside almost entirely on disk/S3 and do not consume JVM Heap for transient data structures (like terms dictionaries) unless a search is actively running.
- B Consistency: Frozen indices only support 'Eventually Consistent' reads with a 24-hour lag.
- C Durability: They are stored in volatile RAM and will be lost on a node reboot.
- D Searchability: They only support `IDS` and `MatchAll` queries; no complex aggregations are allowed.
Answer: A. Extreme Heap efficiency: They reside almost entirely on disk/S3 and do not consume JVM Heap for transient data structures (like terms dictionaries) unless a search is actively running.
Frozen indices allow you to keep massive amounts of data 'searchable' without paying for a massive server fleet. The cost is latency: because ES must rebuild the temporary index structures for every query, a search that takes 20ms on 'Hot' data might take 2 seconds on 'Frozen' data.
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?