如何优化 Elasticsearch 的写入性能（Indexing Performance）？

知识点图片

优化 Elasticsearch (ES) 的写入性能（Indexing Performance）是一个系统工程，涉及客户端策略、索引设置、集群配置以及硬件层面。

以下是按优先级和影响程度分类的优化指南：

1. 客户端策略优化 (Client-side)

这是最容易实施且效果最明显的优化手段。

使用 Bulk API (批量写入)
- 原理：减少网络开销和 HTTP 请求头的解析时间，减少 Lucene 的 commit/flush 次数。
- 建议：不要单条写入。一个 Bulk 请求的大小建议在 5MB ~ 15MB 之间。具体的条数取决于单条数据的大小（通常几千条）。可以通过逐步增加大小测试吞吐量瓶颈。
多线程/多进程并发写入
- 原理：ES 是分布式的，单线程无法压榨集群性能。
- 建议：使用多线程向集群发送 Bulk 请求。观察集群的 CPU 和 I/O 使用率，直到达到瓶颈。
使用自动生成的 ID
- 原理：如果你指定 ID（如 PUT /index/_doc/123），ES 必须先查询该 ID 是否存在以判断是更新还是插入（Check-then-Update）。
- 建议：如果业务允许，让 ES 自动生成 ID（Post 请求不带 ID），这样 ES 可以直接追加写入，跳过版本检查，性能更好。

2. 索引设置优化 (Index Settings)

这些设置通常在创建索引模板（Index Template）时配置。

调整刷新间隔 (refresh_interval)
- 默认：1s（数据写入 1 秒后可被搜索）。
- 问题：频繁的 refresh 会生成大量小的 Segment，导致频繁的 Merge，消耗大量 CPU 和 I/O。
- 建议：如果是海量数据导入，设置为 -1（禁止刷新）或 30s / 60s。导入完成后再改回默认值。
- 注意：这会牺牲数据的实时可见性。
初始导入时将副本数 (number_of_replicas) 设为 0
- 原理：写入副本需要网络传输和重复的索引构建过程。
- 建议：在大批量初始化数据时，将副本设为 0。写入完成后，再将副本数改回 1 或更多，利用 ES 的恢复机制复制数据（直接复制文件比重复构建索引快得多）。
优化 Translog 设置
- 默认：request（每次请求都 fsync 落盘，保证数据不丢）。
- 建议：设置为 async，并增加 flush 阈值。
json
```
"index.translog.durability": "async",
"index.translog.sync_interval": "5s" // 或者更大
```
- 风险：节点宕机可能会丢失最近几秒的数据。

3. Mapping 与数据结构优化

静态 Mapping (Explicit Mapping)
- 建议：避免使用动态 Mapping（Dynamic Mapping）。ES 自动推断类型可能不准确且有开销。手动定义 Mapping 可以精简字段。
减少不必要的字段索引
- index: false：如果字段只需要存储（用于展示）不需要搜索，设置为 false。
- doc_values: false：如果字段不需要排序、聚合或脚本访问，设置为 false。
- norms: false：如果字段不需要打分（Scoring），设置为 false（节省内存和磁盘）。
禁用 _source (谨慎使用)
- 如果不需要从 ES 中取回原始 JSON 数据，可以禁用 _source。但这会影响 Update、Reindex 等功能，通常不建议完全禁用，可以考虑包含特定字段。

4. 集群与节点配置 (Cluster & Node Settings)

加大索引缓冲区 (indices.memory.index_buffer_size)
- 原理：更大的 Buffer 意味着 Segment 更大，减少刷盘和 Merge 次数。
- 建议：默认是 JVM Heap 的 10%。如果你的节点主要用于重写入，可以调整为 20% ~ 30%。确保所有 Shard 的总 buffer 不超过 512MB (ES 限制)。
分片 (Shard) 数量策略
- 建议：
  - 分片数不要太多，也不要太少。
  - 单个分片大小建议在 30GB - 50GB 之间。
  - 确保分片能均匀分布在所有数据节点上。
Merge 策略
- ES 默认的 Merge 策略已经很优秀，通常不需要调整。但在极高吞吐场景下，可以关注 I/O 节流配置（虽然现在的版本 ES 会自动调节）。

5. 硬件与操作系统层面 (Hardware & OS)

使用 SSD (必须)
- ES 对磁盘 I/O 极其敏感。使用 NVMe SSD 是提升写入性能的最直接手段。
- 如果是机械硬盘，确保是 RAID 0（牺牲安全性换速度）。
禁用 Swap (必须)
- 内存交换会导致 GC 停顿剧增，严重拖慢写入。
- 操作：在 elasticsearch.yml 中设置 bootstrap.memory_lock: true，并在系统层面关闭 swap。
JVM Heap 内存设置
- 不要超过物理内存的 50%。
- 不要超过 31GB（为了使用 Compressed Oops 指针压缩）。
- 留一半内存给操作系统的 FileSystem Cache，这对于 Lucene 的性能至关重要。

总结：优化清单 (Checklist)

如果你正在进行一次海量历史数据迁移，推荐的操作步骤如下：

硬件：确保 SSD，关闭 Swap。
配置：indices.memory.index_buffer_size: 20%。

索引设置：

json

PUT /my_index
{
  "settings": {
    "number_of_shards": 6,  // 根据数据量定
    "number_of_replicas": 0, // 暂时设为0
    "refresh_interval": "-1", // 暂时关闭刷新
    "index.translog.durability": "async"
  },
  "mappings": { ... } // 显式指定 Mapping
}

客户端：使用 Bulk API，多线程并发写入，使用自动生成 ID。
写入完成后：
- 将 refresh_interval 改回 1s。
- 将 number_of_replicas 改回 1。
- 执行 POST /my_index/_forcemerge?max_num_segments=1 (可选，优化后续搜索性能)。

播面