我當時就問，是刪索引還是刪索引里的數據？她回答說是刪數據，我說查出這些數據直接刪除就好了，沒有什么坑。。。
后來想想，關於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刪除數據操作，你必須知道的一些坑