Ваше поле content, насколько я понимаю, будет значительно большим, поскольку многие документы могут занимать более 2-3 МБ, и это много слов.
Не было бы никакого смысла в использовании поля keyword для точного соответствия в соответствии с ответом на ваш предыдущий вопрос, где я упоминал, используя keyword. Вам следует использовать keyword тип данных для точного соответствия , только если ваши данные структурированы
Я понимаю, что поле content, которое выесть неструктурированный. В этом случае вы захотите использовать Whitespace Analyzer в своем поле content.
Также для точного соответствия фразы вы можете взглянуть на Match Phrase query.
Ниже приведен пример индекса, документов и запросов, которые будут соответствовать вашему варианту использования.
Отображение:
PUT mycontent_index
{
"mappings": {
"properties": {
"content":{
"type":"text",
"analyzer": "whitespace" <----- Note this
}
}
}
}
Образцы документов:
POST mycontent_index/_doc/1
{
"content": """
There is no pain you are receding
A distant ship smoke on the horizon
You are only coming through in waves
Your lips move but I can't hear what you're saying
"""
}
POST mycontent_index/_doc/2
{
"content": """
there is no pain you are receding
a distant ship smoke on the horizon
you are only coming through in waves
your lips move but I can't hear what you're saying
"""
}
Фразовое соответствие: (Для поиска предложения со словами по порядку)
POST mycontent_index/_search
{
"query": {
"bool": {
"must": [
{
"match_phrase": { <---- Note this for phrase match
"content": "There is no pain"
}
}
]
}
}
}
Match Query:
POST mycontent_index/_search
{
"query": {
"bool": {
"must": [
{
"match": { <---- Use this for token based search
"content": "there"
}
}
]
}
}
}
Обратите внимание, что ваш ответ должен быть соответствующим.
Для точного соответствия слова просто используйте простой запрос Match .
Обратите внимание, что когда вы не указываете какой-либо анализатор, ES по умолчанию использует Standard Analyzer , и это приведет к преобразованию всех токенов в нижний регистр перед сохранением их в Inverted Index. Однако Whitespace Analyzer не будет преобразовывать токены в нижний регистр. В результате There и there сохраняются как два разных токена в вашем индексе ES.
Я предполагаю, что вы знакомы с понятиями Анализ и Анализатор , и если нет, я бы предложил вам перейти по ссылкам, поскольку это поможет вам узнать большео чем я говорю.
Обновленный ответ:
Публикуя понимание ваших требований, вы не сможете применить несколько анализаторов к одному полю, поэтому в основном у вас есть два варианта:
Вариант 1: Использование нескольких индексов
Вариант 2: Использование мультиполя в отображении, как показано ниже:
Таким образом,ваш сценарий или сервисный слой будут иметь логику нажатия на разные индексы или поля в зависимости от вашего входного значения (те, которые имеют двойную инвертированную запятую, и те, которые являются простыми токенами)
Отображение нескольких полей:
PUT <your_index_name>
{
"mappings":{
"properties":{
"content":{
"type":"text", <--- Field with standard analyzer
"fields":{
"whitespace":{
"type":"text", <--- Field with whitespace
"analyzer":"whitespace"
}
}
}
}
}
}
В идеале, я бы предпочел иметь первое решение, то есть использовать несколько индексов с различным отображением, однако я бы настоятельно рекомендовал вам вернуться к своему варианту использования, потому что не имеет смысла управлять такими запросами, но снова еговаш звонок.
Примечание: Кластер с одним узлом - это наихудший вариант, который вы когда-либо можете сделать, особенно для Production.
Я бы посоветовал вам задать в отдельном вопросе подробное описание количества ваших документов, темпов роста в течение следующих 5 лет или чего-то еще, и будет ли ваш вариант использования более читаемым или интенсивным при записи? Может ли этот кластер использовать другие команды? Я бы посоветовал вам прочитать больше и обсудить с вашей командой или менеджером, чтобы получить больше ясности в ваших сценариях.
Надеюсь, это поможет.