Pregunta

¿Alguien ha utilizado Lucene.NET en lugar de utilizar la búsqueda de texto completo que viene con el servidor SQL?

Si es así, me interesaría saber cómo lo implementó.

¿Escribiste, por ejemplo, un servicio de Windows que consultaba la base de datos cada hora y luego guardaba los resultados en el índice lucene.net?

¿Fue útil?

Solución

Sí, lo he usado exactamente para lo que estás describiendo.Teníamos dos servicios: uno para lectura y otro para escritura, pero sólo porque teníamos varios lectores.Estoy seguro de que podríamos haberlo hecho con un solo servicio (el escritor) e integrar el lector en la aplicación y los servicios web.

He usado lucene.net como un indexador de base de datos general, por lo que lo que obtuve fueron básicamente ID de base de datos (para mensajes de correo electrónico indexados), y también lo usé para recuperar suficiente información para completar los resultados de búsqueda o similares sin tocar el base de datos.Ha funcionado muy bien en ambos casos, aunque el SQL puede volverse un poco lento, ya que prácticamente tienes que obtener una identificación, seleccionar una identificación, etc.Solucionamos esto creando una tabla temporal (con solo la fila de ID) e insertando de forma masiva desde un archivo (que era el resultado de lucene) y luego uniéndonos a la tabla de mensajes.Fue mucho más rápido.

Lucene no es perfecto y hay que pensar un poco fuera del marco de la base de datos relacional, porque TOTALMENTE no lo es, pero es muy, muy bueno en lo que hace.Vale la pena echarle un vistazo y, según me han dicho, no tiene los problemas de "ups, lo siento, necesitas reconstruir tu índice nuevamente" que tiene la FTI de MS SQL.

Por cierto, estábamos tratando con entre 20 y 50 millones de correos electrónicos (y alrededor de 1 millón de archivos adjuntos únicos), creo que con un total de aproximadamente 20 GB de índice lucene y más de 250 GB de base de datos SQL + archivos adjuntos.

El rendimiento fue fantástico, por decir lo menos; solo asegúrese de pensar y modificar sus factores de fusión (cuando fusiona segmentos de índice).No hay problema en tener más de un segmento, pero puede haber un GRAN problema si intentas fusionar dos segmentos que tienen 1 millón de elementos en cada uno, y tienes un hilo de vigilancia que finaliza el proceso si tarda demasiado... ..(sí, eso nos pateó el trasero por un tiempo).Así que mantenga BAJA la cantidad máxima de documentos por elemento (es decir, ¡no lo configure en maxint como lo hicimos nosotros!)

EDITAR Corey Trager documentó cómo usar Lucene.NET en BugTracker.NET aquí.

Otros consejos

Todavía no lo he hecho con la base de datos, tu pregunta está un poco abierta.

Si desea buscar una base de datos y puede optar por utilizar Lucene, también supongo que puede controlar cuándo se insertan los datos en la base de datos.Si es así, hay pocas razones para sondear la base de datos para saber si necesita volver a indexar, simplemente indexar a medida que inserta o crear una tabla de cola que pueda usarse para indicarle a Lucene qué indexar.

Creo que no necesitamos otro indexador que ignore lo que está haciendo y reindexe cada vez, o que desperdicie recursos.

También he usado lucene.net como motor de almacenamiento, porque es más fácil distribuir y configurar máquinas alternativas con un índice que una base de datos, es solo una copia del sistema de archivos, puedes indexar en una máquina y simplemente copiar los archivos nuevos a las otras máquinas. para distribuir el índice.Todas las búsquedas y detalles se muestran en el índice de lucene y la base de datos solo se usa para editar.Esta configuración ha demostrado ser una solución muy escalable para nuestras necesidades.

En cuanto a las diferencias entre SQL Server y Lucene, el principal problema con la búsqueda de texto completo de SQL Server 2005 es que el servicio está desacoplado del motor relacional, por lo que unir, ordenar, agregar y filtrar entre los resultados de texto completo y las columnas relacionales son muy costosos. En términos de rendimiento, Microsoft afirma que estos problemas se solucionaron en SQL Server 2008, integrando la búsqueda de texto completo dentro del motor relacional, pero no lo he probado.También hicieron que la búsqueda de texto completo fuera mucho más transparente; en versiones anteriores, los lematizadores, las palabras vacías y varias otras partes de la indexación parecían un cuadro negro y eran difíciles de entender, y en la nueva versión es más fácil ver cómo funcionan.

Según mi experiencia, si el servidor SQL cumple con sus requisitos, será la forma más fácil, si espera mucho crecimiento, consultas complejas o necesita un gran control de la búsqueda de texto completo, podría considerar trabajar con lucene desde el principio porque Será más fácil de escalar y personalizar.

Usé Lucene.NET junto con MySQL.Mi enfoque fue almacenar la clave principal del registro de base de datos en el documento de Lucene junto con el texto indexado.En pseudocódigo se ve así:

  • Registro de la tienda:

    insertar texto, otros datos a la tabla
    obtener la última identificación insertada
    crear documento lucene
    poner (id, texto) en el índice de Lucene Document Update Lucene

  • Consultando
    buscar índice lucene
    para cada documento de lucene en el conjunto de resultados, cargue datos desde la base de datos mediante el ID del registro almacenado

Sólo para tener en cuenta, cambié de Lucene a Esfinge debido a su excelente rendimiento

Creo que este artículo es un buen punto de partida:

http://www.aspfree.com/c/a/braindump/working-with-lucene-net/

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top