elasticsearch批量操作bulk

最新推荐文章于 2022-10-07 16:04:47 发布

赛赛liangks

最新推荐文章于 2022-10-07 16:04:47 发布

阅读量488

点赞数

分类专栏： elasticsearch 文章标签： elasticsearch bulk

本文链接：https://blog.csdn.net/qq_34706514/article/details/119820523

版权

elasticsearch 专栏收录该内容

9 篇文章 0 订阅

订阅专栏

基本语法

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就好