Ответ 1

Есть три условия, которые вы рассматриваете перед тем, как охарактеризовать.

Ситуация 1). Вы хотите использовать elasticsearch с отказоустойчивостью и высокой доступностью. Тогда вы идете на осколки. В этом случае вам нужно выбрать количество черепов в соответствии с количеством узлов [ES instance], которые вы хотите использовать в процессе производства.

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

Ситуация 2) Ваш текущий сервер будет хранить текущие данные. Но из-за увеличения динамических данных в будущем вы можете не иметь места на диске или ваш сервер не может обрабатывать много данных, тогда вам нужно настроить больше не осколков, как 2 или 3 осколка (до ваших требований) для каждого индекса. Но не должно быть никакой реплики.

Ситуация 3) В этой ситуации вы комбинируете ситуацию 1 и 2. тогда вам нужно объединить обе конфигурации. Подумайте, что ваши данные динамически увеличиваются, а также вам необходима высокая доступность и отказоустойчивость. Затем вы настраиваете индекс с двумя осколками и 1 репликой. Затем вы можете обмениваться данными между узлами и получать оптимальную производительность..!

Примечание.. Затем запрос обрабатывается в каждом осколке и выполняет mapreduce по результатам всех осколков и возвращает результат нам. Таким образом, процесс сокращения карты - дорогостоящий процесс. Минимальные осколки дают нам оптимальную производительность

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

Надеюсь, это поможет..!

Ответ 2

Я опаздываю на вечеринку, но я просто хотел бы отметить пару вещей:

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

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

Наконец, следует отметить, что более 1 осколок на node будет вводить соображения ввода-вывода. Поскольку каждый осколок должен быть проиндексирован и запрошен индивидуально, node с 2 или более осколками потребует 2 или более отдельных операций ввода-вывода, которые нельзя запускать одновременно. Если у вас есть SSD на ваших узлах, фактическая стоимость этого может быть уменьшена, так как все операции ввода-вывода происходят намного быстрее. Тем не менее, это то, о чем нужно знать.

Итак, возникает вопрос, почему вы хотите иметь более одного осколка на node? Ответ на это - планируемая масштабируемость. Число осколков в индексе фиксировано. Единственный способ добавить больше осколков позже - это воссоздать индекс и переиндексировать все данные. В зависимости от размера вашего индекса, который может быть или не быть большим делом. На момент написания индекса Qaru составлял 203 ГБ (см. https://stackexchange.com/performance). Это очень важно, чтобы воссоздать все эти данные, поэтому пересмотр будет кошмаром. Если у вас есть 3 узла и в общей сложности 6 осколков, это означает, что вы можете масштабировать до 6 узлов в более позднем пункте без переделки.

Ответ 3

Также неплохо было бы иметь более одного первичного осколка на node, зависит от варианта использования. Я выяснил, что массовое индексирование было довольно медленным, использовалось только одно ядро ​​ЦП, поэтому мы имели простую мощность процессора и очень низкий уровень ввода-вывода, определенно аппаратное обеспечение не было узким местом. Показано, что во время индексации активна только одна массовая нить. У нас есть много анализаторов и сложный токенизатор (разложенный анализ немецких слов). Увеличение количества осколков на node привело к тому, что больше объемных потоков было активным (по одному на осколок на node), и оно значительно улучшило скорость индексации.

Ответ 4

Только что вернулся из настройки некоторого хранилища журналов на 10 ТБ, поэтому позвольте говорить о том, чтобы окутать: D

Node ограничения

Основной источник: Окончательное руководство по elasticsearch

HEAP: не более 32 ГБ:

Если куча меньше 32 ГБ, JVM может использовать сжатые указатели, что экономит много памяти: 4 байта на указатель вместо 8 байтов.

HEAP: не более 50% серверной памяти. Остальное остается в кэшах файловой системы (поэтому серверы с 64 ГБ являются распространенным миром):

Lucene отлично использует кэши файловой системы, управляемые ядром. Без достаточного пространства кеша файловой системы производительность будет страдать. Кроме того, чем больше памяти, выделенной для кучи, тем меньше доступно для всех ваших других полей, используя значения doc.

[Разделение индекса в] N осколков может распространять нагрузку на N серверов:

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

Меньше осколков лучше (идеальный 1 осколок):

Накладные расходы на осколки значительны. См. Этот показатель для чисел https://blog.trifork.com/2014/01/07/elasticsearch-how-many-shards/

Меньше серверов лучше (идеальный 1 сервер (с 1 осколком)]):

Нагрузка на индекс может быть разделена только на узлы путем ошпаривания (достаточно осколка, чтобы использовать все ресурсы на node). Больше осколков позволяет использовать больше серверов, но больше серверов приносят больше накладных расходов для агрегации данных... Нет бесплатного обеда.

Конфигурация

Использование: один большой индекс

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

Предположим, что мы планируем, что индекс будет иметь не более 111 ГБ в будущем, и у нас есть 50-гигабайтные серверы (куча 25 ГБ) у нашего облачного провайдера.

Это означает, что у нас должно быть 5 осколков.

Примечание. Большинство людей склонны переоценивать свой рост, стараются быть реалистичными. Например, этот пример 111GB ​​уже является индексом BIG. Для сравнения, индекс stackoverflow составляет 430 ГБ (2016 год), а он - 50 лучших сайтов по всему миру, полностью составленный из письменных текстов миллионами людей.

Использование: индекс по времени

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

Самый экстремальный пример - журналирование приложений (logstach и graylog), которые каждый день используют новый индекс.

Идеальная конфигурация 1-single-shard-per-index имеет смысл в сценарии. Период вращения индекса может быть скорректирован, если необходимо, чтобы индекс был меньше, чем куча.

Специальный случай. Представьте себе популярный интернет-форум с ежемесячными индексами. 99% запросов попадают в последний индекс. Мы должны установить несколько осколков (например, 3), чтобы распределить нагрузку на несколько узлов. (Примечание: Вероятно, это ненужная оптимизация. В реальном мире 99% попаданий маловероятны, и реплика осколков может распределять часть нагрузки только для чтения).

Использование: переход Exascale (только для записи)

ElasticSearch - это волшебство. Это самая простая база данных для настройки в кластере и одна из немногих, способная масштабировать до многих узлов (исключая Spanner).

Можно перейти exascale с сотнями узлов elasticsearch. Должно быть много индексов и осколков, чтобы распространять нагрузку на многие машины и которая принимает соответствующую конфигурацию осколков (в конечном счете, скорректированную на индекс).

Последний бит магии - настраивать маршрутизацию elasticsearch для целевых определенных узлов для определенных операций.