Elasticsearch hard
When performing aggregations on high-cardinality `keyword` fields, Elasticsearch builds 'Global Ordinals'. Why are these computed eagerly or lazily, and what is their memory structure?
- A They are 128-bit hashes that replace the `_id` field to save disk space.
- B They are a cluster-wide lookup map that translates unique string terms into small, contiguous integers (ordinals). This allows aggregation buckets to be handled as fast numeric arrays rather than slow string-comparison maps.
- C They are Bloom filters used to skip shards that definitely don't contain the requested terms.
- D They are a subset of the transaction log used for auditing search history.
Answer: B. They are a cluster-wide lookup map that translates unique string terms into small, contiguous integers (ordinals). This allows aggregation buckets to be handled as fast numeric arrays rather than slow string-comparison maps.
Global Ordinals are shard-specific but unify the 'local' ordinals of each Lucene segment. Building them can be slow (Refresh latency). In high-cardinality fields, they can consume significant Heap, which is why they are often lazily loaded unless configured otherwise.
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?