兵马俑和Hibernate搜索

Question

有没有人有使用Terracotta和Hibernate Search来满足应用程序查询的经验？

如果是这样的话：

1. “对象的大小” 更新“它能处理吗？（怎么样？ 表现）

2. 这是什么表现 查询有？

3. 是否可以使用兵马俑     Hibernate Search甚至没有     支持所有人的后备数据库     记忆中的“查询”？

Answer 1

我是Terracotta的首席技术官。我上个月花了一些时间看Hibernate Search。它不是以Terracotta透明地聚集的方式构建的。这就是为什么简而言之：Hibernate在JVM上有一个定制的Lucene索引JMS复制。

Search中的基本思想是在lucene下与本地磁盘进行通信非常有效，而在整个网络中对Lucene索引进行分段或分区会引入太多的延迟，以至于当Lucene根本不是Lucene的错误时，它会显得很糟糕。为此，HIbernate Search不依赖于JBossCache或任何内存中分区/缓存方案，而是依赖于JMS和每个JVM的本地磁盘，以便提供跨越的最新索引。同时具有低延迟的集群。然后，Hibernate Search的优点在于标准的Hibernate查询，并且可以通过Hibernate在每台机器的这些自然语言索引中启动更多。

在Terracotta，事实证明我们对Emmanuel有类似的想法，并在Compass之上构建了一个SearchableMap产品。每台计算机都有自己的Compass存储，并且存储配置为在本地溢出到磁盘。 Terracotta用于创建多主机写入功能，任何JVM都可以添加到索引中，并通过Terracotta发送增量，以便在本地重播/重新应用到每个磁盘。它就像Hibernate Search一样工作，但DSO作为网络协议代替JMS，没有漂亮的Hibernate接口，而是使用Compass接口。

我认为我们将在今年年底之前支持来自JBoss的帮助Hibernate Search（他们需要将JMS impl分解为可插拔）。

现在直接提问：

1. Hibernate或SearchableMap中的对象更新/秒应该非常高，因为两者都只发送增量。在Hibernate的情况下，它是我们的JMS提供者的功能。在Terracotta中，只需在阵列中添加更多Terracotta服务器即可扩展。

1. 两者的查询性能都非常快。大多数情况下本地内存性能。如果您需要从磁盘进行登录，事实证明大多数操作系统都做得很好，并且可以比任何基于网络的群集更快地响应查询。

2. 我认为，一旦我们让JBoss分解出他们的JMS假设等，

干杯，

- 阿里

Answer 2

由于Hibernate论坛上的人们不断提到这篇文章，我觉得有必要指出，虽然Ari的评论在2009年初是正确的，但我们一直在不断发展和改进。

Hibernate Search提供了一组开箱即用的后端通道，就像已经提到的基于JMS和使用JGroups的最新添加一样，但我们也很容易插入替代实现或覆盖一些。

除了使用自定义后端之外，现在可以从版本4开始替换整个策略而不是更改后端实现，只需使用遵循不同设计的IndexManager并且根本不使用后端;目前我们只有两名IndexManagers，但我们正在研究更多的替代品;再一次，我们的想法是为最常见的

提供很好的实现

它确实有一个基于Infinispan的后端，可以在不同的节点上快速分发索引，并且可以直接根据Terracotta或任何其他群集技术提供一个。更多解决方案即将到来。