features - solr xls

SOLR autoCommit vs autoSoftCommit

Question

Estoy muy confundido sobre y. Esto es lo que entiendo

• AutoSoftCommit : después de un AutoSoftCommit, si el servidor SOLR se cae, los documentos de autoSoftCommit se perderán.

• autoCommit : realiza un commit duro en el disco y se asegura de que todas las confirmaciones de autoSoftCommit se escriban en el disco y confirme cualquier otro documento.

Mi siguiente configuración parece ser solo con autoSoftCommit. autoCommit por sí solo no parece estar haciendo ningún commit. Hay algo que este olvidando ?

<updateHandler class="solr.DirectUpdateHandler2">
    <updateLog>
        <str name="dir">${solr.ulog.dir:}</str>
    </updateLog>
   <autoSoftCommit>
        <maxDocs>1000</maxDocs>
        <maxTime>1200000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>10000</maxDocs>
        <maxTime>120000</maxTime> 
        <openSearcher>false</openSearcher>
    </autoCommit>
</updateHandler>

¿Por qué AutoCommit está trabajando por su cuenta?

Answer 1

Tienes openSearcher = false para commits duros. Lo que significa que, aunque se haya realizado la confirmación, el buscador no se ha reiniciado y no puede ver los cambios. Intenta cambiar esa configuración y no necesitarás confirmación suave.

SoftCommit vuelve a abrir el buscador. Por lo tanto, si tiene ambas secciones, la confirmación suave muestra nuevos cambios (incluso si no están comprometidos) y, tal como está configurado, la confirmación definitiva los guarda en el disco, pero no cambia la visibilidad.

Esto permite poner el compromiso suave en 1 segundo y hacer que los documentos se muestren rápidamente y que el compromiso sea menos frecuente.

Answer 2

Creo que este artículo te será útil. Explica en detalle cómo funcionan el commit y el soft commit, y las ventajas y desventajas que se deben tener en cuenta al ajustar el sistema.

Siempre me estremezco ante esto, porque cualquier recomendación será incorrecta en algunos casos. Mi primera recomendación sería no pensar demasiado el problema. Algunas personas muy inteligentes han intentado robustecer todo el proceso. Pruebe primero las cosas simples y solo modifique las cosas según sea necesario. En particular, observe el tamaño de los registros de transacciones y ajuste los intervalos de confirmación para mantener estos "tamaños razonables". Recuerde que la penalización es principalmente el tiempo de reproducción involucrado si reinicia después de un bloqueo de JVM. ¿Son 15 segundos tolerables? ¿Por qué ir más pequeño entonces?

Hemos visto situaciones en las que el intervalo de confirmación dura es mucho más corto que el intervalo de confirmación suave, consulte el siguiente bit de indexación masiva.

Estos son lugares para comenzar.

INDEXACIÓN PESADA (A GRANEL)

La suposición aquí es que está interesado en obtener una gran cantidad de datos en el índice lo más rápido posible para la búsqueda en el futuro. Estoy pensando en cargas originales de una fuente de datos, etc.

Establezca su intervalo de confirmación suave bastante largo. Como en 10 minutos. El compromiso suave se trata de visibilidad, y mi suposición aquí es que la indexación masiva no se trata de búsquedas casi en tiempo real, así que no hagas el trabajo extra de abrir cualquier tipo de buscador. Establezca sus intervalos de confirmación duros en 15 segundos, openSearcher = false. Una vez más, la suposición es que vas a estar destruyendo datos en Solr. El peor caso aquí es que reinicias tu sistema y tienes que reproducir 15 segundos más o menos de datos de tu tlog. Si su sistema rebota hacia arriba y hacia abajo con más frecuencia que eso, solucione el problema primero. Solo después de haber probado las cosas simples debería considerar refinamientos, por lo general solo se requieren en circunstancias inusuales. Pero incluyen: Desactivar el tlog por completo para la operación de carga masiva Indexar fuera de línea con algún tipo de proceso de reducción de mapa Solo tener un líder por fragmento, no hay réplicas para la carga, luego encender las réplicas más tarde y dejar que hagan el viejo estilo replicación para ponerse al día. Tenga en cuenta que esto es automático, si el nodo descubre que está "demasiado lejos" de la sincronización con el líder, inicia una replicación antigua. Una vez que se haya alcanzado, obtendrá los documentos que están indexados al líder y mantendrá su propio tlog. etc.

INDEX-HEAVY, QUERY-LIGHT

Con esto quiero decir, digamos, buscar archivos de registro. Este es el caso donde tienes muchos datos llegando al sistema casi todo el tiempo. Pero la carga de consultas es bastante ligera, a menudo para solucionar problemas o analizar el uso.

Establezca un intervalo de confirmación suave bastante largo, hasta la latencia máxima que puede soportar para documentos visibles. Esto podría ser solo un par de minutos o mucho más. Tal vez incluso horas con la capacidad de emitir un commit duro (openSearcher = true) o soft commit on demand. Establezca su compromiso a 15 segundos, openSearcher = false INDEX-LIGHT, QUERY-LIGHT O HEAVY

Este es un índice relativamente estático que a veces obtiene una pequeña ráfaga de indexación. Digamos que cada 5-10 minutos (o más) haces una actualización

A menos que se requiera la funcionalidad NRT, omitiría los commits suaves en esta situación y haré commits duros cada 5-10 minutos con openSearcher = true. Esta es una situación en la que, si está indexando con un solo proceso de indexación externo, podría tener sentido hacer que el cliente emita el compromiso.

INDEX-HEAVY, QUERY-HEAVY

Este es el caso de Near Real Time (NRT), y es realmente el más complicado del lote. Este requerirá experimentación, pero aquí es donde comenzaría

Establezca su intervalo de confirmación suave siempre que pueda pararse. No escuche a su gerente de producto que dice "no necesitamos más de 1 segundo de latencia". De Verdad. Empuje hacia atrás con fuerza y ​​vea si el usuario está mejor servido o incluso lo notará. Los commits suaves y NRT son bastante sorprendentes, pero no son gratuitos. Establezca su intervalo de compromiso duro en 15 segundos.

En mi caso (índice pesado, consulta pesada), el maestro-esclavo de replicación tomaba demasiado tiempo, ralentizando las consultas al esclavo. Al aumentar el softCommit a 15 minutos y aumentar el hardCommit a 1min, la mejora en el rendimiento fue excelente. Ahora la replicación funciona sin problemas, y los servidores pueden manejar muchas más solicitudes por segundo.

Este es mi caso de uso, me di cuenta de que realmente no necesito que los elementos estén disponibles en el maestro en tiempo real, ya que el maestro solo se utiliza para indexar elementos, y los nuevos elementos están disponibles en los esclavos en cada ciclo de replicación (5min ), lo cual está totalmente bien para mi caso. debe ajustar estos parámetros para su caso.