Как добиться равномерного распределения нагрузки на ElasticSearch с индексами с разным количеством осколков?
Мы пытаемся решить некоторые проблемы с производительностью в нашем кластере ES. Мы изучали распределение сегментов на узлах данных. Я знаю, что есть совет, чтобы осколки были равномерно распределены между узлами - и вот мой вопрос:
Для кластера с 8 узлами данных у нас есть несколько индексов, которые имеют 2 основных сегмента и 3 реплики (всего 8 сегментов). У нас также есть некоторые индексы, которые имеют 1 основной сегмент и 3 реплики (всего 4).
Мой вопрос: можно ли считать установку «равномерно распределенной»? Мы думали, что это не так, и думали об индексах с 1 первичным сегментом — 7 реплик (то есть каждый индекс будет размещаться на 8 узлах) — но мы не знаем, есть ли смысл в такой настройке? Если нет, что бы вы порекомендовали вместо этого, чтобы более равномерно распределить осколки?
Вот результат запроса shard cat:
id1 0 p STARTED 2138 16.1mb x.x.x.x node1
id1 0 r STARTED 2138 16.1mb x.x.x.x node2
id1 0 r STARTED 2138 16.1mb x.x.x.x node3
id1 0 r STARTED 2138 16.1mb x.x.x.x node4
id2 0 r STARTED 3379 26.8mb x.x.x.x node5
id2 0 r STARTED 3379 26.8mb x.x.x.x node3
id2 0 r STARTED 3379 26.8mb x.x.x.x node4
id2 0 p STARTED 3379 26.8mb x.x.x.x node6
id3 0 r STARTED 20086 76.1mb x.x.x.x node1
id3 0 r STARTED 20086 76.1mb x.x.x.x node5
id3 0 p STARTED 20086 76.1mb x.x.x.x node6
id3 0 r STARTED 20086 76.1mb x.x.x.x node7
id4 0 r STARTED 2754 7.3mb x.x.x.x node2
id4 0 r STARTED 2754 7.3mb x.x.x.x node3
id4 0 r STARTED 2754 7.3mb x.x.x.x node8
id4 0 p STARTED 2754 7.3mb x.x.x.x node7
id5 0 r STARTED 10239 42.3mb x.x.x.x node1
id5 0 p STARTED 10239 42.3mb x.x.x.x node4
id5 0 r STARTED 10239 42.3mb x.x.x.x node6
id5 0 r STARTED 10239 42.3mb x.x.x.x node8
id6 0 r STARTED 13388 42.4mb x.x.x.x node1
id6 0 p STARTED 13388 42.4mb x.x.x.x node5
id6 0 r STARTED 13388 42.4mb x.x.x.x node3
id6 0 r STARTED 13388 42.4mb x.x.x.x node8
id7 1 r STARTED 27483 136.2mb x.x.x.x node2
id7 1 r STARTED 27483 136.2mb x.x.x.x node3
id7 1 r STARTED 27483 136.3mb x.x.x.x node8
id7 1 p STARTED 27483 136.2mb x.x.x.x node7
id7 0 r STARTED 27189 146.5mb x.x.x.x node1
id7 0 p STARTED 27189 146.6mb x.x.x.x node5
id7 0 r STARTED 27189 146.6mb x.x.x.x node4
id7 0 r STARTED 27189 146.7mb x.x.x.x node6
.kibana 0 r STARTED 13 106.8kb x.x.x.x node2
.kibana 0 p STARTED 13 106.8kb x.x.x.x node3
id8 1 r STARTED 13555 80.8mb x.x.x.x node2
id8 1 r STARTED 13555 80.8mb x.x.x.x node4
id8 1 r STARTED 13555 80.8mb x.x.x.x node8
id8 1 p STARTED 13555 80.8mb x.x.x.x node7
id8 0 r STARTED 13390 63mb x.x.x.x node1
id8 0 p STARTED 13390 62.7mb x.x.x.x node5
id8 0 r STARTED 13390 62.7mb x.x.x.x node6
id8 0 r STARTED 13390 62.8mb x.x.x.x node7
Содержание индексов часто меняется - стоит ли делать принудительное слияние в такой настройке?
Хорошей практикой является регулярное выполнение forcemerge. Но первое, что вам нужно сделать, это изменить свою стратегию сегментирования. (следите за статьей Opster's.
Ответы 1
Распределение всех сегментов на всех узлах данных ES для каждого индекса не имеет смысла по разным причинам.
- Количество первичных осколков следует выбирать в зависимости от их размера, что поможет вам горизонтально масштабировать индекс.
- Количество сегментов реплик помогает обеспечить высокую доступность и повысить производительность поиска.
Очень сложно достичь идеального баланса сегментов в кластере ES (в зависимости от количества сегментов, размера и трафика). Хотя размер ваших сегментов действительно мал (менее 100 МБ), вы можете использовать 1 сегмент и 7 реплик для всех ваших индексов, при этом вам необходимо провести сравнительный анализ и выбрать правильное количество сегментов и реплик в зависимости от настройки вашего кластера и вариантов использования.
Вы находитесь в классической ситуации чрезмерного шардинга. У вас много маленьких индексов. Посмотрите, сможете ли вы их собрать, а затем выполните принудительное слияние с этими новыми большими индексами.