ElasticSearch 7.x 不需要优化分片的数量了吗？

分片数还是需要自己控制的，我觉得默认调整为1的原因是大部分公司都是用es做日志的，并且按照天去分割，对于绝大部分小公司，一天日志量超过40G的较少，一个分片够用，并且分片过多也会导致集群缓慢，对于小公司就不需要调整这个，索引多了的时候性能也比之前好。这类的小公司肯定比大公司多的。大一点的公司都会根据自己的情况对整个集群做优化，分片到时候也会根据情况自行调整了。

使用 ILM 自动进行切分很方便，可以限制单个分片固定大小比如 30G。

分片（shard）：一个ES的index由多个shard组成，每个shard承载index的一部分数据。

副本（replica）：index也可以设定副本数（numberofreplicas），也就是同一个shard有多少个备份。对于查询压力较大的index，可以考虑提高副本数（numberofreplicas），通过多个副本均摊查询压力。

shard数量（numberofshards）设置过多或过低都会引发一些问题：shard数量过多，则批量写入/查询请求被分割为过多的子写入/查询，导致该index的写入、查询拒绝率上升；对于数据量较大的inex，当其shard数量过小时，无法充分利用节点资源，造成机器资源利用率不高 或 不均衡，影响写入/查询的效率。

对于每个index的shard数量，可以根据数据总量、写入压力、节点数量等综合考量后设定，然后根据数据增长状态定期检测下shard数量是否合理。

基础架构部数据库团队的推荐方案是：

对于数据量较小（100GB以下）的index，往往写入压力查询压力相对较低，一般设置3~5个shard，numberofreplicas设置为1即可（也就是一主一从，共两副本） 。

对于数据量较大（100GB以上）的index：

一般把单个shard的数据量控制在（20GB~50GB）

让index压力分摊至多个节点：可通过index.routing.allocation.totalshardsper_node参数，强制限定一个节点上该index的shard数量，让shard尽量分配到不同节点上

综合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个，就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index，分摊数据量，同时配合routing使用，降低每个查询需要访问的shard数量。