Оптимальные сегменты индекса Elasticsearch с высокими показателями чтения и очень низкими данными

1. Да вы правы. При настройке сопоставления вы можете указать количество шардов (первичных) и реплик (копий). Осколки-реплики - это в основном клоны ваших первичных осколков, которые нужны для обеспечения отказоустойчивости, но также улучшают производительность чтения (они могут обслуживать операции чтения). Однако они могут нанести ущерб производительности записи, поскольку эластичный должен реплицировать данные между узлами, чтобы поддерживать их в актуальном состоянии. В зависимости от количества узлов вы можете выбрать количество первичных и реплицированных шардов с учетом устойчивости (что произойдет, если узел выйдет из строя)
2. Да, если у вас есть один осколок без реплик, согласно документации, это будет один поток. Это не обязательно плохо или хорошо. Имейте в виду, что в случае одного запроса этот запрос обслуживается несколькими потоками (несколько сегментов, содержащих части данных), в конце концов, эти записи необходимо накапливать, чтобы их можно было обслужить клиенту. Это может повредить производительности. Более того, даже если у вас есть реплики, если у вас есть только один первичный осколок, это означает, что все данные вашего индекса находятся в осколке (первичном или реплике). Это означает, что разные запросы могут обслуживаться любым шардом (таким образом, любым потоком), но каждый запрос будет обслуживаться одним потоком (не должно происходить накопления, что для МБ данных неплохо)

Поскольку размер данных невелик и вам нужна очень высокая пропускная способность, я бы предпочел иметь 1 первичный и столько реплик, сколько количество узлов - 1 (который будет содержать первичный). Теперь количество узлов зависит. Вам нужно будет протестировать, но вы можете использовать 3 узла (что является обычной устойчивой / производительной первой настройкой). Итак, всего 1 первичный и 2 реплики. Проверьте эту настройку и попробуйте провести стресс-тестирование.

Для стресс-теста вы можете использовать rally, который является фреймворком, который elasticsearch использует при тестировании новых выпусков.

Это интересный сценарий, и да, большая часть предоставленной информации неплохая, просто хочу добавить следующие моменты:

1. Поскольку размер данных очень мал, наличие нескольких основных сегментов фактически приведет к снижению производительности из-за создания нескольких потоков для запроса нескольких сегментов и сбора результатов со всех сегментов.
2. Теперь, поскольку для оптимальной производительности нам нужен только 1 первичный осколок, а реплика для первичного осколка не может быть выделена на том же физическом узле данных, вам необходимо иметь другие узлы в ваших кластерах для обеспечения высокой доступности и повышения производительности чтения (реплики помогают в обоих случаях).
3. Теперь, что касается одного поискового запроса, он должен будет запросить только один сегмент (первичный или реплику), поэтому Elasticsearch просто создаст один поток.
4. Для лучшего использования и экономии средств убедитесь, что у вас есть небольшие узлы данных с меньшим количеством ядер ЦП. В этом случае целесообразно использовать двухъядерный компьютер (но вы можете это проверить).
5. Хорошо, что вы используете AWS Elasticsearch, поэтому вы можете быстро изменить количество реплик и развернуть узлы данных меньшего размера (как объяснено выше), когда вы читаете трафик, и даже можете изменить количество ядер, поэтому лучше автоматическое масштабирование вариант, который вы получаете, основываясь на некотором производственном трафике, и можете настроить его в дальнейшем.
6. вы также можете изменять количество реплик динамически с помощью обновите API настройки индекса, но не забудьте добавить больше узлов данных, когда вы это делаете, если у существующих узлов данных загрузка ЦП высока.