Эластичный поиск, несколько индексов по сравнению с одним индексом и типами для разных наборов данных?

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

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

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

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

ОТВЕТЫ

Ответ 1

Существуют разные последствия для обоих подходов.

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

Оба вышеупомянутых ответа велики!

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

Вопросы:

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

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

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

Ответы:

  • Я планирую хранить книги от 50 k до 70 k (приблизительно)

  • У меня будет 15 k -20 k связанных с технологией книг (информатика, машиностроение, химическая инженерия и т.д.), 15 k исторических книг, 10 k медицинских книг. 10 k книг, связанных с языком (английский, испанский и т.д.)

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

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

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

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

Для достижения вышеуказанного мы можем создать один индекс под названием Books и иметь различные типы.

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

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

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

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

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