Приходилось ли работать с полнотекстовым поиском

Что проверяют

Различаете ли вы библиотеку и поисковый сервис и понимаете ли, как индекс уживается с базой. Ответ «взял Lucene» в Java звучит часто, и следом спрашивают, кто у вас владел писателем индекса и как проходила полная переиндексация.

Как отвечать

Разложите варианты по слоям:

• Lucene это библиотека внутри процесса, писать в каталог индекса может только один владелец;
• Elasticsearch, OpenSearch и Solr это серверы поверх Lucene: кластер, репликация, сетевое API;
• если сущности уже в JPA, связку удобно строить через Hibernate Search или Spring Data Elasticsearch, но описание полей всё равно делается руками;
• при небольшом объёме и живом PostgreSQL разумно начать с tsvector, а движок поднимать, когда понадобятся фасеты и подсказки.

Дальше понятия: анализатор и морфология под язык, инвертированный индекс, BM25, разница между анализируемым текстовым полем и полем для точного совпадения и сортировки. Про эксплуатацию скажите сами: индексация пачками, документ становится доступен поиску не мгновенно, а после обновления сегмента, полная переиндексация делается в новый индекс с переключением псевдонима, чтобы пользователи не увидели пустую выдачу.

Где спотыкаются

Держат Lucene как общее хранилище: несколько экземпляров приложения пишут в один каталог на сетевой шаре. Индекс либо заблокирован чужим писателем, либо портится, а горизонтальное масштабирование становится невозможным.

Второе: ждут, что только что сохранённая сущность сразу найдётся. Поиск работает почти в реальном времени, но не мгновенно, тест «сохранил и ищу» падает через раз, и в код добавляют принудительное обновление индекса на каждую запись, теряя пропускную способность.

Третье: собирают запрос склейкой пользовательского ввода со строкой синтаксиса. Спецсимволы ломают разбор запроса, а в худшем случае пользователь дотягивается до полей, которых видеть не должен.