参考文档
https://www.elastic.co/guide/en/elasticsearch/reference/7.11/docs-bulk.html#bulk-api-request-body
在单个API调用中执行多个索引或删除操作。减少网络请求开销，提高索引速度。
API请求方式如下图所示：
比如以下例子，一个请求中包含index、delete、create、update四个操作
Request body
请求正文包含创建，删除，索引和更新操作以及它们关联的源数据列表。
create 如果文档不存在，在es中索引指定的文档信息
_index：当API路径中的未指定时，此参数必填
_id: 文档的id，如果未指定es回自动生成一个ID
delete从索引中删除指定的文档
_index：当API路径中的未指定时，此参数必填
_id: 文档的id，此参数必须的
index索引指定的文档。如果文档存在，则替换文档并递增版本。第二行必须包含要索引的源数据。
_index：当API路径中的未指定时，此参数必填
_id: 文档的id，如果未指定es回自动生成一个ID
update执行部分文档更新。第二行必须包含部分文档和更新选项。
_index：当API路径中的未指定时，此参数必填
_id: 文档的id，此参数必须的
doc: 索引的部分文档。更新操作所需。
fileds:文档的字段
detect_noop:默认值为true,默认情况下只有原来的source和新的source存在不同的字段情况下才会重建索引，如果一模一样是不会触发重建索引的，如果将detect_noop=false不管内容有没有变化都会重建索引，这一点可以通过version的值的变化来查看是否重建索引。
使用retry_on_conflict参数可以指定当文档冲突时，尝试更新的次数
update操作支持部分文档更新，Upsert，doc_as_upsert，script，params（for脚本），lang（for脚本）和_source。
几种方式可参照以下例子
curl-XPOST-uundefined:$ESPASS"localhost:9200/_bulk?pretty"-H'Content-Type: application/json'-d'#部分文档更新{ "update" : {"_id" : "1", "_index" : "index1", "retry_on_conflict" : 3} } { "doc" : {"field" : "value"} } #支持脚本 upsert{ "update" : { "_id" : "0", "_index" : "index1", "retry_on_conflict" : 3} } { "script" : { "source": "ctx._source.counter += params.param1", "lang" : "painless", "params" : {"param1" : 1}}, "upsert" : {"counter" : 1}} #支撑doc_as_upsert 如果没有就创建，又就覆盖，source如果完全相同，默认不会执行任何操作{ "update" : {"_id" : "2", "_index" : "index1", "retry_on_conflict" : 3} } { "doc" : {"field" : "value"}, "doc_as_upsert" : true } #返回值显示_source信息{ "update" : {"_id" : "3", "_index" : "index1", "_source" : true} } { "doc" : {"field" : "value"} } #返回值显示_source信息{ "update" : {"_id" : "4", "_index" : "index1"} } { "doc" : {"field" : "value"}, "_source": true}
因为是单次请求，批量操作。多个操作中可能部分操作失败，当有操作失败时，返回信息如下所示：
其中errors=true代表有失败的操作，每个error代表失败操作的原因。
若仅需要返回有关失败操作的信息，可使用Filter_Path查询参数。
返回结果如下图所示
批量操作，文档数量的设置
整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。 批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。 但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。
幸运的是，很容易找到这个最佳点：通过批量索引典型文档，并不断增加批量大小进行尝试。 当性能开始下降，那么你的批量大小就太大了。一个好的办法是开始时将 1,000 到 5,000 个文档作为一个批次, 如果你的文档非常大，那么就减少批量的文档个数。
密切关注你的批量请求的物理大小往往非常有用，一千个 1KB 的文档是完全不同于一千个 1MB 文档所占的物理大小。 一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。
