Teracotta和Hibernate搜索 [英] Teracotta and Hibernate Search
问题描述
有没有人有使用Terracotta和Hibernate Search来满足应用程序查询的经验？
Does anyone have experience with using Terracotta with Hibernate Search to satisfy application Queries?
如果是这样的话：
-
它可以处理多大幅度的对象
更新？ （
表现怎么样）
What magnitude of "object updates" can it handle? (How's the performance)
查询有什么样的表现？
What kind of performance do the Queries have?
推荐答案
我是Terracotta的首席技术官。上个月我花了一些时间看看Hibernate Search。它不是以Terracotta透明地聚集的方式构建的。简而言之，这就是原因：Hibernate在JVM上有一个定制的Lucene索引JMS复制。
I am Terracotta's CTO. I spent some time last month looking at Hibernate Search. It is not built in a way to be clustered transparently by Terracotta. Here's why in a nutshell: Hibernate has a custom-built JMS replication of Lucene indexes across JVMs.
搜索中的基本思想是在lucene下与本地磁盘通信真的很有效好吧，虽然在整个网络中对Lucene索引进行分段或分区会引入太多的延迟，以至于当Lucene根本不是Lucene的错误时，它会显得很糟糕。为此，HIbernate Search不依赖于JBossCache或任何内存中分区/缓存方案，而是依赖于JMS和每个JVM的本地磁盘，以便提供跨越的最新索引。同时低延迟的集群。然后，Hibernate Search的优点在于标准的Hibernate查询，并且可以通过Hibernate在每台机器上的这些自然语言索引中启动更多。
The basic idea in Search is that talking to local disk under lucene works really well, whereas fragmenting or partitioning up Lucene indexes across the network introduces sooo much latency as to make Lucene seem bad when it is not Lucene's fault at all. To that end, HIbernate Search doesn't rely on JBossCache or any in-memory partitioning / caching schemes and instead relies on JMS and each JVM's local disk in order to provide up-to-date indexing across a cluster with simultaneous low latency. Then, the beauty of Hibernate Search is that standard Hibernate queries and more can be launch through Hibernate at these natural language indexes in each machine.
在Terracotta，它发现我们有与Emmanuel类似的想法，并在Compass之上构建了一个SearchableMap产品。每台计算机都有自己的Compass存储，并且存储配置为在本地溢出到磁盘。 Terracotta用于创建多主机写入功能，其中任何JVM都可以添加到索引中，并且delta通过Terracotta发送，以便在本地重播/重新应用到每个磁盘。它就像Hibernate Search一样工作，但DSO作为网络协议代替JMS，没有漂亮的Hibernate接口，而是使用Compass接口。
At Terracotta it turns out we had a similar idea to Emmanuel and built a SearchableMap product on top of Compass. Each machine gets its own Compass store and the store is configured to spill to disk locally. Terracotta is used to create a multi-master writing capability where any JVM can add to the index and the delta is sent through Terracotta to be replayed / reapplied locally to each disk. It works just like Hibernate Search but with DSO as the networking protocol in place of JMS and w/o the nice Hibernate interfaces but instead with Compass interfaces.
我想我们会支持Hibernate Search w / joss的帮助（他们需要将JMS impl分解为可插拔的）到年底。
I think we will support Hibernate Search w/ help from JBoss (they would need to factor out the JMS impl as pluggable) by end of the year.
现在直接提问：
1. Hibernate或SearchableMap中的对象更新/秒应该非常高，因为两者都只发送增量。在Hibernate的情况下，它是我们的JMS提供者的功能。在Terracotta中，只需向阵列添加更多Terracotta服务器即可扩展。
1.Object updates/sec in Hibernate or SearchableMap should be quite high because both are sending only deltas. In Hibernate's case it is a function of our JMS provider. In Terracotta it is scalable just by adding more Terracotta Servers to the array.
-
两者的查询性能均为非常快。大多数情况下本地内存性能。如果您需要从磁盘进行登录，事实证明大多数操作系统都做得很好，并且可以比任何基于网络的群集更快地响应查询。
Query performance in both is very fast. Local memory performance in most cases. And if you need to page in from disk, it turns out most OSes do a good job and can respond way faster than any network-based clustering can to queries.
我认为，一旦我们让JBoss分解出他们的JMS假设等，
It will be, I think, once we get JBoss to factor out their JMS assumptions, etc.
干杯，
- Ari
这篇关于Teracotta和Hibernate搜索的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
