Summary
Elasticsearch implements sharding natively: every index is divided into primary shards distributed across nodes, with replica shards providing redundancy. Sharding is not optional: all Elasticsearch data exists within a shard.
Evidence
- ·{'Every Elasticsearch index has a fixed primary shard count set at creation time (default': '1 in ES 7.x)'}
- ·Shards are distributed across nodes automatically by the cluster: no manual placement required
- ·Each shard is a fully functional Lucene index capable of serving queries independently
- ·Replica shards are allocated on different nodes than their primary: automatic failure tolerance
- ·Elasticsearch 7.x introduced ILM (Index Lifecycle Management) for automated shard management
Operational Context
- ·Shard count is immutable after index creation: the Shrink API or reindexing is required to change shard count
- ·Over-sharding is a common production mistake: each shard consumes ~50-100MB of JVM heap
- ·The recommended shard size is 10-50GB: calculate shard count from expected final index size
Tradeoffs
- ·Fixed shard count at creation requires capacity planning before data ingestion begins
- ·Cross-shard queries fan out to all shards and merge results on the coordinating node: too many shards add merge overhead
- ·Replica shards double storage and I/O for writes: fewer replicas during bulk indexing, restore after load
Evidence grounding
Grounded, 5 supporting itemsElasticsearch's sharding model is fundamental to its architecture, documented as a core concept in all official Elasticsearch documentation since version 1.0.