Delete API
Тема дорожной карты · Elasticsearch
Delete API в Elasticsearch удаляет отдельный документ из индекса по его уникальному идентификатору через эндпоинт DELETE /<index>/_doc/<id>. При вызове Delete API Elasticsearch помечает документ как удалённый в файлах сегментов шарда; физическое удаление происходит только при последующем объединении сегментов Lucene в фоновом режиме. Ответ включает поле result со значением "deleted" при успехе или "not_found", если документа с таким идентификатором в индексе не существовало. Elasticsearch также поддерживает POST /<index>/_delete_by_query для удаления всех документов, соответствующих произвольному запросу Query DSL; внутренне этот метод выдаёт отдельные запросы удаления и в целом работает медленнее, чем одиночный Delete API. Для массового удаления включение действий удаления в запрос POST /_bulk эффективнее, чем многократные вызовы Delete API по одному или операция delete-by-query.
Как это работает
Delete API: Index API (PUT /index/_doc/id — create/replace), Get API (GET /index/_doc/id), Update API (POST /index/_update/id — partial update через script или doc), Delete API (DELETE /index/_doc/id), Bulk API (POST /_bulk с newline-delimited actions). Bulk обязателен для high-throughput индексации — single-doc indexing жжёт ресурсы. ES near real-time (NRT): writes ищутся через ~1 секунду (refresh interval).
Когда применять
Bulk API для любой sustained индексации — batch 5-15MB типично. Тюньте refresh_interval в -1 во время bulk-загрузок, потом 1s для normal use — экономит IO + heap. Updates в ES = delete + re-index под капотом — частые updates фрагментируют индексы. Для deletes — reindex-with-filter лучше многих delete-by-query.
Типичные ошибки
Ловушки Delete API: single-doc indexing в hot loop (кластер ползёт); Bulk batches слишком большие (>100MB — OOM); не handle bulk partial failures (часть items падают, игнор); update API для очень частых updates (delete+re-index churn).