elasticsearch文档Delete By Query API(一)

上篇文章和读者分享了Elasticsearch中文档删除API的基本用法,但是这些API还不能满足实际开发中的需求,实际开发中,更加灵活的删除操作还是需要结合查询API才能实现。本文就来看看Delete By Query API。

本文是Elasticsearch系列的第十二篇,阅读前面的文章,有助于更好的理解本文:


1.elasticsearch安装与配置

2.初识elasticsearch中的REST接口

3.elasticsearch修改数据

4.elasticsearch文档操作

5.elasticsearch API约定(一)

6.elasticsearch API约定(二)

7.elasticsearch文档读写模型

8.elasticsearch文档索引API(一)

9.elasticsearch文档索引API(二)

10.elasticsearch文档Get API

11.elasticsearch文档Delete API


1.Delete By Query API

这里最简单的用法是对每个查询匹配的文档执行删除文档,例如下面这样:

curl -X POST “localhost:9200/twitter/_delete_by_query?pretty” -H ‘Content-Type: application/json’ -d’

{

“query”: {

“match”: {

“user”: “kimchy”

}

}

}

执行结果如下:

640?wx_fmt=png

这里的查询需要使用和Search API(后文会讲)相同的方式来将查询条件作为query的值传递,当然也可以使用q关键字,例如如下请求:

curl -X POST “localhost:9200/twitter/_delete_by_query?pretty&q=user:kimchy” -H ‘Content-Type: application/json’

执行结果如下:

640?wx_fmt=png

delete by query在索引启动时获取索引的快照,并使用内部版本控制删除它找到的文档。这意味着如果文档在拍摄快照的时间和处理删除请求之间发生更改,就会出现版本冲突,当版本匹配时(即未出现冲突时),文档将被删除。

注意

由于内部版本控制不支持值0作为有效的版本号,因此无法使用 _delete_by_query删除版本等于零的文档,并且将请求失败。

在 _delete_by_query执行期间,顺序执行多个搜索请求以便找到要删除的所有匹配文档。每次找到一批文档时,都会执行相应的批量请求以删除所有这些文档。如果搜索或批量请求被拒绝,则 _delete_by_query会默认进行重试,最多10次,达到最大重试次数限制会导致 _delete_by_query操作中止,并且所有的失败信息在响应的failures字段中给出。对于已执行的删除仍然有效,换句话说,这个过程不会回滚,只会中止。当第一个失败导致中止时,失败的批量请求返回的所有失败信息都将在响应的failures元素中给出,因此可能存在相当多的失败实体。

如果只是想计算版本冲突而不是让它们中止,那么可以设置在URL中添加conflicts=proceed参数,或者在请求体中设置 "conflicts":"proceed"

开发者可以将 _delete_by_query限制为单一类型,例如如下请求,将会从 twitter索引中删除 _doc类型的文档:

curl -X POST “localhost:9200/twitter/_doc/_delete_by_query?conflicts=proceed&pretty” -H ‘Content-Type: application/json’ -d’

{

“query”: {

“match_all”: {}

}

}

请求执行结果如下:

640?wx_fmt=png

也可以一次删除多个索引和多个type,如下:

curl -X POST “localhost:9200/twitter,blog/_doc,post/_delete_by_query?pretty” -H ‘Content-Type: application/json’ -d’

{

“query”: {

“match_all”: {}

}

}

请求执行结果如下:

640?wx_fmt=png

如果开发者使用了路由,那么路由将被拷贝到滚动查询,那么删除操作将在路由相匹配的分片上执行,如下:

curl -X POST “localhost:9200/twitter/_delete_by_query?routing=2&pretty” -H ‘Content-Type: application/json’ -d’

{

“query”: {

“range” : {

“age” : {

“gte” : 10

}

}

}

}

执行结果如下:

640?wx_fmt=png

默认情况下, _delete_by_query滚动批处理上限为1000,可以在URL中使用 scroll_size参数更改批量大小:

curl -X POST “localhost:9200/twitter/_delete_by_query?scroll_size=5000” -H ‘Content-Type: application/json’ -d’

{

“query”: {

“term”: {

“user”: “kimchy”

}

}

}

2.URL Parameters

除了elasticsearch API约定(二)一文向读者介绍的公共参数如pretty之外, DeleteByQueryAPI还支持 refresh、 wait_for_completion、 wait_for_active_shards、 timeout以及 requests_per_second

2.1 refresh

发送refresh请求将在删除请求完成后刷新 deletebyquery中涉及到的所有分片,这不同于elasticsearch文档Delete API一文中提到的refresh参数,后者仅刷新接收删除请求的分片。

2.2 waitforcompletion

如果请求包含 wait_for_completion=false,则Elasticsearch将执行一些预检查、启动请求、然后返回task,可与Tasks API一起使用来取消或获取任务状态。Elasticsearch还将以.tasks/task/${taskId}作为文档创建此任务的记录,开发者可以自行决定是否保留这个记录,如果删除记录,那么Elasticsearch可以回收它使用的空间。

2.3 waitforactive_shards

waitforactive_shards参数的作用和elasticsearch文档索引API(二)一文中介绍的含义一致,这里不再赘述,读者可以参考该篇文章。

2.4 timeout

timeout控制每个写入请求等待不可用分片变为可用分片的时间。

2.5 scroll

由于 _delete_by_query采用滚动搜索,你还可以指定 scroll参数来控制在多长时间保持“搜索上下文”活着,例如添加 ?scroll=10m参数,默认情况下它是5分钟。

2.6 requestspersecond

requestspersecond可以被设置为任何正十进制数(1.4,6, 1000等),通过该参数可以限制 delete-by-query发出的每秒请求数量,也可以通过设置requestspersecond=-1来禁用这种限制。

节流是通过在批处理之间等待来实现限制作用,通过在 _delete_by_query内部的每批次之间填充时间来实现节流,填充时间是批量大小除以requestspersecond与写入操作所花费的时间之间的差异。在默认情况下,批量大小为1000,因此如果requestspersecond设置为500,填充时间计算如下:

target_time = 1000 / 500 per second = 2 seconds

wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

由于批处理是作为单个_bulk请求发出的,因此大数据量的批处理将导致Elasticsearch创建许多请求,然后等待一段时间再开始下一组。这是 bursty而不是 smooth

3.Response body

根据前面的介绍,响应的数据类似于如下格式:

{

“took” : 147,

“timed_out”: false,

“total”: 119,

“deleted”: 119,

“batches”: 1,

“version_conflicts”: 0,

“noops”: 0,

“retries”: {

“bulk”: 0,

“search”: 0

},

“throttled_millis”: 0,

“requests_per_second”: -1.0,

“throttled_until_millis”: 0,

“failures” : [ ]

}

各字段的含义分别如下:

1.took

执行整个操作所耗费的时间,单位为毫秒。

2.timed_out

在整个操作执行过程中,如果发生了任何的请求超时,则将此字段标记为true。

3.total

成功处理的文档数。

4.deleted

成功删除的文档数。

5.batches

通过 deletebyquery删除的滚动响应数量。

6.version_conflicts

版本冲突数。

7.noops

这个字段在删除响应中始终为0。它的存在只是为了 deletebyquery、 updatebyquery以及 reindexAPIs具有相同的响应结构。

8.retries

这个是重试次数,bulk是bulk行为的重试次数,search是search行为的重试次数。

9.throttled_millis

请求休眠的毫秒数。

10.requestspersecond

在 deletebyquery期间每秒执行的请求数。

11.throttleduntilmillis

该字段在 _delete_by_query响应中应始终等于零,它只在使用Task API时有意义。为了使请求执行满足 requests_per_second,它用来指示下一次 throttled request执行的时间。

12.failures

如果在此过程中存在任何不可恢复的错误,则这个数组将不为空。参考上文,开发者可以使用conflicts选项来防止版本冲突导致操作中止。
好了,本文先说到这里,有问题欢迎留言讨论。
▼往期精彩回顾▼ Redis教程 SpringCloud教程 Git教程 MongoDB教程 SpringBoot+Vue前后端分离开源项目-微人事 SpringBoot+Vue前后端分离开源项目-V部落
640?wx_fmt=png

最后

小编这些年深知大多数初中级工程师,想要提升自己,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Java全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你需要这些资料,⬅专栏获取
分离开源项目-V部落]( )
640?wx_fmt=png

最后

小编这些年深知大多数初中级工程师,想要提升自己,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。

因此我收集整理了一份《2024年Java全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。

[外链图片转存中…(img-qmiaqHpJ-1719507203198)]

[外链图片转存中…(img-0azcZVwK-1719507203200)]

[外链图片转存中…(img-1cbjpT8u-1719507203200)]

由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!

如果你需要这些资料,⬅专栏获取

  • 7
    点赞
  • 24
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值