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
注意事項：對資料安全來說，能夠使用單個命令來刪除所有的資料可能會帶來很可怕的後果，所以，為了避免大量刪除，可以在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刪除資料操作，你必須知道的一些坑