Добавление многозначности к приложению с помощью Hibernate Search

мы используем Hibernate Search в нашем приложении. Используем огранку. Недавно мы обнаружили большое ограничение. Границы полей, которые могут иметь несколько значений, не работают должным образом с Hibernate Search — если в документе есть несколько значений для фасетного поля (например, несколько категорий), учитывается только одно из значений.

В настоящее время я могу думать о паре двух решений:

  • используйте bobo-browse (http://code.google.com/p/bobo-browse/)
  • Солр (http://lucene.apache.org/solr/)

В обоих решениях мы продолжаем поддерживать индекс с помощью Hiberante Search и делать запросы, как и раньше (используя Hiberante Search), и запускать дополнительный запрос bobo-browse или solr для фасетирования, где это необходимо (bobo-browse или solr будут использовать индекс в натуральном выражении). "только для чтения"). Проблема в том, что мы довольно часто обновляем индекс, а в фасетных запросах хотелось бы получать действительно свежие данные. Bobo-browse не интегрируется автоматически с поиском Hiberante, и чтобы поддерживать поиск в актуальном состоянии, у меня могут возникнуть некоторые проблемы (например, https://groups.google.com/forum/?fromgroups=#).!topic/bobo-browse/sn_Efc-YClU). Документация выглядит немного неопрятной и еще не завершенной. Solr, с другой стороны, кажется действительно важной вещью, которую нужно добавить, просто чтобы правильно работать с огранкой. И я все еще боюсь, что у меня могут возникнуть проблемы с обновлением/обновлением индекса.

Есть ли у вас опыт в этом вопросе? Какие-либо предложения?


java lucene hibernate-search
person Potejciak    schedule 01.10.2012    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Как разработчик Hibernate Search, я предлагаю присоединиться к нам и помочь реализовать то, что вам нужно.

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

Hibernate Search уже зависит от многих модулей Solr, особенно из-за большой коллекции отличных анализаторов. Я уверен, что мы могли бы найти способ внедрить логику фасетирования Solr и красиво упаковать ее в наш согласованный API без необходимости запускать Solr в режиме сервера.

Я думаю, мы могли бы сделать то же самое с Bobo-browse; Я бы предпочел, чтобы Solr не добавлял другие зависимости, но если bobo-browse подтверждает превосходное решение, почему бы и нет... но вы можете помочь нам в этом выборе.

Что бы вы получили взамен?

  • мы сохраним его: совместимость останется со всеми будущими версиями. надеюсь, вы немного поможете.
  • вечная благодарность от других пользователей ;)
  • надежное тестирование от тысяч других пользователей
  • исправления и улучшения из ..
  • значок рок-звезды в резюме

Что требуется?

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

https://community.jboss.org/wiki/ContributingToHibernateSearch

person Sanne    schedule 03.10.2012

arrow_upward
0
arrow_downward

Я также использую Bobo Browse в сочетании с Hibernate Search. У меня также есть проблема с регулярными обновлениями и проблемой только для чтения. Bobo — не самая простая библиотека, и я несколько раз рассматривал способы интеграции с Hibernate Search и просто сдался из-за сложности.

Я использую синхронизированную перезагрузку индекса, чтобы обеспечить его свежесть, но это создает много мусора, который необходимо собрать. Lucene со временем оптимизировала процесс повторного открытия программ чтения индексов, но команда Bobo на самом деле не сосредоточена на поддержке этого. https://linkedin.jira.com/browse/BOBO-31 описывает эту проблему.

Инфраструктура Hibernate Search должна обеспечивать достаточную гибкость для интеграции. Zoie — это система индексации в реальном времени, похожая на Hibernate Search, интегрированная с Bobo https://linkedin.jira.com/wiki/display/BOBO/Realtime+Faceting+with+Zoie Возможно, это вдохновит вас

person Marc    schedule 15.02.2013

arrow_upward
0
arrow_downward

Это что-то вроде решения проблемы многозначного подсчета аспектов для hibernate-search.

Блог: http://outbottle.com/hibernate-search-multivalue-facet-counts/

Блог дополнен классом Java, который можно повторно использовать для создания счетчиков фасетов для полей с одним и несколькими значениями.

Предоставленное решение основано на решении BitSet, представленном здесь: http://sujitpal.blogspot.ie/2007/04/lucene-search-within-search-with.html

В блоге есть проект Maven, который довольно подробно демонстрирует решение. Проект демонстрирует использование API фасетирования hibernate-search для фильтрации....

диапазон дат И группа аспектов «один ко многим» (одно значение) И группа аспектов «многие ко многим» (многозначная) вместе взятые.

Затем вызывается решение для правильного получения количества фасетов для каждой группы фасетов.

Решение обеспечивает получение результатов, аналогичных этой эмуляции jsFiddle: http://goo.gl/y5C9UO (за исключением того, что эмуляция не не демонстрация огранки диапазона).

jsFiddle является частью более крупного блога, в котором исследуется концепция фасетного поиска в целом: http://outbottle.com/understanding-faceted-searching/. Если вы похожи на меня и находите само понятие фасетного поиска довольно запутанным, тогда это поможет.

Возможно, это не лучшее решение в мире, поэтому не стесняйтесь оставлять отзывы.

person John    schedule 20.11.2013