前几天同事打来电话，问ES删除数据有没有什么漏洞。
我那时问是删除索引还是删除索引中的数据。 她回答说要删除数据。 我说检测到这些数据后直接删除就可以了。 什么洞都没有。
稍后再想想，关于删除ES数据，迄今为止遇到过很多删除场景。 是否真的有洞，想想，真的有。
我维护的ES群集最大规模在180个节点以上，每天增加70亿个/10TB的日志数据，总容量为2PB，主要提供各种日志的存储、检索和分析。
以前，需要删除一些关键字的日志数据。 时间段最近半年。
这个集群索引是按日志类型进行天分划分的，所以半年内有很多索引。 根据用户提供的关键字搜索最近一个月的话，竟然达到2亿件，半年内达到12亿件，从1万件以上删除了12亿件。 ohmyga~~
该方式只能用_delete_by_query方式删除，如果删除大数据量_delete_by_query，则存在响应超时、集群负载过高、不稳定等各种问题，因此该方式
针对以上问题，我根据现有的经验和网络资料，整理一下ESS的删除操作，整理一下知识进行回顾
要删除数据，请删除索引(同时删除数据和表结构，其作用与MySQL中的DROP TABLE '表名'相同)，而不删除表结构(其作用与MySQL中的Delete语句相同)
一、删除索引：
要删除单个索引，请使用命令【DELETE /索引名称】
删除索引名称
要删除多个索引，请使用命令【DELETE /索引1、索引2】
Delete索引名称1、索引名称2
【DELETE /testindex*】删除以：testindex开头的所有索引文件(如果配置文件禁止，则无法使用此方法)；
Delete索引名称*
所有索引命令【DELETE /_all】(如果配置文件禁止，则此方法不可用)或删除【DELETE /*】)如果配置文件禁止，则此方法不可用)
Delete _all
注：对于数据安全来说，使用一个命令删除所有数据可能会产生可怕的结果，因此为了避免大量删除，可以在elasticsearch.yml配置文件中或在动态配置中使用action.destructivive
设置后，仅当使用特定名称删除索引时，才禁用使用_all或通配符删除索引。 (如果以上描述的配置文件禁止，则不能使用此方法。 ) ) ) ) ) ) ) ) ) ) ) ) )。
2 :删除数据：
1.根据主键删除数据。 【DELETE /索引名/类型名/主键编号】
Delete索引名称/文档名称/主键编号
2 )根据匹配条件删除数据((注意请求方式为开机自检) ) ) ) ) ) ) ) ) )。
POST索引名称/文档名称/_delete_by_query
{
' query':{
' term':{
' _id':100000100
}
}
}
如果想根据条件删除数据，可以用查询体组织条件。
启动时(删除开始时) _delete_by_query为索引) )数据库)的快照，使用内部版本号查找要删除的文档。 也就是说，如果文档在捕获快照和运行删除过程之间发生更改，则版本将发生冲突。 版本控制中匹配的文档将被删除。
由于internal版本控制不支持0作为有效数字，因此无法删除版本号为0的文档，请求将失败。
_delete_by_query运行时，将按顺序执行多个搜索请求以删除所有匹配的文档。 每次找到文档时，都会执行相应的批处理请求，并删除所有找到的文档。 如果搜索或批处理请求被拒绝，_delete_by_query将根据默认策略重试被拒绝的请求。 最多10次)。 达到最大重试次数后，_delete_by_query请求将中止，并在failures字段中响应所有故障。 已删除的仍将运行。 这意味着进程不会回滚，只会中断。
第一个请求失败导致中断，失败批处理请求的所有故障信息都记录在failures元素中。 我会回来的。 因此，失败的请求不少。
如果要计算存在多少版本冲突而不是中止，请在URL中设置conflicts=proceed，或在请求方中设置“conflicts': 'proceed”。
3 )删除所有数据()注意请求方式为开机自检，仅删除数据，不删除表结构) ) )。
post/test index/testtype/_ delete _ by _ query？ 预失真
{
' query': {
' match_all': {
}
}
}