Зачем использовать 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 вариант должен сделать проще.
