Elasticsearch hard
Retrieving a document by ID (`GET /idx/_doc/1`) is considered 'Real-Time', whereas a query (`GET /idx/_search`) is 'Near Real-Time'. Why?
- A GET-by-ID is routed directly to the Master node's in-memory routing table.
- B The GET API synchronously checks the Transaction Log (Translog) for the most recent version of a document if it has not yet been flushed/refreshed into a searchable Lucene segment.
- C Search queries require a cluster-wide lock, while GET-by-ID does not.
- D GET-by-ID uses UDP for faster transmission than the HTTP-based search API.
Answer: B. The GET API synchronously checks the Transaction Log (Translog) for the most recent version of a document if it has not yet been flushed/refreshed into a searchable Lucene segment.
This is a key architectural feature. To ensure 'Read-Your-Writes' for specific record updates, the GET API scans the unstructured Translog if the document isn't in a segment yet. Full-color search cannot do this because scanning the Translog for arbitrary query matches would be prohibitively slow.
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?