Да, вы можете относиться к большему количеству сегментов = больше масштабируемости = больше параллелизма, но это происходит только тогда, когда это полезно, только когда эти сегменты используют многоядерные или более машин (узлов данных) в кластере.
Это конфигурация по умолчанию, которая создается для базовых c рабочих нагрузок и, очевидно, требует более тонкой настройки для предварительных вариантов использования , что является единственной целью сделать ее расширяемой, это очень сложно для разработки идеального кластера Elasticsearch, и поскольку это зависит от различных факторов, Elasticsearch предоставляет некоторые значения по умолчанию, которые больше подходят для общих случаев использования.
Либо вы начинаете со скромной рабочей нагрузки, а затем постепенно ваша рабочая нагрузка имеет тенденцию к увеличить, или вы начинаете с огромной рабочей нагрузки в самом начале (в этом случае, в любом случае, у вас будет больше осколков, чтобы получить преимущество, указанное в первой строке, и это для расширенного варианта использования).
Но первое использование более распространено, и красота Elasticsearch в том, что с ли Вы можете начать работу, и эти настройки по умолчанию работают достаточно хорошо для скромной рабочей нагрузки, и часто вам не нужно их менять и даже не нужно разбираться в них подробно.
Как упоминалось в это тематическое исследование , с большим количеством шардов для небольшого количества документов с огромным поисковым трафиком c создало проблемы (создание 5 потоков для одного поиска, так как шардов по умолчанию было 5), и это общее использование для большинство базовых c и скромных приложений там.
Так что имеет смысл изменить шарды по умолчанию на 1 в качестве его более распространенного варианта использования и далее, если вам нужно go в глубину, чтобы масштабировать кластер, что потребует дальнейшей настройки Elasticsearch.