Слияние результатов поиска Hibernate с запросом реляционной базы данных

Question

У меня сложный запрос, требующий полнотекстового поиска по некоторым полям и основные ограничения по другим полям. Документация Hibernate Search настоятельно рекомендует не добавлять ограничения запросов к базе данных в запрос полнотекстового поиска и вместо этого рекомендует поместить все необходимые поля в полнотекстовый индекс. Проблема, с которой я столкнулся, заключается в том, что другие поля являются изменчивыми; значения могут меняться каждую минуту или около того, и эти обновления в базе данных могут происходить вне JVM, выполняющей поиск, поэтому существует высокая вероятность того, что локальный индекс Lucene будет устаревшим по отношению к этим полям.

Здесь вы найдете рекомендации по стратегии. Лучшее, что я нашел до сих пор, - это объединить результаты вручную, сначала выполнив запрос к базе данных (выбирая только идентификаторы объектов), а затем выполнив полнотекстовый поиск. и каким-то образом эффективно фильтровать результаты Lucene по набору идентификаторов объектов из базы данных. Конечно, я не знаю, сколько результатов я получу от каждого отдельного запроса, поэтому я беспокоюсь о производительности и памяти. В худшем случае это могут быть десятки тысяч строк.

Answer 1

У меня та же проблема, и я делаю отдельный запрос Lucene и критериев. Если я сначала выполню запрос критериев, я буду использовать полученные идентификаторы, чтобы применить пользовательский IdFilter для поиска Lucene, который проверяет, есть ли результат в данной коллекции идентификаторов из первого запроса. Однако этот подход плохо масштабируется, потому что и в моем случае число результатов после первого запроса может быть огромным, а фильтр ограничен 1024 идентификаторами. Я не нашел хорошего решения, но я меняю порядок моих двух запросов в зависимости от количества ожидаемых результатов. Первый запрос должен быть тем, который отфильтровывает большинство результатов.

Answer 2

Можно выполнить обновление индекса индекса планировщика на дату последнего изменения.

Answer 3

Меня очень интересуют другие идеи для этого, поскольку у нас очень похожий сценарий.

Нам нужно было показать максимум 50 строк результатов с парой поисков в строке. Мы выполняем запрос к индексу lucene с идентификаторами db pk в индексе и извлекаем запросы из базы данных на каждую строку. Это по-прежнему актуально для нас.

Поскольку вы, кажется, хотите обработать больше, чем несколько строк и поисков, я рассмотрел альтернативу. Отметка времени любого обновления строки в БД. Это позволило бы нам запрашивать в БД устаревшие индексы, а затем итеративно вызывать реиндекс связанных документов.