经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置：技术经验 » 程序设计 » Elasticsearch » 查看文章
elasticsearch6.7 05. Document APIs（5）Delete By Query API
来源：cnblogs　　作者：说_不_得　　时间：2019/4/15 9:10:56　　对本文有异议

4、Delete By Query API

_delete_by_query API可以删除某个匹配条件的文档：

  1. POST twitter/_delete_by_query
  2. {
  3.   "query": { 
  4.     "match": {
  5.       "message": "some message"
  6.     }
  7.   }
  8. }

query字段的语法规则和 Search API一样。你也可以传递和search API一样的q参数

返回结果：

  1. {
  2.   "took" : 147,
  3.   "timed_out": false,
  4.   "deleted": 119,
  5.   "batches": 1,
  6.   "version_conflicts": 0,
  7.   "noops": 0,
  8.   "retries": {
  9.     "bulk": 0,
  10.     "search": 0
  11.   },
  12.   "throttled_millis": 0,
  13.   "requests_per_second": -1.0,
  14.   "throttled_until_millis": 0,
  15.   "total": 119,
  16.   "failures" : [ ]
  17. }

_delete_by_query 在查找的时候会先获取索引的快照，并删除那些使用内部版本类型的文档。这意味着如果文档在获取快照和处理删除请求之间被修改了，就会造成版本号冲突。

当版本匹配时，文档将被删除。

因为内部版本不支持0，所以使用_delete_by_query将无法删除版本号为0的文档。

_delete_by_query 执行期间，会分多次顺序查询要删除的文档。每次查询完之后就会使用批处理一次性删除本批次的文档。如果在这个过程中的某次搜索或删除操作失败，默认会重试10次（速度呈指数下降）。当重试次数达到最大值的时候，_delete_by_query操作就会终止，并在响应中返回所有失败（failures字段）信息。已经执行的删除操作依然是生效的。换句话说，这个处理过程是不会回滚的，只会中止。因此其中的一些文档有可能删除失败。

如果你不想因为版本冲突导致操作中断，你可以在url中设置conflicts=proceed或者在请求体中设置conflicts:proceed。

下例将删除twitter索引里面的所有tweets:

  1. POST twitter/_doc/_delete_by_query?conflicts=proceed
  2. {
  3.   "query": {
  4.     "match_all": {}
  5.   }
  6. }

你也可以一次删除多个索引和多个类型的文档：

  1. POST twitter,blog/_docs,post/_delete_by_query
  2. {
  3.   "query": {
  4.     "match_all": {}
  5.   }
  6. }

如果你提供routing参数，该参数会被放在到scroll查询中，只删除满足routing条件的分片中的文档。

  1. POST twitter/_delete_by_query?routing=1
  2. {
  3.   "query": {
  4.     "range" : {
  5.         "age" : {
  6.            "gte" : 10
  7.         }
  8.     }
  9.   }
  10. }

默认情况下，_delete_by_query使用scroll query api查询1000个文档，你可以指定scroll_size参数来修改它：

  1. POST twitter/_delete_by_query?scroll_size=5000
  2. {
  3.   "query": {
  4.     "term": {
  5.       "user": "kimchy"
  6.     }
  7.   }
  8. }

4.1 URL参数（URL Parameters）

_delete_by_query API 同样支持refresh, wait_for_completion, wait_for_active_shards,timeout，scroll、pretty等参数。

  • refresh参数
    • 执行完删除操作后刷新_delete_by_query中查询涉及的分片。与delete API不同，delete API只会刷新接收到删除请求的分片。refresh参数不支持wait_for。
  • wait_for_completion
    • 如果请求中wait_for_completion=false，那么elasticsearch将会执行预检查、执行请求，然后返回可与任务API一起使用的任务，以取消或获取任务的状态。elasticsearch还将在.task/task/${taskId}处创建此任务的记录文档。您可以根据需要保留或删除该文档。用完删除后，elasticsearch可以回收其占用的空间。
  • wait_for_active_shards
    • 控制在执行请求前需要有几个可用的分片数。
  • timeout
    • 控制每个请求等待分片从不可用状态到可用状态的时间。因为_update_by_query 使用滚动搜索，所以可以指定 scroll 参数来控制它使 “搜索上下文” 保持活动的时间，例如：scroll=10m。默认情况下，它是 5 分钟。
  • request_per_second
    • 可以设置成任意正数（如1.4，6,1000等），通过设置等待的时间来控制_delete_by_query批量操作执行删除操作的速率。设置requests_per_second设置为-1表示停用该限制。

速率限制是通过在批量处理之间等待来完成的，这样就可以为_delete_by_query内部使用的回滚指定一个考虑填充的超时时间。填充时间是批处理大小除以requests_per_second与写入时间只差。默认情况下，批处理大小为1000，因此如request_per_second设置为500：

  1. target_time = 1000 / 500 per second = 2 seconds
  2. wait_time = target_time - write_time = 2 seconds - .5 seconds = 1.5 seconds

由于该批操作是通过_bulk请求发出的，因此大批量的请求将导致ElasticSearch创建多个请求，然后在启动下一个集合之前等待一段时间。这是“突发”而不是“平稳”。默认值为-1。

4.2 响应体（Response body）

  1. {
  2.   "took" : 147,
  3.   "timed_out": false,
  4.   "total": 119,
  5.   "deleted": 119,
  6.   "batches": 1,
  7.   "version_conflicts": 0,
  8.   "noops": 0,
  9.   "retries": {
  10.     "bulk": 0,
  11.     "search": 0
  12.   },
  13.   "throttled_millis": 0,
  14.   "requests_per_second": -1.0,
  15.   "throttled_until_millis": 0,
  16.   "failures" : [ ]
  17. }
  • took
    • 整个操作耗费的毫秒数
  • timed_out
    • 如果在执行 delete by query 操作时出现超时，那么这个标识将会返回true
  • total
    • 成功执行操作的文档的数量
  • deleted
    • 成功的删除了多少个文档
  • batches
    • 回滚数
  • verison_conflicts
    • 操作过程中出现版本冲突的数量
  • noops
    • 执行_delete_by_query时这个值始终是0，之所以存在是因为_delete_by_query、update_by_query、reindex APIs都返回相同的响应结构。
  • retries
    • 重复尝试的次数，bulk 是批量更新操作重复尝试的次数，search 是查询的重复尝试次数
  • throthled_millis
    • requests_per_second 参数引起的请求等待时间
  • requests_per_second
    • 在操作过程中，每秒执行的请求数
  • throttled_until_millis
    • 执行_delete_by_query时这个值始终0，只在在调用Task API时该值才有意义，它表示下一次（自纪元以来）为了符合requests_per_second，将再次执行请求的毫秒数。
  • failures
    • 执行失败的数组，包含在执行过程中任何不可恢复的错误。如果这个数组不是空的，那么请求会因为这些失败而中止。_delete_by_query是使用批处理实现的，任何失败都会导致整个执行被中止。可以使用conflicts参数来防止reindex在版本冲突时造成操作中止。

4.3 结合taskAPi使用（Works with the Task API）

您可以使用Task API获取任何正在进行_delete_by_query请求的状态：

  1. GET _tasks?detailed=true&actions=*/delete/byquery

返回值：

  1. {
  2.   "nodes" : {
  3.     "r1A2WoRbTwKZ516z6NEs5A" : {
  4.       "name" : "r1A2WoR",
  5.       "transport_address" : "127.0.0.1:9300",
  6.       "host" : "127.0.0.1",
  7.       "ip" : "127.0.0.1:9300",
  8.       "attributes" : {
  9.         "testattr" : "test",
  10.         "portsfile" : "true"
  11.       },
  12.       "tasks" : {
  13.         "r1A2WoRbTwKZ516z6NEs5A:36619" : {
  14.           "node" : "r1A2WoRbTwKZ516z6NEs5A",
  15.           "id" : 36619,
  16.           "type" : "transport",
  17.           "action" : "indices:data/write/delete/byquery",
  18.           "status" : {    
  19.             "total" : 6154,
  20.             "updated" : 0,
  21.             "created" : 0,
  22.             "deleted" : 3500,
  23.             "batches" : 36,
  24.             "version_conflicts" : 0,
  25.             "noops" : 0,
  26.             "retries": 0,
  27.             "throttled_millis": 0
  28.           },
  29.           "description" : ""
  30.         }
  31.       }
  32.     }
  33.   }
  34. }

status：这个对象包含了当前任务的实际状态。total字段是本次操作需要重新索引的文档数。你可以通过updated, created, and deleted字段估计处理进度。当以上几个字段的和等于total字段时，请求就执行完毕了。

你可以使用 task id 查看某个任务。下例查看task id为 r1A2WoRbTwKZ516z6NEs5A：36619的任务信息：

  1. GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619

如果在执行delete_by_query的时候指定了wait_for_completion=false参数，就可以通过该API查看任务的执行情况。

该 API 可以与wait_for_comletion=false集成使用，可以清晰的查看已完成任务的状态。如果任务已经完成，并且在其上设置了wait_for_completion=false，那么请求将会返回结果或是错误字段。此功能的代价是当wait_for_completion=false时会在.tasks/task/${taskId}目录下会创建文档。您可以根据需要删除该文档。

4.4 取消任务(Works with the Cancel Task API)

任何delete_by_query操作都可以通过task cancel API来取消，如：

  1. POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel

取消应该执行很快，但可能需要几秒钟。在此期间上面的 task status API将继续列出该任务，直到它完全被取消了。

4.5 阈值(Rethrottling)

在正在执行的请求中，requests_per_second的值可以在运行时通过_rethrotted API进行修改：

  1. POST _delete_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1

可以使用tasks API找到任务ID。

4.6 切片(slicing)

delete_by_query 支持 sliced scroll 来使删除操作并行进行，这能提高效率并且提供了一种将请求分解为较小的部分的便捷方式。

4.6.1 手动切片(Manually slicing)

通过为每个请求提供切片ID和切片总数，手动将_delete_by_query 操作进行分解：

  1. POST twitter/_delete_by_query
  2. {
  3.   "slice": {
  4.     "id": 0,
  5.     "max": 2
  6.   },
  7.   "query": {
  8.     "range": {
  9.       "likes": {
  10.         "lt": 10
  11.       }
  12.     }
  13.   }
  14. }
  15. POST twitter/_delete_by_query
  16. {
  17.   "slice": {
  18.     "id": 1,
  19.     "max": 2
  20.   },
  21.   "query": {
  22.     "range": {
  23.       "likes": {
  24.         "lt": 10
  25.       }
  26.     }
  27.   }
  28. }

你可以这样验证上述api的结果：

  1. GET _refresh
  2. POST twitter/_search?size=0&filter_path=hits.total
  3. {
  4.   "query": {
  5.     "range": {
  6.       "likes": {
  7.         "lt": 10
  8.       }
  9.     }
  10.   }
  11. }

返回如下的的结果：

  1. {
  2.   "hits": {
  3.     "total": 0
  4.   }
  5. }

4.6.2 自动切片(Automatic slicing)

也可以让delete by query 自动并行地滚动切片。使用slices 指定要使用的切片数：

  1. POST twitter/_delete_by_query?refresh&slices=5
  2. {
  3.   "query": {
  4.     "range": {
  5.       "likes": {
  6.         "lt": 10
  7.       }
  8.     }
  9.   }
  10. }

你可以这样验证上述api的结果：

  1. POST twitter/_search?size=0&filter_path=hits.total
  2. {
  3.   "query": {
  4.     "range": {
  5.       "likes": {
  6.         "lt": 10
  7.       }
  8.     }
  9.   }
  10. }

返回如下的的结果：

  1. {
  2.   "hits": {
  3.     "total": 0
  4.   }
  5. }

slices 设置为 auto 将允许 ElasticSearch 选择要使用的切片数。此设置将使用一个分片一个切片，直至达到某个限制。如果存在多个源索引，它将根据具有最少分片的那个索引所拥有的分片数来作为切片数。

向_delete_by_query添加slices 只会自动执行上一节中使用的手动过程，这意味着它有一些怪癖：

  • 您可以在 Tasks API 中查看这些请求。这些子请求是具有slices 请求的任务的“子"任务。
  • 仅使用slices 获取请求的任务状态(包含已完成切片的状态)。
  • 这些子请求可单独寻址，例如取消和重新限制。
  • 使用slices 重新处理请求将按比例重新调整未完成的子请求。
  • 使用slices 取消请求将取消每个子请求。
  • 由于slices 的性质，每个子请求都不会获得完全均匀的文档部分。这些切片文档都会被处理，但某些切片可能比其他切片分到更大的文档。
  • 像 requests_per_second 这样的参数和带有size的slices请求(按指定比例分配给每个子请求)。将其与上述关于分布不均匀的点相结合，您应该得出结论，使用slices的size可能不会删除指定大小的文档。
  • 每个子请求都会获得和源索引略有不同的快照，尽管这些快照几乎同时进行。

4.6.3 选择切片的数量(Picking the number of slices)

如果设置 slices 为自动切片，elasticsearch 将为大多数索引选择一个合理的数量。如果您是设置手动切片或以其他方式来调整自动切片，请使用以下准则：

当切片的数量等于索引的分片数时，查询性能最好。如果这个数量太大（如 500）, 请选择一个较小的数字，因为太多的切片会影响性能。设置高于分片数的切片通常不会提高效率反而会增加开销。

删除的性能与可用的切片数量呈正相关。

查询或删除是否是影响此时运行时性能的主要原因，这取决于reindexed时的文档和集群的资源。

原文链接：http://www.cnblogs.com/wtc1994/p/10705549.html

 友情链接：直通硅谷 　点职佳 　北美留学生论坛

Elasticsearch热门文章

  • ES 14 - (底层原理) Elasticsearch内部如何处理不同type的数据
  • ES 15 - Elasticsearch中的数据类型 (text、keyword、date、geo等)
  • java中elasticsearch7.x关于nested类型的api使用，新增+更新
  • Elasticsearch 映射参数详解 fields
  • [Elasticsearch] ES聚合场景下部分结果数据未返回问题分析
  • ES 22 - Elasticsearch中如何进行日期(数值)范围查询
  • Elasticsearch查询之Term?Query示例解析
  • ElasticSearch 实现分词全文检索 - SpringBoot 完整实现 Demo 附源码【完结篇】
  • ElasticStack学习（十）：深入ElasticSearch搜索之QueryFiltering、多/单字符串的多字段查询
  • ElasticSearch7 设置外网访问

    • Elasticsearch推荐文章

  • 利用Elasticsearch实现地理位置、城市搜索服务
  • 日志采集/分析
  • ELKF（elasticsearch、logstash、kibana、filebeat）搭建及收集nginx日志特昂糖-
  • ElasticSearch性能原理拆解
  • Elasticsearch使用实战以及代码详解
  • 使用 Docker Compose V2 快速搭建日志分析平台 ELK (Elasticsearch、Logstash 和 Kibana)
  • 【解决方案】MySQL5.7 百万数据迁移到 ElasticSearch7.x 的思考
  • K8s部署轻量级日志收集系统EFK（elasticsearch + filebeat + kibana）
  • Docker下elasticsearch8部署、扩容、基本操作实战(含kibana)
  • Elasticsearch 保姆级入门篇

    • 本站QQ群：前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

    W3xue 的所有内容仅供测试，对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
    关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接（目前9元/月）请联系QQ：27243702 沸活量
    皖ICP备17017327号-2　皖公网安备34020702000426号