Teracotta 和 Hibernate 搜索

Question

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

如果是这样：

1. 可以处理的“对象更新”的幅度是多少？（怎么样 性能）

2. 查询有什么样的性能？

3. 是否可以使用兵马俑 休眠搜索甚至没有 一个后备数据库，满足所有需求 内存中的“查询”？

Answer 1

我是 Terracotta 的 CTO。上个月我花了一些时间研究 Hibernate Search。它不是以 Terracotta 透明集群的方式构建的。简而言之，原因如下：Hibernate 有一个跨 JVM 定制的 Lucene 索引 JMS 复制。

Search 的基本思想是，在 lucene 下与本地磁盘通信效果非常好，而通过网络对 Lucene 索引进行碎片或分区会引入太多的延迟，从而使 Lucene 看起来很糟糕，而这根本不是 Lucene 的错。为此，HIbernate Search 不依赖于 JBossCache 或 任何 内存分区/缓存方案，而是依赖 JMS 和每个 JVM 的本地磁盘，以便在同时保持低延迟的情况下跨集群提供最新索引。然后，Hibernate 搜索的美妙之处在于，可以通过 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 服务器即可进行扩展。

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

3. 我认为，一旦我们让 JBoss 分解出他们的 JMS 假设等，就会发生这种情况。

干杯，

——阿里

Answer 2

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

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

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

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