SOLR la optimización del rendimiento

Question

He leído lo siguiente:

http://wiki.apache.org/solr/SolrPerformanceFactors

http://wiki.apache.org/solr/SolrCaching

http://www.lucidimagination.com/content/scaling-lucene-and-solr

Y tengo preguntas acerca de algunas cosas:

1. Si uso la opción de JVM -XX:+UseCompressedStrings qué tipo de Ahorro de memoria ¿puedo lograrlo? Para mantener un ejemplo simple, si tengo 1 campo indexado (cadena) y 1 campo almacenado (cadena) con omitNorms = true y omitTf = true, ¿qué tipo de ahorros puedo esperar en el índice y en el caché de documentos? Supongo aproximadamente el 50%, pero tal vez eso sea demasiado optimista.
2. ¿Cuándo exactamente está haciendo el caché del filtro Solr? Si solo estoy haciendo una consulta simple con AND y unas pocas RUP, y ordenando por puntaje, ¿la necesito?
3. Si quiero almacenar en caché todos los documentos en el caché del documento, ¿cómo calculo el espacio requerido? Usando el ejemplo de arriba, si tengo documentos de 20M, uso cuerdas comprimidas, y la longitud promedio del campo almacenado es de 25 caracteres, ¿el espacio requerido es básicamente (25 bytes + small_admin_overhead) * 20M?
4. si todos los documentos están en el caché de documentos, ¿qué importancia tiene el caché de consultas?
5. Si quiero autocalentar cada documento en la memoria caché del documento, la consulta automática de *:* lo hará?
6. El artículo scaling-lucene-and-solr dice que FuzzyQuery es lento. Si estoy usando la función de corrección ortográfica de Solr, básicamente estoy usando la consulta difusa a la derecha (porque el corrector ortográfico hace el mismo cálculo de distancia de edición). ¿Entonces, presumiblemente, la revisión ortográfica y la consulta difusa son igualmente "lentas"?
7. La sección que describe el caché de campo lucene para cadenas es un poco confuso. ¿Lo estoy leyendo correctamente que el espacio requerido es básicamente el tamaño del campo de cadena indexado + un número entero arry igual al número de términos únicos en ese campo?
8. Finalmente, al maximizar el rendimiento, hay una declaración sobre dejar suficiente espacio para la memoria caché de disco del sistema operativo. Dice: "En general, para un índice a gran escala, es mejor asegurarse de tener al menos unos pocos gigabytes de RAM más allá de lo que le está dando a la JVM". Entonces, si tengo una máquina de memoria de 12GB (como ejemplo), ¿debería dar al menos 2-3GB al sistema operativo? ¿Puedo estimar el espacio de caché de disco que necesita el sistema operativo mirando el tamaño del índice del disco?

Answer 1

1. La única forma de estar seguro es probarlo. Sin embargo, esperaría muy pocos ahorros en el índice, ya que el índice solo contendría la cadena real una vez cada vez, el resto son datos para las ubicaciones de esa cadena dentro de los documentos. No son una gran parte del índice.
2. La memoria caché del filtro solo almacena en caché las consultas de filtro. Puede que no sea útil para su caso de uso preciso, pero muchos los encuentran útiles. Por ejemplo, reducir los resultados por país, idioma, tipo de producto, etc. Solr puede evitar volver a calcular los resultados de la consulta de este tipo si los usa con frecuencia.
3. Realísticamente, solo tienes que probarlo y medirlo con un generador de perfiles. Sin un conocimiento profundo de EXACTAMENTE la estructura de datos utilizada, cualquier otra cosa es puro SWAG. Su cálculo es tan bueno como el de cualquier otra persona sin perfiles.
4. La memoria caché de documentos solo ahorra tiempo al constituir los resultados DESPUÉS de que se haya calculado la consulta. Si pasa la mayor parte de su tiempo calculando consultas, la memoria caché del documento no le servirá de mucho. Query Cache solo es útil para consultas reutilizadas.Si ninguna de sus consultas se repite, entonces la caché de consultas es inútil
5. sí, suponiendo que su caché de documentos es lo suficientemente grande como para contenerlos a todos.

6-8 No positivo.

Según mi propia experiencia con la optimización del rendimiento de Solr, debe dejar Solr para tratar las consultas, no el almacenamiento de documentos. La mayoría de sus preguntas se centran en cómo los documentos ocupan espacio. Solr es un motor de búsqueda, no un depósito de almacenamiento de documentos. Si desea que Solr sea RÁPIDO y ocupe la memoria mínima, entonces lo único que debe conservar es la información del índice para fines de búsqueda. Los documentos en sí mismos deben almacenarse, recuperarse y traducirse en otro lugar. Preferiblemente en un sistema que está optimizado específicamente para ese trabajo. El único campo que debe almacenar en su documento de Solr es una identificación para recuperar del sistema de almacenamiento de documentos.

Answer 2

cachés

En general, el almacenamiento en caché que parece una buena idea para mejorar el rendimiento, pero esto también tiene un montón de problemas:

• objetos en caché son propensos a entrar en la vieja generación de el recolector de basura, que es más costoso de cobrar,
• administrar inserciones y desalojos agrega algunos gastos generales.

Además, es poco probable que el almacenamiento en caché mejore la latencia de búsqueda a menos que haya patrones en sus consultas. Por el contrario, si el 20% de su tráfico se debe a unas pocas consultas, entonces el caché de resultados de la consulta puede ser interesante. Configurar cachés requiere que conozcas muy bien tus consultas y tus documentos. Si no lo hace, probablemente debería desactivar el almacenamiento en caché.

Incluso si deshabilita todas las memorias caché, el rendimiento podría ser bastante bueno gracias a la memoria caché de E/S del sistema operativo. Prácticamente, esto significa que si lee la misma porción de un archivo una y otra vez, es probable que solo se lea desde el disco la primera vez, y luego desde el caché de E/S. Y deshabilitar todas las memorias caché le permite dar menos memoria a la JVM, de modo que habrá más memoria para la memoria caché de E/S. Si su sistema tiene 12GB de memoria y le da 2GB a la JVM, esto significa que la memoria caché de E/S podría almacenar hasta 10G de su índice (dependiendo de otras aplicaciones en ejecución que requieran memoria también).

os recomiendo que leas esto para obtener más información sobre la memoria caché de nivel de aplicación frente a la caché de E/S:

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

caché campo

El tamaño de la memoria caché de campo para una cadena es (una matriz de enteros de longitud maxDoc) + (una matriz para todas las instancias de cadena únicas). Entonces, si tiene un índice con un campo de cadena que tiene N instancias de tamaño S en promedio, y si su índice tiene M documentos, entonces el tamaño de la memoria caché de campo para este campo será aproximadamente de M * 4 + N * S.

La memoria caché de campo se utiliza principalmente para facetas y clasificación. Incluso cadenas muy cortas (menos de 10 caracteres) are more than 40 bytes, esto significa que debe esperar que Solr requiera mucha memoria si clasifica o faceta en un campo String que tiene un alto número de valores únicos.

consulta difusa

FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.

Depende de la aplicación Corrector ortográfico a elegir, pero creo que el hechizo 3.x corrector Solr utiliza n-gramas para encontrar candidatos (por eso se necesita una índice dedicado) y luego solo calcula las distancias en este conjunto de candidatos, por lo que el rendimiento sigue siendo razonablemente bueno.