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

Question

Я следую документации AWS для "Выбор количества осколков" для индекса Elasticsearch.
Мой TPS для чтения для индекса ES будет очень высоким (около 1300 TPS, и может увеличиться до 6500 TPS), но объем данных, которые будут присутствовать, будет очень меньше (меньше, чем ГБ).

1. Для соответствия при высоких значениях чтения я планирую реализовать горизонтальное масштабирование (увеличить количество узлов данных)
2. Из-за очень небольшого количества данных, согласно приведенной выше документации, количество сегментов должно быть 1 (оптимальный требуемый фрагмент) размер ~ 10 ГБ-50 ГБ, и мои данные меньше 1 ГБ)

Вопросы:

1. Насколько Я могу понять, один шард не распределен по узлам данных . (Один осколок может находиться только на одном узле данных). Правильно ли это понимание?
2. С здесь , In Elasticsearch, each query is executed in a single thread per shard. Multiple shards can however be processed in parallel, as can multiple queries and aggregations against the same shard.. Если приведенное выше понимание верно, все запросы будут однопоточными на одном узле данных, если у меня только один шард. Горизонтальное масштабирование, таким образом, не может быть реализовано.
   Каким должно быть оптимальное количество первичных сегментов / реплик для индекса, учитывая высокий TPS и низкие данные?
   Должен ли я
   1. по-прежнему иметь a один шард, но несколько реплик (пропорционально количеству хостов) или
   2. несколько основных шардов (размер которых будет в мегабайтах), и один реплика (для экономии памяти). (Я не вижу узлов в моем кластере так сильно, что мне НУЖНО более одной реплики!)

Answer 1

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

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

Также см. о том, как эффективно отлаживать медленные запросы и , как настроить задержку поиска (для системы QPS с высоким уровнем чтения), используя улучшенные настройки шардов и реплики , сообщения в блоге.

Let Я знаю, если вам нужно больше информации.

Answer 2

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

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

Для стресс-теста вы можете использовать Rally , который является основой, которую использует эластичный поиск при тестировании новых версий.