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

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

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

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

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

4 ответов


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

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

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

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

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

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

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


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

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

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


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

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

оба вышеуказанных ответа велики!

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

вопросы:

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

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

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

ответы:

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

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

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

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

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

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

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

: Книга

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

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

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

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