Elasticsearch 索引管理入门：分片与保留

发布时间:2025-12-19 10:39

## 场景 日志与检索类业务接入 Elasticsearch 后，最先撞上的两件事就是分片怎么定、旧索引怎么清。分片数在建索引时定死，后期只能重建，保留策略则决定磁盘什么时候被吃光。这两件事在架构初期想清楚，能省掉大量事后返工。 ## 步骤清单 日志类索引按天或按周滚动新建，单索引的分片数按体量估算：分片太小数量就多，集群的元数据负担上升；单个分片过大，迁移与恢复时间拉长。经验区间是单分片承载几十 GB 以内，日增几十 GB 的日志按天建索引、配三五个主分片比较从容。 ``` PUT logs-2025.06.01 { "settings": { "number_of_shards": 3, "number_of_replicas": 1 } } ``` 副本数按可用性需求定，单节点集群副本没有意义，多节点时一副本是常见起点。分片还有一个容易忽视的约束：分片数决定了一个索引能利用的并行度，查询密集的索引适当多分片能吃到更多节点的算力，写入密集的则要权衡索引本身的创建开销。 ## 验证 分片分布用集群健康接口看，状态为绿表示主副分片齐活，黄表示副本缺位。节点间分片是否均匀也要看，数据都压在一个节点上，集群的横向能力就是空谈。索引建好后灌入一天的真实数据，观察写入速率与查询延迟，不达标趁早调整，拖着不改成本只会更高。 ## 注意事项 保留策略交给索引生命周期管理：热索引留在高性能节点，过期的索引自动删除，磁盘占用长期平稳。策略生效的判据是磁盘曲线不再爬坡，而是随索引删除呈锯齿状稳定波动。别用删除文档的方式清日志，空间不立刻归还，删除整个索引才是正解。别名与实际索引名分离，写入与查询都走别名，滚动重建时不影响业务。顺云云服务器上跑小规模日志集群，磁盘按保留天数乘日增量预留两成余量，配合控制台的磁盘监控曲线，扩容时机一眼可辨。