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

Question

Я работаю в приложении Hibernate-search, в настоящее время я индексирую базу данных postgres, и после того, как я создал несколько запросов Lucene, и пока все работает нормально.

У меня есть некоторые опасения по поводу того,можно использовать Hibernate-поиск с несколькими экземплярами (где все экземпляры имеют одинаковую структуру БД). Это потому, что я хочу разделить информацию на несколько экземпляров (не только локальных) и не хранить все данные в одном.

1. Каков наилучший подход для этого?
2. Могу ли я использовать Hibernate-search для этого?

Я бы подумал, что есть способ иметь несколько экземпляров в одном и том же индексе Lucene, поэтому я мог бы запросить этот индекс, чтобы получить и получить информацию безнезависимо от того, откуда поступают данные. Но я думаю, что процесс индексации должен быть другим, как обычно.

Answer 1

В настоящее время лучшим подходом будет использование Hibernate Search 6 и его интеграция с Elasticsearch. Идея состоит в том, что вместо локальной индексации Hibernate Search делегирует кластер узлов Elasticsearch (который может быть только одним узлом, если вы этого хотите). Кластеризация будет полностью прозрачной для вашего приложения.

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

Если вы хотите остаться в Search 5 или если вы хотите избежать Elasticsearch дляпо какой-то причине, тогда единственная оставшаяся опция - это использовать кластеризованные бэкэнды Search 5, опираясь на JMS или JGroups. Однако эти архитектуры сложно настроить, поэтому мы отказались от них в Search 6 (по крайней мере, на данный момент) и сосредоточились на интеграции Elasticsearch. См. здесь для JMS и здесь для JGroups .