做一个简单的记录，以便自己后续查找
一、环境要求
- ElasticSearch 7.3.0
- Kibana 7.3.0
二、详情
ElasticSearch 的 Bulk API 可以批量进行索引或者删除等操作，可以显著的提高索引的速度
其格式如下：
action_and_meta_data
optional_source
action_and_meta_data
optional_source
....
action_and_meta_data
optional_source
注意点: 每一行必须以换行符( )结尾，包括最后一行
action_and_meta_data 指定哪个文档做什么操作：
- action 必须是 create、index、update、delete 中的一个
- meta_data 指定文档的 _index、_id
optional_source 指定需要操作的数据。
比如我们需要删除一部电影，同时创建一部电影
POST /_bulk {"delete":{"_index":"movie", "_id": "2"}} {"index": {"_index":"movie", "_id":"1"}} {"title": "Saving Christmas", "year": 2014}
如果批量操作针对的是同一个index，此时我们不需要重复指定该index，比如上面的语句改为：
POST /movie/_bulk {"delete":{"_id": "2"}} {"index": {"_id":"1"}} {"title": "Saving Christmas", "year": 2014}
三、Bulk API 文档的多大合适
整个批量请求都需要由接收到请求的节点加载到内存中，因此该请求越大，其他请求所能获得的内存就越少。 批量请求的大小有一个最佳值，大于这个值，性能将不再提升，甚至会下降。 但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。
幸运的是，很容易找到这个 最佳点 ：通过批量索引典型文档，并不断增加批量大小进行尝试。 当性能开始下降，那么你的批量大小就太大了。一个好的办法是开始时将 1,000 到 5,000 个文档作为一个批次, 如果你的文档非常大，那么就减少批量的文档个数。
密切关注你的批量请求的物理大小往往非常有用，一千个 1KB 的文档是完全不同于一千个 1MB 文档所占的物理大小。 一个好的批量大小在开始处理后所占用的物理大小约为 5-15 MB。