Большой одиночный осколок против множества осколков

Question

Существует два лучших метода работы с осколками ElasticSearch:

• Оптимальное количество шардов на узел равно 1.
• Размер осколка должен быть не более 50 ГБ.

В моем случае они несколько противоречивы. Чтобы быть более конкретным, предполагая, что размер индекса составляет 2 ТБ, и есть 10 узлов. Сколько шардов мне нужно настроить:

Вариант 1: 10 осколков по 200 ГБ каждый

или

Вариант 2: 40 осколков по 50 ГБ каждый

Каков наилучший вариант для производительности задержки запросов?

Answer 1

Чтобы добавить к ответу Вала: большее количество сегментов позволяет более плавно распределять фрагменты в случае, если вы хотите добавить узлы для повышения производительности. 10 осколков на 10 узлов не позволяет распределить осколки на дополнительные узлы. 40 осколков позволят легко масштабироваться с большим количеством узлов.

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

Answer 2

Что бы ни считалось «оптимальным», обычно теоретически только оптимально, на практике вам нужно сделать некоторые компромиссы. В большинстве случаев вам наверняка захочется иметь хотя бы одну реплику на один основной сегмент (отказоустойчивость), поэтому у вас будет как минимум 2 фрагмента на узел (если у вас нет 5 основных сегментов по 400 ГБ каждый). Так много для оптимальности, давайте спустимся на землю ...

Вы не упомянули объем кучи на узел, но, поскольку вы не должны пересекать ограничение кучи в 30,5 ГБ на узел, вы должны явно склоняться к осколкам, имеющим максимум ~ 50 ГБ данных. 50 осколков @ 40GB тоже подойдут.

Я бы не стал использовать осколки на 200 ГБ, поскольку это, вероятно, слишком большой Я также не стал бы пытаться иметь 1000 шардов по 2 ГБ, поскольку их было бы слишком много.

В конечном счете, это зависит от вашего варианта использования и вашего оборудования. Ваш индекс подвергается большой поисковой нагрузке, или он в основном обрабатывает запросы на индексирование? Сколько одновременных запросов поиска / индекса должно обрабатывать ваш кластер? Лучший способ узнать это - проверить все это, но без дополнительной информации второй вариант явно лучше первого. И не забывайте, что вам, вероятно, нужна также одна реплика для каждого основного сегмента, что удвоит ваши потребности в хранилище (то есть 400 ГБ на узел)