elasticsearch文档Delete By Query API(二)

4.Works with the Task API

开发者可以利用Task API获取任何正在运行的 deletebyquery操作的状态，如下：

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

请求执行结果类似下面这样：

这个对象包含实际状态，和elasticsearch文档Delete By Query API(一)中提到的Response Body类似，不同的是这里增加了total字段，total是reindex期望执行的操作总数，开发者可以通过添加updated，created以及deleted字段来估计进度，请求将在这些字段总和等于total字段时结束。

通过Task ID，开发者可以直接查找任务，如下：

curl -X GET "localhost:9200/_tasks/j3neBny-TnKarVjzXIC3Eg:6736?pretty"

执行结果如下：

此API的优势在于它可以集成 wait_for_completion=false，进而透明地返回任务执行状态。如果任务已完成并且 wait_for_completion=false也已经设置，则它将返回 results或者一个error字段，使用这个功能的会自动创建.tasks/task/${taskId}，当然开发者可以删除该文档。

5.Works with the Cancel Task API

任何的 deletebyquery操作都可以使用Task Cancel API取消，如下：

curl -X POST "localhost:9200/_tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel?pretty"

通过上一小节的请求可以获取到Task ID。 取消应该尽快操作但是依然可能需要花费几秒钟，上面的Task API也会列出Task，直到该Task被唤醒取消自己。

6.Rethrottling

requestpersecond的值可以在 deletebyquery期间使用 _rethrottle API进行修改：

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

通过上一小节的请求可以获取到Task ID。

就像在 _delete_by_query API中设置节流参数一样， request_per_second如果为-1表示禁用限制，或者任何十进制数字，如1.7或12，以节流到该级别，对于加速查询的会立即生效，但是对于减慢查询的，则是在完成当前批处理之后才会生效，这样可以防止滚动超时。

7.Slicing

delete by query 支持 sliced scroll 进而实现并行化删除，这种并行化可以提高效率，并提供一种方便的方法将请求分解为更小的部分。

7.1 Manually slicingedit

首先可以手动的进行并行化处理，如下：

curl -X POST "localhost:9200/twitter/_delete_by_query?pretty" -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?pretty" -H 'Content-Type: application/json' -d'
{
  "slice": {
    "id": 1,
    "max": 2
  },
  "query": {
    "range": {
      "likes": {
        "lt": 10
      }
    }
  }
}
'

开发者只需要指定一个slice id和slice数量即max，这里的slice id不能大于max。

接下来通过如下方式可以验证：

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

一个合理的执行结果类似下面这样：

7.2 Automatic slicingedit

开发者还可以通过使用切片的 _uid来让 deletebyquery自动并行执行，此时，只需要指定slices数量即可，如下：

curl -X POST "localhost:9200/bank/_delete_by_query?refresh&slices=5&pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match_all": {}
  }
}
'

执行结果如下，可以看到每次删除的文档数量：

开发者也可以通过如下请求去验证：

curl -X POST "localhost:9200/bank/_search?size=0&filter_path=hits.total&pretty" -H 'Content-Type: application/json' -d'
{
  "query": {
    "match_all": {}
  }
}
'

验证结果如下：

设置slices为auto将让Elasticsearch选择要使用的切片数，此设置将使每个分片一个切片，达到限制后，如果有多个源索引，它将根据具有最小分片数量的索引选择切片数。

将slices添加到deleteby_query中可以自动执行上述手动切片过程，创建子请求，这意味着它有如下特点：

1. 开发者可以在Tasks API中查看这些请求，这些子请求是具有slices请求任务的“子”任务。
2. 获取slices请求的状态仅包含已完成切片的状态。
3. 这些子请求可单独寻址，例如取消和重置节流。
4. 对slices请求重置节流操作，将按比例重新调整未完成的子请求。
5. 取消slices请求将取消每个子请求。
6. 在slices中，每个子请求将无法获得完全均匀的文档部分，所有文档都将被处理，但是分片大小可能不一。
7. 带有slices请求的requestpersecond和size的参数相应的分配给每个子请求。
8. 每个子请求都会获得源索引的略有不同的快照，尽管这些都是在大约相同的时间进行的。

7.3 Picking the number of slicesedit

如果自动切片，设置slices为auto将为大多数索引选择合理的数字。如果开发者手动切片或以其他方式调整自动切片，请看下面的指南：

1. 当slices数量等于索引中的分片数时，查询性能最有好，但是如果数字很大（例如，500），那么还是请选择较小的数字，因为太多slices会损害性能。另外，设置 slices数量高于分片数通常不会提高效率。
2. 删除性能在可用资源上以切片数量线性增长。
3. 查询或删除性能是否主导运行取决于reindexing的文档和集群资源。

好了，本文就先说到这里，有问题欢迎留言讨论。