Наилучшая практика / эффективность создания политики индекса Elasticsearch

Question

Я проектирую поисковую систему, основанную на ElasticSearch, после прочтения многих я увидел, что некоторые системы, такие как журналы, используют политику нескольких индексов для сохранения одного и того же контента, подобно mylogs-12-02-2020, и создают индекс по дням Затем для поиска они выполняют поиск по всем индексам, которые соответствуют mylogs- * pattern, каждый из этих индексов имеет свои первичные фрагменты и реплики. Мой вопрос касался бы эффективности поисков, которые были бы более эффективными при просмотре индекса 5 миллионов документов с n шардами или поиске 50 индексов 100 000 документов. Есть ли у кого-нибудь опыт применения наилучшей практики?

Я предполагаю, что в моей системе будет примерно 200 000 документов в день.

Какова лучшая практика, разделенная на несколько Индексы или имеют один индекс с несколькими основными сегментами в разных узлах (чтобы они не конкурировали за одни и те же ресурсы при поиске / индексации)?

При выполнении поиска по mylogs-* elastic он параллелен индексам а внутри каждого индекса в его осколках?

Answer 1

Конфигурация Elasticsearch по умолчанию, заданная @Umar, устарела и начиная с последней основной версии 7.0 ES, Первичные осколки уменьшены до 1 , вы можете проверить это в ES официальном объявлении о критических изменениях .

Никто не может разработать идеальный индекс ES с оптимальным количеством осколков и реплик и требует непрерывной точной настройки в течение периода. Некоторые факторы, которые влияют на рассмотрение проекта.

1. Система чтения или записи.

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

3. ES-кластер (мультитенантный или выделенный для один индекс).

Выше приведены лишь несколько выборок, и я могу go дать 100 других факторов, которые вы можете учитывать при разработке конфигурации индекса ES. Но идея состоит в том, чтобы сначала начать с более важных параметров (например, для изменения основных сегментов требуется переиндексация), а также учитывать рост в ближайшем будущем и более точную настройку на основе текущей производительности системы.

Я настоятельно рекомендую вам go через мой подробный блог , в котором будут даны ответы на ваши вопросы (поиск по одному индексу с большим количеством документов, чем поиск по большему количеству индексов / сегментов с меньшим количеством документов) подробно через реальный практический пример.

В приведенном выше блоге также объясняется решение ES об изменении давних основных шардов по умолчанию с 5 на 1.

Ответ на следующий вопрос:

Вопрос: Выполняя поиск по mylogs-* elastic, параллельно ли он индексам и внутри каждого индекса в своих шардах?

Ответ: Да, ES имеет распределенную архитектуру, а индекс ES состоит из сегмента Lucene, который является полнофункциональная поисковая система, Каждый запрос ES будет выполняться несколькими потоками параллельно, если ему нужно будет попасть в несколько шардов (с одинаковым индексом или несколькими индексами), если данные потоки свободны , в противном случае после завершения потока sh, тогда он будет использоваться для запроса другого шарда. Вот почему ES намного быстрее, чем другие распределенные системы.

Answer 2

По умолчанию индекс Elasticsearch имеет 5 основных сегментов и 1 реплику для каждого. Но проблема в том, что конфигурации по умолчанию подходят не для каждого варианта использования.

Размер осколка очень важен для поисковых запросов. Если будет слишком много шардов, которые назначены для индекса, сегменты Lucene будут маленькими, что приведет к увеличению издержек. Множество маленьких осколков также уменьшит пропускную способность при одновременном выполнении нескольких запросов С другой стороны, слишком большие шарды приводят к снижению производительности поиска и увеличению времени восстановления после сбоя. Следовательно, Elasticsearch предполагает, что размер одного осколка должен составлять от 20 до 40 ГБ.

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

Для получения более подробной информации прочитайте эту статью .