Elasticsearch 集群规格和容量规划¶

存储容量规划¶

影响 Elasticsearch 服务存储容量的主要因数：

副本数量：副本有利于增加数据的可靠性，但同时会增加存储成本。默认和建议的副本数为 1。
内部任务开销：Elasticsearch 用于 segment 合并、ES Translog、日志，保留约 20% 的磁盘空间。
索引开销：通常比源数据大 10%，可以使用 _cat/indices?v API 和 pri.store.size 值计算确切的开销。
操作系统预留：默认情况下，Linux 将保留 5% 的磁盘空间，给 root 用户用于关键流程处理、系统恢复、防止磁盘碎片化问题。

公式¶

完整公式	简化版本
源数据 * (1 + 副本数量) * ( 1 + 索引开销) / (1 - Linux 预留空间) / （1 - 内部开销） = 最小存储要求	源数据 * （1 + 副本数量）* 1.45 = 最小存储要求

如果有 500G 数据存储并且需要一个副本，则最低存储要求更接近 500 * 2 * 1.1 / 0.95 / 0.8 = 1.5T.

集群配置¶

在生产环境部署推荐配置：尽量一个节点只承担一个角色。不同节点所需要的计算资源不一样。不同角色分离后，可以按需扩展互不影响。

集群最大节点数 = 单节点 CPU * 5
单节点磁盘最大容量
- 搜索类场景：单节点磁盘最大容量 = 单节点内存大小（GB）* 10。
- 日志类等场景：单节点磁盘最大容量 = 单节点内存大小（GB）* 50。

配置	最大节点数	单节点磁盘最大容量 (查询)	单节点磁盘最大容量 (日志)
4 核 16G	20	160 GB	800 GB
8 核 32G	40	320 GB	1.5 TB
16 核 64G	80	640 GB	2 TB

分片数量规划¶

适用场景：

日志类，写入频繁，查询较少，单个分片 30G 左右
搜索类，写入少，查询频繁，单个分片不超过 20G

每个 Elasticsearch 索引被分为多个分片，数据按哈希算法打散到不同的分片中。由于索引分片的数量影响读写性能和故障恢复速度，建议提前规划。

分片使用概要¶

Elasticsearch 在 7.x 版本中，每个索引默认为 1 个主分片和 1 个副本分片
在单节点上，7.x 版本最大分片数量为 1000
单个分片大小尽量保持在 10-50G 之间为最佳体验，一般推荐在 30G 左右
- 分片过大可能使 Elasticsearch 的故障恢复速度变慢
- 分片过小可能导致非常多的分片，因为每个分片会使用占用一些 CPU 和内存，从而导致读写性能和内存不足的问题。
当分片数量超过数据节点数量时，建议分片数量接近数据节点的整数倍，便于将分片均匀的分布到数据节点中。
对日志场景，建议启用 ILM 功能。在发现分片大小不合理时，通过该功能及时调整分片数量。

索引分片资源占用¶

每个索引和每个分片都需要一些内存和 CPU 资源。在大多数情况下，一小组大分片比许多小分片使用更少的资源。

段在分片的资源使用中起着重要作用。大多数分片包含几个段，用于存储其索引数据。 Elasticsearch 将段元数据保存在 JVM 堆内存中，以便可以快速检索它以进行搜索。随着分片的增长，它的段被合并成更少、更大的段。这减少了段的数量，这意味着更少的元数据保存在堆内存中。

为了减少索引数量并避免造成过大且无序的映射，可以考虑在同一索引中存储类似结构的数据，而不要基于数据来源将数据分到不同的索引中。很重要的一点是在索引/分片的数量和每个单独索引的映射大小之间实现良好平衡。由于集群状态会加载到每个节点（包括主节点）上的堆内存中，而且堆内存大小与索引数量以及单个索引和分片中的字段数成正比关系，所以还需要同时监测主节点上的堆内存使用量并确保其大小适宜，这一点很重要。

分片过小会导致段过小，进而致使开销增加。您要尽量将分片的平均大小控制在至少几 GB 到几十 GB 之间。对时序型数据用例而言，分片大小通常介于 20GB 至 40GB 之间。

由于单个分片的开销取决于段数量和段大小，所以通过 forcemerge 操作强制将较小的段合并为较大的段能够减少开销并改善查询性能。理想状况下，应当在索引内再无数据写入时完成此操作。请注意：这是一个极其耗费资源的操作，所以应该在非高峰时段进行。

每个节点上可以存储的分片数量与可用的堆内存大小成正比关系，但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则：确保对于节点上已配置的每个 GB，将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。一般而言，这可以帮助集群保持良好的运行状态。

更多信息，请参考：

分片计算公式¶

(元数据 + 增长空间) * (1 + 索引开销) / 所需的分片大小 = 主分片的大约数量

假设有 80GiB 的数据。希望将每个分片保持在 30GiB 左右。因此，您的分片数量应大约为 80 * 1.1 / 30 = 3

如何管理分片¶

使用索引生命周期管理（ILM）自动管理索引，管理策略如下：

根据索引大小，自动 rollover
根据索引创建时间，自动 rollover
根据文档数量，自动 rollover

索引生命周期执行策略，默认每 10 分钟执行一次，可以通过修改 indices.lifecycle.poll_interval 参数来控制检查频率。