DeleteByQueryRequest can be used to delete documents from an index. It requires an
existing index (or a set of indices) on which deletion is to be performed.
The simplest form of a
DeleteByQueryRequest looks like this and deletes all documents
in an index:
By default version conflicts abort the
DeleteByQueryRequest process but you can just
count them with this:
You can limit the documents by adding a query.
It’s also possible to limit the number of processed documents by setting size.
DeleteByQueryRequest uses batches of 1000. You can change the batch size
DeleteByQueryRequest can also be parallelized using
DeleteByQueryRequest uses the
scroll parameter to control how long it keeps the
"search context" alive.
If you provide routing then the routing is copied to the scroll query, limiting the process to the shards that match that routing value.
In addition to the options above the following arguments can optionally be also provided:
When executing a
DeleteByQueryRequest in the following manner, the client waits
DeleteByQueryResponse to be returned before continuing with code execution:
BulkByScrollResponse bulkResponse = client.deleteByQuery(request, RequestOptions.DEFAULT);
Synchronous calls may throw an
IOException in case of either failing to
parse the REST response in the high-level REST client, the request times out
or similar cases where there is no response coming back from the server.
In cases where the server returns a
5xx error code, the high-level
client tries to parse the response body error details instead and then throws
ElasticsearchException and adds the original
ResponseException as a
suppressed exception to it.
DeleteByQueryRequest can also be done in an asynchronous fashion so that
the client can return directly. Users need to specify how the response or
potential failures will be handled by passing the request and a listener to the
asynchronous delete-by-query method:
The asynchronous method does not block and returns immediately. Once it is
ActionListener is called back using the
if the execution successfully completed or using the
onFailure method if
it failed. Failure scenarios and expected exceptions are the same as in the
synchronous execution case.
A typical listener for
delete-by-query looks like:
DeleteByQueryResponse contains information about the executed operations and
allows to iterate over each result as follows:
TimeValue timeTaken = bulkResponse.getTook(); boolean timedOut = bulkResponse.isTimedOut(); long totalDocs = bulkResponse.getTotal(); long deletedDocs = bulkResponse.getDeleted(); long batches = bulkResponse.getBatches(); long noops = bulkResponse.getNoops(); long versionConflicts = bulkResponse.getVersionConflicts(); long bulkRetries = bulkResponse.getBulkRetries(); long searchRetries = bulkResponse.getSearchRetries(); TimeValue throttledMillis = bulkResponse.getStatus().getThrottled(); TimeValue throttledUntilMillis = bulkResponse.getStatus().getThrottledUntil(); List<ScrollableHitSource.SearchFailure> searchFailures = bulkResponse.getSearchFailures(); List<BulkItemResponse.Failure> bulkFailures = bulkResponse.getBulkFailures();
Get total time taken
Check if the request timed out
Get total number of docs processed
Number of docs that were deleted
Number of batches that were executed
Number of skipped docs
Number of version conflicts
Number of times request had to retry bulk index operations
Number of times request had to retry search operations
The total time this request has throttled itself not including the current throttle time if it is currently sleeping
Remaining delay of any current throttle sleep or 0 if not sleeping
Failures during search phase
Failures during bulk index operation