OpenSearch splitsindices intoshards. Each shard stores a subset of alldocuments in an index.

1. Shard sizes should be between10–50 GB per shard, 10–30 GB for workloads prioritizing low latency (e.g. search workloads), or between 30–50GB (e.g. logs workloads).

2. Estimate the total size of the data you plan to store in the index, decide on a shard size based on the rule above, and calculate the number ofprimary shards:ingested_data_size/shard_size.

3. The number and size of shards you set for an index corresponds to the size of an index, OpenSearchdefaults toone primary andone replica shard, for a total of two shards per index.

4. Shardcount issecondary to shardsize.

5. Shardsize impacts both search latency and write performance, toomany small shards willexhaust thememory (JVM Heap), and toofew large shards prevent OpenSearch from properlydistributing requests. The JVM heap size should be based on the available RAM: SetXms andXmx to the same value, and no more than50% of yourtotal memory.

6. Forfast indexing (ingestion), you need asmany shards as possible; forfast searching, it is better to have asfew shards as possible.

7. Number of shards for index: you should have at least 1 shard per data node, ideally try to make theindex shard count an even multiple of the data node count.

🛠️ Last, here's a simpleOpenSearch calculator for shard sizing.