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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, каждый сегмент требует небольшого объёма оперативной памяти для каждого отображенного поля. Эти накладные расходы оперативной памяти на сегмент-поле включают копию имени поля, закодированного в ISO-8859-1, если применимо, или в UTF-16 в противном случае. Обычно это незаметно, но вам может потребоваться учесть эти накладные расходы, если ваши фрагменты имеют большое количество сегментов, а соответствующие отображения содержат большое количество полей и/или очень длинные имена полей.

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

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

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

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

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

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

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

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

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

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

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

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

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

resp = client.cat.shards(
    v=True,
    h="index,prirep,shard,store",
    s="prirep,store",
    bytes="gb",
)
print(resp)

response = client.cat.shards(
  v: true,
  h: 'index,prirep,shard,store',
  s: 'prirep,store',
  bytes: 'gb'
)
puts response

const response = await client.cat.shards({
  v: "true",
  h: "index,prirep,shard,store",
  s: "prirep,store",
  bytes: "gb",
});
console.log(response);

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
...

Если фрагмент индекса испытывает ухудшение производительности из-за превышения рекомендуемого размера в 50 ГБ, вы можете рассмотреть возможность исправления размеров фрагментов индекса. Фрагменты неизменяемы, поэтому их размер фиксирован, поэтому индексы необходимо копировать с корректировкой настроек. Для этого необходимо сначала убедиться, что у вас достаточно места на диске для копирования данных. После этого вы можете скопировать данные индекса с корректировкой настроек, используя один из следующих вариантов:

Обратите внимание, что выполнение Восстановления снимка и/или Копирования индекса будет недостаточно для решения проблем с размером фрагментов.

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

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

В качестве общего правила, вы должны иметь меньше 3000 индексов на 1 ГБ кучи на мастер-узлах. Например, если ваш кластер имеет выделенные мастер-узлы с 4 ГБ кучи каждый, то вы должны иметь меньше 12000 индексов. Если ваши мастер-узлы не являются выделенными мастер-узлами, то те же рекомендации по размеру применяются: вы должны зарезервировать как минимум 1 ГБ кучи на каждом узле, подходящем для роли мастер-узла, на каждые 3000 индексов в вашем кластере.

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

Для проверки настроенного размера кучи каждого узла используйте API cat nodes.

resp = client.cat.nodes(
    v=True,
    h="heap.max",
)
print(resp)

response = client.cat.nodes(
  v: true,
  h: 'heap.max'
)
puts response

const response = await client.cat.nodes({
  v: "true",
  h: "heap.max",
});
console.log(response);

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

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

resp = client.cat.shards(
    v=True,
)
print(resp)

response = client.cat.shards(
  v: true
)
puts response

const response = await client.cat.shards({
  v: "true",
});
console.log(response);

GET _cat/shards?v=true

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

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

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

resp = client.cluster.stats(
    human=True,
    filter_path="indices.mappings.total_deduplicated_mapping_size*",
)
print(resp)

response = client.cluster.stats(
  human: true,
  filter_path: 'indices.mappings.total_deduplicated_mapping_size*'
)
puts response

const response = await client.cluster.stats({
  human: "true",
  filter_path: "indices.mappings.total_deduplicated_mapping_size*",
});
console.log(response);

GET _cluster/stats?human&filter_path=indices.mappings.total_deduplicated_mapping_size*

Это покажет вам информацию, подобную приведённому в этом примере выводу:

{
  "indices": {
    "mappings": {
      "total_deduplicated_mapping_size": "1gb",
      "total_deduplicated_mapping_size_in_bytes": 1073741824
    }
  }
}

Вы можете использовать API Nodes stats для получения двух релевантных метрик для каждого узла:

resp = client.nodes.stats(
    human=True,
    filter_path="nodes.*.name,nodes.*.indices.mappings.total_estimated_overhead*,nodes.*.jvm.mem.heap_max*",
)
print(resp)

response = client.nodes.stats(
  human: true,
  filter_path: 'nodes.*.name,nodes.*.indices.mappings.total_estimated_overhead*,nodes.*.jvm.mem.heap_max*'
)
puts response

const response = await client.nodes.stats({
  human: "true",
  filter_path:
    "nodes.*.name,nodes.*.indices.mappings.total_estimated_overhead*,nodes.*.jvm.mem.heap_max*",
});
console.log(response);

GET _nodes/stats?human&filter_path=nodes.*.name,nodes.*.indices.mappings.total_estimated_overhead*,nodes.*.jvm.mem.heap_max*

Для каждого узла это покажет вам информацию, подобную приведённому в этом примере выводу:

{
  "nodes": {
    "USpTGYaBSIKbgSUJR2Z9lg": {
      "name": "node-0",
      "indices": {
        "mappings": {
          "total_estimated_overhead": "1gb",
          "total_estimated_overhead_in_bytes": 1073741824
        }
      },
      "jvm": {
        "mem": {
          "heap_max": "4gb",
          "heap_max_in_bytes": 4294967296
        }
      }
    }
  }
}

Помимо двух метрик накладных расходов полей выше, вы должны дополнительно выделить достаточно кучи для базового использования Elasticsearch, а также для вашей рабочей нагрузки, такой как индексирование, поиск и агрегации. 0,5 ГБ дополнительной кучи будет достаточно для многих разумных рабочих нагрузок, и вам может потребоваться даже меньше, если ваша рабочая нагрузка очень низкая, в то время как для ресурсоёмких нагрузок может потребоваться больше.

В качестве примера рассмотрим вывод выше для узла данных. Куча узла должна иметь как минимум:

Поскольку максимальный размер кучи узла в примере составляет 4 ГБ, то этого достаточно для общего требуемого размера кучи в 2,5 ГБ.

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

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

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

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

resp = client.indices.put_settings(
    index="my-index-000001",
    settings={
        "index": {
            "routing.allocation.total_shards_per_node": 5
        }
    },
)
print(resp)

response = client.indices.put_settings(
  index: 'my-index-000001',
  body: {
    index: {
      'routing.allocation.total_shards_per_node' => 5
    }
  }
)
puts response

const response = await client.indices.putSettings({
  index: "my-index-000001",
  settings: {
    index: {
      "routing.allocation.total_shards_per_node": 5,
    },
  },
});
console.log(response);

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 и производите перенос индексов на основе порога max_age, вы можете непреднамеренно создать индексы без документов. Эти пустые индексы не приносят пользы, но всё ещё потребляют ресурсы.

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

resp = client.cat.count(
    index="my-index-000001",
    v=True,
)
print(resp)

response = client.cat.count(
  index: 'my-index-000001',
  v: true
)
puts response

const response = await client.cat.count({
  index: "my-index-000001",
  v: "true",
});
console.log(response);

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

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

resp = client.indices.delete(
    index="my-index-000001",
)
print(resp)

response = client.indices.delete(
  index: 'my-index-000001'
)
puts response

const response = await client.indices.delete({
  index: "my-index-000001",
});
console.log(response);

DELETE my-index-000001

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

resp = client.indices.forcemerge(
    index="my-index-000001",
)
print(resp)

response = client.indices.forcemerge(
  index: 'my-index-000001'
)
puts response

const response = await client.indices.forcemerge({
  index: "my-index-000001",
});
console.log(response);

POST my-index-000001/_forcemerge

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

ILM также имеет действие уменьшения для индексов в фазе подготовки.

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

resp = client.reindex(
    source={
        "index": "my-index-2099.10.*"
    },
    dest={
        "index": "my-index-2099.10"
    },
)
print(resp)

response = client.reindex(
  body: {
    source: {
      index: 'my-index-2099.10.*'
    },
    dest: {
      index: 'my-index-2099.10'
    }
  }
)
puts response

const response = await client.reindex({
  source: {
    index: "my-index-2099.10.*",
  },
  dest: {
    index: "my-index-2099.10",
  },
});
console.log(response);

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

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

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

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

resp = client.cluster.put_settings(
    persistent={
        "cluster.max_shards_per_node": 1200
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'cluster.max_shards_per_node' => 1200
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "cluster.max_shards_per_node": 1200,
  },
});
console.log(response);

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

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

resp = client.cluster.stats(
    filter_path="indices.shards.total",
)
print(resp)

response = client.cluster.stats(
  filter_path: 'indices.shards.total'
)
puts response

const response = await client.cluster.stats({
  filter_path: "indices.shards.total",
});
console.log(response);

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

При наличии долгосрочного решения рекомендуется сбросить лимит cluster.max_shards_per_node.

resp = client.cluster.put_settings(
    persistent={
        "cluster.max_shards_per_node": None
    },
)
print(resp)

response = client.cluster.put_settings(
  body: {
    persistent: {
      'cluster.max_shards_per_node' => nil
    }
  }
)
puts response

const response = await client.cluster.putSettings({
  persistent: {
    "cluster.max_shards_per_node": null,
  },
});
console.log(response);

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

Каждый фрагмент Elasticsearch — это отдельный индекс Lucene, поэтому он разделяет ограничение Lucene MAX_DOC на максимальное количество документов — 2 147 483 519 ((2^31)-129). Это ограничение на фрагмент относится к сумме docs.count плюс docs.deleted, как сообщается API статистики индекса. Превышение этого лимита приведёт к ошибкам, таким как:

Elasticsearch exception [type=illegal_argument_exception, reason=Number of documents in the shard cannot exceed [2147483519]]

Этот лимит значительно выше, чем рекомендуемое максимальное количество документов примерно 200 млн документов на фрагмент.

Если вы столкнулись с этой проблемой, попробуйте её решить, используя API принудительного слияния для объединения некоторых удалённых документов. Например:

resp = client.indices.forcemerge(
    index="my-index-000001",
    only_expunge_deletes=True,
)
print(resp)

const response = await client.indices.forcemerge({
  index: "my-index-000001",
  only_expunge_deletes: "true",
});
console.log(response);

POST my-index-000001/_forcemerge?only_expunge_deletes=true

Это запустит асинхронную задачу, которую можно отслеживать через API управления задачами.

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