Упругий поиск, несколько индексов против одного индекса и типы для разных наборов данных?


161

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

  • Лучше ли использовать индексы мултиплей, по одному для каждой модели, или иметь тип в пределах одного индекса для каждой модели? Мне кажется, что оба способа потребуют другого поискового запроса. Я только начал с этого.

  • Есть ли различия в производительности между обеими концепциями, если набор данных маленький или огромный?

Я бы сам проверил 2-й вопрос, если бы кто-то мог порекомендовать мне хорошие примеры данных для этой цели.

Ответы:


184

Есть разные последствия для обоих подходов.

Предполагая, что вы используете настройки по умолчанию Elasticsearch, наличие 1 индекса для каждой модели значительно увеличит количество ваших шардов, так как 1 индекс будет использовать 5 шардов, 5 моделей данных будут использовать 25 шардов; в то время как наличие 5 типов объектов в 1 индексе по-прежнему будет использовать 5 шардов.

Последствия для каждой модели данных в качестве индекса:

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

Последствия использования каждой модели данных в качестве типа объекта в индексе:

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

Если вы спрашиваете, что слишком много данных по сравнению с маленькими данными? Обычно это зависит от скорости процессора и оперативной памяти вашего оборудования, объема данных, которые вы храните в каждой переменной в вашем отображении для Elasticsearch и ваших требований к запросам; использование множества аспектов в ваших запросах значительно замедлит время ответа. На этот вопрос нет однозначного ответа, и вам придется оценивать в соответствии с вашими потребностями.


8
Этот ответ не является полным без информации
отasticsearch.org/guide/en/

5
Чтобы добавить к отличному ответу, я цитирую документ ES 5.2, в котором объясняется, почему не рекомендуется поддерживать большое количество By default elasticsearch rejects search requests that would query more than 1000 shards. The reason is that such large numbers of shards make the job of the coordinating node very CPU and memory intensive. It is usually a better idea to organize data in such a way that there are fewer larger shards. In case you would like to bypass this limit, which is discouraged, you can update the action.search.shard_count.limit cluster setting to a greater value.
забвение

49

Хотя в то время ответ Джонатана был верным, мир двигался дальше, и теперь кажется, что люди, стоящие за ElasticSearch, планируют отказаться от поддержки нескольких типов:

К чему мы хотим добраться: мы хотим удалить концепцию типов из Elasticsearch, в то же время поддерживая родителя / ребенка.

Таким образом, для новых проектов использование только одного типа для каждого индекса облегчит возможное обновление до ElasticSearch 6.x.


13

Ответ Джонатана великолепен. Я бы просто добавил несколько других моментов для рассмотрения:

  • количество шардов может быть настроено для каждого выбранного вами решения. Вы можете иметь один индекс с 15 основными сегментами или разделить его на 3 индекса для 5 сегментов - перспектива производительности не изменится (при условии, что данные распределены поровну)
  • думать об использовании данных. То есть. если вы используете kibana для визуализации, легче включить / исключить определенный индекс (ы), но типы должны быть отфильтрованы на панели инструментов
  • сохранение данных: для данных журнала приложений / метрик используйте разные индексы, если вам требуется другой срок хранения

Что подразумевается под сроком хранения? Вы имеете в виду время, чтобы жить поле? Это устанавливается для каждого документа.
Кшитиз Шарма

Нет, здесь срок хранения подразумевается как срок хранения документа / индекса - как долго хранить эти данные. Исходя из качества данных, размера, важности - я использую, чтобы указать другую политику хранения. Некоторые данные / индексы удаляются через 7 дней, другие - через 6 часов, а некоторые - через 10 лет ...
Марсель Матус

2

Оба приведенных выше ответа великолепны!

Я добавляю пример нескольких типов в индекс. Предположим, вы разрабатываете приложение для поиска книг в библиотеке. Есть несколько вопросов, которые можно задать владельцу библиотеки,

Вопросы:

  1. Сколько книг вы планируете хранить?

  2. Какие книги вы собираетесь хранить в библиотеке?

  3. Как вы собираетесь искать книги?

ответы:

  1. Я планирую хранить от 50 до 70 тысяч книг (приблизительно)

  2. У меня будет 15–20 тыс. Книг по технологиям (информатика, машиностроение, химическое машиностроение и т. Д.), 15 тыс. Исторических книг, 10 тыс. Медицинских книг. 10 тыс. Языковых книг (английский, испанский и т. Д.)

  3. Поиск по авторам, имени, фамилии автора, году публикации, имени издателя. (Это дает вам представление о том, какую информацию вы должны хранить в индексе)

Из приведенных выше ответов мы можем сказать, что схема в нашем индексе должна выглядеть примерно так.

// Это не точное отображение, только для примера

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Для достижения вышеизложенного мы можем создать один индекс под названием «Книги», который может иметь различные типы.

Указатель: Книга

Типы: Наука, Искусство

(Или вы можете создать много типов, таких как технология, медицина, история, язык, если у вас много книг)

Здесь важно отметить, что схема похожа, но данные не идентичны. И другая важная вещь - это общие данные, которые вы храните.

Надеюсь, что вышеизложенное помогает, когда переходить к различным типам в индексе, если у вас другая схема, вы должны рассмотреть другой индекс. Небольшой индекс для меньшего количества данных. большой индекс для больших данных :-)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.