Elasticsearch medium
When bulk indexing, increasing the `refresh_interval` helps ingestion speed. What is the technical mechanism at play?
- A It temporary disables the Master node's ability to check for shard health.
- B Reduced I/O: It allows Elasticsearch to batch more documents into a single Lucene segment before writing it to disk. This reduces the frequency of small segment flushes and the subsequent 'Merge' overhead.
- C It disables the encryption-at-rest for the incoming batch.
- D It allows the cluster to bypass the JVM Heap and write directly to system memory.
Answer: B. Reduced I/O: It allows Elasticsearch to batch more documents into a single Lucene segment before writing it to disk. This reduces the frequency of small segment flushes and the subsequent 'Merge' overhead.
Every 'Refresh' creates a new file on disk. Creating 1,000 files of 1MB is far more expensive than creating one file of 1GB. During heavy ingestion, you trade 'visibility' (latency until searchable) for 'throughput' (speed of writing) by increasing the interval from 1s to 30s or more.
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?