es参考版本:elasticsearch:5.5

_delete_by_query会删除所有query语句匹配上的文档,用法如下:

curl -X POST "localhost:9200/twitter/_delete_by_query" -H 'Content-Type: application/json' -d'
{
"query": {
"match": {
"name": "测试删除"
}
}
}
'

查询必须是有效的键值对,​​query​​​是键,这和​​Search API​​​是同样的方式。在​​search api​​​中​​q​​参数和上面效果是一样的。

返回数据格式,告诉你用时和删除多少数据等

{
"took" : 147,
"timed_out": false,
"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,
"total": 119,
"failures" : [ ]
}

当启动时(开始要删除时),_delete_by_query会得到索引(数据库)的快照并且使用内部版本号来找到要删除哪些文档。这意味着,如果获取到快照与执行删除过程的这段时间,有文档发生改变,那么版本就会冲突。通过版本控制匹配到的文档会被删除。


因为internal版本控制不支持0为有效数字,所以版本号为0的文档不能删除,并且请求将会失败。


在执行_delete_by_query期间,为了删除匹配到的所有文档,多个搜索请求是按顺序执行的。每次找到一批文档时,将会执行相应的批处理请求来删除找到的全部文档。如果搜索或者批处理请求被拒绝,_delete_by_query根据默认策略对被拒绝的请求进行重试(最多10次)。达到最大重试次数后,会造成_delete_by_query请求中止,并且会在failures字段中响应 所有的故障。已经删除的仍会执行。换句话说,该过程没有回滚,只有中断。

在第一个请求失败引起中断,失败的批处理请求的所有故障信息都会记录在failures元素中;并返回回去。因此,会有不少失败的请求。

如果你想计算有多少个版本冲突,而不是中止,可以在URL中设置为conflicts=proceed或者在请求体中设置"conflicts": "proceed"。

回到api格式中,你可以在一个单一的类型(即:表)中限制_delete_by_query。

下面仅仅只是删除索引(即:数据库)twitter中类型(即:表)tweet的所有数据:

curl -X POST "localhost:9200/twitter/_doc/_delete_by_query?conflicts=proceed" -H 'Content-Type: application/json' -d'
{
"query": {
"match_all": {}
}
}
'

一次删除多个索引(即:数据库)中的多个类型(即表)中的数据,也是可以的。例如:

curl -X POST "localhost:9200/twitter,blog/_docs,post/_delete_by_query" -H 'Content-Type: application/json' -d'
{
"query": {
"match_all": {}
}
}
'

如果你提供了routing,接着这个路由会被复制给scroll query,根据匹配到的路由值,来决定哪个分片来处理:

curl -X POST "localhost:9200/twitter/_delete_by_query?routing=1" -H 'Content-Type: application/json' -d'
{
"query": {
"range" : {
"age" : {
"gte" : 10
}
}
}
}
'

默认情况下,_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"
}
}
}
'

URL Parameters(url 参数)

除了标准参数像​​pretty​​​,​​Delete By Query API​​​也支持​​refresh​​​、​​wait_for_completion​​​、​​wait_for_active_shards​​​和​​timeout​​。

发送带​​refresh​​​参数的请求一旦完成,在​​delete by query​​​api中涉及到的所有分片都将会刷新。这不同于​​Delete API​​​中的​​refresh​​参数,其是在收到删除请求时就刷新分片。

如果请求中包含​​wait_for_completion=false​​​,那么​​elasticsearch​​​将会执行​​预检查​​​、​​启动请求​​​,并返回一个可被​​Tasks APIs​​​使用的​​task​​​,以取消或者得到​​task​​​状态。​​elasticsearch​​​也将会在​​.tasks/task/${taskId}​​​路径中创建一个文档来记录这个​​task​​​。你可以根据自己的情况来选择保留还是删除它;当你删除后,​​elasticsearch​​会回收利用它的空间。

在处理请求之前,​​wait_for_active_shards​​​控制需要多少个副本分片必须处于活动状态。详情​​这里​​​。​​timeout​​​用于控制每个写请求等待不可用分片变成可用分片的时间。两者都能在​​Bulk API​​中正常工作。

​requests_per_second​​​可以设置任何正的十进制数字(1.4、6、1000等等)并且可以限制​​delete-by-query​​​发出的每秒请求数量或者将其设置为​​-1​​​来禁用这种限制。这种限制会在批处理之间等待,以便于其能操作​​scroll timeout​​​。这个等待时间与完成批处理之间的时间和​​requests_per_second * requests_in_the_batch​​​时间是有区别的。由于批处理不会分解成多个请求,而如此大的批处理将会造成​​elasticsearch​​​创建多个请求并且会在开始下个集合(批处理)之前等待一会,这是​​bursty​​​而不是​​smooth​​​。默认为​​-1​​。

Response body(响应体)

响应体的json格式如下:

{
"took" : 639,
"deleted": 0,
"batches": 1,
"version_conflicts": 2,
"retries": 0,
"throttled_millis": 0,
"failures" : [ ]
}

参数 描述

took 从整个操作开始到结束花费的时间,单位是毫秒

deleted 成功删除文档的数量

batches 通过delete by query返回滚动响应的数量(我的看法:符合delete by query条件的文档数量)

version_conflicts delete by queryapi命中的冲突版本的数量(即在执行过程中,发生了多少次冲突)

retries 在delete by query api响应一个完整队列,重试的次数

throttled_millis 根据requests_per_second,请求睡眠多少毫秒

failures 是个数组,表示失败的所有索引(插入);如果它不为空的话,那么请求会因为故障而中止。可以参考如何防止版本冲突而中止操作。

Works with the Task API

你可以使用Task API来获取任何一个正在运行的delete-by-query请求的状态。

curl -X GET "localhost:9200/_tasks?detailed=true&actions=*/delete/byquery"

响应

{
"nodes" : {
"r1A2WoRbTwKZ516z6NEs5A" : {
"name" : "r1A2WoR",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"attributes" : {
"testattr" : "test",
"portsfile" : "true"
},
"tasks" : {
"r1A2WoRbTwKZ516z6NEs5A:36619" : {
"node" : "r1A2WoRbTwKZ516z6NEs5A",
"id" : 36619,
"type" : "transport",
"action" : "indices:data/write/delete/byquery",
"status" : { [](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html#CO38-1)![](http://upload-images.jianshu.io/upload_images/4097351-8117f89c35e1e6d2.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
"total" : 6154,
"updated" : 0,
"created" : 0,
"deleted" : 3500,
"batches" : 36,
"version_conflicts" : 0,
"noops" : 0,
"retries": 0,
"throttled_millis": 0
},
"description" : ""
}
}
}
}
}</pre>

①这个对象包含实际的状态。响应体是json格式,其中total字段是非常重要的。total表示期望执行reindex操作的数量。你可以通过加入的updated、created和deleted字段来预估进度。但它们之和等于total字段时,请求将结束。

使用task id可以直接查找此task。

curl -X GET "localhost:9200/_tasks/taskId:1"

这个api的优点是它整合了wait_for_completion=false来透明的返回已完成任务的状态。如果此任务完成并且设置为wait_for_completion=false,那么其将返回results或者error字段。这个特性的代价就是当设置wait_for_completion=false时,会在.tasks/task/${taskId}中创建一个文档。当然你也可以删除这个文档。

curl -X POST "localhost:9200/_tasks/task_id:1/_cancel"

可以使用上面的task api来找到task_id;

取消应该尽快发生,但是也可能需要几秒钟,上面的task 状态 api将会进行列出task直到它被唤醒并取消自己。

curl -X POST "localhost:9200/_delete_by_query/task_id:1/_rethrottle?requests_per_second=-1"

Rethrottling

requests_per_second的值可以在使用_rethrottle参数的正在运行的delete by queryapi上进行更改:

curl -X POST "localhost:9200/_delete_by_query/task_id:1/_rethrottle?requests_per_second=-1"

使用上面的tasks API来查找task_id

就像在_delete_by_query中设置一样,requests_per_second可以设置-1来禁止这种限制或者任何一个10进制数字,像1.7或者12来限制到这种级别。加速查询的Rethrottling会立即生效,但是缓慢查询的Rethrottling将会在完成当前批处理后生效。这是为了防止scroll timeouts。

Manually slicing

Delete-by-query支持Sliced Scroll,其可以使你相对容易的手动并行化进程:

curl -X POST "localhost:9200/twitter/_delete_by_query" -H 'Content-Type: application/json' -d'
{
"slice": {
"id": 0,
"max": 2
},
"query": {
"range": {
"likes": {
"lt": 10
}
}
}
}
'
curl -X POST "localhost:9200/twitter/_delete_by_query" -H 'Content-Type: application/json' -d'
{
"slice": {
"id": 1,
"max": 2
},
"query": {
"range": {
"likes": {
"lt": 10
}
}
}
}
'

你可以通过以下方式进行验证:

curl -X GET "localhost:9200/_refresh"
curl -X POST "localhost:9200/twitter/_search?size=0&filter_path=hits.total" -H 'Content-Type: application/json' -d'
{
"query": {
"range": {
"likes": {
"lt": 10
}
}
}
}
'

像下面这样只有一个total是合理的:

{
"hits": {
"total": 0
}
}

Automatic slicing

你也可以使用Sliced Scroll让delete-by-query api自动并行化,以在_uid上切片:

curl -X POST "localhost:9200/twitter/_delete_by_query?refresh&slices=5" -H 'Content-Type: application/json' -d'
{
"query": {
"range": {
"likes": {
"lt": 10
}
}
}
}
'

你可以通过以下来验证:

curl -X POST "localhost:9200/twitter/_search?size=0&filter_path=hits.total" -H 'Content-Type: application/json' -d'
{
"query": {
"range": {
"likes": {
"lt": 10
}
}
}
}
'

像下面的total是一个合理的结果:

{
"hits": {
"total": 0
}
}

添加​​slices​​​,​​_delete_by_query​​将会自动执行上面部分中使用手动处理的部分,创建子请求这意味着有些怪事:

  1. 你可以在​​Tasks APIs​​​中看到这些请求。这些子请求是使用了​​slices​​请求任务的子任务。
  2. 为此请求(使用了​​slices​​)获取任务状态仅仅包含已完成切片的状态。
  3. 这些子请求都是独立寻址的,例如:取消和​​rethrottling​​.
  4. Rethrottling the request with slices will rethrottle the unfinished sub-request proportionally.
  5. 取消​​slices​​请求将会取消每个子请求。
  6. 由于​​slices​​​的性质,每个子请求并不会得到完全均匀的文档结果。所有的文档都将要处理,但是有些​​slices​​​(切片)会大些,有些会小些。希望大的​​slices​​(切片)有更均匀的分配。
  7. 在​​slices​​​请求中像​​requests_per_second​​​和​​size​​​参数,按比例分配给每个子请求。结合上面的关于分配的不均匀性,你应该得出结论:在包含​​slices​​​的​​_delete_by_query​​​请求中使用​​size​​参数可能不会得到正确大小的文档结果。
  8. 每个子请求都会获得一个略微不同的源索引快照,尽管这些请求都是大致相同的时间。

Picking the number of slices

这里我们有些关于​​slices​​​数量的建议(如果是手动并行的话,那么在​​slice api​​​就是​​max​​参数):

  1. 不要使用大数字。比如500,将会创建相当大规模的​​CPU​​​震荡。
    这里说明下震荡(thrashing)的意思:
    ​​​cpu​​​大部分时间都在进行换页,而真正工作时间却很短的现象称之为​​thrashing (震荡)​
  2. 从查询性能角度来看,在源索引中使用多个分片是更高效的。
  3. 从查询性能角度来看,在源索引中使用和分片相同的数量是更高效的。
  4. 索引性能应该在可利用​​slices​​之间进行线性扩展。
  5. 索引(插入)或查询性能是否占主导地位取决于诸多因素,比如:重新索引文档和集群进行重新索引。

参考:


​https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html​​ 




梅花香自古寒来