Руководство по определению размера шардов в Elasticsearch: Баланс между производительностью и масштабируемостью

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

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

Понимание шардов Elasticsearch

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

Первичные и реплика-шарды

Первичные шарды (Primary Shards): Они хранят фактические данные. Они отвечают за операции индексации и поиска. Определяя количество первичных шардов для индекса, вы решаете, как данные будут горизонтально распределяться по кластеру.
Реплика-шарды (Replica Shards): Это копии первичных шардов. Они обеспечивают избыточность (отказоустойчивость) и увеличивают пропускную способность поиска, позволяя обслуживать запросы как первичными, так и реплика-копиями.

Влияние количества шардов

Общее количество шардов (Первичные + Реплики) напрямую влияет на накладные расходы кластера. Каждый шард требует памяти (heap space) и ресурсов ЦП для отслеживания своего статуса и метаданных. Слишком большое количество мелких шардов перегружает мастер-узел и увеличивает накладные расходы на управление кластером, что приводит к снижению производительности, даже если отдельные шарды малы по размеру.

Ключевые ограничения и рекомендации по размеру

Не существует единого «волшебного числа» для размера шарда. Оптимальный размер сильно зависит от объема ваших данных, скорости индексации и шаблонов запросов. Однако документация Elasticsearch и лучшие практики сообщества предлагают несколько важных рекомендаций.

1. Пороговое значение размера: Оптимальный размер шарда

Наиболее важным фактором является размер данных, содержащихся в одном шарде.

Рекомендуемый максимальный размер: Общий консенсус и лучшая практика предполагают, что отдельные первичные шарды должны находиться в пределах от 10 ГБ до 50 ГБ.
Абсолютный максимум: Хотя это технически возможно, превышение 100 ГБ на шард настоятельно не рекомендуется, поскольку это создает нагрузку на операции восстановления, производительность индексации и стабильность кластера.

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

2. Пороговое значение количества документов

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

Рекомендуемый диапазон документов: Стремитесь к тому, чтобы шарды содержали от 100 000 до 5 миллионов документов.

Если ваши документы очень малы (например, несколько сотен байт), вы можете достичь лимита размера (50 ГБ) до достижения рекомендуемого количества документов. И наоборот, если документы очень большие (например, JSON-блоки размером в несколько мегабайт), вы можете быстро достичь лимита количества документов, оставаясь при этом в пределах лимита размера.

3. Накладные расходы кластера и количество шардов

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

Шардов на ГБ Heap: Распространенное руководство предполагает, что общее количество шардов (первичных + реплик) должно быть таким, чтобы кластер использовал примерно 20 шардов на 1 ГБ памяти кучи (heap), выделенной узлам данных.

Пример расчета: Если ваши узлы данных имеют выделенную память кучи 30 ГБ:

$$30 \text{ ГБ} \times 20 \text{ шардов/ГБ} = 600 \text{ шардов всего}$$

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

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

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

Шаг 1: Оценка общего размера индекса

Определите общий объем данных, который, по вашему мнению, будет хранить этот индекс за время его эксплуатации (например, 6 месяцев или 1 год).

Пример: Мы ожидаем хранить 2 ТБ данных для нашего индекса logs-2024.

Шаг 2: Определение целевого размера шарда

Выберите безопасный целевой размер на основе рекомендаций (например, 40 ГБ).

Пример: Целевой размер шарда = 40 ГБ.

Шаг 3: Расчет требуемых первичных шардов

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

$$\text{Первичные Шарды} = \text{Потолок} \left( \frac{\text{Общий Размер Индекса}}{\text{Целевой Размер Шарда}} \right)$$

Пример расчета (2 ТБ = 2048 ГБ):
$$\text{Первичные Шарды} = \text{Потолок} \left( \frac{2048 \text{ ГБ}}{40 \text{ ГБ}} \right) = \text{Потолок}(51.2) = 52$$

В этом сценарии вы должны создать индекс с 52 первичными шардами.

Шаг 4: Определение количества реплик

Определите количество реплик на основе ваших потребностей в отказоустойчивости и объеме поиска.

Отказоустойчивость: Установите number_of_replicas как минимум в 1 (для высокой доступности).
Производительность поиска: Если трафик поиска высок, используйте 2 или более реплик.
Пример: Мы выбираем 1 реплику для стандартной отказоустойчивости.

Окончательные настройки индекса: 52 первичных шарда и 1 реплика (всего 104 шарда).

Шаг 5: Распределение по узлам

Убедитесь, что в вашем кластере достаточно узлов (и достаточного объема памяти кучи), чтобы эффективно разместить эти шарды, сохраняя при этом правило 20 шардов/ГБ памяти кучи.

Управление жизненным циклом индекса и изменение размера

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

Роль управления жизненным циклом индекса (ILM)

Для временных данных (журналов, метрик) лучшей практикой является использование Управления жизненным циклом индекса (ILM) и функции Rollover (переключение).

Вместо создания одного огромного, сложного в управлении индекса, вы создаете псевдоним переключения (rollover alias), указывающий на шаблон.

Фаза Hot (Активная): Данные записываются в текущий активный индекс. ILM отслеживает этот индекс на основе размера или возраста (например, переключение, когда он достигает 40 ГБ).
Rollover (Переключение): Когда порог достигнут, Elasticsearch автоматически создает новый индекс на основе шаблона (с рассчитанным количеством первичных шардов) и переключает псевдоним, чтобы он указывал на новый индекс. Старый индекс переходит в другую фазу (Warm/Cold).

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

Когда необходимо повторное шардирование (Advanced)

Если существующий индекс значительно превышает рекомендуемые 50 ГБ из-за непредвиденных шаблонов данных, вам необходимо использовать API Reindex для исправления распределения шардов:

Создайте новый индекс с исправленной (оптимальной) конфигурацией шардов.
Используйте API Reindex для копирования всех данных из старого, неправильно настроенного индекса в новый.
Обновите псевдонимы, чтобы они указывали на новый индекс.
Удалите старый индекс.

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

Сводка лучших практик

Область	Лучшая практика / Рекомендация
Размер отдельного шарда	Держите первичные шарды в пределах 10 ГБ и 50 ГБ (максимум 100 ГБ).
Количество документов	Стремитесь к 100 тыс. – 5 млн. документов на шард (вторично по отношению к размеру).
Накладные расходы кластера	Ограничьте общее количество шардов (первичных + реплик) примерно 20 шардами на 1 ГБ памяти кучи на узлах данных.
Управление индексами	Используйте Управление жизненным циклом индекса (ILM) и Rollover для временных данных, чтобы обеспечить постоянное оптимальное определение размера.
Изменение размера	Не пытайтесь изменять количество первичных шардов в активных индексах; используйте API Reindex для миграции данных в новый индекс с правильным размером.

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