Tengo un sitio web de anuncios clasificados. Los usuarios pueden poner anuncios, editar anuncios, ver anuncios, etc.SOLR confirmar y optimizar preguntas
Cada vez que un usuario pone un anuncio, estoy agregando un documento a solr. No sé, sin embargo, cuándo cometerlo. Commit ralentiza las cosas a partir de lo que he leído.
¿Cómo debo hacerlo? Autocommit cada 12 horas más o menos?
Además, ¿cómo debo hacerlo con optimización?
En realidad, comprometerse a menudo y optimizar hace que las cosas sean realmente lentas. Es muy pesado.
Después de un día de buscar y leer cosas, descubrí esto:
1- Optimizar hace que el índice de duplicar su tamaño, mientras que beeing optimizado, y hace cosas muy lento.
2- Comprometerse después de cada adición NO es una buena idea, es mejor comprometerse un par de veces al día, y luego hacer una optimización solo una vez al día como máximo.
3- Commit debe establecerse en "autoCommit" en el archivo solrconfig.xml, y allí debe ajustarse según sus necesidades.
comprometerse un par de veces al día ... no tan bueno en la mayoría de los casos de uso, nadie quiere ver sus datos medio día tarde – KaKa
Sí, esto definitivamente depende de su caso de uso. Si está bien no obtener las últimas entradas en los resultados durante medio día y tiene un índice enorme/lento, entonces comprometerse con moderación podría ser la respuesta. – JohannesH
Es importante tener en cuenta que "autocommit" puede causar que las actualizaciones fallen sin posibilidad de recuperación. (Específicamente, parecerá que SolrDocument D falló, pero en realidad los documentos A, B, C y D deben reenviarse). Cuando falla una confirmación, debe volver a cargar todo lo que envió a Solr. ¿Falla un compromiso a menudo? No, pero eso solo significa cuando necesita _need_ atraparlo. – yam655
Pruébelo primero. Sería realmente malo si evitara una solución simple y elegante solo porque usted lee que podría causar un problema de rendimiento. En otras palabras, evite premature optimization.
? La optimización en este contexto significa una operación solr/lucene especial que compacta el índice de búsqueda. No tiene nada que ver con la "optimización prematura". – Joe23
Por el contrario, estoy de acuerdo con John. Una solución simple es todo lo que se requiere si no tiene problemas de rendimiento. La optimización prematura es exactamente lo que dice en la lata. No está combinando el comando Solr Optimize con el significado regular de la palabra. Lo que Pablo está diciendo es una gran solución. Lo que John está diciendo es que no te molestes a menos que lo necesites. Me parece muy justo – Simon
La manera en que este tipo de cosas se realiza normalmente es realizar operaciones de confirmación/optimización en un nodo Solr ubicado fuera de la ruta de solicitud para sus usuarios. Esto requiere hardware adicional, pero asegura que la penalización del rendimiento de las operaciones de indexación no afecte a sus usuarios. La replicación se usa para enviar periódicamente archivos de índice optimizados desde el nodo maestro a los nodos que realizan consultas de búsqueda para los usuarios.
Un poco más de detalle en Commit/Optimizar:
Commit: Cuando está indexando documentos a Solr ninguno de los cambios que está haciendo aparecerán hasta que se ejecute el comando commit. Por lo tanto, el momento de ejecutar el comando de confirmación realmente depende de la velocidad a la que desee que aparezcan los cambios en su sitio a través del motor de búsqueda. Sin embargo, es una operación pesada, por lo que debe hacerse en lotes, no después de cada actualización.
Optimizar: Esto es similar a un comando de desfragmentación en un disco duro. Reorganizará el índice en segmentos (aumentando la velocidad de búsqueda) y eliminará cualquier documento eliminado (reemplazado). Solr es un almacén de datos de solo lectura, por lo que cada vez que indexe un documento marcará el documento anterior como eliminado y luego creará un nuevo documento para reemplazar el eliminado. Optimize eliminará estos documentos eliminados. Puede ver el documento de búsqueda frente a la cantidad de documentos eliminados accediendo a la página Solr Statistics y mirando los números numDocs vs. maxDocs. La diferencia entre los dos números es la cantidad de documentos eliminados (no aptos para la búsqueda) en el índice.
También Optimize genera un índice NUEVO completo del antiguo y luego cambia al nuevo índice cuando se completa. Por lo tanto, el comando requiere el doble de espacio para realizar la acción. Por lo tanto, deberá asegurarse de que el tamaño de su índice no exceda el 50% del espacio disponible en el disco duro.(Esta es una regla de oro, que por lo general tiene menos de% 50 a causa de los documentos eliminados)
Index Server/Servidor de búsqueda: Paul Brown tenía razón en que el mejor diseño para Solr es tener un servidor dedicado y sintonizó para indexar, y luego replica los cambios en los servidores de búsqueda. Puede ajustar el servidor de índice para tener múltiples puntos finales de índice.
eg: http://solrindex01/index1; http://solrindex01/index2
Y puesto que el servidor de índices no es la búsqueda de contenido que se puede tener configurado con diferentes huellas de memoria y comandos índice de calentamiento, etc.
Esperamos que esta información es útil para todos.
Pregunta? ¿Cómo le afecta esta lentitud? Si causa retraso en las lecturas, ¿ha considerado utilizar una disposición de Solr distribuida (Master-Slaves) – droider