上文向读者介绍了 DeleteByQuery中一些常见的URL参数以及响应字段等，本文来继续看 DeleteByQuery中的其他点。
本文是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
12.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中可以自动执行上述手动切片过程，创建子请求，这意味着它有如下特点：
开发者可以在Tasks API中查看这些请求，这些子请求是具有slices请求任务的“子”任务。
获取slices请求的状态仅包含已完成切片的状态。
这些子请求可单独寻址，例如取消和重置节流。
对slices请求重置节流操作，将按比例重新调整未完成的子请求。
取消slices请求将取消每个子请求。
在slices中，每个子请求将无法获得完全均匀的文档部分，所有文档都将被处理，但是分片大小可能不一。
带有slices请求的requestpersecond和size的参数相应的分配给每个子请求。
每个子请求都会获得源索引的略有不同的快照，尽管这些都是在大约相同的时间进行的。
7.3 Picking the number of slicesedit
如果自动切片，设置slices为auto将为大多数索引选择合理的数字。如果开发者手动切片或以其他方式调整自动切片，请看下面的指南：
当slices数量等于索引中的分片数时，查询性能最有好，但是如果数字很大（例如，500），那么还是请选择较小的数字，因为太多slices会损害性能。另外，设置 slices数量高于分片数通常不会提高效率。
删除性能在可用资源上以切片数量线性增长。
查询或删除性能是否主导运行取决于reindexing的文档和集群资源。
好了，本文就先说到这里，有问题欢迎留言讨论。
