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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы:

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"
            }
        }

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

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

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

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

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

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