sql-server lucene.net

Lucene.Net y SQL Server



sql-server (5)

Aún no lo he hecho contra la base de datos, tu pregunta está un poco abierta.

Si desea buscar un archivo db y puede elegir utilizar Lucene, también creo que puede controlar cuándo se insertan datos en la base de datos. Si es así, hay pocas razones para sondear el archivo db para averiguar si necesita volver a indexar, simplemente indexar al insertar, o crear una tabla de cola que se pueda usar para indicarle a lucene qué indexar.

Creo que no necesitamos otro indexador que ignore lo que está haciendo y reindexe todo el tiempo, o utilice recursos derrochadores.

¿Alguien ha usado Lucene.NET en lugar de usar 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 guardaba los resultados en el índice lucene.net?

Usé Lucene.NET junto con MySQL. Mi enfoque era almacenar la clave principal del registro de db en el documento Lucene junto con el texto indexado. En pseudo código, parece que:

  • Registro de la tienda:

    insertar texto, otros datos en la tabla
    obtener la última identificación insertada
    crear un documento lucene
    poner (ID, texto) en lucene actualización de documento índice lucene

  • Consultando
    buscar índice lucene
    para cada documento de lucene en el resultado, establezca datos de carga de DB por ID de registro almacenado

Solo para observar, cambié de Lucene a Sphinx debido a su excelente rendimiento

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, puede indexar en una máquina y copiar los archivos nuevos en las otras máquinas para distribuir el índice. Todas las búsquedas y detalles se muestran en el índice lucene, y la base de datos solo se utiliza para editar. Esta configuración se ha demostrado como una solución muy escalable para nuestras necesidades.

En cuanto a las diferencias entre sql server y lucene, el principal problema con sql server 2005 full text search es que el servicio está desacoplado del motor relacional, por lo que las uniones, pedidos, agregados y filtros entre los resultados de texto completo y las columnas relacionales son muy caros en términos de rendimiento, Microsoft afirma que estos problemas se han abordado en el servidor sql 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 términos, stopwords y otras partes de la indexación eran como una caja negra y difíciles de entender, y en la nueva versión es más fácil ver cómo funcionan.

Con mi experiencia, si el servidor sql cumple con sus requisitos, será la manera 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 escalar y personalizar.

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

Utilicé lucene.net como un indexador de base de datos general, así que lo que obtuve fue básicamente DB id (para mensajes de correo electrónico indexados), y también lo uso para recuperar suficiente información para completar los resultados de búsqueda o similares sin tocar el base de datos. Funcionó muy bien en ambos casos, aunque el SQL puede ser un poco lento, ya que tienes que obtener una ID, seleccionar una ID, etc. Lo solucionamos haciendo una tabla temporal (con solo la fila de ID) y inserción masiva desde un archivo (que fue el resultado de lucene) y luego unirse a la tabla de mensajes. Fue mucho más rápido.

Lucene no es perfecto, y tienes que pensar un poco fuera del cuadro de la base de datos relacional, porque TOTALMENTE no es uno, pero es muy bueno en lo que hace. Vale la pena echarle un vistazo, y, según me han dicho, no tiene los problemas "oops, lo siento, tienes que volver a compilar tu índice" que hace la FTI de MS SQL.

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

El rendimiento fue fantástico, por decir lo menos, solo asegúrate de pensar y modificar tus 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 intenta fusionar dos segmentos que tienen 1mil elementos en cada uno, y usted tiene un hilo de observador que mata el proceso si tarda demasiado ... .. (sí, eso nos pateó el culo por un tiempo). Por lo tanto, mantenga el número máximo de documentos por cosa BAJA (es decir, ¡no lo configure como maxint como lo hicimos nosotros!)

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