Почему слияние сегментов в Elasticsearch требует остановки записи в индекс

Question

Я хочу запустить функцию оптимизации (ES 1.X), которая теперь известна как API Forcemerge в последней версии ES. После прочтения некоторых статей, таких как this и this . кажется, что мы должны запускать его только для индексов только для чтения, цитируя официальные документы ES:

Принудительное объединение должно вызываться только для индексов только для чтения. Выполнение принудительного слияния с индексом чтения-записи может привести к созданию очень больших сегментов (> 5 ГБ на сегмент)

Но я не понимаю причину

1. перевод индекса в режим «только чтение» перед запуском forcemerge или оптимизацией API.
2. Как объяснялось выше, ES делает c, это может привести к очень большим сегментам, что не должно быть так, как я понимаю, новые обновления сначала записываются в память, которые записываются в сегменты, когда происходит refre sh, так почему запись во время forcemerge может привести к очень большим сегментам?

Также есть ли обходной путь, если мы не хочу переводить индекс в режим только для чтения и по-прежнему запускать принудительное слияние для удаления удаления.

Дайте мне знать, если мне потребуется предоставить дополнительную информацию.

Answer 1

forcemerge может значительно повысить производительность ваших запросов, поскольку позволяет объединить существующее количество сегментов в меньшее количество сегментов, что более эффективно для запросов, так как сегменты ищутся последовательно. При слиянии также очищаются все документы, помеченные для удаления.

Слияние происходит регулярно и автоматически в фоновом режиме как часть ведения Elasticsearch на основе политики слияния.

Хитрость: только сегменты до 5 ГБ считаются политикой слияния. Используя API forcemerge с параметром, который позволяет указывать количество результирующих сегментов, вы рискуете, что результирующие сегменты станут больше 5 ГБ, что означает, что они больше не будут учитываться в будущих запросах на слияние. Пока вы не удаляете и не обновляете документы, в этом нет ничего плохого. Однако если вы продолжите удалять или обновлять документы, Lucene пометит старую версию ваших документов в существующих сегментах как удаленную и запишет новую версию ваших документов в новые сегменты. Если удаленные документы располагаются в сегментах размером более 5 ГБ, на них больше не производится уборка, т. Е. Документы, помеченные для удаления, никогда не будут очищены.

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

A refresh делает что-то другое: верно, что документы, которые вы хотите проиндексировать, сначала обрабатываются в памяти, а затем записываются на диск. Но структура данных, которая позволяет вам фактически найти документ («сегмент»), создается не сразу для каждого отдельного документа, поскольку это было бы крайне неэффективно. Сегменты создаются только при переполнении внутреннего буфера или при возникновении refresh. Активировав ссылку sh, вы сразу же сделаете документ доступным для поиска. Тем не менее, сначала сегмент живет только в памяти, поскольку, опять же, было бы крайне неэффективно сразу синхронизировать c каждый сегмент на диске сразу после его создания. Сегменты в памяти периодически синхронизируются с диском. Даже если вы отключите разъем до того, как произойдет синхронизация c с диском, вы не потеряете никакой информации, поскольку Elasticsearch поддерживает транслог, который позволит Elasticsearch «переиграть» все запросы на индексирование, которые еще не перешли в сегмент на диске. .