Приходилось ли работать с полнотекстовым поиском
Что проверяют
Понимаете ли вы, чем полнотекстовый поиск отличается от фильтра по подстроке, и умеете ли выбирать решение по размеру задачи. Ждут разговора про анализатор, инвертированный индекс и ранжирование, а не про название модного движка.
Как отвечать
Сначала уточните вводные: сколько документов, какие языки, нужны ли устойчивость к опечаткам, подсветка, фасеты, насколько свежим должен быть индекс. От этого зависит выбор:
- данные уже в SQL Server: встроенный полнотекстовый поиск с каталогом и предикатами
CONTAINSиFREETEXTзакрывает умеренные объёмы без второго хранилища; - PostgreSQL:
tsvectorиtsqueryс индексом GIN и словарём под нужный язык; - нужны ранжирование, фасеты, подсказки, синонимы, опечатки: внешний движок вроде Elasticsearch или OpenSearch, из .NET через официальный клиент под вашу версию кластера; для индекса внутри процесса есть Lucene.NET.
Дальше покажите понятия, ради которых вопрос и задают: анализатор (токенизация, приведение регистра, стоп-слова, стемминг), BM25 как функция ранжирования, разница между анализируемым полем и полем для точного совпадения, нечёткий поиск, n-граммы для подсказок. Про обновление скажите отдельно: индекс всегда отстаёт от базы, и синхронизируют его через очередь или таблицу исходящих сообщений, а не записью в два места подряд.
Где спотыкаются
Называют полнотекстовым поиском запрос с LIKE и шаблоном по обоим краям строки. Индекс так не используется, морфологии нет, и на сотнях тысяч строк это полный скан таблицы на каждый ввод символа.
Второе: пишут в базу и в индекс в одном обработчике без общей гарантии. Сбой между двумя записями расходится навсегда, и это всплывает не сразу, а когда пользователь жалуется на пропавший из поиска документ.
Третье: не настраивают анализатор под язык данных. По запросу «стулья» не находится «стул», а точное совпадение по анализируемому полю молча возвращает пустую выдачу, и её потом чинят добавлением нечёткого поиска.