Elasticsearch hard
Keyword fields use 'Doc Values' for sorting and aggregations. Where do these structures primarily reside for performance?
- A Directly inside the JVM Heap to minimize garbage collection latency.
- B On disk (Columnar Store), but they are designed to be mapped into memory by the Operating System's Filesystem Cache (Off-Heap).
- C In a specialized memory region managed by the Master node to ensure consistency.
- D Inside the CPU's L3 cache using specialized AVX-512 instructions.
Answer: B. On disk (Columnar Store), but they are designed to be mapped into memory by the Operating System's Filesystem Cache (Off-Heap).
This is why you don't give 100% of RAM to the JVM. By leaving 50% for the OS, Elasticsearch can 'read' files as if they were in RAM. Since they are 'Off-Heap', they don't cause Java Garbage Collection pauses, allowing Elasticsearch to handle petabytes of data without crashing the JVM.
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?