我当时就问,是删索引还是删索引里的数据?她回答说是删数据,我说查出这些数据直接删除就好了,没有什么坑。。。
后来想想,关于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.xiongge.club/1490.html
转载:熊哥club → Elasticsearch删除数据操作,你必须知道的一些坑