一、前言
在ES-head删除索引的时候常常出现很多问题,当大数据量删除的时候往往不是超时就是报错409冲突,具体内容是version conflict,required seqNo [],primary term [],but no document was found
出现这个的原因主要是因为使用随机_id,es内的乐观锁造成的删除不够完全,导致版本号冲突。乐观锁相关的说明可以参见博客Elasticsearch-并发冲突处理机制
网上有说要改用自定义的_id,但是其实不需要,当数据量大的时候也很难操作,找到了一种解决方案,就是在删除操作的时候加上一个字段?wait_for_completion=
false
可以参见博客ElasticSearch6:解决大批量删除数据,导致超时的问题
以下做法主要实现的就是:
①掩耳盗铃——超时与我无关别告诉我
②默默无闻——后台不停运行删除操作,不用我们手动
二、具体操作
1.添加字段?wait_for_completion=
false
这个时候的返回就变成了一个工作编号,接着在head索引页面观察数据量,发现数据量在减少,说明删除操作正在运行,但是由于不用返回信息,所以无法判断运行状况
2.重复提交请求
如果是在head页面操作,就可以把工作请求的频率设置为2s/次或者其他,会发现task编号不断刷新,相当于不停地运行新的删除请求,就算冲突多,也挡不住不停地删
设置2s一次是因为一秒的时候似乎有点太频繁,反而会卡住,发现task内容一直没有变动,包括head数据量也没有减少,可能2s会更合适一些
三、查看任务状态
要查看任务状态,就在网页端输入http://localhost:port/_task/task编码,可以发现目前还是一个正在运行的状态,若运行结束,completed将会显示true
其他
这可能不是最好的方法,运行起来依然效率很低,数据量减得很慢,大约5s钟删除2W的数据,但是比自己手动看着总是超时要舒服得多。我目前还没有找到更好的方式,有建议或经验的欢迎给我私信或者评论里探讨~
另外还有博客说可以用python编程实现,但是似乎有些复杂就没有研究
针对冲突问题,还有一种方式是说进行强制执行删除,可以用?conflicts=proceed,与前面的同理,加在_delete_by_query后面,但是我用这个方法似乎一直超时,也不知道和直接删除有什么区别,就没有使用了,可参见探究 | Elasticsearch如何物理删除给定期限的历史数据?
参考链接:
ElasticSearch6:解决大批量删除数据,导致超时的问题