liveBook · Manning

Shard sizing

As explained in Elasticsearch in Action, Second Edition

Shard sizing is the process of selecting shard capacity and count based on data volume, growth, and node resources.

Shard sizing chooses how many primary shards an index needs and how much data each shard should hold. Start with expected data volume, including future growth, then check the heap memory and disk capacity available on the nodes that will host primaries and replicas. There is no universal shard count: validate a proposed design with sizing trials before treating it as a production configuration. section 3.2.4 section 14.3

A practical starting guideline is 25–40 GB per shard, while an often cited upper bound is 50 GB. Larger shards can exist, but their suitability depends on the workload and resources. Plan for roughly up to 20 shards per gigabyte of heap memory, and adjust JVM heap settings when the available machine memory permits it. section 3.2.4

Sizing a 500 GB movie index

If a movie index may grow to 500 GB, distribute its data across about 10–20 primary shards on multiple nodes. That puts the primary-shard target near the suggested range rather than placing the whole index on a few very large shards. Then add replicas for availability and read capacity, remembering that every replica is a full copy of its primary shard. section 3.2.4 section 14.0

Count replica storage as part of the cluster requirement, not as a minor overhead. For example, 10 primary shards sized at 50 GB require 500 GB; with two replicas per primary, 20 replica copies add 1,000 GB, for at least 1.5 TB before operational headroom. Reserve additional capacity for system indexes, in-memory structures, and other node operations. section 14.3.1

Figure 14.7 Memory sizing of a single index with 10 shards and 2 replicas

Use the capacity diagram to trace how 10 primary shards and two replicas per shard turn a 500 GB primary data set into a larger multi-node storage requirement. section 14.3.1

Size shards as part of cluster administration. More nodes let Elasticsearch spread shards across the cluster, while replicas can help relieve read-performance pressure. Revisit the plan as data volume, node resources, and availability needs change; initial sizing work avoids preventable operational problems later. section 3.2.4 section 14.0

How Elasticsearch in Action, Second Edition covers it

How deep it goes
Explains practical sizing guidelines and a single-index storage calculation, while directing conclusive choices to sizing trials.
Examples
Works through a 500 GB movies index and a five-node, 10-primary-shard cluster with two replicas per shard.
What it assumes
Teaches sizing from shard and replica storage needs while assuming awareness of Elasticsearch nodes, indexes, and heap memory.
What you can do after
Evaluate/understand a shard plan by estimating primary and replica capacity from projected data volume and node resources.
How it connects
Connects shard sizing with replicas, heap memory, JVM settings, cluster nodes, read performance, and horizontal scaling.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Elasticsearch in Action, Second Edition. The section links point to the parts of the book it draws on.