Почему полнотекстовый поиск не делают запросом LIKE '%слово%'?
- Почему LIKE плох для поиска?
LIKE '%слово%' не использует обычный индекс (ведущий шаблон) — читает всю таблицу, и качество поиска примитивное: нет морфологии, опечаток, ранжирования.
- В PostgreSQL: полнотекстовый поиск (tsvector, GIN) или pg_trgm для подстрок
- Для серьёзного поиска — Elasticsearch / OpenSearch
LIKE 'слово%'(префикс) может использовать B-дерево
А ещё «кошками» не найдёт «кошка» без морфологии
Подробно
Проблем две, и обе существенные. Производительность: стоимость растёт линейно с объёмом текста, потому что база вынуждена просмотреть каждую строку. Качество: пользователь ищет «купить телефон», а в тексте «телефоны купили» — точного вхождения нет, и поиск ничего не найдёт; ранжирования результатов тоже не будет. Поисковые системы решают обе задачи, заранее разбирая текст на термины и строя по ним индекс.
Что хотят услышать
- Почему индекс не работает.
- Недостатки качества поиска.
- Альтернативы.
Частые ошибки
- Оставлять поиск на LIKE до момента, когда объём данных вырастет.
- Ожидать от такого поиска релевантной сортировки результатов.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✗LIKE запрещён стандартом SQL для текстовых полей
- ✓Он просматривает все строки и не учитывает словоформы, опечатки и релевантность
- ✗Оператор LIKE не работает с кириллицей и колонками типа TEXT
- ✗LIKE нельзя использовать вместе с ORDER BY
Что спросят дальше
- Как устроен инвертированный индекс?
- Что происходит с текстом на этапе анализа?
Разбор темы
- Полнотекстовый поиск (Elasticsearch)
Почему LIKE не поиск, инвертированный индекс, анализаторы, релевантность BM25, query vs filter context и поиск как read model.
Связанные вопросы
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.