database - tutorial - hibernate start
¿Cuál es la mejor búsqueda contra un DB con Lucene? (5)
Estoy buscando mecanismos para mejorar las capacidades de búsqueda en nuestra base de datos. Actualmente es un gran cuello de botella (que causa consultas de larga duración que están perjudicando el rendimiento de nuestra base de datos).
Mi jefe quería que investigara a Solr , pero en una inspección más cercana, parece que realmente queremos algún tipo de mecanismo de integración de DB con Lucene.
De las preguntas frecuentes de Lucene , recomiendan Hibernate Search , Compass y DBSight .
Como fondo de nuestra pila de tecnología actual, estamos utilizando JSP rectos en Tomcat, no Hibernate, no hay otros marcos en la parte superior ... solo directamente Java, JSP y JDBC contra una base de datos DB2.
Dado que, parece que Hibernate Search puede ser un poco más difícil de integrar en nuestro sistema, aunque podría ser bueno tener la opción de usar Hibernate después de tal integración.
¿Alguien tiene alguna experiencia que puedan compartir con el uso de una de estas herramientas (u otras soluciones similares basadas en Lucene) que podrían ayudar a elegir la herramienta adecuada?
Tiene que ser una solución FOSS e idealmente administrará la actualización automática de Lucene con cambios de la base de datos (aunque de manera eficiente), sin esfuerzo adicional para notificar a la herramienta cuando se han realizado cambios (de lo contrario, parece que mi propia solución Lucene sería solo tan bueno). Además, tenemos múltiples servidores de aplicaciones con solo 1 base de datos (+ conmutación por error), por lo que sería bueno si es fácil usar la solución desde todos los servidores de aplicaciones sin problemas.
Continúo inspeccionando las opciones ahora, pero sería realmente útil utilizar las experiencias de otras personas.
Bueno, parece que DBSight no cumple con los requisitos de FOSS , así que a menos que sea una solución absolutamente estelar, no es una opción para mí en este momento ...
He tenido buenas experiencias con Compass. Tiene una muy buena integración con hibernación y puede reflejar los cambios de datos realizados a través de hibernación y jdbc directamente a los índices de Lucene a través de sus dispositivos GPS http://www.compass-project.org/docs/1.2.2/reference/html/gps- jdbc.html .
Mantener los índices de Lucene en todos sus servidores de aplicaciones puede ser un problema. Si tiene varios servidores de aplicaciones actualizando el db, entonces puede solucionar algunos problemas para mantener el índice sincronizado con todos los cambios. La brújula puede tener un mecanismo alternativo para manejar esto ahora.
El Proyecto Alfresco (CMS) también utiliza Lucene y tiene un mecanismo para replicar los cambios de índice Lucene entre servidores que pueden ser útiles para manejar estos problemas.
Comenzamos a usar Compass antes de que Hibernate Search realmente despegara, por lo que no puedo ofrecer ninguna comparación con él.
Para un aumento de rendimiento puro con la búsqueda de Lucene sin duda ayudará mucho. Solo indexe lo que le importa / necesita y debería ser bueno. Puede usar Hibernate o alguna otra pieza si lo desea, pero no creo que sea necesario.
Cuando dices "buscar contra un DB", ¿qué quieres decir?
Las bases de datos relacionales y los sistemas de recuperación de información usan enfoques muy diferentes por una buena razón. ¿Qué tipo de datos estás buscando? ¿Qué tipo de consultas llevas a cabo?
Si fuera a implementar un índice invertido sobre una base de datos, como lo hace Compass, no utilizaría su enfoque, que es implementar la abstracción de Directory de Lucene con BLOB. Mejor dicho, implementaría la abstracción de IndexReader de Lucene.
Las bases de datos relacionales son bastante capaces de mantener índices. El valor que aporta Lucene en este contexto es su capacidad de análisis, que es más útil para los registros de texto no estructurados. Un buen enfoque aprovecharía las fortalezas de cada herramienta.
A medida que se realizan las actualizaciones en el índice, Lucene crea más segmentos (archivos adicionales o BLOB), que degradan el rendimiento hasta que se utiliza un costoso procedimiento de "optimización". La mayoría de las bases de datos amortizarán este costo en cada actualización de índice, proporcionándole un rendimiento más estable.
LuSql http://code.google.com/p/lusql/ le permite cargar los contenidos de una base de datos accesible para JDBC en Lucene, lo que hace que se pueda buscar. Está altamente optimizado y tiene múltiples subprocesos. Soy el autor de LuSql y saldré con una nueva versión (rediseñada con una nueva arquitectura enchufable) en el próximo mes.