Просто чтобы вы были на одной странице:
Ваши данные организованы в индексы, каждый из которых состоит из сегментов и распределен по нескольким узлам.Если необходимо проиндексировать новый документ, создается новый идентификатор, и на основе этого идентификатора рассчитывается шард назначения.После этого запись делегируется узлу, который содержит вычисленный шард назначения.Это очень хорошо распределит ваши документы по всем осколкам.
Поиск документов по идентификатору теперь прост, поскольку осколок, содержащий искомый документ, может быть вычислен только на основе идентификатора.Нет необходимости искать все осколки.Кстати, это причина, почему вы не можете изменить количество осколков впоследствии.Измененный номер сегмента приведет к другому распределению документов по вашим фрагментам.
Теперь, просто чтобы прояснить это, каждый фрагмент представляет собой отдельный индекс lucene, составленный из файлов сегментов, расположенных на вашем диске.При записи будут созданы новые сегменты.Если будет достигнуто определенное количество файлов сегментов, сегменты будут объединены.Поэтому просто добавление большего количества сегментов без их распределения на другие узлы просто увеличит количество операций ввода-вывода и потребление памяти для вашего отдельного узла.Во время поиска запрос будет выполняться против каждого шарда.Затем результаты всех осколков нужно объединить в один результат - больше осколков, больше работы процессора ...
Возвращаясь к вашему вопросу:
ДляВаш индексный регистр с тяжелой записью, с одним узлом, оптимальное количество индексов и сегментов - 1!Но для случая поиска (без доступа по идентификатору) оптимальным количеством шардов на узел является количество доступных процессоров.Таким образом, поиск может выполняться в нескольких потоках, что повышает производительность поиска.
Но каковы преимущества шардинга?
Доступность: реплицируя осколки на другие узлы, вы все равно сможете обслуживать, если некоторые из ваших узлов больше не будут доступны!
ПроизводительностьРаспределение основных сегментов по разным узлам также распределит рабочую нагрузку.
Так что, если в вашем сценарии интенсивная запись, оставьте количество сегментов в индексе низким.Если вам нужна лучшая производительность поиска, увеличьте количество осколков, но помните о «физике».Если вам нужна надежность, примите во внимание количество узлов / реплик.
Дополнительные показания:
https://www.elastic.co/guide/en/elasticsearch/reference/current/_basic_concepts.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html
https://www.elastic.co/de/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
https://thoughts.t37.net/designing-the-perfect-elasticsearch-cluster-the-almost-definitive-guide-e614eabc1a87