Bulk 批量写入是什么
批量写入接口用 NDJSON 格式：一行动作元数据、一行文档内容，成对出现。它把多次写入合并为一次请求，显著降低网络与协调开销。批量大小直接影响效率——太小浪费请求开销，过大则增加内存占用与失败重试成本，需要按实际情况调优。
基本信息
| 接口 | POST /_bulk（或 /<index>/_bulk） |
|---|---|
| 格式 | NDJSON，每行一个 JSON |
| 动作类型 | index / create / update / delete |
| 注意事项 | 末行也要有换行符 |
| 失败处理 | 响应里的 errors 字段逐条标识 |
| 批量大小 | 常见 5-15MB 或数千条起步实测调优 |
典型使用场景
- 日志写入：把一批日志一次性提交，降低请求数
- 数据迁移或回填：从外部系统批量导入历史数据
- 批量更新文档字段（update 动作）
- 批量删除过期文档（delete 动作）
- 压测时用不同批量大小对比吞吐，找到更优取值
- 写入失败后根据响应逐条重试，避免整批重发
批量写入示例
批量写入示例
POST /_bulk
{ "index": { "_index": "logs-app", "_id": "1" } }
{ "@timestamp": "2026-10-12T10:00:00Z", "level": "error", "msg": "upstream timeout" }
{ "index": { "_index": "logs-app" } }
{ "@timestamp": "2026-10-12T10:00:01Z", "level": "info", "msg": "request done" }
# 注意：每行以换行结尾，末行也要有换行动作类型
| 动作 | 含义 | 使用要点 |
|---|---|---|
| index | 写入或覆盖 | 已有 _id 时按版本覆盖 |
| create | 仅新建 | 已存在则报错，适合防重复 |
| update | 局部更新 | 可配合 doc 或脚本 |
| delete | 删除 | 只需动作行，无文档行 |
批量建议 5-15MB/批或数千条/批起步实测调优；失败条目看响应里的 errors 字段逐条核对，而不是整批重发。
批量接口返回 200 不代表全部成功：需要解析响应里每个条目的 status，部分失败在 200 响应里很常见。
文档 ID 的常见做法是交给 Elasticsearch 自动生成，避免多写入方手工编号造成冲突；只有在需要幂等覆盖时才显式指定 _id。
批量请求会占用协调节点与数据节点的内存，集群繁忙时大批量会放大影响，必要时降低批量大小或错峰执行。