Opciones para agrupamiento de Lucene.NET?

Question

Estoy interesado en ejecutar Lucene.NET para una aplicación que se ejecuta en clústeres de Windows. El problema de búsqueda en sí es razonablemente pequeño, pero el problema de apatrón/clúster aún debe ser manejado.

Entiendo que SOLR maneja mi escenario (y más) pero que requieren un contenedor de servlet (y Java) me plantea algunos problemas. Dependiendo de la complejidad de un enfoque basado en Lucene.NET, aún así puede ser una opción de vial.

Mi pregunta ahora es qué opciones tengo para manejar el problema de que se ejecuta en múltiples hosts:

• Persistir en un almacenamiento compartido, común para todos los nodos? ¿Lucene.NET manejaría la concurrencia de forma transparente? ¿Los servidores usarían RAM para el almacenamiento en caché, y si es así, Lucene.NET manejaría la invalidación de esto basándose en archivos actualizados de forma transparente?

• ¿Replicación? Cada servidor tiene su propia copia de todo lo que necesita. En cualquier actualización, todos los servidores obtienen una nueva réplica (o diff si esto es razonablemente simple). ¿Las herramientas existentes para esto, o depende de mí para manejarlas?

• Partición de la carga de trabajo/fragmentación? Cada servidor maneja solo sus propios datos, tanto para lecturas como para actualizaciones. Herramientas para manejar esto, unir resultados parciales, etc.

• ¿Me han perdido otras opciones en mi investigación inicial?

Al experimentar con una versión local, mi directorio Lucene estaba en el orden de un par de cientos de megas. A más largo plazo, puedo ver 1-5 GB, tal vez. Si la frecuencia de las actualizaciones es una dificultad, puedo controlar esto con bastante flexibilidad. Se espera que las cargas concurrentes de lectura/búsqueda sean muy moderadas.

Answer 1

Puede usar lucene.net con varios servidores pero debe implementar un servidor de indexación.

Todos los cambios que realice se deben poner en cola e indexar de vez en cuando los documentos pendientes. También debe indexar inmediatamente si x elementos están en la cola (x depende de la configuración de sus documentos de combinación, esto fue 25,000 para mí).

El razonamiento detrás de lo anterior es que debe evitar hacer pequeños cambios en el índice, ya que esto reducirá el tiempo extra de rendimiento debido a que se han creado muchos archivos pequeños. Puede ejecutar 2 servidores de indexación pero solo 1 indexará a la vez debido al bloqueo en el índice. La única razón para hacer esto es para la conmutación por error, si la primera falla, depende de sus necesidades.

He usado un índice de 15Gb con 30 millones de registros. El escenario que tuve con esto estaba bajo azul.

• 1 papel del trabajador al índice cambia

• 2 - 20 papeles web que sirven contenido de cada uno con el índice.

Los cambios se realizaron cada 15 minutos y el índice se fusionó en 25,000 cambios y cada índice combinado contiene 250,000 documentos. Cada servidor web verificaba el almacenamiento de blobs para ver los cambios cada 15 minutos y bloqueaba el lector de índices, que luego se invalidaba si se descargaban los cambios. Su máximo de documentos por archivo es básicamente para evitar que los servidores web descarguen muchos cambios previos.

Utilicé Lucene.AzureDirectory para empezar pero no fue confiable para detectar blobs modificados en el almacenamiento de blobs, así que terminé iterando los blobs y los comparé localmente y los descargué según fue necesario.

¿Ahora implementaría algo como esto otra vez? la respuesta es un gran no. Usaría elasticsearch o solr en su lugar mientras reinventa la rueda.