Document APIs 文档接口

这一部分开始会简短介绍 Elasticsearch 的数据复制模型，接下来会详解介绍下面的增删改查接口（CRUD APIs）。

1. Single document APIs 单文档操作接口
- Index API
- Get API
- Delete API
- Update API
2.  Multi-document APIs 多文档操作接口
- Multi Get API
- Bulk API
- Delete By Query API
- Update By Query API
- Reindex API

Reading and Writing documents 读写文档

**Introduction 介绍**
在 Elasticsearch 中，每一个索引可以分片，而每一个分片可以有多个副本。当增加或删除文档的时候，它的这些副本集需要同步复制，否则，会出现读不同副本的数据结果返回不一致的情况。我们称保持分片副本一致性和处理分片副本读取的过程为数据复制模型（data replication model）
Elasticsearch 的数据复制模型基于主备模型并且在微软研究的PacificA论文中描述的非常清楚。模型是基于一个复制集中的单拷贝的主分片。其他拷贝被称为复制分片。主分片作为所有索引操作的主入口。挑战在于校验并确保这些主分片正确有效。当主分片接收到一个索引操作请求，它同时要对对其他副本的复制操作负责。
    
**Basic write model 基本写模型**
在 Elasticsearch 中每个索引操作根据路由规则首先被分解到一个复制集，通常基于文档ID。一旦复制集被选中，操作会被直接转发到这个复制集的主分片。主分片负责校验操作或者转发操作到其他副本。因为副本可能下线，主分片不需要将数据复制到所有副本。Elasticsearch 维护了一个可以接收操作的分片列表作为替代方案。这个列表被称为in-sync副本被主节点持有。顾名思义，这组状态“好”的分片拷贝，保证已经处理了所有已经被用户确认的索引和删除操作。
**Failure handling 失败处理**
索引的过程当中可能会发生任何意想不到的事情-尽管主节点运行良好，二磁盘崩溃，节点之间不能通信，以及一些配置丢失都可能导致副本上的操作失败。以上虽然很少发生，但主分片必须对此负责。
当主分片自己失败的时候，持有主分片的节点会发送消息给Master。索引操作会等待（默认最多1分钟）master重新选举出一个副本为新的主分片。索引操作会被转发到新的主分片处理。比较典型的是当持有主分片的节点因为网络问题与集群是回去联系会出现这种情况。
**Basic read model 基本读模型**
在 ElasticSearch 中，读操作可能是非常轻量的根据ID查询或是需要消耗大量CPU资源的复杂聚合查询。主备模型的一个优点是它保存全量数据在所有分片中。因此，任何一个 in-sync 拷贝都可以有效地服务于查询操作。
当一个节点接收到读取请求时，该节点负责将其转发到保存相关分片的节点，整理响应，并响应客户端。我们称该节点为该请求的协调节点。基本流程如下：
1. 分解读取请求并解析到相关分片。注意由于大多数搜索将发送到一个或多个索引，因此通常需要从多个分片中读取数据，每个分片代表数据的不同子集。
2. 从分片复制集选择一个分片的活跃拷贝，可以是主分片也可以是复制分片。默认情况下，ElasticSearch会使用 round-robin算法在分片拷贝中选择。
3. 向选中的副本发送相应级别读请求。
4. 整合结果并返回。注意如果是基于ID的检索，只有一个分片相关，这一步会省略。

**Shard failures 分片错误**
当一个分片响应失败，协调节点会发送消息到同一个副本集的另一个分片副本。重复的失败会导致无可用的分片副本。
为了确保快速响应，如果一个或多个分片响应失败，如下 APIs 会返回部分结果。
- [Search](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/search-search.html)
- [Multi Search](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/search-multi-search.html)
- [Bulk](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-bulk.html)
- [Multi Get](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-multi-get.html)
包含部分数据的响应仍然会返回200 HTTP状态码。分片失败会在timed_out 和 _shards 的响应头信息中展示。
**A few simple implications**
如下这些基本流程决定了 ElasticSearch 作为一个搜索系统的如何读写。此外，因为读写请求并发执行，所以这两个基本操作流程互相影响。
- 高效读取
在正常操作下，每个相关复制集执行一次读取操作。只有在失败的情况下，同一个分片的多个副本才会执行相同的搜索。
- 阅读未确认
由于首先执行主索引本地索引，然后执行复制请求，所以并发读取情况下可能在看到了未确认的更改。
- 默认2拷贝
此模型包含两份拷贝，可以做到容错处理。这与其它基于仲裁的至少保留3份拷贝的机制不同。

**Failures**

The Tip of the Iceberg 冰山一角
本文档提供了 ElasticSearch 如何处理数据的高级概述。当然还有很多很多其他特性。想_primay_term、集群状态发布及主节点选举在保持 ElasticSearch 正确有效运行起到了关键作用。此文档同样没有覆盖重要或已知的bugs。我们认识到Github很难跟上，为了帮助大家对此保持了解，我们在我们的网站上维护一个专门的[弹性页面](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html)。我们强烈建议阅读。

Index API 索引 API

See 删除映射类型.
注：目前一个es的索引Index仅含一种type的数据即_doc,相似的数据希望放在同一个Index下的话，可以在mapping中增加一个类型字段解决，同一个Index下不同类型（业务）的数据字段个数及类型要基本一致，保持索引数据的密集。

curl -X PUT "localhost:9200/twitter/_doc/1" -H 'Content-Type: application/json' -d'
  {
      "user" : "kimchy",
      "post_date" : "2009-11-15T14:12:12",
      "message" : "trying out Elasticsearch"
  }
  '

结果如下：

{
    "_index": "twitter",
    "_type": "_doc",
    "_id": "1",
    "_version": 1,
    "result": "created", #创建成功
    "_shards": {
        "total": 2, #两个分片（一主、一副本）
        "successful": 1, #索引操作在一个分片副本上成功执行，这里是主分片
        "failed": 0 # #没有任何一个分片上的索引操作失败，说明只有一个分片（主分片）启动了
    },
    "_seq_no": 0,
    "_primary_term": 1
}

**Automatic Index Creation 自动创建索引**
  当执行索引操作的时候如果索引不存在自动创建，并使用 已经配置好的[索引模板](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/indices-templates.html)。索引操作同时也会自动创建（如果不存在的话）一个动态映射文档。默认情况下，如果有需要新的字段或对象会准备自动添加到映射定义中。有关映射定义的更多信息，请查看[映射](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/mapping.html)部分；有关手动更新映射的信息，请参阅[修改映射](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/indices-put-mapping.html)API。
  自动创建索引由action.auto_create_index配置控制。此配置默认为True，这意味着索引总是自动被创建的。自动创建索引可以设置为只有匹配特定格式的索引才允许自动创建索引，方法是将这些索引格式以逗号分隔配置。还可以通过在列表中的格式前面加上+或-来明确地允许和禁止。最后，通过将此设置更改为false，可以完全禁用它。

设置twitter,index10可以被自动创建，匹配ind开头的，忽略以index1开头
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "action.auto_create_index": "twitter,index10,-index1*,+ind*" 
    }
}
'
设置为不可以自动创建
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "action.auto_create_index": "false" 
    }
}
'
默认配置，自动创建
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
    "persistent": {
        "action.auto_create_index": "true" 
    }
}
'

**Operation Type 操作类型**
  索引操作允许"put-if-absent"操作，也可以接口 op_type 参数来强制进行创建操作。如果使用了create，如果一个文档已经存在name创建操作会失败。

curl -X PUT "localhost:9200/twitter/_doc/1?op_type=create" -H 'Content-Type: application/json' -d'
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}
'

  如果已经存在报错：

{
    "error": {
        "root_cause": [{
            "type": "version_conflict_engine_exception",
            "reason": "[1]: version conflict, document already exists (current version [1])",
            "index_uuid": "tEuwvTUyRN6Szp5Kh6yqOQ",
            "shard": "0",
            "index": "twitter"
        }],
        "type": "version_conflict_engine_exception",
        "reason": "[1]: version conflict, document already exists (current version [1])",
        "index_uuid": "tEuwvTUyRN6Szp5Kh6yqOQ",
        "shard": "0",
        "index": "twitter"
      },
      "status": 409
}

**Automatic ID Generation ID自动生成**
索引操作可以不指定id而被执行。这种情况下id会被自动生成。一般情况下，op_type会自动设置为 create。

curl -X POST "localhost:9200/twitter/_doc/" -H 'Content-Type: application/json' -d'
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}
'

结果如下：

{
    "_index": "twitter",
    "_type": "_doc",
    "_id": "1voRtGoBVXq4m3oClq2T",  ##自动生成的id
    "_version": 1,
    "result": "created",
    "_shards": {
        "total": 2,
        "successful": 1,
        "failed": 0
    },
    "_seq_no": 1,  ##这里_seq_no为1了，为什么？
    "_primary_term": 1
}

**Optimistic concurrency control 乐观并发控制**
索引操作可以使用最后一次查询返回的序列号seq_no和主术语primary_term作为参数修改指定版本if_seq_no=362&if_primary_term=2的数据。如果检测到不匹配，操作将导致版本冲突异常和状态代码409。有关更多详细信息，请参阅乐观并发控制[link](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/optimistic-concurrency-control.html)。

Routing 路由

 默认路由机制基于id的hash到不同数据分片。可以在创建文档的时候指定_routing来控制。比如按照用户id来指定_routing，那么这个id的相关数据都会路由的同一个分片，如果有些id的数据量比较大，有些id数据量比较小，那么会导致数据不均匀。

Distributed 分发

基于路由表索引操作会被导向到主分片，并且被持有这个分片的实际节点执行。主分片执行完操作后，如果需要的话，更新会被同步到相应的复制分片。
**Wait For Active Shards**

**Refresh 刷新**
控制数据更新后对新的请求可以见行。[见](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-refresh.html)
**Noop Updates**
未完待续……
**Timeout**
执行索引操作时，分配给执行索引操作的主分片可能不可用。原因可能是主分片当前正在从网关恢复或正在重新定位。默认情况下，索引操作将在主分片上等待1分钟，然后失败并以错误响应。timeout参数可用于显式指定等待的时间。下面是将其设置为5分钟的示例：
curl -X PUT "localhost:9200/twitter/_doc/1?timeout=5m" -H 'Content-Type: application/json' -d'
{
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elasticsearch"
}
'

**Versioning**
未完待续……

Get API 查询API

API 允许通过 ID 获取json文档。如下：

curl -X GET "localhost:9200/twitter/_doc/1"

结果如下：

{
  "_index": "twitter",
  "_type": "_doc",
  "_id": "1",
  "_version": 1,
  "_seq_no": 0,
  "_primary_term": 1,
  "found": true,
  "_source": {
      "user": "kimchy",
      "post_date": "2009-11-15T14:12:12",
      "message": "trying out Elasticsearch"
  }
}

同样允许使用HEAD检查指定的资源是否存在，如下：

curl -I "localhost:9200/twitter/_doc/1"

结果日下：
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
content-length: 224

**Realtime 实时**
默认情况下，Get API是实时获取的，且不受索引刷新率的影响（数据在搜索时即可见）。如果文档已更新但尚未刷新，则Get API将在适当位置发出刷新调用，以使文档可见。这还将使上次刷新后更改的其他文档可见。如果要禁用实时获取，可以将 realtime 参数设置为false。

**Source filtering 资源过滤**
默认情况下，“获取”操作返回 _source 字段的内容，除非您使用了 stored_fields 参数或禁用了 _source 字段。您可以通过 _source 参数关闭 _source 检索： 
curl -X GET "localhost:9200/twitter/_doc/1?_source=false"

如果您只需要完整 souce 中的一个或两个字段，您可以使用包含和排除参数来包含或筛选您需要的字段。这对于大型文档尤其有用，因为部分检索可以节省网络开销。两个参数都采用逗号分隔的字段列表或通配符表达式。例子：
curl -X GET "localhost:9200/twitter/_doc/1?_source_includes=*.id&_source_excludes=entities"

如果只想指定包含的字段，可以使用较短的语法：
curl -X GET "localhost:9200/twitter/_doc/1?_source=*.id,retweeted"

**Stored Fields**
获取操作允许指定一组存储字段，这些字段将通过传递 stored_fields 参数返回。如果请求的字段未被存储将忽略。例如如下映射：
curl -X PUT "localhost:9200/twitter" -H 'Content-Type: application/json' -d'
{
   "mappings": {
       "properties": {
          "counter": {
             "type": "integer",
             "store": false
          },
          "tags": {
             "type": "keyword",
             "store": true
          }
       }
   }
}
'
添加一个文档：
curl -X PUT "localhost:9200/twitter/_doc/1" -H 'Content-Type: application/json' -d'
{
    "counter" : 1,
    "tags" : ["red"]
}
'
获取这个文档：
curl -X GET "localhost:9200/twitter/_doc/1?stored_fields=tags,counter"
结果如下：
{
     "_index": "twitter",
     "_type": "_doc",
     "_id": "1",
     "_version": 1,
     "_seq_no" : 22,
     "_primary_term" : 1,
     "found": true,
     "fields": {
        "tags": [
           "red"
        ]
     }
  }

 还可以检索元数据字段，如 _routing 字段：
curl -X PUT "localhost:9200/twitter/_doc/2?routing=user1" -H 'Content-Type: application/json' -d'
{
    "counter" : 1,
    "tags" : ["white"]
}
'
curl -X GET "localhost:9200/twitter/_doc/2?routing=user1&stored_fields=tags,counter"
结果如下：
{
"_index": "twitter",
"_type": "_doc",
"_id": "2",
"_version": 1,
"_seq_no": 1,
"_primary_term": 1,
"_routing": "user1",
"found": true,
"fields": {
    "tags": ["white"]
}
}

此外，只有叶子字段可以通过 stored_field 选项返回。所以不能返回对象字段，这样的请求将失败。

**Geting the _source directly 直接获取_source数据**
使用 /{index}/_source/{id} endpoint 可以只获取文档的source字段，例如：
curl -X GET "localhost:9200/twitter/_source/1"
结果如下：
{
"counter": 1,
"tags": ["red"]
}

**Routing 路由**
当索引使用使用路由控制表，为了获取到数据，需要将 routing 参数加上。（注：路由是为了加快搜索，避免了轮询所有分片的）
curl -X GET "localhost:9200/twitter/_doc/2?routing=user1"
**Preference 设置**
未完待续……
**Refresh**
可以将refresh参数设置为true，以便在get操作之前刷新相关的分片并使其可搜索。将其设置为true应该在仔细考虑并验证这不会导致系统负载过重（并减慢索引速度）后进行。
**Distribuited 分发**
Get操作被散列到一个特定的shard id中，然后被重定向到该shard id的一个副本，并返回结果。副本是主分片及其在该分片复制集中的副本。这意味着我们拥有的副本越多，我们将拥有更好的扩展能力。

**Versioning Support 版本支持**
curl -X GET "localhost:9200/twitter/_doc/2?version=1"
结果如下：
{"_index":"twitter","_type":"_doc","_id":"2","_version":1,"_seq_no":1,"_primary_term":1,"_routing":"user1","found":true,"_source":
    {
        "counter" : 1,
        "tags" : ["white"]
    }
}

在ElasticSearch内部，旧文档被标记为已删除，并添加了一个全新的文档。旧版本的文档不会立即消失，尽管您将无法访问它。ElasticSearch 在继续索引更多数据时在后台清除删除的文档。

Delete API 删除API

curl -X DELETE "localhost:9200/twitter/_doc/1"
结果如下：
{
      "_shards" : {
          "total" : 2,
          "failed" : 0,
          "successful" : 2
      },
      "_index" : "twitter",
      "_type" : "_doc",
      "_id" : "1",
      "_version" : 2,
      "_primary_term": 1,
      "_seq_no": 5,
      "result": "deleted"
  }    
  
**Optimistic concurrency control 乐观并发控制**
删除操作是有条件的，只有在最后一次对文档的修改被分配了if-seq-no和if-primary-term参数指定的序列号和主术语时才能执行。如果检测到不匹配项，操作将导致版本冲突异常并返回状态代码409。有关更多详细信息，请参阅[乐观并发控制](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/optimistic-concurrency-control.html)。

**Versioning 版本**
索引的每个文档都有版本控制。当删除文档时，可以指定版本以确保我们要删除的相关文档实际上已被删除，并且在此期间没有更改。对文档执行的每个写入操作（包括删除）都会导致其版本增加。删除后，已删除文档的版本号在短时间内保持可用，以允许控制并发操作。已删除文档的版本保持可用的时间长度由index.gc_删除索引设置确定，默认为60秒。

**Routing路由**

当索引使用了路由控制的功能时，为了删除文档，还应该提供路由值。例如：
curl -X DELETE "localhost:9200/twitter/_doc/1?routing=kimchy"
上面将删除一条ID为1的tweet，但将根据用户进行路由。请注意，如果没有正确的发送路由，则发出“删除”命令将导致文档无法删除。
当 _routing 映射设置为必需且未指定路由值时，删除API将抛出RoutingMissingException并拒绝请求。
{

"_index": "twitter",
"_type": "_doc",
"_id": "1",
"_version": 2,
"result": "not_found",
"_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
},
"_seq_no": 7,
"_primary_term": 2

}

**Automatic index creation 自动索引创建**
如果使用了外部版本控制变量，如果以前没有创建过，则删除操作会自动创建索引（签出用于手动创建索引的创建索引API）。

**Distributed 分发**
删除操作被散列到一个特定的分片 ID 中，然后被重定向到该分片集中的主分片中，并复制（如果需要）到该分片集中的分片副本中。
**Wait For Active Shards** 
当发出删除请求时，可以将 wait_for_active_shards 参数设置最少分片副本活跃数。有关详细信息和用法示例，请参阅[此处](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-index_.html#index-wait-for-active-shards)。

**Refresh 刷新**
控制此请求所做的更改对搜索可见的时间。见[?refresh](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-refresh.html)

**Timeout 超时**

当执行删除操作时，执行删除操作的主分片可能不可用。一些原因可能是主分片当前正在恢复或正在重新定位。默认情况下，删除操作将在主分片变为可用状态前等待1分钟，然后失败并以错误响应。timeout参数可用于显式指定等待的时间。下面是将其设置为5分钟的示例：
curl -X DELETE "localhost:9200/twitter/_doc/1?timeout=5m"

Delete By Query 根据查询删除

curl -X POST "localhost:9200/twitter/_delete_by_query" -H 'Content-Type: application/json' -d'
{
  "query": { 
    "match": {
      "message": "some message"
    }
  }
}
'
结果如下：
{
  "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 在索引启动时获取索引快照，并使用内部版本控制删除找到的内容。这意味着，如果文档在拍摄快照和处理删除请求之间发生更改，则会出现版本冲突。只有当当版本匹配时，文档才会被删除。
注：因为内部版本控制不支持将0值作为有效的版本号，因此版本为0的文档不能使用 _delete_by_query 删除，并且将使请求失败。

在 _delete_by_query 执行期间，将按顺序执行多个搜索请求，以查找所有匹配的要删除的文档。每次找到一批文档时，都会执行相应的批量请求来删除所有这些文档。如果搜索或批量请求被拒绝，_delete_by_query 按照默认策略重试被拒绝的请求（最多10次，指数后退）。达到最大重试次数限制会导致 _delete_by_query 中止，并在响应的 failures 返回所有失败。已执行的删除操作仍然保持不变。换句话说，进程不会回滚，只会中止。当第一个失败导致中止时，由失败的批量请求返回的所有失败都会在failures 元素中返回；因此，可能会有相当多失败的实体。

If you’d like to count version conflicts rather than cause them to abort, then set conflicts=proceed on the url or "conflicts": "proceed" in the request body.

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

"query": {
  "match_all": {}
}

}
'
结果如下:
{

"took": 115,
"timed_out": false,
"total": 1,
"deleted": 1,
"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": []

}

删除多个索引数据，如下：

POST twitter,blog/_delete_by_query
{

"query": {
  "match_all": {}
}

}

根据routing key指定分片下的数据：
If you provide routing then the routing is copied to the scroll query, limiting the process to the shards that match that routing value:
POST twitter/_delete_by_query?routing=1
{

"query": {
  "range" : {
      "age" : {
         "gte" : 10
      }
  }
}

}

By default _delete_by_query uses scroll batches of 1000. You can change the batch size with the scroll_size URL parameter:
POST twitter/_delete_by_query?scroll_size=5000
{

"query": {
  "term": {
    "user": "kimchy"
  }
}

}

**Url Parameters参数**

除了标准参数如pretty，delete by query api还支持refresh、wait_for_completion、wait_for_active_shards、timeout和scroll。

发送 refresh 将在请求完成后刷新 _delete_by_query 中涉及的所有分片。这与delete api的refresh参数不同，后者只会刷新接收到删除请求的shard。与删除API不同，它不支持等待。
如果请求中包含wait_for_completion=false，那么ElasticSearch将执行一些飞行前检查，启动请求，然后返回可与任务API一起使用的任务，以取消或获取任务的状态。ElasticSearch还将在.tasks/task/$taskid处创建此任务的记录作为文档。这是您的，您可以根据需要保留或删除。完成后，删除它，这样ElasticSearch可以回收它使用的空间。

wait_for_active_shards控制在继续执行请求之前必须存在多少个活跃的shard副本。详情请参阅此处。timeout 控制每个写请求等待不可用分片可用的时间。这两种方法在批量API中的工作方式完全相同。由于“按查询删除”使用scroll搜索，您还可以指定scroll参数来控制“搜索上下文”保持活动的时间，例如？scroll=10m。默认为5分钟。

每秒请求书可以设置为任何正十进制数（1.4、6、1000等），并通过用等待时间间隔每个批来限制查询删除请求操作的速率。通过将每秒请求数设置为-1，可以禁用阈值。

### Response body 响应体
The JSON response looks like this:

{
    "took" : 147,                        //整个操作消耗的毫秒数
    "timed_out": false,               //是否超时
    "total": 119,                         //匹配总数
    "deleted": 119,                    //删除总数
    "batches": 1,                        //批次
    "version_conflicts": 0,          //版本冲突
    "noops": 0,                          //This field is always equal to zero for delete by query. It only exists so that delete by query, update by query, and reindex APIs return responses with the same structure.
    "retries": {                            //
      "bulk": 0,
      "search": 0
    },
    "throttled_millis": 0,              //休眠时间
    "requests_per_second": -1.0,    //
    "throttled_until_millis": 0,      //This field should always be equal to zero in a _delete_by_query response. It only has meaning when using the Task API, where it indicates the next time (in milliseconds since epoch) a throttled request will be executed again in order to conform to requests_per_second.
    "failures" : [ ]                        //失败ids
}

**Works with task API**

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" : {    
            "total" : 6154,
            "updated" : 0,
            "created" : 0,
            "deleted" : 3500,
            "batches" : 36,
            "version_conflicts" : 0,
            "noops" : 0,
            "retries": 0,
            "throttled_millis": 0
          },
          "description" : ""
        }
      }
    }
  }
}

使用task id可以直接查看详情：
curl -X GET "localhost:9200/_tasks/r1A2WoRbTwKZ516z6NEs5A:36619"

### Works with Cancel Task API
使用取消任务api可以取消查询删除操作
curl -X POST "localhost:9200/_tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel"

取消操作会快速执行但是也需要几秒的时间。Task列表API仍然会展示这个查询删除操作直到他检查到自己被取消并且终结自己。

**Rethrottling**

执行中的删除操作的requests_per_second值可以使用_rethrottle API修改，如下：
curl -X POST "localhost:9200/_delete_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1"

就像在 delete by query API使用一样，requests_per_second可以设置为-1来取消限流或者其他小数比如1.7或2来限制流量。提高速率可以立即生效，限制速率会在完成本批次以后生效。以上为了防止超时。

**Slicing 切片**

查询删除支持切片滚动的方式并行执行删除操作。这种并行化操作可以提高效率并且提供了一种便捷的方式将请求切分为一个个的小部分。