Как работает эластичный поиск delete_by_query? Что происходит, когда мы вставляем новые данные и извлекаем их при удалении документов?

1. Как в doc: Также можно ограничить количество обрабатываемых документов, установив размер. запрос.setSize(10); Что означает обработанный документ? Будет ли удалено только 10 документов?

Если вы еще этого не сделали, прочитайте search/_scroll документация. _delete_by_query выполняет поиск по прокрутке, используя запрос, указанный в качестве параметра.

Параметр size соответствует количеству документов, возвращаемых каждым вызовом конечной точки scroll. Если у вас есть 10 документов, соответствующих вашему запросу, и размер 2, elasticsearch внутренне выполнит 5 вызовов search/_scroll (т. е. 5 пакетов), а если вы установите размер 5, будут выполнены только 2 вызова search/_scroll.

Независимо от параметра size все документы, соответствующие запросу, будут удалены, но это будет более или менее эффективно.

2. Какой размер партии я должен установить? запрос.setBatchSize(100); его производительность зависит от того, сколько документов мы собираемся удалить?

Метод setBatchSize() эквивалентен установке параметра size в запросе. Чтобы узнать, правильное значение параметра размера.

3. Должен ли я сначала сделать вызов, чтобы не получить документы, и на основе этого setBatchSize должен быть изменен?

Вам придется дважды запустить поисковый запрос, чтобы получить количество удаленных документов, я думаю, что это будет неэффективно. Советую найти и придерживаться постоянного значения.

4. Срезы должны зависеть от того, сколько ядер у машины-исполнителя или от количества ядер в эластичном кластере?

Количество срезов должно быть задано в конфигурации кластера elasticsearch. Это также для распараллеливания поиска как между осколками, так и внутри осколков.

Вы можете прочитать документацию, чтобы узнать, как установить этот параметр. Обычно количество осколков для вашего index.

5. В документации указан метод setSlices(2), который я не могу найти в классе org.elasticsearch.index.reindex.DeleteByQueryRequest. Что мне здесь не хватает?

Вы правы, это, вероятно, ошибка в документации. Я никогда не пробовал, но я считаю, что вам следует использовать forSlice(TaskId slicingTask, SearchRequest slice, int totalSlices).

6. Давайте рассмотрим, выполняю ли я этот запрос на удаление в асинхронном режиме, который занимает 0,5-1,0 секунды, между тем, если я делаю запрос на получение этого индекса, выдаст ли это какое-то исключение? Также в то же время, если я вставлю новый документ и извлеку его, сможет ли он дать ответ?

Во-первых, как указано в документации, конечная точка _delete_by_query создает снимок индекса и работает с этой копией.

Для запроса get это зависит от того, был ли документ уже удален или нет. Он никогда не отправит исключение, вы просто получите тот же результат, если вы извлекаете существующий или несуществующий документ. Обратите внимание, что если вы не укажете sort в поисковом запросе, порядок удаления документов не определяется.

Если вы вставляете (или обновляете) документ во время обработки, этот документ не будет учитываться конечной точкой _delete_by_query, даже если он соответствует запросу _delete_by_query. Здесь используется снимок. Поэтому, если вы вставите новый документ, вы сможете получить его. То же самое, если вы обновите существующий документ, документ будет создан снова, если он уже был удален или обновлен, но не удален, если он еще не удален.

В качестве примечания: удаленные документы по-прежнему будут доступны для поиска (даже после завершения задачи delete_by_query) до refresh произошла операция.

_delete_by_query не поддерживает параметр refresh. request return, упомянутый в документации для операции refresh, относится к запросам, которые могут иметь параметр обновления. Если вы хотите принудительно обновить, вы можете использовать _refresh конечная точка. По умолчанию операция обновления выполняется каждую секунду. Таким образом, после завершения операции _delete_by_query не более чем через 1 секунду удаленные документы не будут доступны для поиска.