文章目录
前言
博主介绍：✌目前全网粉丝4W+，csdn博客专家、Java领域优质创作者，博客之星、阿里云平台优质作者、专注于Java后端技术领域。
涵盖技术内容：Java后端、大数据、算法、分布式微服务、中间件、前端、运维等。
博主所有博客文件目录索引：博客目录索引(持续更新)
CSDN搜索：长路
视频平台：b站-Coder长路
资料
es分为单机、集群部署模式
es中文站点：https://elastic.ac.cn/
分片容量计算：https://blog.csdn.net/hekuinumberone/article/details/145828769
阿里云资源规划：https://help.aliyun.com/zh/es/user-guide/evaluate-specifications-and-storage-capacity
磁盘容量
参考来源：https://jelinet.com/es/2020/06/01/ES容量预估最佳实践.html
影响ES磁盘空间的因素有以下几点：
- 副本数量。至少1个副本。
- 索引开销。通常比源数据大10% （_all等未计算）。
- 操作系统预留。操作系统默认会保留**5%**的文件系统供用户处理关键流程、系统恢复以及磁盘碎片等。
- ES内部开销。段合并、日志等内部操作，预留20%。
- 安全阈值。通常至少预留**15%**的安全阈值。
根据以上因素得到：最小磁盘总大小 = 源数据大小 * 3.4。
磁盘总大小 = 源数据 * (1 + 副本数量) * (1 + 索引开销) / (1 - 操作系统预留空间) / (1 - ES内部开销) / (1 - 安全阈值) = 源数据 * (1 + 副本数量) * 1.7 = 源数据 * 3.4
注意点：磁盘空间一般要预留15%，也就是磁盘空间不能>85%。
分片
官网：https://elastic.ac.cn/guide/en/elasticsearch/reference/current/size-your-shards.html
每个索引和每个分片都需要一些内存和 CPU 资源。在大多数情况下，一小组大分片使用的资源比许多小分片少。
市面方案：
分片容量
参考来源：https://blog.csdn.net/hekuinumberone/article/details/145828769
单分片建议容量：20-50GB（SSD场景）
· 小规格节点：不超过30GB
· 高规格节点：可扩展至50GB
· 超过80GB时聚合查询性能下降40%
推荐场景情况：
| 场景 | 节点规格 | 最优分片大小 | 性能表现 |
|---|---|---|---|
| 日志分析 | 16核/32GB | 30GB | 查询延迟50ms |
| 电商搜索 | 8核/16GB | 20-40GB | 聚合性能提升30% |
分片数量
参考来源：https://blog.csdn.net/hekuinumberone/article/details/145828769
精炼：
1、分片数尽量为数据节点数或者其整数倍。如 6 节点集群可设 6/12/18 分片【扩展分片，一般是原始分片的整数倍】
2、每个分片大小尽量在10-50GB左右。
3、官方建议一个GB jvm内存空间 <=20分片
5、在规划Elasticsearch分片时，必须基于主分片占用空间进行计算。副本分片仅作为冗余备份，不增加数据总量。
根据 Elastic 官方博客和阿里云文档的权威解释：
- 分片数无硬性限制 ：Elasticsearch 允许任意整数作为分片数（如 3、5、7 等），无需满足整数倍关系。
- 扩容场景建议：为保持节点间数据均衡，建议分片数等于数据节点数或其整数倍（如 6 节点集群可设 6/12/18 分片）。
- Split API 例外 ：使用
_splitAPI 扩容时，新分片数必须是原分片数的整数倍（如原 3 分片只能扩为 6、9 等）。
参考：
- 官方文档：https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
- 规格容量评估：https://help.aliyun.com/zh/es/user-guide/evaluate-specifications-and-storage-capacity
目前在索引社区在扩展性配置主要是：
1、Aim for shard sizes between 10GB and 50GB 【每一个分片大小10-50GB】
2、Aim for 20 shards or fewer per GB of heap memory【每分配一个GB jvm内存空间 <= 20个分片】
3、cluster.max_shards_per_node default 1000【单节点最大分片1000个】
4、集群合理的shard数控制在3K以内【集群总分片数尽量在3000内】
关于分片数量的权衡，不一定越大分片越好，当数据量小时，合理的少量分片数量（单分片20-50GB）规划效果会更啊后：
可扩展策略
滚动索引（Rollover） & 别名（Alias）
这是处理时序数据（如日志、搜索记录）的黄金标准。通过设置索引别名和滚动条件（如大小或
时间），当达到阈值时，系统会自动创建新索引，并将写入流量切换到新索引，而旧索引则变为只读。
冷热数据分层优化
该架构根据数据的访问频率，将其存储在不同性能和成本的硬件上，实现资源的最优利用。
•热数据（Hot）：最新、最常被查询的数据。应部署在高性能的SSD磁盘上，配置较多的主分片
以支持高并发写入和查询。
• 温数据（Warm）：较旧但仍有一定查询需求的数据。可迁移到成本较低的SAS磁盘，并通过
Shrink API压缩分片数量，减少资源占用。
• 冷数据（Cold）：很少被查询的归档数据。可进一步迁移到更低成本的存储，如SATA硬盘或对象
存储，并使用Force Merge合并段，提升查询效率。
索引生命周期ILM
ILM是实现冷热分层自动化的关键。通过预设策略，可以自动将索引从"热"阶段滚动到"温"、"冷"阶段，并最终在达到保留期限后自动删除。这极大地简化了运维工作。
类似logback的滚动策略：
- 当前索引满足定义的
max_primary_shard_size、max_age、max_docs或max_size阈值时，它会创建一个新的写入索引。当不再需要索引时，您可以使用 ILM 自动删除它并释放资源。
避免踩坑
关闭动态映射
参考文档：https://blog.csdn.net/hekuinumberone/article/details/145828769
某社交平台因未关闭动态映射，用户输入的特殊符号导致字段爆炸式增长，最终引发集群元数据内存溢出。解决方案：
- 生产环境必须设置dynamic: strict
- 通过ingest pipeline进行字段清洗和类型校验
json
PUT /financial_transactions {
"mappings": {
"dynamic": false, // 关闭动态映射
"properties": {
"txn_id": {"type": "keyword"},
"amount": {"type": "scaled_float", "scaling_factor": 100}, // 精确到分
"timestamp": {"type": "date", "format": "epoch_millis"}
}
}
}优化参考文档
1\]. Elasticsearch索引设计与分片策略深度优化-手记：https://blog.csdn.net/hekuinumberone/article/details/145828769 ## 资料获取 大家点赞、收藏、关注、评论啦\~ 精彩专栏推荐订阅：在下方专栏👇🏻 * [长路-文章目录汇总（算法、后端Java、前端、运维技术导航）](https://blog.csdn.net/cl939974883/category_11568291.html?spm=1001.2014.3001.5482)：博主所有博客导航索引汇总 * [开源项目Studio-Vue---校园工作室管理系统(含前后台，SpringBoot+Vue)](https://changlu.blog.csdn.net/article/details/125295334)：博主个人独立项目，包含详细部署上线视频，已开源 * [学习与生活-专栏](https://blog.csdn.net/cl939974883/category_10700595.html)：可以了解博主的学习历程 * [算法专栏](https://blog.csdn.net/cl939974883/category_11403550.html?spm=1001.2014.3001.5482)：算法收录 更多博客与资料可查看👇🏻获取联系方式👇🏻，🍅文末获取开发资源及更多资源博客获取🍅