Проектирование кластера ElaticSearch для массивных данных

Question

Я довольно новичок в ElasticSearch, и я пытаюсь использовать его для индексации содержимого документа для наших пользователей. Содержимое документа будет извлечено с использованием Apache Tika, а также метаданные файла и относительная информация (размер, дата, расширение и т. Д.), И все они будут сохранены и проиндексированы в ElasticSearch.

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

Я думаю о том, чтобы начать с одного узла в моем кластере, который будет иметь 1000 осколков и 1 реплику (всего 2000 обломков). Каждый клиент будет иметь свой собственный индекс, это означает, что этот узел будет поддерживать только 1000 клиентов, которых должно быть достаточно, так как у нас не так много клиентов. Как только узел будет заполнен, мы разберем кластер и добавим новый узел, и это расширит кластер для поддержки 2000 клиентов и так далее.

Моя забота о хранении. Поскольку я буду индексировать большие наборы данных, сохраненные данные будут быстро расширяться по размеру.

Для аргумента допустим, что я присоединю том 1 ГБ к моему узлу и предположим, что я не могу расширить его за пределы этого. Теперь, если я добавлю новый узел в кластер, как будет выглядеть elasticsearch, предполагая, что первый узел уже достиг своего предела хранения (скажем, теперь он использует 999 МБ).

Если давайте скажем, что у клиента A есть индекс для индекса, а размер документа - 5 МБ. как Elasticsearch ведет себя к этому? Будет ли он перемещать индекс на новый узел? или он сохраняет индекс в оригинале и отмечает новый запрос индекса как отказ?

Причина, по которой я спрашиваю об этом, заключается в том, что я буду размещать свой кластер ElasticSearch на Amazon EC2 с прилагаемым к нему томом EBS, а так как плата Amazon за предоставленный GB для EBS, было бы разумно начать с малого и расширить объем когда это необходимо, поэтому нам не нужно брать на себя огромные затраты в начале проекта.

Answer 1

Для ваших целей вам нужно беспокоиться о черепах; Вероятно, 1000 осколков на индекс insane overkill. Каждый индекс (не каждый узел!) Состоит из некоторого количества осколков и их реплик. Elasticsearch автоматически распределяет осколки на узлах вашего кластера, пытаясь сбалансировать их распределение по всему кластеру. Когда использование диска достигает сконфигурированного водяного знака на узле, Elasticsearch прекратит выделение осколков этого узла. Осколки могут быть прозрачно перенесены на разные узлы.

Вы можете обновить общую емкость хранилища вашего кластера, добавив новый узел с большим объемом памяти. Вы должны позаботиться о том, чтобы размер вашего осколка оставался достаточно маленьким, чтобы он мог жить на одном узле, но если он слишком мал, накладные расходы на управление множеством осколков могут стать непомерно высокими. Имейте в виду, что ES может запрашивать несколько индексов; общий шаблон для хронологических операций с большим объемом - это создать новый индекс каждые N дней, а когда необходимы данные, вы запускаете запрос по всем индексам, в которых хранится ваш набор данных. Это позволяет вам контролировать размер отдельных индексов при одновременном удовлетворении значительных потребностей масштабирования.