Spec-Zone.ru › Elasticsearch 7
›Elasticsearch Guide [7.17] ›Query DSL ›Полные текстовые запросы

Запрос с строкой запроса

Эта страница содержит информацию о типе запроса query_string. Для получения информации о выполнении запроса поиска в Elasticsearch см. Поиск данных.

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

Этот запрос использует синтаксис для разбора и разделения предоставленной строки запроса на основе операторов, таких как AND или NOT. Затем запрос анализирует каждый разделённый текст независимо перед возвратом соответствующих документов.

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

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

Если вам не нужно поддерживать синтаксис запроса, рассмотрите использование запроса match. Если вам нужны возможности синтаксиса запроса, используйте запрос simple_query_string, который менее строгий.

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

При выполнении следующего поиска запрос query_string разделяет (new york city) OR (big apple) на две части: new york city и big apple. Анализатор поля content затем независимо преобразует каждую часть в токены перед возвратом соответствующих документов. Поскольку синтаксис запроса не использует пробелы в качестве оператора, new york city передаётся анализатору как есть.

GET /_search
{
  "query": {
    "query_string": {
      "query": "(new york city) OR (big apple)",
      "default_field": "content"
    }
  }
}

Параметры верхнего уровня для query_string

query
(Обязательный, строка) Строка запроса, которую вы хотите проанализировать и использовать для поиска. См. синтаксис строки запроса.
default_field

(Необязательный, строка) Поле по умолчанию для поиска, если в строке запроса не указано поле. Поддерживает подстановки (*).

По умолчанию устанавливается значение параметра index.query.default_field в индексе, которое имеет значение по умолчанию *. Значение * извлекает все поля, подходящие для запросов типа term и фильтрует поля метаданных. Затем все извлечённые поля объединяются для создания запроса, если не указан параметр prefix.

Поиск по всем подходящим полям не включает вложенные документы. Используйте запрос nested для поиска таких документов.

Для индексов с большим количеством полей поиск по всем подходящим полям может быть ресурсоёмким.

Существует ограничение на количество полей, которые можно запросить одновременно. Оно определяется параметром indices.query.bool.max_clause_count настройки поиска, по умолчанию равным 1024.

allow_leading_wildcard
(Необязательный, булево) Если true, символы подстановки * и ? разрешены в качестве первого символа в строке запроса. По умолчанию true.
analyze_wildcard
(Необязательный, булево) Если true, запрос пытается проанализировать символы подстановки в строке запроса. По умолчанию false.
analyzer
(Необязательный, строка) Анализатор, используемый для преобразования текста в строке запроса в токены. По умолчанию используется анализатор индекса, сопоставленный с полем default_field. Если анализатор не сопоставлен, используется анализатор по умолчанию для индекса.
auto_generate_synonyms_phrase_query
(Необязательный, булево) Если true, запросы match phrase автоматически создаются для многословных синонимов. По умолчанию true. См. Синонимы и запрос query_string для примера.
boost

(Необязательный, число с плавающей точкой) Число с плавающей точкой, используемое для уменьшения или увеличения баллов релевантности запроса. По умолчанию 1.0.

Значения буста относительны к значению по умолчанию параметра 1.0. Значение буста между 0 и 1.0 уменьшает релевантность. Значение больше чем 1.0 увеличивает релевантность.

default_operator

(Необязательный, строка) Логика по умолчанию для интерпретации текста в строке запроса, если не указаны операторы. Допустимые значения:

OR (По умолчанию)
Например, строка запроса capital of Hungary интерпретируется как capital OR of OR Hungary.
AND
Например, строка запроса capital of Hungary интерпретируется как capital AND of AND Hungary.
enable_position_increments
(Необязательный, булево) Если true, включить приращения позиций в запросах, построенных из поиска query_string. По умолчанию true.
fields

(Необязательный, массив строк) Массив полей для поиска. Поддерживает подстановки (*).

Вы можете использовать этот параметр для поиска по нескольким полям. См. Поиск по нескольким полям.

fuzziness
(Необязательный, строка) Максимальное расстояние редактирования, разрешенное для неточного совпадения. Для синтаксиса неточного совпадения см. Неточность.
fuzzy_max_expansions
(Необязательный, целое число) Максимальное количество терминов, до которых запрос расширяется для неточного совпадения. По умолчанию 50.
fuzzy_prefix_length
(Необязательный, целое число) Максимальное количество начальных символов, оставленных неизменными для неточного совпадения. По умолчанию 0.
fuzzy_transpositions
(Необязательный, булево) Если true, исправления для неточного совпадения включают перестановки двух смежных символов (ab → ba). По умолчанию true.
lenient
(Необязательный, булево) Если true, ошибки, основанные на формате, такие как предоставление текстового значения для числового поля, игнорируются. По умолчанию false.
max_determinized_states

(Необязательный, целое число) Максимальное количество состояний автомата, требуемых для запроса. По умолчанию 10000.

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

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

minimum_should_match
(Необязательный, строка) Минимальное количество клаузов, которые должны совпадать для возврата документа. См. параметр minimum_should_match для допустимых значений и дополнительной информации. См. Как работает minimum_should_match для примера.
quote_analyzer

(Необязательный, строка) Анализатор, используемый для преобразования цитируемого текста в строке запроса в токены. По умолчанию используется search_quote_analyzer, сопоставленный с полем default_field.

Для цитируемого текста этот параметр переопределяет анализатор, указанный в параметре analyzer.

phrase_slop
(Необязательный, целое число) Максимальное количество позиций, разрешенных между совпадающими токенами для фраз. По умолчанию 0. Если 0, требуются точные совпадения фраз. Для переставленных терминов значение параметра slop равно 2.
quote_field_suffix

(Необязательный, строка) Суффикс, добавляемый к цитируемому тексту в строке запроса.

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

rewrite
(Необязательный, строка) Метод переопределения запроса. Для допустимых значений и дополнительной информации см. rewrite.
time_zone

(Необязательный, строка) Смещение Coordinated Universal Time (UTC) или часовой пояс IANA, используемый для преобразования значений date в строке запроса в UTC.

Допустимые значения: смещения UTC в формате ISO 8601, например, +01:00 или -08:00, и идентификаторы часовых поясов IANA, такие как America/Los_Angeles.

Параметр time_zone не влияет на значение date math now. now всегда является текущим системным временем в UTC. Однако параметр time_zone преобразует даты, вычисленные с помощью now и округления date math. Например, параметр time_zone преобразует значение now/d.

Примечания

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

Язык запросов в строке используется запросом по строке и параметром строки запроса q в search API.

Строка запроса анализируется в ряд терминов и операторов. Термин может быть одним словом — quick или brown — или фразой, заключённой в двойные кавычки — "quick brown" — которая ищет все слова в фразе в том же порядке.

Операторы позволяют настроить поиск — доступные варианты объяснены ниже.

Имена полей

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

  • где поле status содержит active

    status:active
  • где поле title содержит quick или brown

    title:(quick OR brown)
  • где поле author содержит точную фразу "john smith"

    author:"John Smith"
  • где поле first name содержит Alice (обратите внимание, как мы должны экранировать пробел с помощью обратного слэша)

    first\ name:Alice
  • где любое из полей book.title, book.content или book.date содержит quick или brown (обратите внимание, как мы должны экранировать * с помощью обратного слэша):

    book.\*:(quick OR brown)
  • где поле title имеет какое-либо ненулевое значение:

    _exists_:title
Подстановочные знаки

Поиск с подстановочными знаками может выполняться по отдельным терминам, используя ? для замены одного символа и * для замены нуля или более символов:

qu?ck bro*

Следует учитывать, что запросы с подстановочными знаками могут использовать огромное количество памяти и работать очень медленно — просто представьте, сколько терминов нужно запросить, чтобы соответствовать строке запроса "a* b* c*".

Чистые подстановочные знаки \* переписываются в запросы exists для повышения эффективности. В результате подстановочный знак "field:*" будет соответствовать документам с пустым значением, как в следующем примере:

{
  "field": ""
}

… и не будет соответствовать, если поле отсутствует или установлено явным образом как нулевое, как в следующем примере:

{
  "field": null
}

Разрешение подстановочного знака в начале слова (например, "*ing") особенно ресурсоёмко, потому что все термины в индексе необходимо проверить, чтобы проверить соответствие. Ведущие подстановочные знаки могут быть отключены путем установки allow_leading_wildcard в false.

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

Установив analyze_wildcard в значение true, запросы, заканчивающиеся на *, будут проанализированы, и на основе различных токенов будет построен булевый запрос, гарантирующий точное совпадение первых N-1 токенов и поиск по префиксу последнего токена.

Регулярные выражения

Шаблоны регулярных выражений могут быть встроены в строку запроса, заключив их в обратные слэши ("/"):

name:/joh?n(ath[oa]n)/

Синтаксис поддерживаемых регулярных выражений описан в синтаксисе регулярных выражений.

Параметр allow_leading_wildcard не имеет никакого влияния на регулярные выражения. Строка запроса, подобная следующей, заставит Elasticsearch посетить каждый термин в индексе:

/.*n/

Используйте с осторожностью!

Неточность

Вы можете выполнить fuzzy запросы с использованием оператора ~:

quikc~ brwn~ foks~

Для этих запросов строка запроса нормализуется. Если они присутствуют, применяются только определённые фильтры из анализатора. Список применимых фильтров см. в Нормализаторах.

Запрос использует расстояние Дамерау-Левенштейна, чтобы найти все термины с максимальным количеством двух изменений, где изменение — это вставка, удаление или замена одного символа или транспозиция двух смежных символов.

По умолчанию расстояние редактирования равно 2, но расстояние редактирования 1 должно быть достаточно, чтобы поймать 80% всех орфографических ошибок человека. Его можно указать следующим образом:

quikc~1

Избегайте смешивания неточности с подстановочными знаками

Смешивание неточных и подстановочных операторов не поддерживается. При смешивании один из операторов не применяется. Например, вы можете искать app~1 (неточно) или app* (подстановочный знак), но поиск app*~1 не применяет оператор неточности (~1).

Поиск по близости

В то время как запрос по фразе (например, "john smith") ожидает все термины в точно таком же порядке, запрос по близости допускает, что указанные слова могут находиться дальше друг от друга или в другом порядке. Так же как запросы с неточностями могут указать максимальное расстояние редактирования для символов в слове, запрос по близости позволяет указать максимальное расстояние редактирования слов во фразе:

"fox quick"~5

Чем ближе текст в поле к исходному порядку, указанному в строке запроса, тем более релевантным считается этот документ. В сравнении с вышеупомянутым запросом, фраза "quick fox" будет считаться более релевантной, чем "quick brown fox".

Диапазоны

Диапазоны могут быть указаны для полей даты, числовых или строковых полей. Включительно диапазоны задаются квадратными скобками [min TO max], а исключающие диапазоны — фигурными скобками {min TO max}.

  • Все дни 2012 года:

    date:[2012-01-01 TO 2012-12-31]
  • Числа от 1 до 5

    count:[1 TO 5]
  • Теги между alpha и omega, исключая alpha и omega:

    tag:{alpha TO omega}
  • Числа от 10 и выше

    count:[10 TO *]
  • Даты до 2012 года

    date:{* TO 2012-01-01}

Фигурные и квадратные скобки можно комбинировать:

  • Числа от 1 до 5, не включая 5

    count:[1 TO 5}

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

age:>10
age:>=10
age:<10
age:<=10

Чтобы объединить верхнюю и нижнюю границы с упрощенным синтаксисом, вам нужно будет объединить два условия с оператором AND:

age:(>=10 AND <20)
age:(+>=10 +<20)

Парсинг диапазонов в строках запросов может быть сложным и подвержен ошибкам. Гораздо надёжнее использовать явный range запрос.

Усиление

Используйте оператор усиления ^, чтобы сделать один термин более релевантным, чем другой. Например, если мы хотим найти все документы о лисах, но особенно интересуемся быстрыми лисами:

quick^2 fox

Значение по умолчанию boost равно 1, но может быть любым положительным числом с плавающей точкой. Усиления от 0 до 1 уменьшают релевантность.

Усиления также могут применяться к фразам или группам:

"john smith"^2   (foo bar)^4
Булевы операторы

По умолчанию все термины являются необязательными, если хотя бы один термин совпадает. Поиск foo bar baz найдет любые документы, содержащие один или несколько из foo, bar или baz. Мы уже обсуждали default_operator выше, который позволяет принудительно сделать все термины обязательными, но также существуют булевы операторы, которые могут быть использованы в строке запроса для большего контроля.

Предпочтительными операторами являются + (этот термин должен присутствовать) и - (этот термин не должен присутствовать). Все остальные термины необязательны. Например, этот запрос:

quick brown +fox -news

указывает, что:

  • fox должен присутствовать
  • news не должен присутствовать
  • quick и brown необязательны — их присутствие повышает релевантность

Обычные булевы операторы AND, OR и NOT (также записанные как &&, || и !) также поддерживаются, но будьте осторожны, поскольку они не учитывают обычные правила приоритета, поэтому скобки следует использовать всякий раз, когда несколько операторов используются вместе. Например, предыдущий запрос можно переписать как:

((quick AND fox) OR (brown AND fox) OR fox) AND NOT news
Эта форма теперь правильно воспроизводит логику исходного запроса, но оценка релевантности мало похожа на исходную.

В противоположность этому, тот же запрос, переписанный с использованием match запроса, будет выглядеть так:

{
    "bool": {
        "must":     { "match": "fox"         },
        "should":   { "match": "quick brown" },
        "must_not": { "match": "news"        }
    }
}
Группировка

Несколько терминов или предложений можно сгруппировать вместе в скобках, чтобы сформировать подзапросы:

(quick OR brown) AND fox

Группы могут быть использованы для нацеливания на определённое поле или для повышения результата подзапроса:

status:(active OR pending) title:(full text search)^2
Зарезервированные символы

Если вам нужно использовать любой из символов, которые работают как операторы в вашем запросе (а не как операторы), то их следует экранировать с помощью ведущей обратной косой черты. Например, чтобы найти (1+1)=2, вам нужно записать свой запрос как \(1\+1\)\=2. При использовании JSON для тела запроса требуются две предшествующие обратные косые черты (\\); обратная косая черта является зарезервированным символом экранирования в JSON-строках.

GET /my-index-000001/_search
{
  "query" : {
    "query_string" : {
      "query" : "kimchy\\!",
      "fields"  : ["user.id"]
    }
  }
}

Зарезервированные символы: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /

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

< и > вообще нельзя экранировать. Единственный способ предотвратить их попытку создания запроса диапазона — полностью удалить их из строки запроса.

Пробелы и пустые запросы

Пробелы не рассматриваются как операторы.

Если строка запроса пуста или содержит только пробелы, запрос вернет пустой набор результатов.

Избегайте использования запроса query_string для вложенных документов

Поиск query_string не возвращает вложенные документы. Для поиска вложенных документов используйте nested запрос.

Поиск по нескольким полям

Вы можете использовать параметр fields для выполнения поиска query_string по нескольким полям.

Идея запуска query_string запроса по нескольким полям заключается в расширении каждого поискового термина до логического ИЛИ, как показано ниже:

field1:query_term OR field2:query_term | ...

Например, следующий запрос

GET /_search
{
  "query": {
    "query_string": {
      "fields": [ "content", "name" ],
      "query": "this AND that"
    }
  }
}

соответствует тем же словам, что и

GET /_search
{
  "query": {
    "query_string": {
      "query": "(content:this OR name:this) AND (content:that OR name:that)"
    }
  }
}

Поскольку из отдельных поисковых терминов генерируется несколько запросов, их объединение автоматически выполняется с использованием dis_max запроса с tie_breaker. Например (name усиливается на 5 с помощью ^5 обозначения):

GET /_search
{
  "query": {
    "query_string" : {
      "fields" : ["content", "name^5"],
      "query" : "this AND that OR thus",
      "tie_breaker" : 0
    }
  }
}

Простые символы подстановки также могут использоваться для поиска «внутри» определённых внутренних элементов документа. Например, если у нас есть объект city с несколькими полями (или вложенный объект с полями), мы можем автоматически искать по всем полям «city»:

GET /_search
{
  "query": {
    "query_string" : {
      "fields" : ["city.*"],
      "query" : "this AND that OR thus"
    }
  }
}

Другой вариант — указать поиск с символами подстановки в строке запроса (правильно экранируя символ *), например: city.\*:something:

GET /_search
{
  "query": {
    "query_string" : {
      "query" : "city.\\*:(this AND that OR thus)"
    }
  }
}

Поскольку \ (обратная косая черта) является специальным символом в JSON-строках, его необходимо экранировать, поэтому в приведенном выше query_string используются две обратные косые черты.

Параметр fields также может включать шаблоны имён полей, позволяя автоматически расширяться до соответствующих полей (включая динамически введённые поля). Например:

GET /_search
{
  "query": {
    "query_string" : {
      "fields" : ["content", "name.*^5"],
      "query" : "this AND that OR thus"
    }
  }
}
Дополнительные параметры для поиска по нескольким полям

При выполнении query_string запроса по нескольким полям поддерживаются следующие дополнительные параметры.

type

(Необязательный, строка) Определяет, как запрос соответствует и оценивает документы. Допустимые значения:

best_fields (По умолчанию)
Находит документы, которые соответствуют любому полю, и использует наивысшую _score из любого соответствующего поля. См. best_fields.
bool_prefix
Создает match_bool_prefix запрос для каждого поля и комбинирует _score из каждого поля. См. bool_prefix.
cross_fields
Обрабатывает поля с одинаковым analyzer, как будто они представляют одно большое поле. Ищет каждое слово в любом поле. См. cross_fields.
most_fields
Находит документы, которые соответствуют любому полю, и объединяет _score из каждого поля. См. most_fields.
phrase
Выполняет match_phrase запрос для каждого поля и использует _score из лучшего поля. См. phrase и phrase_prefix.
phrase_prefix
Выполняет match_phrase_prefix запрос для каждого поля и использует _score из лучшего поля. См. phrase и phrase_prefix.

ПРИМЕЧАНИЕ: Доступны дополнительные параметры верхнего уровня multi_match, в зависимости от значения type.

Синонимы и запрос query_string

Запрос query_string поддерживает расширение синонимов с множеством терминов с помощью фильтра токенов synonym_graph. При использовании этого фильтра парсер создаёт фразный запрос для каждого синонима с несколькими терминами. Например, следующий синоним: ny, new york создаст:

(ny OR ("new york"))

Также можно сопоставить синонимы с несколькими терминами с помощью союзов:

GET /_search
{
   "query": {
       "query_string" : {
           "default_field": "title",
           "query" : "ny city",
           "auto_generate_synonyms_phrase_query" : false
       }
   }
}

Приведённый выше пример создаёт булев запрос:

(ny OR (new AND york)) city

который соответствует документам с термином ny или союзом new AND york. По умолчанию параметр auto_generate_synonyms_phrase_query установлен в true.

Как работает запрос minimum_should_match

query_string разбивает запрос вокруг каждого оператора, создавая булев запрос для всего входного значения. Вы можете использовать minimum_should_match для управления тем, сколько «должных» пунктов в результирующем запросе должны совпадать.

GET /_search
{
  "query": {
    "query_string": {
      "fields": [
        "title"
      ],
      "query": "this that thus",
      "minimum_should_match": 2
    }
  }
}

Приведённый выше пример создаёт булев запрос:

(title:this title:that title:thus)~2

который соответствует документам, содержащим по крайней мере два из терминов this, that или thus в единственном поле title.

Как работает minimum_should_match для нескольких полей

GET /_search
{
  "query": {
    "query_string": {
      "fields": [
        "title",
        "content"
      ],
      "query": "this that thus",
      "minimum_should_match": 2
    }
  }
}

Приведенный выше пример создает булеву запросу:

((content:this content:that content:thus) | (title:this title:that title:thus))

которая соответствует документам с дизъюнкцией max по полям title и content. Здесь параметр minimum_should_match нельзя применить.

GET /_search
{
  "query": {
    "query_string": {
      "fields": [
        "title",
        "content"
      ],
      "query": "this OR that OR thus",
      "minimum_should_match": 2
    }
  }
}

Добавление явных операторов заставляет каждый терм рассматриваться как отдельную клаузу.

Приведенный выше пример создает булеву запросу:

((content:this | title:this) (content:that | title:that) (content:thus | title:thus))~2

которая соответствует документам с по крайней мере двумя из трех клауз "should", каждая из которых состоит из дизъюнкции max по полям для каждого термина.

Как работает minimum_should_match для межпольных поисков

Значение cross_fields в поле type указывает на то, что поля с одинаковым анализатор будут сгруппированы вместе при анализе входных данных.

GET /_search
{
  "query": {
    "query_string": {
      "fields": [
        "title",
        "content"
      ],
      "query": "this OR that OR thus",
      "type": "cross_fields",
      "minimum_should_match": 2
    }
  }
}

Приведенный выше пример создает булеву запросу:

(blended(terms:[field2:this, field1:this]) blended(terms:[field2:that, field1:that]) blended(terms:[field2:thus, field1:thus]))~2

которая соответствует документам с по крайней мере двумя из трех смешанных запросов по каждому термину.

Разрешение дорогостоящих запросов

Запрос с использованием строки запроса может быть внутренне преобразован в prefix query, что означает, что если запросы с префиксом отключены, как описано в здесь, запрос не будет выполнен, и будет выброшено исключение.

© 2023-2025 Elasticsearch
As of September 2024, Elasticsearch is available under a choice of three licenses: the Server Side Public License (SSPL), the Elastic License, or the AGPLv3 (OSI approved).
Elasticsearch and the Elasticsearch logo are trademarks of Elasticsearch B.V., registered in the U.S. and in other countries.
https://www.elastic.co/guide/en/elasticsearch/reference/7.17/query-dsl-query-string-query.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API