Elasticsearch - один индекс против нескольких индексов

Question

У меня есть более 4000 различных полей в одном из моих индексов. И это число может увеличиваться со временем. В качестве Elasticsearch укажите ограничение по умолчанию в 1000 полей для каждого индекса. Должна быть какая-то причина.

Теперь я думаю, что мне не следует увеличивать предел, установленный Elasticsearch. Поэтому я должен разбить свой единственный большой индекс на несколько маленьких индексов.

Прежде чем перейти к нескольким индексам, у меня есть несколько вопросов:

1. Количество небольших множественных индексов может увеличиться до 50. Таким образом, поиск по всем 50 индексам за раз может замедлить время поиска по сравнению с поиском по одному большому индексу?

2. Есть ли необходимость разбивать мой один большой индекс на несколько индексов из-за большого количества полей?

3. Когда я использую несколько небольших индексов, общее количество шардов резко возрастает (более 250 шардов). Каждый индекс будет иметь 5 осколков (номер по умолчанию, который я не хочу менять). Поиск по этим нескольким индексам будет искать по этим 250 шардам одновременно. Повлияет ли это на мою эффективность поиска? Примечание: эти осколки могут также увеличиться со временем. Когда я использую один большой индекс, который содержит только 5 фрагментов и большое количество документов, не будет ли это перегрузкой для этих 5 фрагментов?

Answer 1

1. Это сильно зависит от вашей инфраструктуры. Если вы запустите один узел с 50 осколками, запрос будет выполняться дольше, чем с одним осколком. Если у вас есть 50 узлов, каждый из которых содержит один осколок, он, скорее всего, будет работать быстрее, чем один узел с 1 осколком (если у вас большой набор данных). В конце вы должны проверить реальные данные, чтобы быть уверенным.

2. При большом количестве полей у ES возникает проблема с производительностью, и ошибки более вероятны. Основная проблема заключается в том, что каждое поле должно храниться в состоянии кластера, что сказывается на вашем главном узле (ах). Кроме того, во многих случаях вам приходится работать с большим количеством разреженных данных (90% пустых полей).

3. Как правило, один осколок должен содержать от 30 до 50 ГБ данных. Я бы не стал слишком беспокоиться о перегрузке осколков в вашем сценарии использования. Все наоборот.

Я предлагаю протестировать ваш вариант использования с меньшим количеством осколков, перейдите к 1 осколку, 1 реплике для вашего индекса. Затраты на поиск по нескольким шардам (5 первичных, умноженные на реплики) и последующем объединении результатов огромны по сравнению с вашим небольшим набором данных.

Имейте в виду, что поведение document_type изменилось и будет меняться дальше. Начиная с 6.X вы можете иметь только один document_type для каждого индекса, начиная с 7.X document_type полностью удаляется Поскольку API прослушивает _doc, _doc - это рекомендуемый тип документа для использования в 6.X. Перейдите к одному индексу для каждого типа или введите новое поле, в котором хранится ваш тип, если вам нужны данные в одном индексе.