分片大小设计——sizing shards

每个索引都是由分片组成的，可能是一个可能是多个，每个分片还可能有对应的副本，以便应对硬件故障。

Elasticsearch 中存储的最小单元也是分片，一个分片实际上是一个完整的 Lucene 索引。

单个节点上可以存储的数据量是有限的，因此可以通过添加节点和增加索引的分片数增加可存储容量。

由于分片的数量是一个静态配置项，只可以在创建索引时指定分片数，因此在创建索引前必须小心的做好规划，设置一个合理的分片数。

如果设置过多的分片，在写入数据时，需要将数据划分到过多的分片，搜索时可能会导致集群对搜索的响应效率较低，在极端情况下甚至可能变得不稳定。

如果设置了过少的分片，可能随着数据量的增加，单个分片过大，在发生故障恢复时，可能会花费更长的时间（还可能导致集群各节点的磁盘占用水平不一致，有的磁盘占用率低，有的占用率高，随着业务发展，后期可能会经常触发分片重分配）。

分片可以移动但不可分割，数量不可以调整。因此在创建索引时，选择一个合理的分片数是很重要的。

除了站在单个索引的角度，还需要站在集群的角度考虑，例如集群的容量，某个节点的容量，单个节点最多可以持有多少个分片，等。

需要考虑的问题

搜索时每个分片一个线程

大部分的搜索都会命中多个分片。每个分片都会一个CPU线程上执行搜索。虽然一个分片上可以运行多个并发的搜索，但跨大量分片的搜索可能会耗尽节点的搜索线程池。这可能导致吞吐量低和搜索速度慢。

每个索引和分片都有开销

每个索引和分片都会占用一定的内存和CPU资源。大部分情况下，一些大分片比很多小分片占用的资源更少。

分片的资源占用主要是其对应的分段。每个分片都对应着一些分段，用于存储索引数据。为了能够更快的检索，Elasticsearch将分段的元数据存储于JVM的堆内存中。随着分片变大，它的分段会合并为更大的分段，分段数量减少，意味着更少的元数据存在于JVM堆中。

每个映射的字段也会带来一些内存和磁盘的开销。默认情况下，Elasticsearch会为索引的每个文档的每个字段的创建映射，也可以关闭。

Elasticsearch自动平衡分片的存储

集群的节点被到数据层中。Elasticsearch尝试将索引的分片分布在尽可能多的节点上。当添加新节点或节点故障时，Elasticsearch会自动在其余节点上重新平衡索引的分片。

最佳实践

分片大小保持在10GB-50GB之间

大的分片在故障恢复时会占用较长的时间。当某个节点发生故障时，elasticsearch会根据剩余节点的数据自动的重新平衡分片。恢复进程通常是在网络之间拷贝分片的内容，因此一个100GB的分片会比50GB的分片花费更多的时间。相比之下，小分片的开销更大，搜索效率也更低。搜索50个1GB分片将比搜索一个包含相同数据的50GB分片占用更多资源。

分片的大小并没有强制的限制。但经验值是10-50GB之间的分片通常在日志和时间序列的数据流索引上表现更好。

每GB堆内存对应少于20个分片

数据节点可以容纳的分片数与节点的堆内存成比例。例如，具有30GB堆内存的节点最多应该有600个分片。越是低于此比例，就越能保持节点性能。如果发现节点超过每GB 20个以上的分片，请考虑添加另一个节点。

避免节成为热点

如果分配给特定节点的分片太多，该节点可能会成为热点。例如，如果单个节点包含的分片太多，索引量太大，则该节点可能会出现问题。

总结

站在索引的角度，我们在创建索引前要合理的设定分片数

• 评估数据量大小
• 保持每个分片在10-50GB之间

站在集群的角度，在使用搭建或者购买集群，选定配置时，需要先规划好，集群的使用负载，评估出分片数

• 单节点分片数 <= 堆内存 * 20

另外，生产环境，还可以参照阿里云提供的监控，对索引和集群做好监控，根据慢写和慢查，即时发现不合理的分片配置，即时纠正

参考

• 可以参考官方文档推荐用法

https://www.elastic.co/guide/en/elasticsearch/reference/8.2/size-your-shards.html#size-your-shards

• 阿里云 Elasticsearch 集群监控：

https://help.aliyun.com/document_detail/137967.html#section-sb4-bow-10y