Elasticsearch hard
When using the `nested` field type to store arrays of objects, how does Lucene physically store these components to ensure high-performance joining during a query?
- A They are stored in a hidden 'Global Shadow Index' that is shared across all shards.
- B Block Join Architecture: Each nested object is stored as a separate, hidden Lucene document, but they are guaranteed to be physically adjacent to the root parent document within the same Lucene segment.
- C They are stored as a compressed binary blob (CBOR) within the parent's `_source` field only.
- D They are distributed across replica shards to balance the I/O load during parent traversal.
Answer: B. Block Join Architecture: Each nested object is stored as a separate, hidden Lucene document, but they are guaranteed to be physically adjacent to the root parent document within the same Lucene segment.
This adjacency allows Lucene to 'Join' without performing expensive network or disk seeks. However, the trade-off is update cost: because the parent and all nested children must stay together in a block, updating just one child requires re-indexing the entire parent-child hierarchy.
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?