Almacenamiento en memoria caché de Solr con EHCache/BigMemory

Question

Estamos implementando una configuración de Lucene/Solr grande con documentos que superan los 150 millones. También tendremos una cantidad moderada de actualizaciones de documentos todos los días.

Mi pregunta es realmente un dos parte:

¿Cuáles son las implicaciones de utilizar otra aplicación de almacenamiento en caché dentro de Solr, es decir EHCache en lugar de la nativa Solr LRUCache/FastLRUCache?

Terracotta ha anunciado BigMemory que debe utilizarse junto con EHCache como un caché de almacenamiento dinámico fuera de proceso. Según TC, esto le permite almacenar grandes cantidades de datos sin la sobrecarga de GC de la JVM. ¿Es esta una buena idea para usar con Solr? ¿Realmente ayudará?

I would esp. me gusta escuchar a gente con experiencia en producción real con EHCache/BigMemory y/o Solr Cache tuning.

Answer 1

No estoy seguro de que alguien haya intentado esto todavía. Ciertamente nos encantaría asociarnos con los chicos de Solr para descubrir qué tan útil sería esto. Incluso podríamos ser capaces de optimizarlo para el caso de uso.

Answer 2

Muchas ideas sobre este tema. Aunque mi respuesta no aprovecha EhCache de ninguna manera.

En primer lugar, no creo que los documentos se deben almacenar en su índice de búsqueda. El contenido de búsqueda debe almacenarse allí, no el documento completo. Lo que quiero decir con esto es que lo que devuelve tu consulta de búsqueda debe ser documentos ID. No el contenido de los documentos en sí. Los documentos en sí mismos deberían almacenarse y recuperarse de un segundo sistema, probablemente el archivo original desde el que están indexados para comenzar. Esto reducirá el tamaño del índice, disminuirá el tamaño de la memoria caché del documento, disminuirá el tiempo de replicación del esclavo maestro (esto puede convertirse en un cuello de botella si se actualiza con frecuencia) y disminuirá la sobrecarga al escribir las respuestas de búsqueda.

A continuación, considere poner un proxy HTTP inverso delante de Solr. Aunque las cachés de consulta permiten que Solr responda rápidamente, un caché como Varnish sentado frente a Solr es incluso más rápido. Esto descarga Solr, lo que le permite dedicar tiempo a responder consultas que no ha visto antes. El segundo efecto es que ahora puede lanzar la mayor parte de su memoria en cachés de documentos en lugar de cachés de consultas. Si siguió mi primera sugerencia, sus documentos serán increíblemente pequeños, lo que le permitirá conservar la mayoría, si no todos, en la memoria.

Recuperación rápida del cálculo del sobre para tamaños de documentos. Puedo proporcionar fácilmente un int de 32 bits como ID para 150 millones de documentos. Todavía tengo 10x margen para el crecimiento de documentos. 150 millones de ID toman 600 MB. Agregue un factor de desenfoque para los documentos de envoltura de Solr, y probablemente pueda almacenar fácilmente todos sus documentos Solr en caché de 1 a 2 GB. Considerar obtener 12GB-24GB o RAM es fácil hoy en día, y yo diría que puedes hacer esto todo en una caja y obtener un rendimiento increíble. No hay necesidad de nada extraño como EhCache. Solo asegúrese de usar su índice de búsqueda lo más eficientemente posible.

En cuanto a GC: No vi mucho tiempo de GC en mis servidores de Solr. La mayoría de lo que se debía recopilar era el de los objetos de muy corta vida que participan en el ciclo de solicitud y respuesta HTTP, que nunca sale del espacio de eden. Las memorias caché no tenían alta rotación cuando se sintonizaban correctamente. Los únicos grandes cambios se produjeron cuando se cargó un nuevo índice y se calaron los cachés, pero eso no sucedía constantemente.

EDITAR: Para el fondo, pasé un tiempo considerable ajustando el almacenamiento en caché Solr para una gran compañía que vende consolas y sirve millones de búsquedas por día desde sus servidores Solr.