NOTE
Elasticsearch Performance Tuning
A workload-first approach to shard sizing, mappings, refresh, indexing, queries, caches, merges, and JVM/storage capacity.
This is a historical learning note and may contain outdated or incomplete understanding.
Start with workload evidence: indexing rate, query mix, latency percentiles, shard sizes/counts, heap pressure, disk I/O, merge time, cache behavior, and thread-pool rejections.
Common high-impact choices are appropriate shard count/size, correct field mappings, avoiding unnecessary analyzed/indexed fields, bulk indexing, sensible refresh frequency, query/filter design, and lifecycle rollover/retention.
More shards are not automatically faster; tiny shards add metadata/scheduling overhead, while very large shards can slow recovery. Tune JVM/storage only after fixing data-model/query/index architecture.