Эластичный Поиск, несколько индексов против одного индекса и типов для разных наборов данных?
У меня есть приложение, разработанное с использованием шаблона MVC и я хочу индексировать несколько моделей, это означает, что каждая модель имеет другую структуру данных.
лучше ли использовать индексы mutliple, по одному для каждой модели или иметь тип в пределах одного индекса для каждой модели? В обоих случаях также потребуется другой поисковый запрос, я думаю. Я только начал.
существуют ли различия между обоими понятиями, если набор данных маленький или огромный?
Я бы сам проверил 2-й вопрос, если бы кто-нибудь мог порекомендовать мне хорошие данные для этой цели.
4 ответов
существуют различные последствия для обоих подходов.
предполагая, что вы используете настройки по умолчанию Elasticsearch, наличие 1 индекса для каждой модели значительно увеличит количество ваших осколков, поскольку 1 индекс будет использовать 5 осколков, 5 моделей данных будут использовать 25 осколков; в то время как наличие 5 типов объектов в 1 индексе все еще будет использовать 5 осколков.
последствия для каждой модели данных в качестве индекса:
- эффективный и быстрый поиск в индексе, как объем данных должен быть меньше в каждом осколке, поскольку он распределен по разным индексам.
- Поиск комбинации моделей данных из 2 или более индексов будет генерировать накладные расходы, потому что запрос должен быть отправлен в большее количество осколков по индексам, скомпилирован и отправлен обратно пользователю.
- Не рекомендуется, если ваш набор данных мал, так как вы будете нести больше хранения с каждым дополнительным осколком создается и прирост производительности предельный.
- рекомендуется, если ваш набор данных большой, и ваши запросы занимают много времени для обработки, так как выделенные осколки хранят ваши конкретные данные, и Elasticsearch будет легче обрабатывать.
последствия для каждой модели данных в качестве типа объекта в индексе:
- больше данных будет храниться в пределах 5 осколков индекса, что означает, что есть меньше накладных расходов при запросе между различными моделями данных, но ваш размер осколка будет значительно больше.
- больше данных в осколках займет больше времени для Elasticsearch для поиска, так как есть больше документов для фильтрации.
- Не рекомендуется, если вы знаете, что вы проходите через 1 терабайт данных, и вы не распространяете свои данные по различным индексам или нескольким осколкам в вашем сопоставлении Elasticsearch.
- рекомендуется для небольших наборов данных, потому что вы не будете тратить место для хранения предельный прирост производительности, так как каждый осколок занимает место в вашем оборудовании.
Если вы спрашиваете, что слишком много данных против небольших данных? Обычно это зависит от скорости процессора и ОЗУ вашего оборудования, объема данных, которые вы храните в каждой переменной в вашем сопоставлении для Elasticsearch и ваших требований к запросу; использование многих аспектов в ваших запросах значительно замедлит время ответа. На это нет прямого ответа, и вам придется benchmark согласно вашим потребностям.
хотя ответ Джонатана был правильным в то время, мир двинулся дальше, и теперь кажется, что люди за ElasticSearch имеют долгосрочный план, чтобы отказаться от поддержки нескольких типов:
таким образом, для новых проектов использование только одного типа на индекс сделает возможное обновление до ElasticSearch 6.х будет легче.
ответ Джонатана велик. Я бы просто добавил несколько других моментов для рассмотрения:
- число Черепков можно подгонять в решение вы выбираете. У вас может быть один индекс с 15 первичными осколками или разделить его на 3 индекса для 5 осколков - перспектива производительности не изменится (при условии, что данные распределены поровну)
- подумайте об использовании данных. То есть. если вы используете kibana для визуализации, проще включить / исключить определенный индекс(индексы), но типы должны быть отфильтрованы в приборная панель
- хранение данных: для данных журнала приложений / метрики используйте разные индексы, если вам требуется другой период хранения
оба вышеуказанных ответа велики!
Я добавляю пример нескольких типов в индекс. Предположим, вы разрабатываете приложение для поиска книг в библиотеке. Есть несколько вопросов, чтобы задать владельцу библиотеки,
вопросы:
сколько книг вы планируете хранить?
какие книги вы собираетесь хранить в библиотеке?
Как вы собираетесь искать книги?
ответы:
Я планирую хранить от 50 к-до 70 к книг (приблизительно)
У меня будет 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"
}
}
для достижения вышеуказанного мы можем создать один индекс, называемый книгами, и можем иметь различные типы.
: Книгатипы: Наука, Искусство
(или вы можете создать много типов как технология, медицинская наука, история, язык, если вы имеете много больше книг)
важно отметить, что схема похожа, но данные не идентичны. И еще одна важная вещь-это общая информация, которую вы храните.
надеюсь, что вышеизложенное поможет, когда идти для разных типов в индексе, если у вас есть другая схема, вы должны рассмотреть другой индекс. Малый индекс для меньше данных . большой индекс для больших данных :-)