Уровни данных

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

Используемые вами уровни данных и способ их использования зависят от категории данных.

Следующие уровни данных могут использоваться с каждой категорией данных:

Данные контента:

Данные временных рядов:

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

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

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

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

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

Горячий уровень — это входная точка Elasticsearch для данных временных рядов и хранит ваши самые последние и наиболее часто используемые данные временных рядов. Узлы горячего уровня должны быть быстрыми как для чтения, так и для записи, что требует больше аппаратных ресурсов и более быстрого хранения (SSD). Для отказоустойчивости индексы в горячем уровне должны быть настроены на использование одной или нескольких реплик.

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

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

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

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

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

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

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

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

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

Чтобы добавить теплый, холодный или замороженный уровень при создании развертывания:

Чтобы добавить уровень данных к существующему развертыванию:

Чтобы удалить уровень данных, см. Отключить уровень данных.

Для самостоятельно управляемых развертываний роль узла обработки данных каждого узла настраивается в elasticsearch.yml. Например, узлы с самой высокой производительностью в кластере могут быть назначены как на уровень контента, так и на горячий уровень:

node.roles: ["data_hot", "data_content"]

Настройка index.routing.allocation.include._tier_preference определяет, на какой уровень следует назначить индекс.

При создании индекса Elasticsearch по умолчанию устанавливает _tier_preference на data_content, чтобы автоматически назначить фрагменты индекса на уровень контента.

Когда Elasticsearch создаёт индекс как часть потока данных (потока данных), по умолчанию Elasticsearch устанавливает _tier_preference в data_hot, чтобы автоматически назначить фрагменты индекса на горячий уровень.

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

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

Это значение также может принимать несколько уровней в порядке предпочтения. Это предотвращает оставание индексов без назначения, если доступны узлы на предпочтительном уровне. Например, когда управление жизненным циклом индексов мигрирует индекс в холодную фазу, оно устанавливает _tier_preference в data_cold,data_warm,data_hot.

Чтобы удалить предпочтительное значение уровня данных, установите значение _tier_preference в null. Это позволит индексу назначиться на любой узел данных в кластере. Установка _tier_preference в null не восстановит значение по умолчанию. Обратите внимание, что в случае управляемых индексов действие миграции может применить новое значение вместо него.

Вы можете проверить текущее предпочтение уровня данных существующего индекса, получив его настройки для index.routing.allocation.include._tier_preference:

resp = client.indices.get_settings(
    index="my-index-000001",
    filter_path="*.settings.index.routing.allocation.include._tier_preference",
)
print(resp)

const response = await client.indices.getSettings({
  index: "my-index-000001",
  filter_path: "*.settings.index.routing.allocation.include._tier_preference",
});
console.log(response);

GET /my-index-000001/_settings?filter_path=*.settings.index.routing.allocation.include._tier_preference

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

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

ILM автоматически переносит управляемые индексы через доступные уровни данных с помощью действия миграции. По умолчанию это действие автоматически включено в каждую фазу. Вы можете явно указать действие миграции с помощью "enabled": false, чтобы отключить автоматическую миграцию, например, если вы используете действие назначения для ручного указания правил назначения.