?refresh

API индексации, обновления, удаления и Bulk поддерживают установку refresh для управления временем, когда изменения, внесённые этим запросом, станут видимыми для поиска. Доступные значения:

Если у вас нет веской причины ждать, пока изменения станут видимыми, всегда используйте refresh=false (значение по умолчанию). Самый простой и быстрый вариант — опустить параметр refresh из URL.

Если вам абсолютно необходимо, чтобы изменения, внесённые запросом, были видимы синхронно с запросом, вы должны выбрать между большей нагрузкой на Elasticsearch (true) и более длительным ожиданием ответа (wait_for). Вот несколько моментов, которые должны прояснить это решение:

Если запрос refresh=wait_for поступает, когда уже есть index.max_refresh_listeners (по умолчанию 1000) запросов, ожидающих обновления в этом фрагменте, этот запрос будет вести себя так, как будто у него был установлен refresh на true: он принудительно вызовет обновление. Это сохраняет обещание, что при возврате запроса refresh=wait_for его изменения будут видны для поиска, одновременно предотвращая неконтролируемое использование ресурсов для заблокированных запросов. Если запрос принудительно вызывал обновление из-за исчерпания слотов слушателей, то его ответ будет содержать "forced_refresh": true.

Массовые запросы занимают только один слот на каждом фрагменте, который они затрагивают, независимо от того, сколько раз они изменяют фрагмент.

Эти запросы создадут документ и немедленно обновят индекс, чтобы он стал видимым:

PUT /test/_doc/1?refresh
{"test": "test"}
PUT /test/_doc/2?refresh=true
{"test": "test"}

Эти запросы создадут документ, не выполнив никаких действий, чтобы сделать его видимым для поиска:

PUT /test/_doc/3
{"test": "test"}
PUT /test/_doc/4?refresh=false
{"test": "test"}

Этот запрос создаст документ и подождёт, пока он станет видимым для поиска:

PUT /test/_doc/4?refresh=wait_for
{"test": "test"}