asp.net - ¿Lucene.Net administra múltiples hilos que acceden al mismo índice, un índice mientras que el otro está buscando?
concurrency (3)
De acuerdo con esta página ,
La indexación y la búsqueda no solo son seguras para hilos, sino que son seguras para el proceso. Lo que esto significa es que:
- Múltiples buscadores de índice pueden leer los archivos de índice lucene al mismo tiempo.
- Un escritor o lector de índice puede editar los archivos de índice lucene mientras las búsquedas están en curso
- Varios escritores de índice o lectores pueden intentar editar los archivos de índice de lucene al mismo tiempo (es importante que el escritor / lector de índices se cierre para que libere el bloqueo de archivos). Sin embargo, el analizador de consultas no es seguro para subprocesos, por lo que cada subproceso que use el índice debe tener su propio analizador de consultas.
Sin embargo, el escritor de índices es seguro para subprocesos, por lo que puede actualizar el índice mientras las personas lo buscan. Sin embargo, debe asegurarse de que los hilos con buscadores de índice abiertos los cierren y abran nuevos, para obtener los datos recién actualizados.
Cuando uso Lucene.Net con ASP.NET, puedo imaginar que una solicitud web puede desencadenar una actualización del índice mientras que otra solicitud web realiza una búsqueda. ¿Lucene.Net ha incorporado la posibilidad de gestionar el acceso simultáneo, o tengo que administrarlo, para evitar errores de "ser utilizado por otro proceso"?
EDITAR: Después de leer documentos y experimentar, esto es lo que creo que aprendí: hay dos problemas, seguridad de hilos y concurrencia. El subprocesamiento múltiple es "seguro" en el sentido de que no se puede hacer nada malo con el índice. Pero, es seguro a costa de un solo objeto que tiene un bloqueo en el índice a la vez. El segundo objeto vendrá y lanzará una excepción. Por lo tanto, no puede dejar una búsqueda abierta y esperar que un escritor en otro hilo pueda actualizar el índice. Y si un hilo está ocupado actualizando el índice, entonces tratar de crear un buscador fallará.
Además, los buscadores ven el índice tal como estaba en el momento en que lo abren, por lo que si los mantienes cerca y actualizas el índice, no verán las actualizaciones.
Quería que mis buscadores vieran las últimas actualizaciones.
Mi diseño, y parece estar funcionando hasta ahora, es que mis escritores y buscadores comparten un candado, para que no fallen, solo esperan, hasta que se complete la escritura o búsqueda actual.
No tiene un problema con eso tanto como administrar escrituras concurrentes en el índice. He tenido un camino más fácil con SOLR, que abstrae la mayoría de esas diferencias, ya que se ejecuta como servidor.
Puede tener problemas, si su hilo de indexación está creando un documento nuevo que da como resultado la fusión de algunos segmentos de índice, los segmentos fusionados se eliminarán y se creará un nuevo segmento. El problema es que el buscador de índice cargó todos los segmentos cuando se abrió, por lo que tiene "punteros" para los segmentos que existían cuando se abrió. Ahora, si el escritor del índice fusiona un segmento y elimina un segmento, su buscador de índice seguirá creyendo que ese archivo de segmento existe y fallará con un "error de archivo no encontrado". Lo que realmente necesita hacer es separar su índice de escritura de su índice de búsqueda, utilizando SOLR o haciendo su propia replicación de instantáneas de índice similar a lo que SOLR hace. Tengo un sistema muy similar a SOLR usando .NET y Lucene.NET en Windows, usando enlaces duros NTFS para hacer una replicación eficiente de instantáneas. Te puedo dar más información si estás interesado.