ES 系列 #04：ES 写入最佳实践

从 Mapping 设计、索引模板、Bulk 批写、Refresh/Translog 调优四个层面系统梳理 ES 写入性能优化手段，覆盖从"数据建模"到"参数配置"的全链路实践。

---

目录

章节	说明
Mapping 设计	字段类型选择、动态映射控制
索引模板与滚动策略	时序索引、冷热分离
Bulk 批量写入	批大小选择、自动 ID
Refresh 与 Translog 调优	降低刷盘频率提升吞吐
段合并策略	写入与合并的 Trade-off
副本与写入	副本数对写入的影响
性能基准参考	不同机型的写入 QPS 参考值

---

Mapping 设计

字段类型选择

场景	推荐类型	原因
精确匹配（ID、状态码）	keyword	term 查询性能比数值类型快 3-5 倍
全文检索	text	分词建倒排索引
数值仅做精确 term 查询	keyword	数字类型 term 查询性能差，CPU 占用高
数值需要范围查询或聚合	long / double	BKD 树结构更适合范围查询
不需要排序/聚合的字段	关闭 doc_values	节省磁盘和内存
不需要全文检索的字符串	关闭 index	不建倒排，节省存储

核心原则：不需要范围查询时优先用 keyword；需要范围查询时才用数值类型。ES 5.x 起数字类型 term 查询性能相比 2.x 下降约 80%，CPU 利用率飙升 30%+。

Schema 扁平化

• ES 不支持 JOIN，Schema 应尽量扁平，避免 nested 和 parent-child
  • nested 查询比普通查询慢 10 倍以上
  • parent-child 查询比普通查询慢 100 倍以上
• 将 join 逻辑放到应用层处理

关键 Mapping 参数

{
  "mappings": {
    "dynamic": "strict",
    "_source": {
      "enabled": true
    },
    "properties": {
      "id": { "type": "keyword" },
      "price": { "type": "double" },
      "name": {
        "type": "text",
        "fields": {
          "keyword": { "type": "keyword", "ignore_above": 256 }
        }
      },
      "tag": {
        "type": "keyword",
        "doc_values": false
      }
    }
  },
  "settings": {
    "index.mapping.total_fields.limit": 1000,
    "index.mapping.depth.limit": 20,
    "index.mapping.nested_fields.limit": 50
  }
}

参数	默认值	说明
dynamic: strict	-	禁止写入未定义字段，防止字段爆炸
total_fields.limit	1000	单索引最大字段数
depth.limit	20	嵌套对象最大深度
nested_fields.limit	50	nested 字段最大数量

_source 的作用与取舍

_source 是 ES 写入时单独保存的原始 JSON 副本，与倒排索引、Doc Values 并存，互相独立：

写入一条文档时，ES 同时构建：
  ├─ 倒排索引  → 用于搜索
  ├─ Doc Values → 用于排序/聚合
  └─ _source   → 存储原始 JSON，用于返回文档内容 / update / reindex / highlight

_source 在磁盘上以**压缩 JSON（LZ4）**存储，占索引总体积的 30%～50%。

_source: false 的影响

功能	是否依赖 _source
搜索命中（返回文档内容）	✅ 依赖，关闭后返回空
_update 部分字段更新	✅ 依赖，关闭后报错
reindex 跨索引迁移	✅ 依赖，关闭后无法迁移
highlight 高亮	✅ 依赖
搜索匹配本身（召回）	❌ 不依赖（走倒排索引）
排序/聚合	❌ 不依赖（走 Doc Values）

_source: false 几乎没有合适的使用场景——节省的存储空间换来的是一堆功能残废，且无法恢复（不存就是没了）。

真正有用的是 includes/excludes 裁剪：只存需要的字段，兼顾存储节省与功能完整：

"_source": {
  "includes": ["id", "name", "price", "status"],
  "excludes": ["raw_content", "embedding_vector"]
}

⚠️ 如需部分字段更新，必须保留 _source: true（或至少 includes 包含相关字段），否则 _update 请求会报错。

---

索引模板与滚动策略

什么时候用模板

• 数据量持续增长 → 必须使用模板，按时间周期（天/月/年）滚动创建索引
• 数据量固定 → 可以不用模板

按时间滚动的好处

• 单索引大小可控，便于后续数据清理和归档
• 历史冷数据可整索引迁移到冷集群（冷热分离）
• 小索引迁移成本低

分片大小规范

• 单个分片物理大小 不超过 40 GB（推荐 10-30 GB）
• 单个索引建议 不超过 200 GB
• 根据每日/每月数据增量决定滚动周期

索引别名

# 创建索引时绑定别名
PUT /orders-2024-01
{
  "aliases": {
    "orders": {}
  }
}

# 原子切换别名（零停机）
POST /_aliases
{
  "actions": [
    { "remove": { "index": "orders-2024-01", "alias": "orders" }},
    { "add":    { "index": "orders-2024-02", "alias": "orders" }}
  ]
}

⚠️ 别名绑定的索引不宜超过 20 个，否则查询需要遍历过多分片，影响性能。要定期解绑或清理历史索引。

---

写入优化

Bulk 批量写入

核心原则

• 永远用 Bulk 而非单条写入，Bulk 效率远高于单条
• 单次 Bulk 数据量控制在 5 MB ～ 15 MB，不超过 100 MB
• 逐步从 5 MB 增加，直到性能不再提升为止

自动 ID vs 自定义 ID

// 推荐：自动生成 ID，避免 Get-before-Write 查重
POST /my_index/_doc
{
  "field": "value"
}

// 不推荐（如无必要）：指定 ID 时 ES 需先查重
PUT /my_index/_doc/custom_id_123
{
  "field": "value"
}

使用自定义 ID 会触发写入前查重（Get-before-Write），增加额外开销，尽量使用 ES 自动生成的文档 ID。

Index Buffer 调优

# elasticsearch.yml
indices.memory.index_buffer_size: 15%

写入期间数据先缓存在 index buffer，适当增大此值可提高写入效率（默认 10%）。

---

Refresh 与 Translog 调优

Refresh 策略

ES 默认每 1 秒 refresh 一次（将内存数据刷到文件系统缓存），每次 refresh 产生一个新 segment。

# 对实时性要求不高的索引，延长 refresh 间隔
PUT /my_index/_settings
{
  "index": {
    "refresh_interval": "30s"
  }
}

# 大批量导入时，临时关闭 refresh
PUT /my_index/_settings
{
  "index.refresh_interval": "-1"
}
# 导入完成后恢复
PUT /my_index/_settings
{
  "index.refresh_interval": "1s"
}

Translog 异步策略

Translog 默认每次写入都同步刷盘（request 模式），改为异步可大幅提升写入吞吐：

PUT /my_index/_settings
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "60s"
}

参数	默认值	推荐值	说明
translog.durability	request	async	异步刷盘，提升吞吐
translog.sync_interval	5s	60s	刷盘间隔，可适当调大

⚠️ 异步模式下节点崩溃可能丢失最近 sync_interval 内的数据，非强一致性场景下才适用。

---

段合并策略

为什么要合并段

每次 refresh 产生一个新 segment，segment 过多会：

• 消耗大量文件句柄和内存
• 每次查询需遍历所有 segment，查询变慢
• delete 操作只是标记删除，合并时才真正释放空间

手动强制合并

# 对不再写入的历史只读索引执行强制合并，极大提升查询速度
POST /my_index/_forcemerge?max_num_segments=1

⚠️ 不要对正在写入的索引执行 forcemerge，会消耗大量 I/O，影响正常写入和查询。避免在高峰期执行。

提升段合并速度（SSD 场景）

PUT /_cluster/settings
{
  "persistent": {
    "indices.store.throttle.max_bytes_per_sec": "100mb"
  }
}

默认合并速度限制为 20 MB/s，SSD 可调高到 100 MB/s。

---

副本与写入

副本越多，写入越慢（每条数据需同步到所有副本节点）。

# 大批量导入前临时关闭副本
PUT /my_index/_settings
{
  "index.number_of_replicas": 0
}

# 导入完成后恢复
PUT /my_index/_settings
{
  "index.number_of_replicas": 1
}

关闭副本期间集群无容灾能力，仅适用于全量数据导入场景，增量写入不建议关闭副本。

---

性能基准参考

以下为简单写入场景、单节点压测参考值，复杂场景需自行压测。索引大小 50 GB，文档数 2 亿+，字段数 8 个。

机器类型	配置	单条写入 QPS	单条写入 avg(ms)	Bulk QPS（bulk=100）	Bulk avg(ms)
SSD（8C 16G）	VM/物理机	~500	10-13	~100	18-20
高性能 SSD（16C 32G）	-	~1000	9	~200	19

结论：

• Bulk 写入效率远高于单条写入
• 写入性能对 CPU 较为敏感，高 QPS 业务需要更好的 CPU
• 使用高性能 SSD 写入 QPS 可达普通机型的 2 倍

---

参考资料

• Elasticsearch - Tune for indexing speed
• Elasticsearch - Mapping parameters
• Elasticsearch - Size your shards