Сравнение query_string и match в Elasticsearch при работе со спецсимволами

Дата подготовки материала: (по информации из сети).

При работе с Elasticsearch часто возникает необходимость выбрать подходящий тип запроса. Два самых популярных варианта – query_string и match – различаются по синтаксису, гибкости и способу обработки специальных символов (например, точки, запятые, дефисы, кавычки, звёздочки и т.д.). В этой статье мы подробно рассмотрим, как каждый из них ведёт себя при наличии спецсимволов, какие подводные камни могут возникнуть и как их избежать.

Что такое query_string

query_string – это мощный запрос, который позволяет использовать почти весь синтаксис Lucene в одной строке. Он поддерживает логические операторы (AND, OR, NOT), групповые скобки, фразовый поиск, подстановочные знаки, диапазоны и т.д.

Преимущества

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

Недостатки при работе со спецсимволами

Спецсимволы имеют особое значение в синтаксисе Lucene (например, + ౼ & | ! ( ) { } [ ] ^ " ~ * ? : ). Если они встречаются в поисковом термине без экранирования, запрос может быть интерпретирован неправильно или вернуть ошибку parse exception.
Необходимость экранирования каждого спецсимвола, который должен восприниматься как обычный символ. Это делает запрос громоздким и повышает риск ошибок.
При использовании анализируемых полей (analyzed) query_string сначала разбирается, затем каждый токен проходит через анализатор. Если анализатор удаляет или изменяет спецсимволы, ожидаемое поведение может измениться.

Пример экранирования

Найдём документы, где поле title содержит строку C++:

query_string запрос:

{
 "query": {
 "query_string": {
 "query": "title:C\+\+",
 "default_field": "title"
 }
 }
}

Здесь каждый плюс экранирован обратным слешем (+), а сам обратный слеш также экранирован для JSON.

Что такое match query

match – это запрос на уровне полей, который анализирует введённый текст с помощью того же анализатора, что использовался при индексации поля. Он предназначен для простого полнотекстового поиска и не поддерживает сложный Lucene‑синтаксис.

Автоматическое применение анализатора: спецсимволы обрабатываются согласно настройкам анализатора (например, стандартный анализатор удаляет большинство пунктуационных знаков).
Отсутствие необходимости ручного экранирования – пользователь вводит текст «как есть».
Простота и читаемость запроса.

Если нужно найти точное вхождение спецсимвола (например, искать e-mail с дефисом), стандартный анализатор может удалить дефис, и совпадение не будет найдено. В таких случаях требуется либо использовать keyword‑поле (неанализируемое), либо задать кастомный анализатор, сохраняющий нужные символы.
Меньше возможностей для сложных логических конструкций (нет прямой поддержки AND/OR, групп, подстановочных знаков без дополнительных запросов).
Boost применяется только к целому полю, а не к отдельным частям запроса.

Пример работы с дефисом

Поле description анализируется стандартным анализатором. Нужно найти документы, содержащие слово e-mail.

Запрос match:

{
 "query": {
 "match": {
 "description": "e-mail"
 }
 }
}

Стандартный анализатор разобьёт «e-mail» на токены e и mail (дефис считается разделителем). Поэтому запрос не найдёт документы с оригинальным «e-mail». Решение:

Использовать keyword‑поле: description.keyword и запрос term или match_phrase на этом поле.
Или создать кастомный анализатор, который сохраняет дефис (например, добавить его в список символов, не считающихся разделителями).

Сравнительный обзор при наличии спецсимволов

Таблица сравнения (в виде списка)

Синтаксис и гибкость
- query_string: высокая гибкость, поддержка сложных булевых выражений, фразового поиска, подстановочных знаков.
- match: простой синтаксис, подходит для обычного полнотекстового поиска.
Обработка спецсимволов
- query_string: спецсимволы имеют смысл в синтаксисе Lucene → обязательное экранирование; иначе – ошибка парсинга или неверная интерпретация.
- match: спецсимволы передаются анализатору; поведение зависит от выбранного анализатора (по умолчанию многие символы удаляются).
Производительность
- query_string: чуть более тяжёлый из‑за парсинга сложного синтаксиса; при неправильном экранировании может привести к дорогостоящим перепроверкам.
- match: обычно быстрее, так как запрос проходит через стандартный путь анализа и оценки.
Удобство использования
- query_string: требует знания Lucene‑синтаксиса и внимательного экранирования пользовательского ввода.
- match: проще для конечных пользователей и интеграции в формы поиска без дополнительной обработки.
Когда использовать
- query_string: когда нужен сложный поиск с логическими операторами, фразами, подстановочными знаками, boost‑ами и т.п., и вы можете контролировать ввод (например, админский интерфейс или доверенный API).
- match: для обычного поиска по тексту, где пользователь вводит свободную фразу и ожидает, что спецсимволы будут обработаны согласно языковым правилам (например, поиск по статьям, описаниям товаров).

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

Всегда экранируйте пользовательский ввод перед передачей в query_string. Можно воспользоваться готовыми библиотеками (например, Elasticsearch DSL для Python имеет метод escape).
Если требуется искать буквальное вхождение спецсимволов (точки, дефисы, плюсы и т.д.), рассмотрите использование keyword-полей или match_phrase с анализируемым полем, которое сохраняет эти символы (например, анализатор whitespace или кастомный pattern-анализатор).
Для полей, где важны только буквенно‑цифровые токены (стандартный анализ), match обычно достаточно и безопаснее с точки зрения инъекций.
Тестируйте запросы на реальном наборе данных с помощью _analyze API, чтобы увидеть, как анализатор преобразует ваш текст.
При построении сложных поисковых интерфейсов комбинируйте оба типа: используйте match для основного свободного ввода и query_string для дополнительных фильтров (например, поиск по тегам, датам, числовым полям).

Выбор между query_string и match в Elasticsearch зависит от задачи и уровня контроля над пользовательским вводом. query_string предлагает максимальную выразительность, но требует тщательного экранирования спецсимволов и знания Lucene‑синтаксиса. match проще и безопаснее для обычного полнотекстового поиска, однако его поведение со спецсимволами полностью определяется выбранным анализатором. Понимание этих различий позволяет построить эффективный и надёжный поиск, минимизируя риски ошибок и непредвиденного поведения при работе со специальными символами.