Elasticsearch 搜索系统实践：索引设计、分片规划与集群稳定性

Elasticsearch 和 OpenSearch 常被用于搜索、日志分析、指标检索和报表查询。它们查询能力强，接入简单，但如果把它当成普通数据库使用，很快会遇到分片过多、heap 压力、mapping 爆炸、写入抖动和查询拖垮集群的问题。

搜索系统的关键不是“能查到”，而是在数据增长、并发查询、冷热数据和故障恢复下仍然稳定。

Mapping 设计

Mapping 决定字段类型、分词方式和索引结构。动态 mapping 很方便，但生产环境不应完全依赖它。字段类型一旦不合适，后续修改通常需要重建索引。

常见原则：

• 精确匹配字段使用 keyword。
• 全文搜索字段使用 text 并配置 analyzer。
• 时间字段使用 date。
• 数值字段使用合适数值类型。
• 不需要搜索的字段关闭 indexing。
• 控制动态字段，避免 mapping 爆炸。

日志场景中最容易出现字段爆炸，例如把请求参数或 JSON payload 中的任意 key 都索引。字段数量过多会增加 heap 压力和集群状态负担。

分片规划

分片是 Elasticsearch 扩展和并行查询的基本单元。分片太大，恢复和迁移慢；分片太小，元数据和调度开销大。

时间序列数据建议按时间滚动索引，例如按天、周或大小 rollover。配合 ILM 管理生命周期，让热数据在高性能节点，冷数据在低成本节点。

分片规划要考虑：

• 每日写入量。
• 查询时间范围。
• 保留周期。
• 节点数量。
• 单分片大小。
• 故障恢复时间。

不要为每个小租户创建大量独立索引，除非有明确隔离需求。大量小索引会让集群状态膨胀。

写入路径

Elasticsearch 写入不是立即可搜索。refresh interval 决定新文档多久对搜索可见。默认近实时适合大多数场景，但高写入场景可以适当调大 refresh interval，提高吞吐。

批量写入应使用 bulk API，并控制批大小。批太小吞吐低，批太大会造成内存压力和失败重试成本。

写入高峰期关注：

• indexing latency。
• refresh time。
• merge time。
• rejected writes。
• translog size。
• disk IO。

查询治理

复杂查询可能消耗大量 CPU、heap 和磁盘 IO。生产中要限制高风险查询：

• 深分页。
• 大范围 wildcard。
• 高基数字段聚合。
• 无时间范围查询。
• script query。

深分页不要使用 from + size 翻到很深，建议使用 search_after 或 scroll。聚合查询要控制桶数量，避免一次请求生成海量 buckets。

Heap 与 JVM

Elasticsearch 依赖 JVM heap 管理元数据、缓存和查询结构。Heap 设置过小容易频繁 GC，过大可能影响文件系统缓存。通常建议 heap 不超过物理内存的一半，并注意压缩指针边界。

要监控：

• heap 使用率。
• GC 时间。
• fielddata。
• query cache。
• request cache。
• circuit breaker 触发。

频繁 circuit breaker 通常说明查询或聚合超出集群承载能力。

冷热分层

日志和搜索数据通常有明显冷热规律。最近数据查询多，历史数据查询少。可以使用热、温、冷节点分层，配合 ILM 自动迁移、压缩和删除。

典型生命周期：

1. Hot：高写入、高查询。
2. Warm：只读或低写入。
3. Cold：低频查询。
4. Delete：超过保留周期删除。

这能显著降低成本，也能避免热节点被历史数据占满。

高可用与备份

副本分片提供节点故障容忍，但不是备份。误删索引、错误更新、mapping 错误会被复制。生产必须配置 snapshot，将数据备份到对象存储或共享存储。

备份策略要验证恢复速度。对日志场景，可能只需要恢复部分时间范围；对搜索主索引，恢复时间可能直接影响业务。

总结

Elasticsearch 是搜索引擎，不是无限灵活的数据库。生产稳定性来自良好的 mapping、合理分片、受控查询、冷热分层和持续容量治理。它能让搜索和分析非常强大，但前提是团队尊重它的运行模型，而不是把所有数据和所有查询都丢进去。