Terracota y Hibernate Buscar

Question

¿Alguien tiene experiencia con el uso de terracota con Hibernate Search para satisfacer las consultas de aplicación?

Si es así:

1. ¿Qué magnitud del "objeto actualizaciones" que pueden manejar? (¿Cómo está la rendimiento)

2. ¿Qué tipo de rendimiento hacer lo Las consultas tienen?

3. ¿Es posible utilizar terracota     Hibernate Búsqueda sin ni siquiera tener     una base de datos de respaldo para satisfacer todas     "consultas" en la memoria?

Answer 1

Soy director de tecnología de terracota. Pasé algún tiempo el mes pasado mirando Hibernate Search. No se construye de manera que se agrupan de forma transparente por terracota. He aquí por qué, en pocas palabras:. Hibernate tiene una réplica JMS hecha a la medida de los índices de Lucene entre las JVM

La idea básica en la búsqueda es que hablar en el disco local bajo Lucene funciona muy bien, mientras que la fragmentación o la partición de hasta índices de Lucene través de la red presenta tan mucha latencia como para hacer Lucene parece mal cuando no es culpa de Lucene en absoluto. A tal fin, Hibernate búsqueda no se basa en JBossCache o cualquier en memoria esquemas de partición / almacenamiento en caché y su lugar se basa en JMS y el disco local de cada JVM con el fin de proporcionar la indexación hasta a la fecha a través de una cluster con baja latencia simultánea. Entonces, la belleza de hibernación de búsqueda es que las consultas de Hibernate estándar y más pueden ser puesta en marcha a través de hibernación en estos índices de lenguaje natural en cada máquina.

A terracota resulta que teníamos una idea similar a Emmanuel y construimos un producto SearchableMap en la parte superior de la brújula. Cada máquina tiene su propia tienda de brújula y la tienda está configurado para derramarse en el disco local. Terracota se utiliza para crear una capacidad de escritura de múltiples maestros que cualquier JVM puede añadir al índice y el delta se envía a través de terracota para que se reproduzca / volver a aplicar localmente para cada disco. Funciona como Hibernate búsqueda pero con DSO como el protocolo de red en lugar de JMS y w / o las buenas interfaces de Hibernate, sino con interfaces brújula.

Creo que vamos a apoyar Hibernate Buscar w / ayuda de JBoss (que necesitarían para factorizar las impl JMS como enchufable) a finales del año.

Ahora a sus preguntas directamente:

actualizaciones 1.object / seg en hibernación o SearchableMap deben ser bastante alto debido a que ambos están enviando solamente los deltas. En el caso de Hibernate es una función de nuestro proveedor de JMS. En terracota es escalable simplemente añadiendo más servidores de terracota a la matriz.

2. El rendimiento de consultas en tanto es muy rápido. rendimiento de la memoria local en la mayoría de los casos. Y si es necesario a la página desde el disco, resulta que la mayoría de los sistemas operativos hacen un buen trabajo y pueden responder de forma más rápida que cualquier red basada en la agrupación lata para consultas.

3. Será, creo que, una vez que tengamos JBoss factorizar sus supuestos JMS, etc.

Saludos,

- Ari

Answer 2

Dado que las personas en los foros de Hibernate siguen refiriéndose a este post me siento en la necesidad de señalar que si bien los comentarios de Ari, donde correctas al comienzo de 2009, se han estado desarrollando y mejorando mucho.

Hibernate Search proporciona un conjunto de canales de back-end fuera de la caja, al igual que las JMS ya mencionados base y una adición más reciente utilizando JGroups, pero hemos hecho también muy fácil de conectar en implementaciones alternativas o anular algunos.

Además de utilizar un motor de costumbre, ahora es posible desde la versión 4 para reemplazar toda la estrategia y en lugar de cambiar la aplicación de back-end sólo se puede utilizar un IndexManager que sigue un diseño diferente y no utiliza un motor en absoluto; en este momento tenemos solamente dos IndexManagers pero estamos trabajando en más alternativas; de nuevo la idea es proporcionar buenas implementaciones de los más comunes

Se tiene un back-end basado Infinispan de distribución muy rápida del índice a través de diferentes nodos, y que debería ser sencillo para contribuir uno basado en terracota o cualquier otra tecnología de agrupación. Más soluciones están llegando.