Поиск по товарам

01Три уровня: LIKE, полнотекстовый поиск, поисковый движок

Первый уровень — запрос к базе данных с LIKE: WHERE name LIKE '%dog food%'. Это просто, но wildcard в начале не может использовать обычный индекс, поэтому таблица сканируется целиком, и такой запрос ничего не знает об опечатках, порядке слов или релевантности. Второй уровень — полнотекстовый поиск в базе данных: индексы FULLTEXT в MySQL или tsvector с GIN-индексами в PostgreSQL. Они разбивают текст на слова, выполняют стемминг («running» находит «run») и ранжируют по релевантности — этого достаточно для блогов и небольших каталогов, без дополнительного сервиса. Расширение pg_trgm в PostgreSQL добавляет нечёткое сопоставление. Третий уровень — специализированный поисковый движок, который строит инвертированный индекс, оптимизированный для мгновенного поиска с устойчивостью к опечаткам, фасетами и настраиваемым ранжированием. Переходите на следующий уровень, только когда предыдущий перестаёт справляться с задачами пользователей.

1-- PostgreSQL full-text search with ranking
2ALTER TABLE products ADD COLUMN search tsvector
3  GENERATED ALWAYS AS (
4    setweight(to_tsvector('english', coalesce(name, '')), 'A') ||
5    setweight(to_tsvector('english', coalesce(description, '')), 'B')
6  ) STORED;
7 
8CREATE INDEX products_search_idx ON products USING GIN (search);
9 
10SELECT id, name, ts_rank(search, query) AS rank
11FROM products, websearch_to_tsquery('english', 'dry dog food') AS query
12WHERE search @@ query
13ORDER BY rank DESC
14LIMIT 20;

02Как работает поисковый движок

Поисковый движок хранит инвертированный индекс: как предметный указатель в конце книги, он сопоставляет каждому слову список документов, в которых оно встречается. Когда вы индексируете товар, движок токенизирует текст (разбивает на слова), нормализует его (нижний регистр, удаление диакритики) и может применять стемминг или языковые правила. Во время запроса он ищет каждое слово, допускает небольшое число опечаток — обычно одну для коротких слов и две для длинных, по расстоянию редактирования, — сопоставляет префиксы, чтобы результаты появлялись во время ввода, и ранжирует результаты. Ранжирование обычно сочетает текстовую релевантность (сколько слов совпало, насколько близко, в каком поле) с бизнес-сигналами, которые вы настраиваете, например популярностью, наличием или маржой. Фасеты — это количества по каждому значению фильтра («Бренд: 12, Размер: 5»), которые вычисляются вместе с результатами.

03Выбор движка

Algolia — хостинговый сервис с отличной скоростью, устойчивостью к опечаткам, инструментами мерчандайзинга и аналитикой; вы платите за поисковые запросы и записи, и это может стать дорого. Meilisearch и Typesense — open-source движки, которые можно развернуть у себя на небольшом сервере или использовать как облачные сервисы; оба быстрые, устойчивы к опечаткам и просты в настройке — идеально для большинства магазинов. Elasticsearch и OpenSearch — мощные универсальные движки для огромных каталогов, сложных запросов, агрегаций и логов, но им нужно больше памяти и опыта эксплуатации. В Laravel Scout даёт единый API поверх Algolia, Meilisearch, Typesense и драйвера базы данных, поэтому можно начать с простого и сменить движок позже.

• Небольшой каталог, нет бюджета на ещё один сервис: полнотекстовый поиск в базе данных.
• Большинство магазинов: Meilisearch или Typesense, у себя или в облаке.
• Мерчандайзинг и аналитика без эксплуатации: Algolia.
• Огромные данные, сложные агрегации или уже существующий кластер: Elasticsearch / OpenSearch.

04Проектирование индекса

Поисковый индекс — это не копия базы данных, а плоский документ, спроектированный под один экран. Для магазина решите, что считается результатом: обычно это товар, в который влиты атрибуты его вариантов (все цвета и размеры), чтобы работали фильтры, и минимальная доступная цена для сортировки. Включайте только то, что нужно поиску: название, бренд, путь категорий, атрибуты, ключевые слова, цену, флаг наличия, популярность и URL изображения. Объявите, какие поля участвуют в поиске (в порядке приоритета), по каким можно фильтровать (фасеты) и по каким сортировать. Используйте синонимы для слов, которые покупатели употребляют по-разному («котёнок» и «кошка», «лак для ногтей» и «лак»), и стоп-слова для шума. Отдельные индексы для категорий, брендов и статей позволяют сделать богатый выпадающий список подсказок.

1// Laravel Scout: what goes into the search document
2class Product extends Model
3{
4    use \Laravel\Scout\Searchable;
5    public function toSearchableArray(): array
6    {
7        return [
8            'id'         => $this->id,
9            'name'       => $this->name,
10            'brand'      => $this->brand?->name,
11            'categories' => $this->categories->pluck('name')->all(),
12            'colours'    => $this->variants->pluck('colour')->filter()->unique()->values()->all(),
13            'price_min'  => $this->variants->min('price'),       // integer minor units
14            'in_stock'   => $this->variants->contains(fn ($v) => $v->available > 0),
15            'popularity' => $this->sales_last_30_days,
16        ];
17    }
18 
19    public function shouldBeSearchable(): bool { return $this->is_active; }
20}

05Синхронизация индекса

Индекс — это вторая копия ваших данных, поэтому он может устаревать. Обновляйте его при изменении данных: Scout делает это автоматически при сохранении и удалении модели, но отправляйте эту работу в очередь, чтобы сохранение товара никогда не ждало поисковый сервис. Остерегайтесь изменений в обход событий модели — массовых SQL-обновлений, импортов из ERP, изменений остатков в другой таблице или переименования бренда, которое затрагивает тысячи товаров, — и явно запускайте переиндексацию затронутых записей. Регулярно запускайте полную переиндексацию по расписанию, в идеале в новый индекс с последующей подменой через алиас, чтобы пользователи никогда не видели наполовину построенный индекс. Остатки и цены меняются часто; подумайте об обновлении только этих полей пакетами, а не целых документов.

• Ставьте обновления индекса в очередь; при массовых импортах объединяйте их в пакеты.
• Пересобирайте в новый индекс и подменяйте атомарно.
• Поднимайте алерт, когда число проиндексированных документов сильно отличается от базы данных.

06Ранжирование, аналитика и советы для продакшена

Хорошее ранжирование настраивают, а не угадывают. Начните с настроек движка по умолчанию, задайте поля поиска по порядку (название раньше описания) и добавьте кастомный сигнал ранжирования, например популярность или продажи. Опускайте товары, которых нет в наличии, ниже, а не скрывайте их, если бизнес не предпочитает иначе. Логируйте поиски: запрос, количество результатов и клики. Список запросов без результатов показывает недостающие синонимы, товары и проблемы с написанием; популярные запросы можно использовать для подсказок. Защищайте поисковый эндпоинт ограничением частоты запросов и никогда не раскрывайте браузеру админские API-ключи — используйте ключи только для поиска, в идеале с ограниченной областью или сроком действия. Делайте debounce для поиска во время ввода на клиенте примерно на 150–300 ms и кэшируйте популярные запросы.

07Как устроена релевантность: BM25 и правила ранжирования

Универсальные движки вроде Elasticsearch и OpenSearch по умолчанию оценивают документы с помощью BM25. Если по-простому, документ получает более высокий балл, когда в нём часто встречаются слова запроса (с убывающей отдачей, поэтому повторить слово двадцать раз почти не помогает), когда эти слова редки во всём индексе («merino» весит больше, чем «the») и когда поле короткое (совпадение в заголовке из пяти слов важнее, чем в длинном описании). Бусты полей умножают этот балл. Движки для мгновенного поиска, такие как Meilisearch, Typesense и Algolia, вместо этого используют упорядоченный список правил ранжирования, или tie-breakers: число совпавших слов, опечатки, близость слов, порядок атрибутов, точность совпадения и затем ваше собственное ранжирование. Понимая, какую модель использует ваш движок, вы знаете, что настраивать: бусты и функции в движках на BM25, порядок правил и кастомные атрибуты — в остальных.

08Переиндексация без простоя с помощью алиасов и swap

Изменение настроек индекса — новые searchable-атрибуты, другой токенизатор, новый язык — часто требует перестроить индекс целиком. Никогда не делайте это на месте, иначе пользователи несколько минут будут видеть наполовину заполненные результаты. Постройте новый индекс рядом с рабочим, заполните его пачками, проверьте количество документов и прогоните несколько smoke-запросов, а затем переключите трафик одним атомарным шагом. В Elasticsearch и OpenSearch это делается алиасами: приложение всегда обращается к алиасу «products», а обновление алиаса переводит его с products_v1 на products_v2. В Typesense есть алиасы коллекций, которые работают так же. Meilisearch предлагает операцию swap индексов, которая атомарно меняет местами содержимое двух индексов. Сохраните старый индекс на короткое время, чтобы мгновенно переключиться обратно, если что-то пойдёт не так.

1# Meilisearch: swap the freshly built index with the live one
2curl -X POST 'http://localhost:7700/swap-indexes' \
3  -H 'Authorization: Bearer MEILI_ADMIN_KEY' \
4  -H 'Content-Type: application/json' \
5  --data '[{ "indexes": ["products", "products_new"] }]'
6 
7# Elasticsearch / OpenSearch: move an alias atomically
8curl -X POST 'http://localhost:9200/_aliases' -H 'Content-Type: application/json' -d '{
9  "actions": [
10    { "remove": { "index": "products_v1", "alias": "products" } },
11    { "add":    { "index": "products_v2", "alias": "products" } }
12  ]
13}'

09Безопасные поисковые ключи и фильтрация по пользователю

Поиск из браузера быстрый, потому что клиент обращается к движку напрямую, но это значит, что ключ виден всем. Используйте ключ только для поиска, никогда не admin-ключ. Когда результаты должны отличаться для разных пользователей — B2B-прайс-листы, закрытые каталоги, данные конкретного тенанта, — не полагайтесь на то, что клиент добавит фильтр, ведь он может его просто убрать. Вместо этого сервер генерирует ограниченный ключ со встроенным фильтром и сроком действия: в Algolia это secured API keys, в Typesense — scoped API keys, а в Meilisearch — tenant tokens, которые представляют собой подписанные JWT. Движок применяет встроенный фильтр к каждому запросу. Кроме того, индексируйте только публичные поля: всё, что есть в индексе, настойчивый пользователь сможет прочитать. Ставьте rate limit по ключу или IP и задавайте короткий срок действия, чтобы утёкшие ключи быстро переставали работать.

1// Meilisearch tenant token: the filter is enforced by the engine
2import { generateTenantToken } from "meilisearch/token";
3 
4export async function searchTokenFor(customer: { priceListId: number }) {
5  return generateTenantToken({
6    apiKey: process.env.MEILI_SEARCH_KEY!,       // a search-only key
7    apiKeyUid: process.env.MEILI_SEARCH_KEY_UID!,
8    searchRules: { products: { filter: `price_list = ${customer.priceListId}` } },
9    expiresAt: new Date(Date.now() + 60 * 60 * 1000), // 1 hour
10  });
11}

10Многоязычный поиск и языковые граничные случаи

Качество поиска зависит от того, как текст разбивается и нормализуется, а это зависит от языка. Английский стемминг превращает «boots» в «boot»; в русском и армянском богатые окончания слов, которым нужна обработка с учётом языка или поиск по префиксу; китайскому и японскому нужна сегментация, потому что слова там не разделяются пробелами. Встречается и смешение алфавитов: покупатели вводят названия брендов латиницей или транслитерируют местные слова. Практичный подход: храните каждый язык в отдельном поле или индексе, явно задавайте в движке настройки языка или локали, а не полагайтесь на автоопределение, добавьте синонимы между вариантами транслитерации («krem» и «крем») и нормализуйте диакритику. Тестируйте на реальных запросах из логов на каждом языке, потому что конфигурация, хорошо работающая на английском, может незаметно проваливаться на другом языке.

• Одно поле для поиска на каждый язык, например name_en и name_ru.
• Сначала запрашивайте индекс на языке интерфейса пользователя.
• SKU и штрихкоды — поля точного совпадения с отключённой толерантностью к опечаткам.