optimization - recommendation - seo meta descriptions
¿Debería optimizarse un índice después de los índices incrementales en Lucene? (3)
Ejecutamos re-índices completos cada 7 días (es decir, creando el índice desde cero) en nuestro índice Lucene y en índices incrementales cada 2 horas más o menos. Nuestro índice tiene alrededor de 700,000 documentos y un índice completo demora alrededor de 17 horas (lo cual no es un problema).
Cuando hacemos índices incrementales, solo indexamos contenido que ha cambiado en las últimas dos horas, por lo que toma mucho menos tiempo, alrededor de media hora. Sin embargo, hemos notado que una gran cantidad de este tiempo (quizás 10 minutos) se usa para ejecutar el método IndexWriter.optimize ().
El LuceneFAQ menciona que:
La clase IndexWriter admite un método optimize () que compacta la base de datos de índice y acelera las consultas. Es posible que desee utilizar este método después de realizar una indexación completa de su conjunto de documentos o después de las actualizaciones incrementales del índice. Si su actualización incremental agrega documentos con frecuencia, desea realizar la optimización solo de vez en cuando para evitar la sobrecarga adicional de la optimización.
... pero esto no parece dar ninguna definición de lo que significa "con frecuencia". La optimización es intensiva en CPU y MUY IO-intensiva, por lo que preferiríamos no hacerlo si podemos salirse con la suya. ¿Cuánto cuesta la ejecución de consultas en un índice no optimizado (estoy pensando especialmente en términos de rendimiento de la consulta después de un nuevo índice completo en comparación con después de 20 índices incrementales donde, digamos, 50,000 documentos han cambiado)? ¿Deberíamos estar optimizando después de cada índice incremental o el rendimiento alcanzado no lo vale?
Mat, ya que parece que tienes una buena idea de cuánto tiempo lleva tu proceso actual, te sugiero que elimines el optimize() y midas el impacto.
¿Cambian muchos de los documentos en esas ventanas de 2 horas? Si solo una pequeña fracción (50,000 / 700,000 es aproximadamente 7%) se vuelven a indexar incrementalmente, entonces no creo que esté obteniendo mucho valor de un optimize() .
Algunas ideas:
- No haga una
optimize()incrementaloptimize()en absoluto. Mi experiencia dice que, de todos modos, no se ve una gran mejora en la consulta. - Haga el
optimize()todos los días en lugar de 2 horas. - Haga la
optimize()durante tiempos de bajo volumen (que es lo que dice el javadoc ).
Y asegúrate de tomar medidas. Este tipo de cambios pueden ser un tiro en la oscuridad sin ellos.
En este correo , Otis Gospodnetic advierte sobre el uso de optimizar, si su índice está viendo actualizaciones constantes. Es a partir de 2007, pero llamar a optimize() es, por su propia naturaleza, una operación pesada en IO. Podría considerar usar un enfoque más gradual; un MergeScheduler
Una operación de optimize lee y escribe todo el índice, ¡por eso es tan intensivo en IO!
La idea detrás de optimizar las operaciones es volver a combinar todos los diversos segmentos en el índice Lucene en un solo segmento, lo que puede reducir en gran medida los tiempos de consulta ya que no tiene que abrir y buscar varios archivos por consulta. Si está utilizando la estructura de archivos de índice Lucene normal (en lugar de la estructura combinada), obtiene un nuevo segmento por operación de confirmación; lo mismo que su re-indexes supongo?
Creo que Matt tiene un gran consejo y yo diría que todo lo que diga, impulsado por la información que tienes. De hecho, iría un paso más allá y solo optimizaría a) cuando lo necesite yb) cuando tenga un volumen de consulta bajo.
Como el rendimiento de la consulta está íntimamente ligado al número de segmentos en su índice, un simple ls -1 index/segments_* | count ls -1 index/segments_* | count podría ser un indicador útil para cuando la optimización es realmente necesaria.
Alternativamente, el seguimiento del rendimiento y el volumen de la consulta y el inicio de una optimización cuando se alcanza un bajo rendimiento inaceptable con un volumen aceptablemente bajo sería una solución más agradable.