Hibernate Search 集群和近实时搜索答案

【问题标题】：Hibernate Search cluster and near-real-time searchHibernate Search 集群和近实时搜索
【发布时间】：2016-06-05 10:24:07
【问题描述】：

我正在尝试找到在我的集群网络应用中实现搜索引擎的最佳索引解决方案，但我无法在官方文档中找到我的问题的明确答案。

我的 Java/Java EE 后端将部署在几个负载平衡的实例中。搜索引擎将需要近乎实时的索引数据可用性（即索引和可检索之间的时间少于 5 秒）。

Hibernate Search 可以使用 JGroups 在集群环境中工作，但文档还说，as a tradeoff it requires a non-clustered and non-shared index 几乎是实时的。

这是否意味着 NRTIndexManager 不能在 JGroups 从/主设置中使用？即只能在一个节点上使用？
这是否意味着通过这样的设置，索引数据的可用性仅取决于刷新周期（索引复制到从节点的周期）？

【问题讨论】：

标签： java lucene search-engine hibernate-search

【解决方案1】：

使用标准 IndexManager，您只能在将最新更改写入磁盘并重新打开 IndexSearcher 时才能看到它们。

默认情况下，Hibernate Search 会写入磁盘并为每个查询打开一个新的 IndexSearcher，这样您就可以确保您的搜索始终与您的数据库同步。

NRTIndexManager 与标准的不同，因为它允许您搜索索引的最新更改，而无需在磁盘上显式写入。当您需要高吞吐量并且无法立即将所有内容写入磁盘时，通常会使用它。因此，这与您是否会立即看到更改并没有真正的关联：这是一种优化，您可以允许丢失一些索引数据 - 最新的更改可能会丢失。

正如http://docs.jboss.org/hibernate/search/5.5/reference/en-US/html_single/#jgroups-backend 的文档中所述，您可以让同步 JGroups 与 Hibernate Search 阻塞，直到所有索引都同步。所以它适用于您的情况。

请注意，我们目前正在为 Elasticsearch 后端开发 5.6，您可能会对它感兴趣，因为它通常是为您的情况而设计的。它仍处于测试阶段，但它已经处于相当不错的状态。你可能想看看它：http://docs.jboss.org/hibernate/search/5.6/reference/en-US/html/ch11.html。

【讨论】：

感谢您的回答，但我可能遗漏了一点。据我了解，在集群环境中使用 JGroups（或 JMS）可以将您的索引复制到多个节点上。所有索引更新都委托给主节点，然后每隔 X 秒将主索引复制到从节点。由于搜索请求是在本地索引上处理的，因此可检索数据的新鲜度取决于配置的时间段。我知道 NRTIndexManager 并不是为了满足我的需求，但是有没有办法在几秒钟内对复制到从节点索引的主索引进行更改？
这在很大程度上取决于索引的大小。如果您的索引的大小是随之而来的，并且您不能每隔 X 秒将它复制到从属服务器，那么它对您来说将无法正常工作。我的建议：尝试使用 Hibernate Search 5.6.0.Beta1 的 Elasticsearch 后端，如果您的索引很大，最好在约束条件下启动并运行一些东西。我们真的很想得到更多关于它的反馈！
好吧，我可能会试一试。对纯 ElasticSearch 使用它有什么好处？除了不必手动编写索引创建/更新例程。顺便说一句，我的索引文件会非常小（顶部 20Mb），但与 ElasticSearch 在节点之间拆分数据的方式相比，每 X 秒复制一次完整索引似乎有点过头了。
您可以获得 Hibernate Search 的所有优点：您可以操作托管实体，您不必手动管理您的索引，模式是从您的注释中自动生成的，您可以获得 FieldBridge 的魔力等等.就好像你问我，与直接使用 Lucene 相比，Hibernate Search 给你带来了什么；）。