Оптимальный размер шардов: балансировка производительности кластера и управления им

Оптимальный размер шардов: баланс между производительностью кластера и управлением

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

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

Основы шардов Elasticsearch

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

Индекс: Коллекция документов. В Elasticsearch индекс делится на несколько шардов.
Шард: Единица распределения. Каждый шард представляет собой самодостаточный индекс Lucene. Индекс может содержать несколько шардов, распределенных между различными узлами в кластере.
Первичный шард: При создании индекса ему присваивается фиксированное количество первичных шардов. Эти шарды используются для индексации ваших данных. После создания количество первичных шардов не может быть изменено. Однако вы можете добавить больше реплик шардов.
Реплика шард: Копии ваших первичных шардов. Они обеспечивают избыточность и увеличивают пропускную способность чтения. В случае сбоя первичного шарда реплика может быть повышена до первичного. Количество реплик шардов может быть изменено в любое время.

Как шарды влияют на производительность

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

Ключевые соображения при определении размера шардов

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

1. Объем данных и скорость роста

Текущий размер данных: Сколько данных у вас сейчас в индексе?
Скорость роста: Как быстро растут ваши данные? Это помогает прогнозировать будущие размеры шардов.
Политика хранения данных: Будете ли вы удалять старые данные? Это влияет на эффективный размер активных данных.

2. Нагрузка индексации

Скорость индексации: Сколько документов в секунду вы индексируете?
Размер документа: Насколько велики отдельные документы в среднем?
Пропускная способность индексации: Могут ли ваши узлы обрабатывать нагрузку индексации с текущей конфигурацией шардов?

3. Шаблоны запросов

Сложность запросов: Ваши запросы — это простые поиски по ключевым словам или сложные агрегации?
Частота запросов: Как часто выполняются запросы к вашим данным?
Требования к задержке запросов: Каково ваше допустимое время отклика?

4. Топология кластера и ресурсы

Количество узлов: Сколько узлов в вашем кластере?
Аппаратное обеспечение узла: Процессор, оперативная память и диск (для Elasticsearch настоятельно рекомендуется SSD).
Лимит шардов на узел: Elasticsearch имеет ограничение по умолчанию на максимальное количество шардов, которое может содержать узел, чтобы предотвратить проблемы с производительностью. Это контролируется параметром cluster.routing.allocation.total_shards_per_node (по умолчанию 1000). Желательно, чтобы фактическое количество шардов было значительно ниже этого предела.

Рекомендации по распределению шардов

1. Стремитесь к целевому размеру шарда

Хотя нет волшебного числа, обычно рекомендуемый целевой размер шарда составляет от 10 ГБ до 50 ГБ. Этот диапазон часто представляет собой хороший баланс.

Слишком маленький (< 10 ГБ): Может привести к чрезмерным накладным расходам. Каждый шард имеет свой объем памяти и увеличивает нагрузку на мастер-узел. Управление тысячами крошечных шардов становится значительным операционным бременем.
Слишком большой (> 50 ГБ): Может вызвать проблемы с производительностью. Операции слияния сегментов, восстановления и перебалансировки занимают больше времени. Если большой шард выходит из строя, его восстановление может занять значительное время.

2. Рассмотрите индексы на основе времени

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

Пример: Вместо одного массивного индекса у вас могут быть logs-2023.10.26, logs-2023.10.27 и т. д.
Преимущества: Более простое управление данными (удаление старых индексов с помощью Index Lifecycle Management - ILM), лучшая производительность, поскольку запросы часто нацелены на недавние данные, и контролируемые размеры шардов.

3. Внедрите управление жизненным циклом индексов (ILM)

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

Горячая фаза: В индекс активно производится запись и к нему выполняются запросы. Максимизация производительности.
Теплая фаза: В индекс больше не производится запись, но к нему по-прежнему выполняются запросы. Может быть перемещен на менее производительное оборудование, возможно, с меньшим количеством реплик или сжат.
Холодная фаза: Запрашивается редко. Данные могут быть перемещены на более дешевое хранилище, с еще меньшим количеством реплик или заморожены.
Фаза удаления: Данные больше не нужны и удаляются.

4. Избегайте чрезмерного шардирования

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

Симптомы: Высокая загрузка ЦП на мастер-узлах, медленные обновления состояния кластера, длительное время восстановления и общая вялость.
Смягчение: Планируйте количество первичных шардов с самого начала. Для индексов на основе времени начинайте с разумного количества первичных шардов на индекс (например, 1 или 3). Реплики всегда можно добавить позже.

5. Не переиндексируйте

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

6. Учитывайте настройку `number_of_shards`

При создании индекса параметр number_of_shards определяет количество первичных шардов. Эта настройка неизменна после создания индекса.

PUT my-index
{
  "settings": {
    "index": {
      "number_of_shards": 3,  // Пример: 3 первичных шарда
      "number_of_replicas": 1   // Пример: 1 реплика шарда
    }
  }
}

Совет: Для небольших индексов или индексов с очень низкой нагрузкой индексации/запросов может быть достаточно одного первичного шарда. Для более крупных, более активных индексов 3 или 5 первичных шардов могут обеспечить лучшее распределение и отказоустойчивость, особенно если вы планируете разделить индекс позже (хотя разделение сложно).

7. Перебалансировка и перемещение

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

8. Настройка производительности запросов

Если производительность ваших запросов страдает, оцените свою стратегию шардирования. Рассмотрите:

Количество шардов: Слишком много шардов может увеличить накладные расходы на координацию.
Размер шарда: Очень большие шарды могут замедлить слияние сегментов и поиск внутри шарда.
Дизайн индекса: Используете ли вы подходящие сопоставления и анализаторы?

Расчет оптимального количества шардов

Единой формулы не существует, но вот распространенный подход:

Оцените общий объем данных на индекс за весь его жизненный цикл.
Определите целевой размер шарда (например, 30 ГБ).
Рассчитайте необходимое количество первичных шардов: Общий объем данных / Целевой размер шарда.
Округлите до ближайшего целого числа. Это даст вам number_of_shards для индекса.
- Пример: Если вы ожидаете 90 ГБ данных и стремитесь к шард размером 30 ГБ, вам потребуется 90 ГБ / 30 ГБ = 3 первичных шарда.
Рассмотрите отказоустойчивость и распределение: Для критически важных индексов рассмотрите использование 3 или 5 первичных шардов для лучшего распределения и возможностей восстановления, даже если ваш начальный объем данных этого строго не требует. Компромисс заключается в увеличении накладных расходов.
Начинайте консервативно: Обычно легче добавить реплики, чем изменить количество первичных шардов (что обычно требует переиндексации или сложных обходных путей). Если вы не уверены, начните с меньшего количества первичных шардов и отслеживайте производительность.

Пример сценария: Анализ логов

Предположим, вы индексируете логи приложений:

Объем данных: Вы ожидаете 1 ТБ логов в месяц.
Хранение данных: Вы храните логи в течение 30 дней.
Целевой размер шарда: Вы стремитесь к 20 ГБ.
Ежедневные индексы: Вы создаете ежедневные индексы (logstash-YYYY.MM.DD). Каждый ежедневный индекс будет содержать примерно 1 ТБ / 30 дней ≈ 33 ГБ данных.
Первичные шарды на индекс: Учитывая целевой размер 20 ГБ и ежедневный объем 33 ГБ, вы можете выбрать 2 первичных шарда на индекс (33 ГБ / 20 ГБ ≈ 1.65, округляется до 2). Это гарантирует, что отдельные шарды остаются в пределах вашего целевого размера.
Реплики: Вы выбираете 1 реплику для высокой доступности.
Общее количество шардов: За 30-дневный период хранения у вас будет 30 индексов, каждый с 2 первичными и 2 репликами шардов, что в сумме составляет 60 первичных и 60 реплик шардов, активных в любой момент времени.

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

Заключение

Оптимальный размер шардов в Elasticsearch — это непрерывный баланс. Понимая взаимосвязь между количеством шардов, размером шардов, нагрузкой индексации, шаблонами запросов и ресурсами кластера, вы можете принимать обоснованные решения. Отдавайте приоритет индексам на основе времени для данных временных рядов, используйте ILM для автоматического управления и всегда помните об операционных издержках управления шардами. Целевой размер шардов от 10 ГБ до 50 ГБ, при избегании чрезмерного шардирования, является хорошей отправной точкой. Регулярный мониторинг и настройка производительности обеспечат эффективность, масштабируемость и отказоустойчивость вашего кластера Elasticsearch по мере роста ваших данных.