Настройка размера фрагментов

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

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

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

Лучший способ создать стратегию фрагментации — это провести бенчмаркинг своих производственных данных на производственном оборудовании с использованием тех же запросов и нагрузок индексирования, которые вы увидите в производстве. Для нашей рекомендуемой методологии посмотрите видео о количественной оценке размера кластера. По мере тестирования различных конфигураций фрагментов используйте инструменты мониторинга Elasticsearch в Kibana, чтобы отслеживать стабильность и производительность вашего кластера.

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

Учитывайте следующие моменты при построении стратегии фрагментации.

Большинство запросов обращаются к нескольким фрагментам. Каждый фрагмент выполняет поиск в одном потоке ЦП. Хотя фрагмент может выполнять несколько одновременных запросов, запросы по большому количеству фрагментов могут истощить пул потоков поиска узла. Это может привести к низкой пропускной способности и медленным скоростям поиска.

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

Сегменты играют важную роль в использовании ресурсов фрагмента. Большинство фрагментов содержат несколько сегментов, которые хранят данные индекса. Elasticsearch хранит метаданные сегментов в памяти JVM, чтобы они быстро извлекались для поиска. По мере роста фрагмента его сегменты сливаются в меньшее количество более крупных сегментов. Это уменьшает количество сегментов, а значит, меньше метаданных хранится в памяти.

Каждый сопоставленный поле также несёт определённую нагрузку с точки зрения использования памяти и места на диске. По умолчанию Elasticsearch автоматически создаст отображение для каждого поля в каждом документе, который он индексирует, но вы можете отключить это поведение, чтобы управлять своими отображениями.

Узлы кластера сгруппированы в уровни данных. В пределах каждого уровня Elasticsearch пытается распределить фрагменты индекса по максимально возможному количеству узлов. При добавлении нового узла или сбое узла Elasticsearch автоматически перераспределяет фрагменты индекса по оставшимся узлам уровня.

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

Удалённые документы не сразу удаляются из файловой системы Elasticsearch. Вместо этого Elasticsearch помечает документ как удалённый на каждом связанном фрагменте. Пометенный документ по-прежнему будет использовать ресурсы до его удаления во время периодического слияния сегментов.

Когда это возможно, удаляйте целые индексы вместо отдельных документов. Elasticsearch может сразу удалить удалённые индексы непосредственно из файловой системы и освободить ресурсы.

Потоки данных позволяют хранить данные временных рядов в нескольких индексах-носителях, основанных на времени. Вы можете использовать управление жизненным циклом индексов (ILM) для автоматического управления этими индексами-носителями.

Одним из преимуществ такой настройки является автоматическое переключение, которое создаёт новый индекс для записи, когда текущий достигает определённого max_primary_shard_size, max_age, max_docs или max_size порога. Когда индекс больше не нужен, вы можете использовать ILM для его автоматического удаления и освобождения ресурсов.

ILM также упрощает изменение вашей стратегии фрагментации со временем:

Каждый новый индекс-носитель — это возможность дальнейшей настройки вашей стратегии.

Более крупные фрагменты дольше восстанавливаются после сбоя. При выходе из строя узла Elasticsearch перебалансирует фрагменты узла по оставшимся узлам уровня данных. Этот процесс восстановления, как правило, включает копирование содержимого фрагмента по сети, поэтому восстановление фрагмента размером 100 ГБ займет вдвое больше времени, чем фрагмента размером 50 ГБ. В отличие от этого, мелкие фрагменты пропорционально более ресурсоёмки и менее эффективны при поиске. Поиск пятидесяти фрагментов по 1 ГБ потребует значительно больше ресурсов, чем поиск одного фрагмента размером 50 ГБ, содержащего те же данные.

Нет жёстких ограничений на размер фрагмента, но опыт показывает, что фрагменты размером от 10 ГБ до 50 ГБ, как правило, хорошо подходят для журналов и данных временных рядов. Возможно, вы сможете использовать более крупные фрагменты в зависимости от вашей сети и потребностей. Более мелкие фрагменты могут быть уместны для Enterprise Search и аналогичных сценариев использования.

Если вы используете ILM, установите порог действия переключения на 50gb, чтобы избежать фрагментов размером более 50 ГБ.

Чтобы увидеть текущий размер ваших фрагментов, воспользуйтесь API cat shards.

GET _cat/shards?v=true&h=index,prirep,shard,store&s=prirep,store&bytes=gb

Значение pri.store.size показывает общий размер всех основных фрагментов для индекса.

index                                 prirep shard store
.ds-my-data-stream-2099.05.06-000001  p      0      50gb
...

Количество фрагментов, которое может содержать узел данных, пропорционально объёму оперативной памяти узла. Например, узел с 30 ГБ оперативной памяти должен иметь не более 600 фрагментов. Чем ниже вы можете держать этот показатель, тем лучше. Если вы обнаружите, что ваши узлы превышают 20 фрагментов на 1 ГБ, рассмотрите возможность добавления другого узла.

Некоторые системные индексы для Enterprise Search практически пустые и редко используются. Из-за низкой нагрузки вы не должны учитывать фрагменты этих индексов при расчёте лимита фрагментов узла.

Чтобы проверить текущий размер кучи каждого узла, воспользуйтесь API cat nodes.

GET _cat/nodes?v=true&h=heap.current

Вы можете использовать API cat shards для проверки количества фрагментов на узел.

GET _cat/shards?v=true

Если слишком много фрагментов выделено на конкретном узле, узел может стать "горячей точкой". Например, если на одном узле находится слишком много фрагментов для индекса с высокой скоростью индексирования, узел, вероятно, столкнётся с проблемами.

Для предотвращения "горячих точек" используйте настройку индекса index.routing.allocation.total_shards_per_node для явного ограничения количества фрагментов на одном узле. Вы можете настроить index.routing.allocation.total_shards_per_node с помощью API изменения настроек индекса.

PUT my-index-000001/_settings
{
  "index" : {
    "routing.allocation.total_shards_per_node" : 5
  }
}

По умолчанию Elasticsearch автоматически создаёт отображение для каждого поля в каждом документе, который он индексирует. Каждое сопоставленное поле соответствует определённым структурам данных на диске, которые необходимы для эффективного поиска, извлечения и агрегирования по этому полю. Подробная информация о каждом сопоставленном поле также хранится в памяти. Во многих случаях эта нагрузка излишняя, потому что поле не используется ни в одном поиске или агрегировании. Используйте явное отображение вместо динамического отображения, чтобы избежать создания полей, которые никогда не используются. Если набор полей обычно используется вместе, рассмотрите использование copy_to для их объединения во время индексирования. Если поле используется редко, лучше сделать его временным полем.

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

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

Если вы используете ILM и ваша политика удержания это позволяет, избегайте использования порога max_age для действия rollover. Вместо этого используйте max_primary_shard_size, чтобы избежать создания пустых индексов или множества небольших фрагментов.

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

Если вы используете ILM и выполняете rollover индексов на основе порога max_age, вы можете непреднамеренно создать индексы без документов. Эти пустые индексы не приносят никакой пользы, но все равно потребляют ресурсы.

Вы можете найти эти пустые индексы с помощью API cat count.

GET _cat/count/my-index-000001?v=true

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

DELETE my-index-000001

Если вы больше не записываете в индекс, вы можете использовать API принудительного слияния для слияния меньших фрагментов в более крупные. Это может уменьшить нагрузку на фрагменты и улучшить скорость поиска. Однако принудительные слияния ресурсоемки. Если возможно, выполните принудительное слияние во внепиковые часы.

POST my-index-000001/_forcemerge

Если вы больше не записываете в индекс, вы можете использовать API сжатия индекса для уменьшения количества его фрагментов.

ILM также имеет действие сжатия для индексов в фазе тепловой обработки.

Вы также можете использовать API переиндексации для объединения индексов с аналогичными отображениями в один большой индекс. Для временных рядов данных вы можете переиндексировать индексы за короткие периоды времени в новый индекс, охватывающий более длительный период. Например, вы можете переиндексировать ежедневные индексы с октября с общим шаблоном индекса, например my-index-2099.10.11, в ежемесячный my-index-2099.10 индекс. После переиндексации удалите меньшие индексы.

POST _reindex
{
  "source": {
    "index": "my-index-2099.10.*"
  },
  "dest": {
    "index": "my-index-2099.10"
  }
}

Вот как решить распространённые ошибки, связанные с фрагментами.

Настройка кластера cluster.max_shards_per_node ограничивает максимальное количество открытых фрагментов для кластера. Эта ошибка указывает на то, что действие превысит этот предел.

Если вы уверены, что ваши изменения не дестабилизируют кластер, вы можете временно увеличить предел с помощью API изменения настроек кластера и повторить действие.

PUT _cluster/settings
{
  "persistent" : {
    "cluster.max_shards_per_node": 1200
  }
}

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

GET _cluster/stats?filter_path=indices.shards.total

Когда долгосрочное решение будет реализовано, рекомендуется сбросить предел cluster.max_shards_per_node.

PUT _cluster/settings
{
  "persistent" : {
    "cluster.max_shards_per_node": null
  }
}