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

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

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

Ещё один момент состоит в том, что более крупные шарды дольше восстанавливаются после сбоя. Когда нода выходит из строя, Elasticsearch восстанавливает баланс между шардами. Этот процесс копирует содержимое шарда по сети, поэтому для восстановления шарда размером 100 ГБ потребуется в два раза больше времени, чем для шарда размером 50 ГБ. В отличие от этого, маленькие хранилища несут пропорционально больше накладных расходов и менее эффективны при поиске. Поиск в пятидесяти хранилищах размером 1 ГБ займет значительно больше ресурсов, чем поиск в одном хранилище размером 50 ГБ, содержащем те же данные. Важен баланс.

Не существует жестких ограничений на размер шарда, но опыт показывает, что для логов и данных временных рядов обычно подходят шарды размером от 10 до 50 ГБ. Вы можете определять размеры шардов в зависимости от ёмкости сети и условий использования. Если используете ILM, установите порог max_primary_shard_size действия rollover на 50 ГБ, чтобы избежать использования шардов размером более 50 ГБ. А чтобы узнать текущий размер шардов, используйте cat shards API.

Запомнить:

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

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

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

Если тема вам интересна, рекомендуем пару статей к прочтению:

How many shards should I have in my Elasticsearch cluster? (блог Elastic)
Size your shards (документация Elastic)