Зачем использовать Elasticsearch или Apache Solr вместе с Hibernate Search?

Я узнал и понял, что Elasticsearch, Apache Solr и Hibernate Search основаны на библиотеке Apache Lucene. Они обеспечивают быстрый полнотекстовый поиск, и все они либо используют аннотации JPA, реализуют JPA и/или определяют пользовательские аннотации. Они в основном используются в дополнение к хранилищу данных RDBMS/NoSQL. Индексированные и доступные для поиска данные представлены в виде документов.

Я полностью согласен с тем, что кто-то задает вопрос Solr vs Hibernate Search - что выбрать и когда? или даже "Elasticsearch vs Solr" или "Elasticsearch vs Hibernate Search" ' Но тогда есть Hibernate Search/Elasticsearch connector в качестве подхода к использованию Hibernate Search и Elasticsearch рядом или этот пост, просящий "Как интегрировать Hibernate и Solr вместе?" с ответом, как интегрировать Hibernate Search и Solr вместе, что для меня что-то другое, не так ли?

Предполагая, что приведенное выше резюме верное и учитывая, что связанные сообщения путают меня: почему люди считают или используют Elasticsearch или Solr в дополнение к Hibernate Search? Разве это не избыточно? Или Hibernate Search предоставляет любой интерфейс для Solr/Elasticsearch, который Hibernate ORM не имеет и поэтому используется только как какой-то адаптер?

Ответ 1

Я не реализовал elasticsearch, но я рассматриваю его как back-end для поиска в спящем режиме.

Одна проблема, с которой я столкнулся с Hibernate-поиском, заключается в том, что я запускаю кластер из 8 серверов JBoss в автономном режиме, по умолчанию все они имеют отдельный индекс в своей локальной файловой системе. Когда изменение производится с помощью спящего режима, оно только обновляет индекс на этом единственном node. Трудно постоянно обновлять все индексы.

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

Ответ 2

Из моего прежнего опыта я перешел из поиска спящего режима в elasticsearch, не сохранив ничего из поиска Hibernate (я имею в виду аннотации).

Я думаю, что так легко сериализовать bean для JSon с Jackson, что вам не нужны сложные вещи. Однажды у вас есть документ Json, просто отправьте его в elasticsearch, и все готово.

Тем не менее, я сохранил старый поиск SQL в том случае, если мне нужно было выполнить некоторые операции по обслуживанию кластера elasticsearch. Но если вы встраиваете elasticsearch в свой webapp (скажем, у вас не так много данных для управления), тогда вам не нужно об этом думать.

Мои 2 цента

Ответ 3

Использовать возможности поиска в режиме Hibernate Search rdbms/index. Это означает, что ваши поисковые индексы всегда синхронизируются с реляционной базой данных/источником. Хотя в то же время вы все еще можете использовать некоторые из расширенных функций, которые вы получаете от Solr или Elastic Search (переосмысление автофокусировки с высоким освещением...

Ответ 4

Обратите внимание: предыдущие ответы хороши, но устарели годами.

Hibernate Search теперь имеет большую интеграцию с Elasticsearch, поэтому вы можете использовать преимущества интеграции с Hibernate, как и другие, предлагая при этом пользоваться преимуществами Elasticsearch.

См. search.hibernate.org

Интеграция с Apache Solr также должна быть возможна, но это еще не было реализовано, и команде потребуется помощь.

Надеюсь, что после тяжелой работы по де-мутации и интеграции с Elasticsearch вариант должен сделать проще.