Elasticsearch Interview Self-Test: 8 ELK Questions & Answers Explained

This article presents a self‑test of eight typical Elasticsearch interview questions and supplies thorough answers, making it a practical study resource for candidates preparing for ELK‑related roles.

Q1 – Inverted Index vs. B+ Tree

An inverted index maps terms to the list of document IDs that contain them, enabling O(1) term lookup and fast multi‑term intersections. By contrast, a B+ tree requires tree traversal (O(log n)) for range or exact matches and cannot efficiently support full‑text, prefix, or fuzzy queries. The article illustrates the index structure with a term‑to‑doc‑IDs table and shows example queries such as error hitting documents 1 and 3 instantly.

Q2 – Determining Shard Count

Recommended shard size is 30‑50 GB. The number of shards is calculated as ceil(total_index_size / 50GB). Examples: 1 TB of logs kept 15 days → a single 15 GB index fits in one shard; a 1 TB index → 20 shards. Planning steps: estimate per‑index size, compute shards, ensure total shards ≤ nodes × 600. Over‑sharding leads to high memory, file‑handle usage, slower queries, and longer recovery; under‑sharding causes large segments, write bottlenecks, and limited horizontal scaling. Once set, shard count cannot be changed without reindexing (shrink, split, or full reindex).

Q3 – ILM Hot‑Warm‑Cold‑Delete Lifecycle

ILM automates index lifecycle:

hot : rollover when size ≥ 50 GB, age ≥ 1 day, or docs ≥ 100 M; writes go through an alias.

warm : after 7 days, forcemerge to 1 segment, set priority 50, allocate one replica.

cold : after 21 days, set priority 0 and replicas 0 to save disk and CPU.

delete : after 30 days, delete the index.

The article provides a full ILM policy JSON and explains why replicas are removed in the cold phase (disk savings, limited node resources, data can be rebuilt from snapshots).

Q4 – Dynamic Templates

Dynamic templates control mapping of unknown fields. The example maps all string fields to keyword with ignore_above: 256, preventing field explosion and reducing storage. It also shows how to set total field limits and provides best‑practice steps: explicitly define core fields, use dynamic templates for the rest, and limit total_fields.limit.

Q5 – Logstash vs. Ingest Pipeline vs. Filebeat Processor

A comparison table evaluates deployment location, resource usage, processing capability, plugin richness, and suitable scenarios. Recommendations:

Simple JSON logs → Filebeat Processor.

Need GeoIP or date parsing → Ingest Pipeline.

Complex filtering, Kafka buffering, multiple inputs/outputs → Logstash.

The article lists configuration snippets for each component and outlines their pros and cons.

Q6 – Sample Query and Context Difference

Provides a DSL query that fetches the top‑10 logger names for ERROR logs in the last hour, using size:0 and a bool filter. It explains the difference between query and filter contexts: filter does not compute _score, is cacheable, and is faster; query computes relevance scores. Example queries for both contexts and a performance‑focused combined query are shown.

Q7 – Scaling from 1 GB/day to 1 TB/day

Describes a full optimization plan:

Capacity planning : calculate required storage (≈ 94 TB) and node specs for master, hot, warm, and cold data.

Write‑side tuning : increase refresh_interval to 30 s, set replicas to 0 during bulk load, raise bulk_max_size, increase workers, enlarge index buffer, raise translog.flush_threshold_size, enable compression.

Filebeat tuning : more workers, larger bulk size, compression level 5.

ILM : keep hot indices ≤ 50 GB.

Query tuning : narrow time ranges, use filter context, aggregate on keyword fields, avoid deep pagination, use routing, force‑merge cold data.

Field governance : limit total_fields.limit, use dynamic templates, drop unused fields.

Shard strategy : 30‑50 GB per shard, per‑day indices, ≤ 600 shards per node.

Cluster architecture : separate master, hot, warm, cold, and coordinating nodes.

JVM tuning : 31 GB heap, G1GC, pause target 200 ms.

Monitoring : set alerts for cluster health, disk usage, JVM heap, write rejections, query latency, pending tasks.

Resulting improvements: write rejections drop to zero, query latency from 30 s to 2 s, disk usage from 90 % to 60 %.

Q8 – High‑Availability Deployment

Recommends an architecture with three master nodes (odd count for quorum), role‑separated data nodes (hot, warm, cold), and coordinating nodes. Uses Elasticsearch awareness attributes to spread shards across availability zones, forcing replicas to different zones. Provides configuration snippets for master, data, and coordinating nodes, explains why an odd number of masters prevents split‑brain scenarios, and shows validation steps (node failure simulation, health check, data integrity). Also covers replica strategies per ILM phase and additional HA measures such as snapshots, cross‑cluster replication, load balancers, and client retries.

All sections reference the original “ELK全解析” series and official Elasticsearch documentation.