delete API

Delete API 允许基于 ID，从特定索引中删除类型化的 JSON 文档。下面的例子中，从一个 twitter 索引中，_doc 类型下，删除了 ID 为 1 的 JSON 文档。

  1. curl -X DELETE "localhost:9200/twitter/_doc/1?pretty"

上面删除操作的结果如下：

  1. {
  2.     "_shards" : {
  3.         "total" : 2,
  4.         "failed" : 0,
  5.         "successful" : 2
  6.     },
  7.     "_index" : "twitter",
  8.     "_type" : "_doc",
  9.     "_id" : "1",
  10.     "_version" : 2,
  11.     "_primary_term": 1,
  12.     "_seq_no": 5,
  13.     "result": "deleted"
  14. }

版本控制

索引的每个文档都经过版本控制。当删除一个文档，可以指定 version，可以确保准备删除的相关文档确实被删除了，并在此期间未做修改。每一个删除操作，包括写操作，造成文档版本加一。删除文档的版本号在短期内仍然可用，以便控制并发操作。删除文档的版本号可见时间取决于索引的 index.gc_deletes 设置，默认为 60s。

路由

当索引时使用控制路由的功能时，为了删除文档，路由值也必须提供。如：

  1. curl -X DELETE "localhost:9200/twitter/_doc/1?routing=kimchy&pretty"

上面将删除 ID 为 1 的推文，但将根据用户进行路由。注意，发起一个没有正确路由值的删除操作，将会导致文档不被删除。

当 _routing 映射设置为 required，但是没有指定路由值，删除 API 会抛出一个 RoutingMissingException 异常，并拒绝请求。

自动索引创建

如果使用了一个外部的版本变量，如果之前未创建过索引，删除操作会自动创建一个（请查看 create index API 中手动创建索引的部分），如果之前尚未创建，也会自动为特定类型创建一个动态类型映射（请查看 put mapping API 中的手动创建类型映射）。

分散式

删除操作会哈希到一个特定的分片 ID。然后将其重定向到该 ID 组的主分片，并复制（如果需要）到该 ID 组中的分片副本。

等待活跃分片

当创建一个删除请求，可以设置 wait_for_active_shards 参数，要求最小数量的分片处于活跃状态，然后再开始处理删除请求。这里 查看更详细的细节，和使用范例。

刷新

控制这次请求的改变什么时候对搜索可见，看 ?refresh。

超时

执行删除操作时，分配给执行删除操作的主分片可能不可用。造成这种情况的原因有可能是主分片正在从存储中恢复，或者是正在进行重新布置。默认情况下，删除操作会等待主分片可用长达 1 min，然后才会失败，并返回错误。可以使用 timeout 参数显示的指定等待时间。下面是一个设置等待 5min 的例子：

  1. curl -X DELETE "localhost:9200/twitter/_doc/1?timeout=5m&pretty"