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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаг 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: Распределение по узлам

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

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

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

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

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

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

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

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

Когда необходимо повторное шардирование (продвинутый уровень)

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

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

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

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

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

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