Bulk API，能够在一个单一的API调用执行多项索引/删除操作。这可以大大提高索引速度。
该 REST API 端点/_bulk，它遵循JSON结构：
action_and_meta_data\n
optional_source\n
action_and_meta_data\n
optional_source\n
....
action_and_meta_data\n
optional_source\n
注意：数据的最终行必须以换行符结束\n。
可能的操作有 index，create，delete和 update， index 和 ``create期望在下一行的作为源，并与索引 API 有相同的语义。（如果文件具有相同的索引和类型的文件已经存在，就会创建失败，必要时候而索引回添加或替换文件）。delete不会作为下一行的源，并与 delete API 中具有相同的语义。update 是希望部分文档，upsert 和脚本及其选项能够在下一行指定。
如果提供的文本文件输入到 curl，必须使用 --data-binary的标志，而不是 -d。后者不保留换行符。例：
$ cat requests
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
$ curl -s -XPOST localhost:9200/_bulk --data-binary "@requests"; echo
{"took":7, "errors": false, "items":[{"index":{"_index":"test","_type":"type1","_id":"1","_version":1,"result":"created","forced_refresh":false}}]}
因为这种格式使用 \n 作为分隔符，请确保 JSON action 和 source 没有被打印。这里是一个正确的 bulk 命令使用的例子：
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_type" : "type1", "_id" : "2" } }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "index1"} }
{ "doc" : {"field2" : "value2"} }
在上面的例子中更新的 doc是不完整的文件，将与已存储的文件进行合并。
端点是 /_bulk，/{index}/_bulk和{index}/{type}/_bulk。当提供索引或索引/类型时，它们将在 bulk 对象中使用默认值。
对格式的注释。这里的想法是使该处理尽可能快。由于一些 action 将被重定向到其它分片或在其他节点上，只有 action_meta_data被接收端被解析。
使用此协议应尽量努力做到在客户端使用，并尽可能减少缓存。
针对 bulk action 的响应是一个大的 Json 结构，包含着每个 action 执行后的结果。单一的 action 故障不会影响其余的操作。
在一个单独的 bulk call 中没有正确的执行数目。你应该使用不同的设置实验来确定适合您的特定工作负载的最佳大小。
如果使用 HTTP API，请确保客户端不发送 HTTP 块，因为这会使得运行速度降低。
每个 bulk 对象使用 _version/ version 来显示使用的版本。它自动基于 _version映射跟随该索引/删除操作的行为。它还支持 version_type/ _version_type（见版本）
每个 bulk 对象使用 _routing/ routing 来显示 routing 值。它自动基于 _routing映射跟随该索引/删除操作的行为。
每个 bulk 对象使用 _parent/ parent 来显示 parent 值。它自动基于 _parent/_routing映射跟随该索引/删除操作的行为。
当创建 bulk call 时，您可以设置 wait_for_active_shards 参数，在开始 bulk 请求之前要求活跃分片副本的最低数量。请参见这里进一步的详细信息和使用示例。
控制当通过请求所做的更改是可见的。
当使用 update操作，_retry_on_conflict可以被用作在 action 本身，指定了在一个版本冲突的情况下多少次更新可以被重试。
更新 action 的负载，支持下列选项：doc（部分文档）upsert，doc_as_upsert，script，params（脚本）， lang（脚本）和_source。见更新文档的详细信息。更新 action 的Curl 例子如下：
{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "index1", "_retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"} }
{ "update" : { "_id" : "0", "_type" : "type1", "_index" : "index1", "_retry_on_conflict" : 3} }
{ "script" : { "inline": "ctx._source.counter += params.param1", "lang" : "painless", "params" : {"param1" : 1}}, "upsert" : {"counter" : 1}}
{ "update" : {"_id" : "2", "_type" : "type1", "_index" : "index1", "_retry_on_conflict" : 3} }
{ "doc" : {"field" : "value"}, "doc_as_upsert" : true }
{ "update" : {"_id" : "3", "_type" : "type1", "_index" : "index1", "_source" : true} }
{ "doc" : {"field" : "value"} }
{ "update" : {"_id" : "4", "_type" : "type1", "_index" : "index1"} }
{ "doc" : {"field" : "value"}, "_source": true}
见 URL-based access control