elasticsearch索引如何合理设计

Elasticsearch（ES）索引的合理设计，核心目标是写入性能、查询性能、存储成本、可维护性之间的平衡。下面从实践经验角度，系统性讲一下怎么设计才“合理”。

一、先明确使用场景（非常重要）

在设计前先问自己：

1. 写多还是读多？
   • 日志类：写多读少
   • 搜索类：读多写少
2. 数据是否有时效性？
   • 日志、监控：有（按时间）
   • 商品、用户：基本无
3. 查询方式是什么？
   • 关键词搜索
   • 聚合统计
   • 精确匹配
4. 数据规模？
   • 百万 / 千万 / 亿级

二、索引粒度设计（怎么拆索引）

1️⃣ 按时间拆分（最常用）

适合：日志、监控、行为数据

logs-2025-01
logs-2025-02

优点：

• 方便过期删除（delete index 成本极低）
• 热冷数据分离
• 查询范围可控

✅ 推荐：

• 天 / 周 / 月（看数据量）
• 单索引控制在 20–50GB

2️⃣ 按业务维度拆分

适合：业务差异大

order-index
user-index
product-index

避免：

• 一个索引塞所有类型数据（mapping 混乱）

3️⃣ 避免“一个索引搞定一切”

❌ 反例：

data-index（用户+订单+日志）

问题：

• mapping 复杂
• 查询慢
• 难以优化

三、Mapping 设计（最容易踩坑）

1️⃣ 明确字段类型（不要全 text）

❌ 错误：

{ "price": "text" }

✅ 正确：

{ "price": "scaled_float" }

2️⃣ 不需要分词就别分词

"username": {
  "type": "keyword"
}

text 字段：

• 占空间
• 写入慢
• 聚合慢

3️⃣ 禁用 _source（极端情况）

如果：

• 只写不读
• 或数据可重建

"_source": false

⚠️ 一般不推荐，调试会很难受

4️⃣ 合理使用 index: false

不用于搜索的字段：

"remark": {
  "type": "text",
  "index": false
}

四、分片（Shard）设计

1️⃣ 分片不是越多越好

经验值：

• 单分片 10–50GB
• 分片数 ≈ 数据总量 / 30GB

2️⃣ 写多场景

• 分片稍多（提高并发写入）
• 副本少（1）

3️⃣ 读多场景

• 副本多（1–2）
• 分片适中

4️⃣ 固定索引 vs 动态索引

• 固定：分片数一旦设定不能改
• 动态（rollover）：推荐 ✅

五、使用 Rollover + ILM（生产级方案）

✅ 强烈推荐

流程：

写 alias → 自动 rollover → 冷热分离 → 自动删除

好处：

• 不用人工管索引
• 性能稳定
• 存储可控

六、别名（Alias）一定要用

write-alias → logs-2025-01
read-alias → logs-*

好处：

• 无缝切换索引
• 查询不用关心底层

七、常见不合理设计（避坑）

❌ 单索引几百 GB
❌ 所有字段都是 text
❌ 分片数 = 节点数 × 很多
❌ 用 ES 当数据库（事务、强一致）
❌ 深度分页（from+size 超大）

八、一个“合理设计”的示例

日志系统

logs-write (alias)
logs-2025-01-01
logs-2025-01-02

ILM:
- hot: 1 replica
- warm: 0 replica
- delete: 30d

Mapping

• level: keyword
• message: text
• timestamp: date

总结一句话

ES 索引设计 = 按时间拆 + 精准 mapping + 合理分片 + 别名 + ILM

如果你愿意，可以告诉我：

• 数据量
• 查询场景
• 是否是日志 / 搜索 / 聚合

我可以直接帮你设计一套索引方案。