Elasticsearch删除数据操作，你必须知道的一些坑

前两天有同事打电话问我，说ES删除数据有没有什么坑？

我当时就问，是删索引还是删索引里的数据？她回答说是删数据，我说查出这些数据直接删除就好了，没有什么坑。。。

后来想想，关于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

注意事项：对数据安全来说，能够使用单个命令来删除所有的数据可能会带来很可怕的后果，所以，为了避免大量删除，可以在elasticsearch.yml 配置文件中（或者动态配置中）修改 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": {
}
}
}

好了，本文先说到这里，有问题欢迎留言讨论。

参考：

https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html https://blog.csdn.net/u013066244/article/details/76258188