У меня есть настройка elasticsearch со 192 активными индексами в диапазоне от нескольких сотен МБ до 5 ГБ каждый. Я читал, что для случая использования logstash с индексами 1 ГБ вам следует использовать только 1 осколок. Разница с моей настройкой в том, что у меня будет больше пользователей (оценка до 100), ожидающих быстрого ответа. Я намерен иметь 1 реплику для надежности.
Будет ли по-прежнему подходящим для моего варианта использования наличие 1 осколка на индекс?
Одним словом: да.
Необходимость создания нескольких первичных сегментов проистекает из необходимости изолировать документы, чрезмерных подсчетов (например, когда вы находитесь в объеме миллиардов документов) или повышения пропускной способности записи (писать документы в большем количестве мест, тем самым снижая индивидуальную нагрузку).
На практике вы хотите сегментировать на основе вашего варианта использования, если только вы не входите в один из этих первых двух сценариев (изоляция или экстремальное количество).
Если вас много читают, как это бывает в большинстве случаев использования, то меньшее количество шардов поможет вам, ограничив размер запроса (меньше мест для поиска). Учитывая, что размеры ваших сегментов также относительно малы (я считаю, что размер менее 5 ГБ является относительно небольшим), вы можете легко обойтись одним основным сегментом, и это должно повысить производительность вашего поиска за счет делать это.
Индексы с одинаковыми сопоставлениями, но крошечные («несколько сотен МБ»), вероятно, должны быть объединены , если вы выполняете поиск по ним. Если они независимы, то это действительно не имеет значения, и изоляция кажется хорошей практикой за счет небольшого раздувания состояния вашего кластера (с каждым индексом).
Взгляните на этот блог: https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index. У него есть много хороших указаний на сегментирование и определение размеров сегментов.
Однако вопрос, который вы действительно должны задать себе: насколько легко это изменить? Когда дело доходит до размеров и масштабируемости, ответ часто - «это зависит от обстоятельств» - и реальный вопрос: как быстро вы сможете перенастроить?
Это могло бы, например, означает, что вы разрабатываете свое приложение таким образом, чтобы можно было быстро переупорядочить данные в новый индекс, что вы используете псевдонимы, чтобы вы могли фактически изменить эти вещи, где находятся ваши данные (не только в Elastic, я надеюсь) и т.п.
Построив систему с самого начала, чтобы вы могли быстро перестроить индикаторы, вы можете экспериментировать с размерами и, что более важно, изменять их по мере изменения ваших потребностей.
