ElasticSearch Оберточная головка по типам индексов

Question

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

настоящее время я использую MongoDB для хранения своих данных, давайте рассмотрим этот пример коллекции статьи, которую я хочу быть проиндексированы для поиска, мой документ выглядит следующим образом:

Article = { 
    title: String, 
    publisher: String, 
    subject: String, 
    description: String, 
    year: Integer, 
} 

Теперь я хочу, чтобы каждый из них поля, подлежащие поиску, поэтому я бы сделал индекс elasticsearch «Article». Мне нужно будет определить каждое поле и как его анализировать и хранить, или нет, что я понимаю.

Теперь, как сюда входит тип индекса? Насколько мне известно, у Lucene нет этой концепции, это слой, добавленный Elasticsearch.

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

Является ли это скорее аспектом, связанным с производительностью, у нас есть типы индексов?

Answer 1

Не очень простой вопрос для ответа, но я собираюсь дать ему попробовать. Но будьте осторожны, это мое мнение.

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

Вы можете использовать типы, если вы считаете, что документы принадлежат друг другу, они имеют схожую структуру, но не обязательно такую ​​же структуру. Однако будьте осторожны, не создавайте отдельные сопоставления для полей с одним и тем же именем в разных типах одного и того же индекса. Люцене это не нравится.

Чем больше существует финальный сценарий в отношениях между родителем и ребенком, здесь вам нужны типы. Таким образом, родитель и его дети могут быть местами в одном осколке, что лучше для производительности.

Надеюсь, что это поможет.

Answer 2

Если я не ошибаюсь, улов с использованием более одного типа данных в одном индексе почти идентичен использованию разных индексов. Скажем, вы можете хранить (как я) документы типов «simple_address», «delivery_address», «some_strange_but_official_address_info» в одном и том же «адресе» индекса, чтобы сделать ваш код более разумным. Но если вы не используете ссылки parent-child, это эквивалентно просто наличию трех индексов.

Говоря о вашем примере, вы должны обернуть вокруг себя то, что вы хотите найти. Если, например, вы добавляете комментарии в уравнение, лучше использовать какое-то разделение - либо как родительский, либо разные индексы с ручным сопоставлением ключей. И, очевидно, у вас должны быть разные сопоставления типов «Article» и «Comment».