¿Mejores prácticas para combinar Lucene.NET y una base de datos relacional?

Question

Estoy trabajando en un proyecto en el que tendré MUCHOS datos, y podrá buscarse en varios formularios que se expresan muy eficientemente como Consultas SQL, pero también debe buscarse mediante el procesamiento de lenguaje natural.

Mi plan es crear un índice usando Lucene para esta forma de búsqueda.

Mi pregunta es que si hago esto y realizo una búsqueda, Lucene devolverá los ID de los documentos coincidentes en el índice, entonces debo buscar estas entidades desde la base de datos relacional.

Esto podría hacerse de dos maneras (Eso se me ocurre hasta ahora):

• N cantidad de consultas (horrible)
• pasar todos los ID a un procedimiento almacenado a la vez (quizás como un parámetro delimitado por comas). Esto tiene la desventaja de estar limitado al tamaño máximo del parámetro y el bajo rendimiento de una UDF para dividir la cadena en una tabla temporal.

Estoy casi tentado a reflejar todo en el índice de lucenes, por lo que puedo generar periódicamente el índice de la tienda de respaldo, pero solo necesito acceder a él para la interfaz.

¿Asesoramiento?

Answer 1

Cuando encontré este problema, fui con una base de datos relacional que tiene capacidades de búsqueda de texto completo (utilicé PostgreSQL 8.3, que tiene soporte ft incorporado, con apoyo de raíces y tesauros). De esta forma, la base de datos puede realizar consultas utilizando comandos SQL y ft. El inconveniente es que necesita un DB que tenga capacidades de búsqueda de texto completo, y estas capacidades pueden ser inferiores a lo que puede hacer Lucene.

Answer 2

Almacenaba los datos de 'frontend' dentro del índice en sí, evitando cualquier interacción db. El archivo db se consultará solo cuando desee obtener más información sobre el registro específico.

Answer 3

Supongo que la respuesta depende de lo que va a hacer con los resultados, si va a mostrar los resultados en una cuadrícula y le permite al usuario elegir el documento exacto al que desea acceder, entonces es posible que desee agregar a el índice de texto suficiente para ayudar al usuario a identificar el documento, como una propaganda de, digamos, 200 caracteres y luego, una vez que el miembro selecciona un documento, acceda al DB para recuperarlo por completo.

Esto tendrá un impacto en el tamaño de su índice seguro, por lo que es otra consideración que debe tener en cuenta. También pondría un caché entre el DB y el front-end para que los artículos más usados ​​no incurran en el costo total de un acceso a DB cada vez.

Answer 4

Probablemente no sea una opción, dependiendo de la cantidad de cosas que hay en su base de datos, pero lo que he hecho es almacenar las id de db en el índice de búsqueda junto con las propiedades que quería indexadas. Luego, en mis clases de servicio, guardo en caché todos los datos necesarios para mostrar los resultados de búsqueda de todos los objetos (por ejemplo, nombre, ID de db, URL de la imagen, elementos borrosos de la descripción, información de las redes sociales). La clase de servicio devuelve un diccionario que puede buscar objetos por db id, y yo uso los id devueltos por Lucene.NET para extraer datos del caché en memoria.

También puede renunciar a la memoria caché en memoria y almacenar todas las propiedades necesarias para mostrar un resultado de búsqueda en el índice de búsqueda. No hice esto porque la memoria caché en memoria también se usa en escenarios distintos a la búsqueda.

La memoria caché en memoria siempre está actualizada en pocas horas, y la única vez que tengo que presionar la base de datos es si necesito obtener datos más detallados para un solo objeto (si el usuario hace clic en el enlace para un objeto específico para ir a la página para ese objeto).