3

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

如果是这样的话：

  1. 它可以处理多大的“对象更新”？（表现如何）

  2. 查询有什么样的表现？

  3. 是否可以使用 Terracotta Hibernate Search 甚至没有后备数据库来满足内存中的所有“查询”？
4

2 回答 2

4

我是 Terracotta 的 CTO。上个月我花了一些时间研究 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 假设等因素考虑在内，就可以了。

干杯，

——阿里

于 2009-05-21T15:15:23.960 回答
2

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

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

除了使用自定义后端之外，从版本 4 开始，现在可以替换整个策略，而不是仅更改后端实现，您可以使用遵循不同设计且根本不使用后端的 IndexManager；目前我们只有两个 IndexManager，但我们正在研究更多替代方案；再次，这个想法是为最常见的提供很好的实现

它确实有一个基于 Infinispan 的后端，用于在不同节点之间非常快速地分配索引，并且应该直接贡献一个基于 Terracotta 或任何其他集群技术的后端。更多解决方案即将推出。

于 2011-10-04T18:33:44.590 回答