1. Сравнительный анализ
Лучший способ определить идеальный размер сегмента — провести эксперименты. Выберите сервер, который максимально идентичен будущему боевому серверу, а затем:
- Настройте кластер Elasticsearch с 1 узлом.
- Индексируйте свои производственные данные.
- Измерьте скорость индексации с помощью инструмента сравнительного анализа (например, Rally).
Если время приема соответствует SLA или сферическим ожиданиям в вакууме, значит, все в порядке, и вы уже знаете будущие настройки. После этого сравните производительность запросов. Если они удовлетворяют требованиям к быстродействию, можно идти в бой. В противном случае нужно повторить бенчмаркинг с большим количеством сегментов или узлов, пока не достигнете своих SLA. Это наиболее точный способ определить размер сегмента конкретно для вашего случая. Если это слишком сложно, можно начать с большего количества шардов и/или большего количества нод и уменьшать масштаб.
2. Общие рекомендации
Эксперименты, конечно, хорошо, но есть также и общие рекомендации:
- Удалять индексы вместо отдельных документов;
- Использовать политику управления индексами (ILM);
- Для логирования обычно хорошо подходят шарды размером от 10 до 50 ГБ, а для операций поиска достаточно 20-25 ГБ;
- Учитывать общий размер JVM Heap. Нужно стремиться иметь 20 шардов на каждый ГБ JVM Heap;
- Избегать овершардинга на ноде;
- Следить за корректностью типов полей.
Удаляйте индексы, а не документы. Удаленные документы не удаляются сразу из файловой системы Elasticsearch. Вместо этого Elasticsearch помечает документ как удаленный на каждом связанном шарде. Отмеченный документ будет продолжать использовать ресурсы до тех пор, пока не будет удален во время периодического
слияния сегментов. По возможности, вместо документов удаляйте целые индексы. Elasticsearch сразу же удаляет такие индексы прямо из файловой системы и высвобождает ресурсы.
Используйте механизм Index Lifecycle Management (ILM). Преимущество этого механизма — автоматический перенос индексов, который создает новые индексы, когда текущий соответствует определенному порогу:
max_primary_shard_size,
max_age,
max_docs или
max_size. Когда индекс больше не нужен, можно использовать ILM для его автоматического удаления и освобождения ресурсов.
ILM также позволяет легко менять стратегию шардирования с течением времени:
- Хотите уменьшить количество шардов для новых индексов? Измените параметр index.number_of_shards в соответствующем шаблоне индекса потока данных.
- Хотите больше шардов или меньше реплицированных индексов? Увеличьте порог переноса в ILM.
- Нужны индексы, охватывающие более короткие интервалы? Компенсируйте увеличение количества шардов, удаляя старые индексы раньше. Это можно сделать, снизив пороговое значение min_age на фазе удаления удаления.
Управляйте размером шардов. Ключевая причина: большие шарды дольше восстанавливаются после сбоя. Когда нода выходит из строя, Elasticsearch перераспределяет шарды узла по оставшимся нодам с ролью data. Процесс восстановления обычно включает копирование содержимого шарда по сети, поэтому для восстановления шарда размером 100 ГБ потребуется в два раза больше времени, чем для шарда размером 50 ГБ. Напротив, маленькие шарды несут пропорционально больше накладных расходов и менее эффективны для поиска. Поиск по пятидесяти шардам размером 1 ГБ потребует значительно больше ресурсов, чем поиск по одному шарду размером 50 ГБ, содержащего те же данные. Золотую середину никто не отменял.
Жестких ограничений на размер шарда нет, но опыт показывает, что шарды размером от 10 до 50 ГБ обычно хорошо подходят для логов и данных временных рядов. Никто не запрещает использовать более крупные шарды в зависимости от возможностей сети и подходам к использованию Elasticsearch. Шарды меньшего размера могут подойти, например, для корпоративного поиска. Если вы используете ILM, установите пороговое значение
max_primary_shard_size для действия переноса равным 50 ГБ, чтобы избежать сегментов размером более 50 ГБ.
Текущий размер шардов можно узнать через API: