Elasticsearch hard
You are aggregating on a field with millions of unique values (e.g., UserID) and nesting sub-aggregations within it. Which setting prevents 'Bucket Explosion'?
- A Changing the collection mode to `breadth_first`. This prunes the tree by identifying the 'top' buckets before calculating the sub-aggregations for only those winners.
- B Disabling the `_source` field for the duration of the query.
- C Increasing the `index.mapping.total_fields.limit` to 5000.
- D Using a `script_score` to manually calculate the bucket weights.
Answer: A. Changing the collection mode to `breadth_first`. This prunes the tree by identifying the 'top' buckets before calculating the sub-aggregations for only those winners.
By default (`depth_first`), ES tries to build every possible bucket path. If you have 1M users and a date histogram, you get millions of buckets in RAM. `breadth_first` says 'Find me the top 10 users by sales, and THEN calculate their monthly history'. This uses dramatically less memory for high-cardinality 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?