Elasticsearch删除数据操作，你必须知道的⼀些坑
⽬录
前两天有同事打电话问我，说数据有没有什么坑？
我当时就问，是删索引还是删索引⾥的数据？她回答说是删数据，我说查出这些数据直接删除就好了，没有什么坑。。。
后来想想，关于ES数据的删除，之前确实遇到过很多删除场景，如果真要说有没有所谓的坑，细想⼀下，还真有。
我维护过的ES集最⼤规模是180多个节点，每天增量70亿条/10TB的⽇志数据，总容量2PB+，主要是提供各类⽇志的存储、检索和分析⽤的。
之前遇到过⼀个需求就是删除某些关键字的⽇志数据，时间区间是最近半年。
因为这个集索引是按⽇志类型按天分的，半年有很多索引，根据⽤户提供的关键字搜了最近⼀个⽉的量居然有2亿条+，半年就是12亿+，从1万多亿条中删除12亿。。ohmyga~~
这种⽅式只能通过_delete_by_query⽅式进⾏删除，⼤数据量_delete_by_query的删除会导致响应超时，集负载过⾼或不稳定等各种问题，所以不建议⽤这种⽅式删除⼤量的数据。
针对以上问题，我根据已有经验及⽹上资料，整理了⼀下ES的删除操作，算是对知识做个整理回顾吧
删除数据分为两种：⼀种是删除索引（数据和表结构同时删除，作⽤同MySQL中 DROP TABLE "表名" ），另⼀种是删除数据（不删除表结构，作⽤同MySQL中Delete 语句）。
⼀：删除索引：
删除单个索引可以使⽤命令【DELETE /索引名称】
Delete 索引名称
删除多个索引可以使⽤命令【DELETE /索引1，索引2】
Delete 索引名称1，索引名称2
【DELETE /testindex*】：删除以testindex 开头的所有索引⽂件（如果配置⽂件中禁⽌后此⽅式不能使⽤）；
Delete 索引名称*
删除全部索引命令【DELETE /_all】（配置⽂件中禁⽌后此⽅式不能使⽤）或者【DELETE /*】（配置⽂件中禁⽌后此⽅式不能使⽤）
Delete _all
注意事项：对数据安全来说，能够使⽤单个命令来删除所有的数据可能会带来很可怕的后果，所以，为了避免⼤量删除，可以在l 配置⽂件中（或者动态配置中）修改action.destructive_requires_name: true
设置之后只限于使⽤特定名称来删除索引，使⽤_all 或者通配符来删除索引⽆效（上述中说明配置⽂件中禁⽌后此⽅式不能使⽤）】
⼆：删除数据：
1.：根据主键删除数据：【DELETE /索引名称/类型名称/主键编号】
Delete 索引名称/⽂档名称/主键编号
2：根据匹配条件删除数据：（注意请求⽅式是Post）
POST 索引名称/⽂档名称/_delete_by_query
{
"query":{
"term":{
"_id":100000100
}
}
}
如果你想根据条件来删除你的数据，则在Query查询体中组织你的条件就可以了。
当启动时（开始要删除时），_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，只删除数据，不删除表结构）
POST /testindex/testtype/_delete_by_query?pretty
{
"query": {
"match_all": {
mysql中delete语句}
}
}
原⽂地址:
转载：熊哥club → Elasticsearch删除数据操作，你必须知道的⼀些坑

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。