参考文档

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 -X POST -u undefined:$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。