Elasticsearch 写入性能优化，文章将从 写入路径、常见瓶颈、实用优化策略和实际案例 四个层面系统性输出，确保既有理论支撑，也贴合实际生产经验。
一、ES 写入路径简要回顾
写入流程核心环节如下：
客户端请求
→ 协调节点（Coordinating Node）
→ 主分片（Primary Shard）处理
→ 内存 buffer + translog
→ refresh（生成 segment）→ flush（落盘）
→ 复制到副本分片（Replica）
瓶颈可能出现在：分片路由、segment 频繁生成、磁盘 IO、网络复制。
二、常见写入性能瓶颈
| 类别 | 具体问题 |
|---|---|
| 分片问题 | 分片过多、分片过小、路由不均衡 |
| 硬件瓶颈 | 磁盘 IOPS 不足、CPU 打满、内存不足 |
| 写入频率 | refresh 太频繁、flush 太频繁 |
| mapping 问题 | 动态 mapping 开启、字段类型不规范 |
| 副本同步 | replica 写入压力大、网络瓶颈 |
| bulk 设置 | 批量请求过小或过大 |
三、实战可行的优化策略（分 6 类）
分片设计优化
| 建议 | 描述 |
|---|---|
| 降低分片数量 | 避免“每写一条，就有多个 shard 写入” |
| shard size 控制在 10~50GB | 太小增加管理开销，太大影响查询合并效率 |
| 使用 Index Lifecycle Management（ILM） | 滚动索引控制分片大小、数据冷热分离 |
写入频率调节
| 设置项 | 建议 |
|---|---|
refresh_interval | 设置为 30s（默认 1s，频繁生成 segment，I/O 开销大） |
number_of_replicas | 临时设置为 0，提升写入性能，写完再恢复 |
translog.durability | 设为 async可提升吞吐（默认 request更安全） |
批量写入优化
- 使用 bulk API，每次批量写入 515MB，或 5005000 条数据
- 避免单条写入（小文件写入压力大）
示例：
POST /_bulk
{ "index": { "_index": "log" } }
{ "message": "..." }
...
mapping 与字段优化
| 问题 | 建议 |
|---|---|
| 动态字段频繁生成 | 显式定义 mapping，关闭 dynamic: false |
| 高基数字段（如 IP、时间戳） | 避免 keyword 默认做 aggregatable，必要时禁用 doc_values |
禁用不需要的 _source、 _all、 _field_names | 减少磁盘存储与写入开销 |
硬件资源与系统调优
| 优化项 | 建议说明 |
|---|---|
| SSD 磁盘 | 提高 segment merge 性能 |
| JVM Heap 设置 | 设置为物理内存的 50%（最多不超过 32G） |
| OS 参数优化 | 调整 vm.max_map_count，ulimit |
| 网络带宽 & MTU | 保障副本同步、bulk 数据传输效率 |
Segment 合并调优
| 建议 | 原因 |
|---|---|
| 避免小 segment 过多 | 小 segment 多会导致频繁 merge、IO 高峰 |
| 控制 merge 策略 | 调整 merge.policy.*参数，避免低峰时暴力合并 |
使用 force_merge | 针对冷数据、历史索引压缩，提高查询效率 |
四、实战案例分享
某日志类索引每天写入量 5000 万条，最初写入延迟高达 2s+
问题排查：
- 每天创建新索引但 shard=5，副本=1 → 实际每天 10 shard 写入
- 每 1s 自动 refresh → segment 暴增
- 使用单条写入方式，未用 bulk
优化方案：
| 项目 | 优化前 | 优化后 |
|---|---|---|
| refresh_interval | 1s | 30s |
| shard 数量 | 5 | 1 |
| 副本数量 | 1 | 0（写入阶段） |
| 写入方式 | 单条 | bulk（5000 条/次） |
效果：
- 写入吞吐提升 4 倍
- CPU 降低 30%，磁盘 IO 明显下降
- 写入延迟控制在 100~200ms 内
五、总结
写入性能优化的核心是 减少磁盘操作频率（segment）、合理规划分片、批量写入、mapping 明确、系统资源保障。优化前必须明确瓶颈点，再对症下药逐步调整，切忌一刀切参数。
