基本语法
bulk操作和以往的普通请求格式有区别。不要格式化json,不然就不在同一行了,这个需要注意。
{ action: { metadata }}\n
{ request body }\n
{ action: { metadata }}\n
{ request body }\n
...
- { action: { metadata }} 代表批量操作的类型,可以是新增、删除或修改
- \n 是每行结尾必须填写的一个规范,每一行包括最后一行都要写,用于es的解析
- { request body } 是请求body,增加和修改操作需要,删除操作则不需要
批量操作的类型
action 必须是以下选项之一:
- create:如果文档不存在,那么就创建它。存在会报错。发生异常报错不会影响其他操作。
- index:创建一个新文档或者替换一个现有的文档。
- update:部分更新一个文档。
-
delete:删除一个文档。
metadata 中需要指定要操作的文档的 _index 、 _type 和 _id , _index 、 _type 也可以在url中指定
实操
create新增文档数据,在metadata中指定index以及type
POST /_bulk
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2001"}}
{"id": "2001", "nickname": "name2001"}
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2002"}}
{"id": "2002", "nickname": "name2002"}
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2003"}}
{"id": "2003", "nickname": "name2003"}
create创建已有id文档,在url中指定index和type
POST /shop/_doc/_bulk
{"create": {"_id": "2003"}}
{"id": "2003", "nickname": "name2003"}
{"create": {"_id": "2004"}}
{"id": "2004", "nickname": "name2004"}
{"create": {"_id": "2005"}}
{"id": "2005", "nickname": "name2005"}
index创建,已有文档id会被覆盖,不存在的id则新增
POST /shop/_doc/_bulk
{"index": {"_id": "2004"}}
{"id": "2004", "nickname": "index2004"}
{"index": {"_id": "2007"}}
{"id": "2007", "nickname": "name2007"}
{"index": {"_id": "2008"}}
{"id": "2008", "nickname": "name2008"}
update创建,部分更新一个文档。
POST /shop/_doc/_bulk
{"update": {"_id": "2004"}}
{"doc": {"id": "20041"}}
{"update": {"_id": "2007"}}
{"doc": {"nickname": "name-20071"}}
delete创建,删除一个文档。
POST /shop/_doc/_bulk
{"delete": {"_id": "2004"}}
{"delete": {"_id": "2007"}}
{"delete": {"_id": "2008"}}
一次处理多少最好
整个批量清求都需要由接收到请求的节点加载到内存中,因此该请求越大,其他请求所能获得的内存就越少。批量请求的大小有一个最佳值,大于这个值,性能将不再提升,甚至会下降。但是最佳值不是一个固定的值。它完全取决于硬件、文档的大小和复杂度、索引和搜索的负载的整体情况。
幸运的是,很容易找到这个最佳点:通过批量索引典型文档,并不断增加批量大小进行尝试。当性能开始下降,那么你的批量大小就太大了。一个好的办法是开始时将1000到5000个文档作为一个批次,如果你的文档非常大,那么就减少批量的文档个数。
密切关注你的批量请求的物理大小往往非常有用,一千个1KB的文档是完全不同于一千个1MB文档所占的物理大小。一个好的批量大小在开始处理后所占用的物理大小约为5-15 MB。
个人感觉最好每次设置1000就好