Query DSL - язык запросов OpenSearch

• 1: Контекст запроса и фильтра
• 2: Сравнение термовых и полнотекстовых запросов
• 3: Термино-уровневые запросы
• 3.1: exists
• 3.2: fuzzy
• 3.3: ids
• 3.4: prefix
• 3.5: range
• 3.6: regexp
• 3.7: term
• 3.8: terms
• 3.9: terms set
• 3.10: wildcard
• 4: full_text
• 4.1: match
• 4.2: match-bool-prefix
• 4.3: match-phrase
• 4.4: match-phrase-prefix
• 4.5: multi-match
• 4.6: query-string
• 4.7: simple-query-string
• 4.8: intervals query
• 5: compound queries
• 5.1: boolean query
• 5.2: boosting query
• 5.3: constant_score
• 5.4: disjunction_max
• 5.5: function_score
• 5.6: hibrid
• 6: geographic and xy query
• 6.1: Запрос по гео-ограничивающему прямоугольнику
• 6.2: Запрос по гео-расстоянию
• 6.3: Запрос по гео-многоугольнику
• 6.4: Запрос по гео-форме
• 6.5: xy запрос
• 7: Объединение запросов
• 7.1: Запрос has_child
• 7.2: Запрос has_parent
• 7.3: Вложенный запрос
• 7.4: Запрос по идентификатору родителя
• 8: Запросы Span
• 8.1: Запрос Span containing
• 8.2: Запрос Span field masking
• 8.3: Запрос Span first
• 8.4: Запрос Span multi-term
• 8.5: Запрос Span near
• 8.6: span_not
• 8.7: Запрос Span or
• 8.8: Запрос Span term
• 8.9: Запрос Span within
• 9: Запрос Match all
• 10: Специализированные запросы
• 10.1: distance_feature
• 10.2: k-NN
• 10.3: k-NN explain
• 10.4: neural
• 10.5: Нейронный разреженный запрос
• 10.6: Перколяция
• 10.7: script query
• 10.8: Запрос с оценкой скрипта
• 10.9: Запрос шаблона
• 10.10: Обертка
• 11: Minimum should match (Минимальное соответствие)
• 12: Синтаксис регулярных выражений

GET testindex/_search
{
  "query": {
    "match_all": {}
  }

{
  "match": {
    "user.id": "User-1" 
  }
}

PUT _cluster/settings
{
  "persistent": {
    "search.allow_expensive_queries": false
  }
}

1 - Контекст запроса и фильтра

Основные концепции

Запросы состоят из условий (query clauses), которые могут выполняться в:

1. Контексте фильтра - проверяет соответствие документа условию (“Да/Нет”)
2. Контексте запроса - оценивает степень соответствия документа условию с расчетом релевантности

Оценка релевантности (_score)

Релевантность измеряется числовым значением в поле _score:

"hits" : [
      {
        "_index" : "shakespeare",
        "_id" : "32437",
        "_score" : 18.781435,
        "_source" : {
          "type" : "line",
          "line_id" : 32438,
          "play_name" : "Hamlet",
          "speech_number" : 3,
          "line_number" : "1.1.3",
          "speaker" : "BERNARDO",
          "text_entry" : "Long live the king!"
        }
      },
...

Чем выше значение _score, тем более релевантен документ. Разные типы запросов используют различные алгоритмы расчета релевантности, но все учитывают тип контекста выполнения условия.

Контекст фильтра

Характеристики:

• Возвращает только факт соответствия (бинарный результат)
• Не вычисляет оценку релевантности
• Оптимален для точных значений
• Результаты кэшируются для повышения производительности

Пример использования:

GET students/_search
{
  "query": {
    "bool": {
      "filter": [
        { "term": { "honors": true }},
        { "range": { "graduation_year": { "gte": 2020, "lte": 2022 }}}
      ]
    }
  }
}

Этот запрос ищет студентов:

• С отличием (honors: true)
• Выпустившихся в 2020-2022 годах

Контекст запроса

Характеристики:

• Оценивает степень соответствия документа
• Возвращает численную оценку релевантности
• Используется для полнотекстового поиска
• Поддерживает анализ текста (морфологию, синонимы)

Пример использования:

GET shakespeare/_search
{
  "query": {
    "match": {
      "text_entry": "long live king"
    }
  }
}

Этот запрос:

• Ищет вариации фразы “long live king”
• Учитывает словоформы и синонимы
• Сортирует результаты по релевантности

Особенности вычисления _score

• Используется 24-битная точность (числа с плавающей запятой)
• При превышении точности может происходить потеря данных
• Разные типы запросов используют различные алгоритмы расчета

Рекомендации по применению:

1. Для точных значений (ID, даты, категории) используйте контекст фильтра
2. Для текстового поиска применяйте контекст запроса
3. Комбинируйте оба подхода в сложных запросах через bool запрос

2 - Сравнение термовых и полнотекстовых запросов

Основные различия

Термовые (term-level) и полнотекстовые (full-text) запросы используются для поиска по тексту, но имеют принципиальные отличия:

OpenSearch использует алгоритм ранжирования BM25 для расчета оценок релевантности.

Когда использовать каждый тип запроса?

Пример 1: Поиск фразы

Рассмотрим поиск фразы “To be, or not to be” в произведениях Шекспира.

Термовый запрос:

GET shakespeare/_search
{
  "query": {
    "term": {
      "text_entry": "To be, or not to be"
    }
  }
}

Результат:

{
  "took": 3,
  "hits": {
    "total": {
      "value": 0,
      "relation": "eq"
    },
    "hits": []
  }
}

Запрос не нашел совпадений, так как ищет точную неизмененную фразу.

Полнотекстовый запрос:

GET shakespeare/_search
{
  "query": {
    "match": {
      "text_entry": "To be, or not to be"
    }
  }
}

Результат (сокращенный):

{
  "took": 19,
  "hits": {
    "total": {
      "value": 10000,
      "relation": "gte"
    },
    "hits": [
      {
        "_score": 17.419369,
        "_source": {
          "text_entry": "To be, or not to be: that is the question:"
        }
      },
      {
        "_score": 14.883024,
        "_source": {
          "text_entry": "Not like a corse; or if, not to be buried,"
        }
      }
    ]
  }
}

Полнотекстовый запрос нашел релевантные результаты, проанализировав фразу.

Пример 2: Поиск точного термина

Для поиска точного значения “HAMLET” в поле speaker эффективнее термовый запрос:

GET shakespeare/_search
{
  "query": {
    "term": {
      "speaker": "HAMLET"
    }
  }
}

Результат (сокращенный):

{
  "took": 5,
  "hits": {
    "total": {
      "value": 1582,
      "relation": "eq"
    },
    "hits": [
      {
        "_score": 4.2540946,
        "_source": {
          "speaker": "HAMLET",
          "text_entry": "[Aside] A little more than kin..."
        }
      },
      {
        "_score": 4.2540946,
        "_source": {
          "speaker": "HAMLET",
          "text_entry": "Not so, my lord..."
        }
      }
    ]
  }
}

Важно: Поиск по “Hamlet” не даст результатов, так как поле speaker является keyword и хранится в исходном регистре.

Рекомендации по выбору типа запроса

1. Используйте термовые запросы для:

   • Точных значений (ID, коды, категории)
   • Полям типа keyword
   • Когда не нужна сортировка по релевантности

2. Используйте полнотекстовые запросы для:

   • Текстового поиска с анализом
   • Когда важна оценка релевантности
   • Поиска по словоформам и синонимам

3. Для полей text:
   Всегда используйте полнотекстовые запросы, так как их значения анализируются при индексации.

4. Для полей keyword:
   Используйте термовые запросы для точного соответствия.

3 - Термино-уровневые запросы

Общее описание

Термино-уровневые запросы (term-level queries) выполняют поиск по индексу для нахождения документов, содержащих точное соответствие указанному термину. В отличие от полнотекстовых запросов, результаты термино-уровневых запросов не сортируются по оценке релевантности.

Ключевые особенности:

• Работают только с точными значениями
• Не анализируют поисковый термин
• Оптимальны для поиска по полям типа keyword
• Не подходят для анализа текстовых полей (используйте полнотекстовые запросы)

Типы термино-уровневых запросов

В таблице представлены все виды термино-уровневых запросов:

Практические рекомендации

1. Для полей keyword всегда используйте термино-уровневые запросы:

   GET products/_search
   {
     "query": {
       "term": {
         "product_code": "ABC-123"
       }
     }
   }
   

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

3. Для сложных условий комбинируйте несколько термино-уровневых запросов через bool:

   GET logs/_search
   {
     "query": {
       "bool": {
         "must": [
           { "term": { "status": "error" } },
           { "range": { "timestamp": { "gte": "2023-01-01" }}}
         ]
       }
     }
   }
   

4. Для нечеткого поиска используйте fuzzy с указанием максимального расстояния:

   GET contacts/_search
   {
     "query": {
       "fuzzy": {
         "last_name": {
           "value": "Smith",
           "fuzziness": 2
         }
       }
     }
   }
   

Все технические термины сохранены в оригинальном написании (term, fuzzy, wildcard и т.д.) для соответствия международной практике, с добавлением пояснений на русском языке для лучшего понимания.

3.1 - exists

Запрос exists

Назначение

Запрос exists используется для поиска документов, содержащих указанное поле.

Когда поле считается отсутствующим?

Индексированное значение будет отсутствовать для поля документа в следующих случаях:

1. В маппинге поля указано "index": false
2. Значение поля в исходном JSON равно null или [] (пустой массив)
3. Длина значения поля превышает параметр ignore_above в маппинге
4. Значение поля имеет некорректный формат и в маппинге определен ignore_malformed

Когда поле считается существующим?

Индексированное значение будет присутствовать для поля документа в следующих случаях:

1. Значение является массивом, содержащим как null, так и не-null элементы (например, ["один", null])
2. Значение представляет собой пустую строку ("" или "-")
3. Значение является кастомным null_value, определенным в маппинге поля

Пример использования

Добавление тестовых документов:

PUT testindex/_doc/1
{
  "title": "Ветер крепчает"
}

PUT testindex/_doc/2
{
  "title": "Унесенные ветром",
  "description": "Американский эпический исторический фильм 1939 года"
}

Поиск документов с полем description:

GET testindex/_search
{
  "query": {
    "exists": {
      "field": "description"
    }
  }
}

Результат выполнения:

{
  "took": 3,
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "testindex",
        "_id": "2",
        "_source": {
          "title": "Унесенные ветром",
          "description": "Американский эпический исторический фильм 1939 года"
        }
      }
    ]
  }
}

Поиск документов с отсутствующими полями

Для поиска документов без определенного поля используйте комбинацию must_not и exists:

GET testindex/_search
{
  "query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "description"
        }
      }
    }
  }
}

Результат выполнения:

{
  "took": 19,
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "testindex",
        "_id": "1",
        "_source": {
          "title": "Ветер крепчает"
        }
      }
    ]
  }
}

Параметры запроса

Запрос принимает следующие параметры:

Пример с параметром boost:

GET testindex/_search
{
  "query": {
    "exists": {
      "field": "description",
      "boost": 2.0
    }
  }
}

Особенности работы

1. Запрос exists проверяет именно наличие индексированного значения поля, а не его наличие в исходном документе.
2. Для проверки отсутствия поля всегда используйте комбинацию bool + must_not + exists.
3. Запрос можно комбинировать с другими типами запросов в составе bool запроса.

3.2 - fuzzy

Нечеткий поиск (Fuzzy query)

Основные понятия

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

1. Замены: кот → бот
2. Вставки: кот → коты
3. Удаления: кот → от
4. Транспозиции: кот → кто

Принцип работы

1. Запрос генерирует все возможные варианты поискового термина, попадающие в заданное расстояние редактирования
2. Количество вариантов ограничивается параметром max_expansions
3. Поиск выполняется по всем сгенерированным вариантам

Примеры запросов

Базовый пример с поиском ошибочного написания “HALET” вместо “HAMLET”:

GET shakespeare/_search
{
  "query": {
    "fuzzy": {
      "speaker": {
        "value": "HALET"
      }
    }
  }
}

Примечание: Используется автоматическое определение расстояния (AUTO)

Расширенный пример с настройкой параметров:

GET shakespeare/_search
{
  "query": {
    "fuzzy": {
      "speaker": {
        "value": "HALET",
        "fuzziness": "2",
        "max_expansions": 40,
        "prefix_length": 0,
        "transpositions": true,
        "rewrite": "constant_score"
      }
    }
  }
}

Параметры запроса

Синтаксис запроса:

GET _search
{
  "query": {
    "fuzzy": {
      "<поле>": {
        "value": "образец",
        ...
      }
    }
  }
}

Доступные параметры:

Особенности производительности

1. Большие значения max_expansions (особенно с prefix_length=0) могут снизить производительность из-за генерации множества вариантов
2. При search.allow_expensive_queries=false нечеткие запросы не выполняются
3. Для длинных слов рекомендуется использовать prefix_length>0

Практические рекомендации

1. Для исправления опечаток используйте fuzziness=1 или fuzziness=2
2. Для профессиональных терминов уменьшайте max_expansions
3. Для ускорения поиска увеличивайте prefix_length
4. Для точных полей отключайте транспозиции (transpositions=false)

3.3 - ids

Запрос IDs (поиск по идентификаторам)

Назначение

Запрос ids позволяет находить документы по их уникальным идентификаторам в поле _id.

Синтаксис запроса

GET shakespeare/_search
{
  "query": {
    "ids": {
      "values": [
        "34229",
        "91296"
      ]
    }
  }
}

Параметры запроса

Особенности работы

1. Тип идентификаторов:
   Идентификаторы всегда передаются как строки, даже если в системе они числовые.

2. Производительность:
   Запрос оптимален для выборки небольшого количества документов по известным ID.

3. Использование с boost:
   Пример с изменением релевантности:

   GET shakespeare/_search
   {
     "query": {
       "ids": {
         "values": ["34229", "91296"],
         "boost": 2.0
       }
     }
   }
   

4. Ограничения:

   • Не поддерживает шаблоны или диапазоны ID
   • Для поиска по >1000 ID рекомендуется использовать terms запрос

5. Ответ системы:
   Возвращает только те документы, чьи ID присутствуют в индексе (несуществующие ID игнорируются без ошибки)

Альтернативные подходы

Для сложных сценариев поиска по ID можно использовать:

GET _search
{
  "query": {
    "terms": {
      "_id": ["34229", "91296"]
    }
  }
}

3.4 - prefix

Запрос prefix (поиск по префиксу)

Назначение

Запрос prefix выполняет поиск терминов, начинающихся с указанной приставки (префикса). Используется для:

• Автодополнения
• Поиска по начальным символам
• Классификации данных с общими префиксами

Базовый синтаксис

GET shakespeare/_search
{
  "query": {
    "prefix": {
      "speaker": "KING H"
    }
  }
}

Этот запрос ищет документы, где поле speaker содержит термины, начинающиеся на “KING H”.

Расширенный синтаксис с параметрами

GET shakespeare/_search
{
  "query": {
    "prefix": {
      "speaker": {
        "value": "KING H",
        "boost": 1.5,
        "case_insensitive": true,
        "rewrite": "scoring_boolean"
      }
    }
  }
}

Параметры запроса

Особенности работы

1. Производительность:

   • При включенной настройке index_prefixes в маппинге поля запрос выполняется оптимально
   • При search.allow_expensive_queries=false запросы prefix не выполняются (кроме случаев с index_prefixes)

2. Регистр символов:

   • По умолчанию поиск чувствителен к регистру
   • Для регистронезависимого поиска используйте "case_insensitive": true

3. Примеры использования:

   // Поиск продуктов с кодом, начинающимся на "A12"
   GET products/_search
   {
     "query": {
       "prefix": {
         "product_code": "A12"
       }
     }
   }
   
   // Поиск городов, названия которых начинаются на "сан"
   GET cities/_search
   {
     "query": {
       "prefix": {
         "name": {
           "value": "сан",
           "case_insensitive": true
         }
       }
     }
   }
   

4. Рекомендации:

   • Для полей с длинными значениями установите index_prefixes в маппинге
   • Избегайте очень коротких префиксов (1-2 символа) на больших индексах
   • Для сложных сценариев автодополнения рассмотрите completion suggester

3.5 - range

Запрос range (диапазонный запрос)

Основные возможности

Запрос range позволяет выполнять поиск документов, значения полей которых попадают в указанный диапазон.

Синтаксис базового запроса

GET shakespeare/_search
{
  "query": {
    "range": {
      "line_id": {
        "gte": 10,
        "lte": 20
      }
    }
  }
}

Этот запрос находит документы, где значение поля line_id находится в диапазоне от 10 до 20 включительно.

Операторы сравнения

Параметр поля в запросе range принимает следующие операторы:

Работа с датами

Пример поиска по датам:

GET products/_search
{
  "query": {
    "range": {
      "created": {
        "gte": "2019/01/01",
        "lte": "2019/12/31"
      }
    }
  }
}

Этот запрос находит все товары, добавленные в 2019 году.

Указание формата даты:

GET /products/_search
{
  "query": {
    "range": {
      "created": {
        "gte": "01/01/2022",
        "lte": "31/12/2022",
        "format":"dd/MM/yyyy"
      }
    }
  }
}

Параметр format позволяет указать формат даты, отличный от формата, заданного в маппинге поля.

Особенности обработки дат

Автозаполнение отсутствующих компонентов даты: OpenSearch заполняет отсутствующие компоненты даты следующими значениями:

• MONTH_OF_YEAR: 01
• DAY_OF_MONTH: 01
• HOUR_OF_DAY: 23
• MINUTE_OF_HOUR: 59
• SECOND_OF_MINUTE: 59
• NANO_OF_SECOND: 999_999_999

Пример:

GET /products/_search
{
  "query": {
    "range": {
      "created": {
        "gte": "2022",
        "lte": "2022-12-31"
      }
    }
  }
}

В этом случае начальная дата будет интерпретирована как 2022-01-01T23:59:59.999999999Z.

Относительные даты

Использование математики дат:

GET products/_search
{
  "query": {
    "range": {
      "created": {
        "gte": "2019/01/01||-1y-1d"
      }
    }
  }
}

Здесь 2019/01/01 - это опорная дата, от которой вычитается 1 год и 1 день.

Округление дат:

GET products/_search
{
  "query": {
    "range": {
      "created": {
        "gte": "now-1y/M"
      }
    }
  }
}

Ключевое слово now ссылается на текущую дату и время, /M означает округление по месяцам.

Правила округления относительных дат

| Параметр | Правило округления | Пример для 2022-05-18||/M | |———-|—————————————-|—————————–| | gt | Округляет вверх | 2022-06-01T00:00:00.000 | | gte | Округляет вниз | 2022-05-01T00:00:00.000 | | lt | Округляет вниз до последней миллисекунды | 2022-04-30T23:59:59.999 | | lte | Округляет вверх до последней миллисекунды | 2022-05-31T23:59:59.999 |

Часовые пояса

По умолчанию даты считаются в UTC. Можно указать часовой пояс параметром time_zone:

GET /products/_search
{
  "query": {
    "range": {
      "created": {
        "time_zone": "-04:00",
        "gte": "2022-04-17T06:00:00"
      }
    }
  }
}

Значение 2022-04-17T06:00:00-04:00 будет преобразовано в 2022-04-17T10:00:00 UTC.

Дополнительные параметры

Синтаксис с параметрами:

GET _search
{
  "query": {
    "range": {
      "<поле>": {
        "gt": 10,
        ...
      }
    }
  }
}

Доступные параметры:

Важно: При search.allow_expensive_queries=false диапазонные запросы по текстовым и ключевым полям не выполняются.

3.6 - regexp

Запрос regexp (поиск по регулярным выражениям)

Назначение

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

Базовый пример

GET shakespeare/_search
{
  "query": {
    "regexp": {
      "play_name": "[a-zA-Z]amlet"
    }
  }
}

Этот запрос ищет любые термины в поле play_name, которые начинаются с любой буквы (верхнего или нижнего регистра), за которой следует “amlet”.

Ключевые особенности

1. Область применения:
   Регулярные выражения применяются к отдельным терминам (токенам) в поле, а не ко всему полю целиком.

2. Ограничения:

   • Максимальная длина регулярного выражения по умолчанию: 1,000 символов (настраивается через index.max_regex_length)
   • Используется синтаксис Lucene, который отличается от стандартных реализаций

3. Производительность:

   • Избегайте шаблонов с .* или .*?+ без префикса/суффикса
   • Ресурсоемкие операции, требуют search.allow_expensive_queries=true
   • Для частых запросов рекомендуется тестировать влияние на кластер

4. Оптимизация:
   Тип поля wildcard специально оптимизирован для эффективных запросов с регулярными выражениями.

Расширенный синтаксис с параметрами

GET _search
{
  "query": {
    "regexp": {
      "<поле>": {
        "value": "[Ss]ample",
        "boost": 1.5,
        "case_insensitive": true,
        "flags": "INTERSECTION|COMPLEMENT",
        "max_determinized_states": 20000,
        "rewrite": "constant_score"
      }
    }
  }
}

Параметры запроса

Рекомендации по использованию

1. Тестирование:
   Всегда проверяйте регулярные выражения на тестовых данных перед использованием в production.

2. Производительность:

   // Неэффективно:
   { "regexp": { "text": ".*pattern.*" } }
   
   // Оптимально:
   { "regexp": { "text": "prefix.*suffix" } }
   

3. Альтернативы:
   Для сложных сценариев рассмотрите:

   • Использование wildcard типа поля
   • Применение match_phrase для текстовых фраз
   • Использование keyword полей для точного соответствия

4. Безопасность:
   Ограничивайте max_determinized_states для предотвращения DoS-атак через сложные регулярные выражения.

Примечание: При search.allow_expensive_queries=false запросы regexp не выполняются.

3.7 - term

Запрос term (поиск точного термина)

Назначение

Запрос term выполняет поиск точного соответствия указанному термину в поле. Основные характеристики:

• Ищет неизмененное значение без анализа текста
• Чувствителен к регистру по умолчанию
• Оптимален для полей типа keyword, дат и чисел

Базовый синтаксис

GET shakespeare/_search
{
  "query": {
    "term": {
      "line_id": {
        "value": "61809"
      }
    }
  }
}

Этот запрос ищет строку с точным значением line_id = "61809".

Важные особенности

1. Отличие от match запросов:

   • term не анализирует поисковый термин
   • Не подходит для текстовых полей (text), так как они анализируются при индексации
   • Для текстовых полей используйте match запросы

2. Регистронезависимый поиск (начиная с OpenSearch 2.x):

GET shakespeare/_search
{
  "query": {
    "term": {
      "speaker": {
        "value": "HAMLET",
        "case_insensitive": true
      }
    }
  }
}

Внимание! В версиях OpenSearch 2.x и ранее регистронезависимый поиск может значительно снижать производительность. Рекомендуется:

• Использовать lowercase фильтр при индексации
• Применять термины в нижнем регистре в запросах

Пример ответа

{
  "hits": {
    "total": {
      "value": 1582,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "shakespeare",
        "_id": "32700",
        "_score": 2,
        "_source": {
          "speaker": "HAMLET",
          "text_entry": "[Aside] A little more than kin..."
        }
      }
    ]
  }
}

Параметры запроса

Синтаксис с параметрами:

GET _search
{
  "query": {
    "term": {
      "<поле>": {
        "value": "образец",
        ...
      }
    }
  }
}

Практические рекомендации

1. Для текстовых полей всегда используйте match вместо term:

   // Неправильно (для text полей):
   { "term": { "description": "quick brown fox" } }
   
   // Правильно:
   { "match": { "description": "quick brown fox" } }
   

2. Для точных значений (ID, коды, категории):

   GET products/_search
   {
     "query": {
       "term": {
         "product_code": "ABC-123"
       }
     }
   }
   

3. Комбинируйте с другими запросами:

   GET logs/_search
   {
     "query": {
       "bool": {
         "must": [
           { "term": { "status": "error" } },
           { "range": { "timestamp": { "gte": "2023-01-01" }}}
         ]
       }
     }
   }
   

4. Производительность:

   • Для частых запросов добавьте индекс на поле
   • Избегайте case_insensitive в favor lowercase анализаторов

3.8 - terms

Terms Query (Поиск по нескольким значениям)

Основное назначение

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

Базовый синтаксис

GET shakespeare/_search
{
  "query": {
    "terms": {
      "line_id": [
        "61809",
        "61810"
      ]
    }
  }
}

Ключевые особенности

1. Лимит терминов:
   По умолчанию максимальное количество терминов в запросе - 65,536. Настраивается через параметр index.max_terms_count.

2. Производительность:
   Для оптимизации производительности с длинными списками терминов рекомендуется:

   • Передавать термины в отсортированном порядке (по возрастанию UTF-8 byte values)
   • Использовать механизм Terms Lookup для больших наборов терминов

3. Подсветка результатов:
   Возможность подсветки результатов зависит от:

   • Типа highlighter’а
   • Количества терминов в запросе

Параметры запроса

Terms Lookup (Поиск терминов из другого документа)

Общие принципы

Механизм Terms Lookup позволяет:

1. Извлекать значения полей из указанного документа
2. Использовать эти значения как условия поиска
3. Работать с большими наборами терминов

Требования:

• Поле _source должно быть включено (включено по умолчанию)
• Для уменьшения сетевого трафика рекомендуется использовать индекс с:
  • Одним первичным шардом
  • Полными репликами на всех узлах данных

Пример использования

1. Создаем индекс студентов:

PUT students
{
  "mappings": {
    "properties": {
      "student_id": { "type": "keyword" }
    }
  }
}

2. Добавляем данные студентов:

PUT students/_doc/1
{
  "name": "Jane Doe",
  "student_id" : "111"
}

PUT students/_doc/2
{
  "name": "Mary Major",
  "student_id" : "222"
}

PUT students/_doc/3
{
  "name": "John Doe",
  "student_id" : "333"
}

3. Создаем индекс классов с информацией о зачисленных студентах:

PUT classes/_doc/101
{
  "name": "CS101",
  "enrolled" : ["111" , "222"]
}

4. Поиск студентов, зачисленных на CS101:

GET students/_search
{
  "query": {
    "terms": {
      "student_id": {
        "index": "classes",
        "id": "101",
        "path": "enrolled"
      }
    }
  }
}

5. Результат содержит соответствующих студентов:

{
  "took": 13,
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_source": {
          "name": "Jane Doe",
          "student_id": "111"
        }
      },
      {
        "_index": "students",
        "_id": "2",
        "_source": {
          "name": "Mary Major",
          "student_id": "222"
        }
      }
    ]
  }
}

Работа с вложенными полями

1. Добавляем документ с вложенной структурой:

PUT classes/_doc/102
{
  "name": "CS102",
  "enrolled_students" : {
    "id_list" : ["111" , "333"]
  }
}

2. Поиск с указанием пути к вложенному полю:

GET students/_search
{
  "query": {
    "terms": {
      "student_id": {
        "index": "classes",
        "id": "102",
        "path": "enrolled_students.id_list"
      }
    }
  }
}

3. Результат поиска:

{
  "took": 18,
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "hits": [
      {
        "_index": "students",
        "_id": "1",
        "_source": {
          "name": "Jane Doe",
          "student_id": "111"
        }
      },
      {
        "_index": "students",
        "_id": "3",
        "_source": {
          "name": "John Doe",
          "student_id": "333"
        }
      }
    ]
  }
}

Параметры Terms Lookup

*Обязателен, если при индексации использовалось кастомное routing

Важные замечания

1. Для полей типа text используйте match вместо terms
2. При работе с большими наборами терминов (>10,000) рассмотрите возможность использования Bitmap Filtering
3. Убедитесь, что поле _source включено для документов-источников

Bitmap Filtering (Фильтрация с использованием битовых карт)

Введение

Начиная с версии 2.17, OpenSearch предлагает механизм bitmap filtering для эффективной фильтрации по большому количеству терминов (10,000+). Этот подход решает проблему высокой нагрузки на сеть и память при работе с обычными terms-запросами.

Основные концепции

1. Проблема:
   Обычные terms-запросы становятся неэффективными при большом количестве терминов из-за:

   • Высокого сетевого трафика
   • Чрезмерного потребления памяти

2. Решение:
   Использование roaring bitmap для кодирования условий фильтрации:

   • Эффективное сжатие данных
   • Быстрые битовые операции
   • Оптимизированное использование памяти

Пример реализации

1. Подготовка индексов

Индекс продуктов:

PUT /products
{
  "mappings": {
    "properties": {
      "product_id": { "type": "integer" }
    }
  }
}

Добавление продуктов:

PUT /products/_doc/1
{
  "name": "Product 1",
  "product_id" : 111
}

PUT /products/_doc/2
{
  "name": "Product 2",
  "product_id" : 222
}

PUT /products/_doc/3
{
  "name": "Product 3",
  "product_id" : 333
}

Индекс клиентов с bitmap-полем:

PUT /customers
{
  "mappings": {
    "properties": {
      "customer_filter": {
        "type": "binary",
        "store": true
      }
    }
  }
}

2. Генерация bitmap

Пример кода на Python с использованием PyRoaringBitMap:

from pyroaring import BitMap
import base64

bm = BitMap([111, 222, 333])  # ID продуктов клиента
encoded = base64.b64encode(BitMap.serialize(bm))
encoded_bm_str = encoded.decode('utf-8')

print(f"Encoded Bitmap: {encoded_bm_str}")

3. Индексация bitmap

POST customers/_doc/customer123
{
  "customer_filter": "OjAAAAEAAAAAAAIAEAAAAG8A3gBNAQ==" 
}

Использование bitmap в запросах

Вариант 1: Lookup из документа

POST /products/_search
{
  "query": {
    "terms": {
      "product_id": {
        "index": "customers",
        "id": "customer123",
        "path": "customer_filter",
        "store": true
      },
      "value_type": "bitmap"
    }
  }
}

Вариант 2: Прямая передача bitmap

POST /products/_search
{
  "query": {
    "terms": {
      "product_id": [
        "OjAAAAEAAAAAAAIAEAAAAG8A3gBNAQ=="
      ],
      "value_type": "bitmap"
    }
  }
}

Ключевые параметры

Преимущества подхода

1. Эффективность:

   • Снижение сетевого трафика до 10 раз
   • Уменьшение использования памяти на 50-90%

2. Гибкость:

   • Поддержка динамического обновления фильтров
   • Возможность комбинирования условий

3. Производительность:

   • Быстрое выполнение даже для 100,000+ терминов
   • Оптимизированные битовые операции на уровне ядра

Рекомендации

1. Используйте для сложных фильтров с >10,000 значений
2. Регулярно обновляйте bitmap при изменении данных
3. Тестируйте производительность для вашего конкретного сценария
4. Рассмотрите использование сжатых форматов bitmap для экономии места

3.9 - terms set

Terms Set Query (Запрос с условием минимального соответствия терминов)

Основное назначение

Запрос terms_set позволяет искать документы, которые соответствуют минимальному количеству точных терминов в указанном поле. В отличие от обычного terms запроса, terms_set требует явного указания минимального количества совпадений, которое может быть задано либо через поле индекса, либо через скрипт.

Основные характеристики

• Ищет точные соответствия терминов (без анализа текста)
• Требует указания минимального количества совпадающих терминов
• Поддерживает два способа определения минимального количества:
  • Через поле документа (minimum_should_match_field)
  • Через скрипт (minimum_should_match_script)
• Оптимален для работы с полями типа keyword

Пример использования

1. Подготовка индекса

PUT students
{
  "mappings": {
    "properties": {
      "name": { "type": "keyword" },
      "classes": { "type": "keyword" },
      "min_required": { "type": "integer" }
    }
  }
}

2. Индексация документов

PUT students/_doc/1
{
  "name": "Mary Major",
  "classes": [ "CS101", "CS102", "MATH101" ],
  "min_required": 2
}

PUT students/_doc/2
{
  "name": "John Doe",
  "classes": [ "CS101", "MATH101", "ENG101" ],
  "min_required": 2
}

3. Поиск с использованием поля для минимального соответствия

GET students/_search
{
  "query": {
    "terms_set": {
      "classes": {
        "terms": [ "CS101", "CS102", "MATH101" ],
        "minimum_should_match_field": "min_required"
      }
    }
  }
}

4. Поиск с использованием скрипта для минимального соответствия

GET students/_search
{
  "query": {
    "terms_set": {
      "classes": {
        "terms": [ "CS101", "CS102", "MATH101" ],
        "minimum_should_match_script": {
          "source": "Math.min(params.num_terms, doc['min_required'].value)"
        }
      }
    }
  }
}

Параметры запроса

Базовый синтаксис:

GET _search
{
  "query": {
    "terms_set": {
      "<поле>": {
        "terms": [ "term1", "term2" ],
        ...
      }
    }
  }
}

Особенности работы

1. Механизм подсчета:
   Документ считается соответствующим, если количество совпадающих терминов из массива terms ≥ указанного минимума.

2. Определение минимума:

   • Через поле: значение берется из указанного поля документа
   • Через скрипт: вычисляется динамически для каждого документа

3. Производительность:

   • Использование поля minimum_should_match_field обычно более эффективно
   • Скрипты обеспечивают гибкость, но могут снижать производительность

Рекомендации по использованию

1. Для статических условий используйте minimum_should_match_field
2. Для сложной логики применяйте minimum_should_match_script
3. Всегда индексируйте поля, используемые для определения минимума
4. Для текстовых полей предварительно применяйте нормализацию
5. Тестируйте производительность на реалистичных объемах данных

Примеры скриптов

1. Фиксированное значение:

"minimum_should_match_script": {
  "source": "2"
}

2. Динамическое вычисление:

"minimum_should_match_script": {
  "source": "doc['min_required'].value * params.factor",
  "params": {
    "factor": 1.5
  }
}

3. Ограничение сверху:

"minimum_should_match_script": {
  "source": "Math.min(5, doc['min_required'].value)"
}

3.10 - wildcard

Wildcard Query (Поиск с подстановочными символами)

Основное назначение

Запрос wildcard позволяет выполнять поиск терминов по шаблону с использованием подстановочных символов. Особенно полезен для:

• Поиска по частичным совпадениям
• Нечеткого поиска с известной структурой
• Работы с кодами, артикулами и другими структурированными данными

Поддерживаемые операторы

Примеры запросов

1. Чувствительный к регистру поиск:

GET shakespeare/_search
{
  "query": {
    "wildcard": {
      "speaker": {
        "value": "H*Y",
        "case_insensitive": false
      }
    }
  }
}

2. Использование разных операторов:

• H*Y - найдет любые значения, начинающиеся на H и заканчивающиеся на Y
• H?Y - найдет только 3-символьные значения типа “HMY”

Параметры запроса

Базовый синтаксис:

GET _search
{
  "query": {
    "wildcard": {
      "<поле>": {
        "value": "шаб*лон",
        ...
      }
    }
  }
}

Критические особенности производительности

1. Предупреждение:
   Wildcard-запросы могут быть медленными, так как требуют перебора множества терминов.

2. Золотое правило:
   Избегайте размещения подстановочных символов в начале шаблона (например, *pattern), так как это:

   • Крайне ресурсоемко
   • Может привести к таймаутам
   • Создает нагрузку на кластер

3. Оптимизация:
   Для частых wildcard-запросов используйте специальный wildcard тип поля, который:

   • Создает оптимизированный индекс
   • Обеспечивает высокую производительность
   • Поддерживает сложные шаблоны

Практические рекомендации

1. Для префиксного поиска используйте prefix запрос вместо H*:

   {
     "query": {
       "prefix": {
         "field": "H"
       }
     }
   }
   

2. Для сложных шаблонов рассмотрите:

   • Использование wildcard типа поля
   • Применение regexp запросов для более сложных паттернов

3. При работе с большими индексами:

   • Ограничивайте время выполнения через timeout
   • Используйте search.allow_expensive_queries для контроля

4. Пример безопасного шаблона:

   {
     "query": {
       "wildcard": {
         "product_code": {
           "value": "ABC-202?-*",
           "case_insensitive": true
         }
       }
     }
   }
   

   Такой шаблон найдет коды типа “ABC-2023-XXX” и безопасен для выполнения.

Важные ограничения

1. При search.allow_expensive_queries=false wildcard-запросы не выполняются
2. Максимальная длина шаблона ограничена параметром index.max_regex_length (по умолчанию 1000 символов)
3. Не поддерживает стандартные regex-конструкции (используйте regexp запрос для сложных выражений)

4 - full_text

Полнотекстовые запросы

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

OpenSearch использует библиотеку поиска Apache Lucene, которая предоставляет высокоэффективные структуры данных и алгоритмы для загрузки, индексации, поиска и агрегации данных.

Чтобы узнать больше о классах запросов поиска, смотрите JavaDocs по запросам Lucene.

Типы полнотекстовых запросов, показанные в этом разделе, используют стандартный анализатор, который автоматически анализирует текст при отправке запроса.

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

4.1 - match

Запрос Match

Используйте запрос match для полнотекстового поиска по конкретному полю документа. Если вы выполняете запрос match по текстовому полю, он анализирует предоставленную строку поиска и возвращает документы, которые соответствуют любым терминам этой строки. Если вы выполняете запрос match по полю с точным значением, он возвращает документы, которые соответствуют этому точному значению. Предпочтительный способ поиска по полям с точными значениями — использовать фильтр, поскольку, в отличие от запроса, фильтр кэшируется.

Пример

Следующий пример показывает базовый запрос match для слова “wind” в заголовке:

GET _search
{
  "query": {
    "match": {
      "title": "wind"
    }
  }
}

Чтобы передать дополнительные параметры, вы можете использовать расширенный синтаксис:

GET _search
{
  "query": {
    "match": {
      "title": {
        "query": "wind",
        "analyzer": "stop"
      }
    }
  }
}

Примеры

В следующих примерах вы будете использовать индекс, содержащий следующие документы:

PUT testindex/_doc/1
{
  "title": "Let the wind rise"
}

PUT testindex/_doc/2
{
  "title": "Gone with the wind"
}

PUT testindex/_doc/3
{
  "title": "Rise is gone"
}

Оператор

Если запрос match выполняется по текстовому полю, текст анализируется с помощью анализатора, указанного в параметре analyzer. Затем полученные токены объединяются в логический запрос с использованием оператора, указанного в параметре operator. Оператор по умолчанию — OR, поэтому запрос “wind rise” преобразуется в “wind OR rise”. В этом примере этот запрос возвращает документы 1–3, поскольку каждый документ содержит термин, соответствующий запросу. Чтобы указать оператор AND, используйте следующий запрос:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "wind rise",
        "operator": "and"
      }
    }
  }
}

Запрос формируется как “wind AND rise” и возвращает документ 1 как совпадающий документ.

Минимальное количество совпадений

Вы можете контролировать минимальное количество терминов, которые документ должен совпадать, чтобы быть возвращенным в результатах, указав параметр minimum_should_match:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "wind rise",
        "operator": "or",
        "minimum_should_match": 2
      }
    }
  }
}

Теперь документы должны совпадать с обоими терминами, поэтому возвращается только документ 1 (это эквивалентно оператору AND).

Анализатор

Поскольку в этом примере вы не указали анализатор, используется анализатор по умолчанию — стандартный анализатор. Стандартный анализатор не выполняет стемминг, поэтому если вы выполните запрос “the wind rises”, вы не получите результатов, поскольку токен “rises” не совпадает с токеном “rise”. Чтобы изменить анализатор поиска, укажите его в поле analyzer. Например, следующий запрос использует английский анализатор:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "the wind rises",
        "operator": "and",
        "analyzer": "english"
      }
    }
  }
}

Английский анализатор удаляет стоп-слово “the” и выполняет стемминг, производя токены “wind” и “rise”. Последний токен совпадает с документом 1, который возвращается в результатах.

Пустой запрос

В некоторых случаях анализатор может удалить все токены из запроса. Например, английский анализатор удаляет стоп-слова, поэтому в запросе “and OR or” все токены удаляются. Чтобы проверить поведение анализатора, вы можете использовать API анализа:

GET testindex/_analyze
{
  "analyzer": "english",
  "text": "and OR or"
}

Как и ожидалось, запрос не производит токенов:

{
  "tokens": []
}

Вы можете задать поведение для пустого запроса с помощью параметра zero_terms_query. Установка zero_terms_query в значение all возвращает все документы в индексе, а установка в none не возвращает ни одного документа:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "and OR or",
        "analyzer": "english",
        "zero_terms_query": "all"
      }
    }
  }
}

Неопределенность (Fuzziness)

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

• Целое число, которое указывает максимальное допустимое расстояние по Дамерау-Левенштейну для этого редактирования.
• AUTO:
  • Строки длиной 0–2 символа должны совпадать точно.
  • Строки длиной 3–5 символов допускают 1 редактирование.
  • Строки длиной более 5 символов допускают 2 редактирования.

Установка нечеткости на значение по умолчанию AUTO работает лучше всего в большинстве случаев:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "wnid",
        "fuzziness": "AUTO"
      }
    }
  }
}

Токен “wnid” совпадает с “wind”, и запрос возвращает документы 1 и 2.

Длина префикса

Опечатки редко встречаются в начале слов. Таким образом, вы можете указать минимальную длину, которую должен иметь совпадающий префикс, чтобы документ был возвращен в результатах. Например, вы можете изменить предыдущий запрос, добавив параметр prefix_length:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "wnid",
        "fuzziness": "AUTO",
        "prefix_length": 2
      }
    }
  }
}

Предыдущий запрос не возвращает результатов. Если вы измените prefix_length на 1, документы 1 и 2 будут возвращены, поскольку первая буква токена “wnid” не ошибочна.

Транспозиции

В предыдущем примере слово “wnid” содержало транспозицию (буквы “i” и “n” были поменяны местами). По умолчанию транспозиции допускаются в нечетком совпадении, но вы можете запретить их, установив fuzzy_transpositions в false:

GET testindex/_search
{
  "query": {
    "match": {
      "title": {
        "query": "wnid",
        "fuzziness": "AUTO",
        "fuzzy_transpositions": false
      }
    }
  }
}

Теперь запрос не возвращает результатов.

Синонимы

Если вы используете фильтр synonym_graph и параметр auto_generate_synonyms_phrase_query установлен в true (по умолчанию), OpenSearch разбивает запрос на термины, а затем объединяет термины для генерации фразового запроса для многословных синонимов. Например, если вы укажете “ba, batting average” как синонимы и выполните поиск по “ba”, OpenSearch будет искать “ba” OR “batting average”.

Чтобы сопоставить многословные синонимы с союзами, установите auto_generate_synonyms_phrase_query в false:

GET /testindex/_search
{
  "query": {
    "match": {
      "text": {
        "query": "good ba",
        "auto_generate_synonyms_phrase_query": false
      }
    }
  }
}

Сформированный запрос будет “ba” OR (“batting” AND “average”).

Параметры

Запрос принимает имя поля (<field>) в качестве верхнеуровневого параметра:

GET _search
{
  "query": {
    "match": {
      "<field>": {
        "query": "text to search for",
        ...
      }
    }
  }
}

Параметр <field> принимает следующие параметры. Все параметры, кроме query, являются необязательными.

4.2 - match-bool-prefix

Запрос Match Boolean Prefix

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

Пример

Следующий пример показывает базовый запрос match_bool_prefix:

GET _search
{
  "query": {
    "match_bool_prefix": {
      "title": "the wind"
    }
  }
}

Чтобы передать дополнительные параметры, вы можете использовать расширенный синтаксис:

GET _search
{
  "query": {
    "match_bool_prefix": {
      "title": {
        "query": "the wind",
        "analyzer": "stop"
      }
    }
  }
}

Пример документов

Рассмотрим индекс с следующими документами:

PUT testindex/_doc/1
{
  "title": "The wind rises"
}

PUT testindex/_doc/2
{
  "title": "Gone with the wind"
}

Следующий запрос match_bool_prefix ищет целое слово “rises” и слова, начинающиеся с “wi”, в любом порядке:

GET testindex/_search
{
  "query": {
    "match_bool_prefix": {
      "title": "rises wi"
    }
  }
}

Предыдущий запрос эквивалентен следующему логическому запросу:

GET testindex/_search
{
  "query": {
    "bool": {
      "should": [
        { "term": { "title": "rises" }},
        { "prefix": { "title": "wi" }}
      ]
    }
  }
}

Ответ содержит оба документа:

Ответ

{
  "took": 15,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 2,
      "relation": "eq"
    },
    "max_score": 1.73617,
    "hits": [
      {
        "_index": "testindex",
        "_id": "1",
        "_score": 1.73617,
        "_source": {
          "title": "The wind rises"
        }
      },
      {
        "_index": "testindex",
        "_id": "2",
        "_score": 1,
        "_source": {
          "title": "Gone with the wind"
        }
      }
    ]
  }
}

Запросы match_bool_prefix и match_phrase_prefix

Запрос match_bool_prefix сопоставляет термины в любой позиции, в то время как запрос match_phrase_prefix сопоставляет термины как целую фразу. Чтобы проиллюстрировать разницу, снова рассмотрим запрос match_bool_prefix из предыдущего раздела:

GET testindex/_search
{
  "query": {
    "match_bool_prefix": {
      "title": "rises wi"
    }
  }
}

Оба документа “The wind rises” и “Gone with the wind” соответствуют поисковым терминам, поэтому запрос возвращает оба документа.

Теперь выполните запрос match_phrase_prefix по тому же индексу:

GET testindex/_search
{
  "query": {
    "match_phrase_prefix": {
      "title": "rises wi"
    }
  }
}

Ответ не возвращает документов, потому что ни один из документов не содержит фразу “rises wi” в указанном порядке.

Анализатор

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

GET testindex/_search
{
  "query": {
    "match_bool_prefix": {
      "title": {
        "query": "rise the wi",
        "analyzer": "stop"
      }
    }
  }
}

Параметры

Запрос принимает имя поля (<field>) в качестве верхнеуровневого параметра:

GET _search
{
  "query": {
    "match_bool_prefix": {
      "<field>": {
        "query": "text to search for",
        ...
      }
    }
  }
}

Параметр <field> принимает следующие параметры. Все параметры, кроме query, являются необязательными.

Параметры fuzziness, fuzzy_transpositions, fuzzy_rewrite, max_expansions и prefix_length могут применяться к подзапросам term, созданным для всех терминов, кроме последнего. Они не оказывают никакого влияния на префиксный запрос, созданный для последнего термина.

4.3 - match-phrase

Запрос match_phrase

Используйте запрос match_phrase, чтобы находить документы, содержащие точную фразу в указанном порядке. Вы можете добавить гибкость к фразовому соответствию, указав параметр slop.

Запрос match_phrase создает фразовый запрос, который соответствует последовательности терминов.

Пример базового запроса match_phrase:

GET _search
{
  "query": {
    "match_phrase": {
      "title": "ветер дует"
    }
  }
}

Чтобы передать дополнительные параметры, вы можете использовать расширенный синтаксис:

GET _search
{
  "query": {
    "match_phrase": {
      "title": {
        "query": "ветер дует",
        "analyzer": "stop"
      }
    }
  }
}

Пример

Рассмотрим индекс с следующими документами:

PUT testindex/_doc/1
{
  "title": "The wind rises"
}

PUT testindex/_doc/2
{
  "title": "Ушедший с ветром"
}

Следующий запрос match_phrase ищет фразу “wind rises”, где слово “ветер” следует за словом “поднимается”:

GET testindex/_search
{
  "query": {
    "match_phrase": {
      "title": "wind rises"
    }
  }
}

Ответ содержит соответствующий документ:

{
  "took": 30,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.92980814,
    "hits": [
      {
        "_index": "testindex",
        "_id": "1",
        "_score": 0.92980814,
        "_source": {
          "title": "The wind rises"
        }
      }
    ]
  }
}

Анализатор

По умолчанию, когда вы выполняете запрос по текстовому полю, текст поиска анализируется с использованием анализатора индекса, связанного с полем. Вы можете указать другой анализатор поиска в параметре analyzer. Например, следующий запрос использует английский анализатор:

GET testindex/_search
{
  "query": {
    "match_phrase": {
      "title": {
        "query": "ветра",
        "analyzer": "english"
      }
    }
  }
}

Английский анализатор удаляет стоп-слово “the” и выполняет стемминг, производя токен “ветер”. Оба документа соответствуют этому токену и возвращаются в результатах:

Slop

Если вы укажете параметр slop, запрос допускает перестановку поисковых терминов. Параметр slop указывает количество других слов, разрешенных между словами в фразе запроса. Например, в следующем запросе текст поиска переставлен по сравнению с текстом документа:

GET _search
{
  "query": {
    "match_phrase": {
      "title": {
        "query": "ветер поднимается",
        "slop": 3
      }
    }
  }
}

Запрос все равно возвращает соответствующий документ:

Пустой запрос

Для информации о возможном пустом запросе смотрите соответствующий раздел запроса match.

Параметры

Запрос принимает имя поля (<field>) в качестве параметра верхнего уровня:

GET _search
{
  "query": {
    "match_phrase": {
      "<field>": {
        "query": "текст для поиска",
        ...
      }
    }
  }
}

Параметры <field> принимают следующие значения. Все параметры, кроме query, являются необязательными.

4.4 - match-phrase-prefix

Запрос match_phrase_prefix

Используйте запрос match_phrase_prefix, чтобы указать фразу для поиска в заданном порядке. Документы, содержащие указанную вами фразу, будут возвращены. Последний неполный термин в фразе интерпретируется как префикс, поэтому любые документы, содержащие фразы, начинающиеся с указанной фразы и префикса последнего термина, будут возвращены.

Запрос аналогичен match_phrase, но создает префиксный запрос из последнего термина в строке запроса.

Для различий между запросами match_phrase_prefix и match_bool_prefix смотрите раздел о запросах match_bool_prefix и match_phrase_prefix.

Пример базового запроса match_phrase_prefix:

GET _search
{
  "query": {
    "match_phrase_prefix": {
      "title": "ветер дует"
    }
  }
}

Чтобы передать дополнительные параметры, вы можете использовать расширенный синтаксис:

GET _search
{
  "query": {
    "match_phrase_prefix": {
      "title": {
        "query": "ветер дует",
        "analyzer": "stop"
      }
    }
  }
}

Пример

Рассмотрим индекс с следующими документами:

PUT testindex/_doc/1
{
  "title": "Ветер поднимается"
}

PUT testindex/_doc/2
{
  "title": "Ушедший с ветром"
}

Следующий запрос match_phrase_prefix ищет полное слово “ветер”, за которым следует слово, начинающееся на “под”:

GET testindex/_search
{
  "query": {
    "match_phrase_prefix": {
      "title": "ветер под"
    }
  }
}

Ответ содержит соответствующий документ:

{
  "took": 6,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1,
      "relation": "eq"
    },
    "max_score": 0.92980814,
    "hits": [
      {
        "_index": "testindex",
        "_id": "1",
        "_score": 0.92980814,
        "_source": {
          "title": "Ветер поднимается"
        }
      }
    ]
  }
}

Параметры

Запрос принимает имя поля (<field>) в качестве параметра верхнего уровня:

GET _search
{
  "query": {
    "match_phrase_prefix": {
      "<field>": {
        "query": "текст для поиска",
        ...
      }
    }
  }
}

Параметры <field> принимают следующие значения. Все параметры, кроме query, являются необязательными.

4.5 - multi-match

Многофункциональные запросы (Multi-match queries)

Операция multi-match функционирует аналогично операции match. Вы можете использовать запрос multi_match для поиска по нескольким полям.

Символ ^ “увеличивает” вес определенных полей. Увеличения — это множители, которые придают больший вес совпадениям в одном поле по сравнению с совпадениями в других полях. В следующем примере совпадение для “ветер” в поле title влияет на _score в четыре раза больше, чем совпадение в поле plot:

GET _search
{
  "query": {
    "multi_match": {
      "query": "ветер",
      "fields": ["title^4", "plot"]
    }
  }
}

В результате фильмы, такие как “Ветер поднимается” и “Ушедший с ветром”, находятся в верхней части результатов поиска, а фильмы, такие как “Ураган”, которые, предположительно, содержат “ветер” в своих аннотациях, находятся внизу.

Вы можете использовать подстановочные знаки в имени поля. Например, следующий запрос будет искать поле speaker и все поля, начинающиеся с play_, например, play_name или play_title: