Shard规划建议

一个index可以被分为多个shards，从而分布到不同的物理机上。shard的划分结果也会影响索引和查询速度。

每个分片都可以处理数据写入和查询请求，在设置索引分片数时，可从以下几个方面考虑：

• 每个shard包含的数据条数越多，查询性能会降低（建议1亿条左右，最多建议不超过4亿）。
• 建议单个分片保存的数据量在20GB左右，最大不超过30GB。
• 根据索引预计承载的最大数据容量和单个分片容量确定主分片个数。一般来说，预计存储的数据量越大，应当分配的shard越多，分布式查询的优势越明显。如果确认某个index的数据量非常少（如不到1GB），那么过多的分配shard，反而可能不如单shard的性能好
• 为了提升数据可靠性，合理设置副本分片个数，至少设置为1，如果集群的存储空间足够，推荐设置为2。
• 每个node可以支撑的shards个数是有限的，node是物理资源分配的对象，随着shards中数据的增大，shards中的数据在查询时被不断加载到内存，达到一定量时，将会把HeapSize耗尽，导致频繁GC，系统将不能正常工作。推荐1GB内存管理15个shard，以一个Elasticsearch实例内存最大28G为例，单实例管理的shard数保持在500以内。