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

Ответ 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 и иметь различные типы.

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

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

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

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

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