intermediate
Full-text search
Обрабатывайте tokenization, stemming, ranking, typo tolerance, highlighting и filters beyond simple SQL LIKE matching.
Полнотекстовый поиск выходит за рамки `LIKE` и точных совпадений: текст проходит анализ в токены, при необходимости стемминг или нормализацию, попадает в инвертированную структуру и ранжируется по сигналам релевантности (TF-IDF, BM25) плюс бизнес-boost и фильтры.
Модель конвейера:
исходный текст → анализатор → токены → инвертированный индекс → запрос → score + подсветка
Продукту часто нужны: префиксный и нечёткий поиск, синонимы, языковой стемминг, фасетные фильтры (бренд, цена), подсветка совпадений и стабильная пагинация при параллельных записях.
`tsvector` в PostgreSQL хватает для умеренных корпусов; отдельный search-кластер даёт анализаторы, распределённое масштабирование и тонкую настройку релевантности.
На интервью: разберите анализ при индексации и при запросе, объясните, почему тот же запрос ведёт себя иначе, чем SQL-подстрока, и как фильтры сочетаются со scoring.
Типовые ошибки: индексировать одним анализатором, а искать другим; «поиск» только через lower case; нет синонимов и опечаток при ожидании Google-like UX; ранжирование только по дате; публичный query DSL с внутренними полями.
Компромисс — качество релевантности и UX против сложности индексации, поддержки языков и оценки поиска на реальных запросах, а не только unit-тестами.
Чеклист:
- Нарисуйте конвейер анализатора (tokenizer, filters).
- Сравните анализ при индексации и при запросе.
- Назовите входы ранжирования: BM25, boost, фильтры.
- Скажите, когда хватит Postgres FTS, а когда нужен кластер.
- Упомяните метрики: CTR, доля нулевых результатов.