Elasticsearch中删除海量数据的最优实现方式是什么？

优先选择拆分为多个小请求执行，同时配置 max_docs 和 requests_per_second 参数的方案，具体对比和原因如下：

两种方案的核心差异 #

• 单个delete_by_query请求的问题：
  • 容错性极低：数十万级数据的删除请求一旦出现集群负载波动、网络抖动导致超时中断，已执行的删除进度不会保留，需要全量重新执行，重试成本极高。
  • 限流灵活性差：仅靠requests_per_second只能做固定粗粒度限流，无法根据集群实时的CPU、磁盘IO、分片负载动态调整速率，很容易抢占业务读写的集群资源。
  • 段合并压力集中：ES的删除为标记删除，真正的空间释放依赖后台段合并，单请求大量删除会触发集中式段合并，严重拖慢集群正常读写性能。
• 拆分小请求的优势：
  • 容错性强：单个小请求失败只需要重试对应批次即可，不需要全量重跑，还可以自行记录删除进度，中断后可续跑。
  • 限流更可控：可以根据集群实时负载动态调整每批的max_docs大小和requests_per_second速率，甚至随时暂停任务，对业务的影响可以降到最低。
  • 压力平摊：分批删除可以把段合并的压力均匀分散到更长的时间窗口，不会出现性能突降的情况。

额外优化提示：如果你要删除的数据属于按时间分片的历史索引，优先直接删除整个索引或分片，性能比delete_by_query高至少一个数量级。如果必须按条件删除，也可以先扫出符合条件的文档ID再走批量删除接口，能降低查询+删除的整体开销。

内容的提问来源于stack exchange，提问作者Jacky Wang