Arquitectura de almacenamiento en caché para resultados de búsqueda en una aplicación ASP.NET

Question

¿Qué es un buen diseño para almacenar en caché los resultados de una búsqueda costosa en un sistema ASP.NET?

Cualquier idea sería bienvenida ... especialmente aquellas que no requieren inventar una infraestructura compleja propia.

Éstos son algunos de los requisitos generales relacionados con el problema:

• cada resultado de búsqueda puede producir incluir de cero a varios cientos de registros de resultados
• Cada búsqueda es relativamente caro y requiere mucho tiempo para ejecutar (5-15 segundos en la base de datos)
• Los resultados se deben paginar antes de mostrarse en el cliente para evitar la sobrecarga de información para el usuario
• Los usuarios esperan poder ordenar, filtrar y buscar dentro de los resultados devueltos
• Los usuarios esperan a ser capaz de cambiar rápidamente entre páginas en los resultados de búsqueda
• Los usuarios esperan para ser capaz de seleccionar varios elementos (a través de la casilla de verificación) en cualquier número de páginas
• Usuarios esperar un rendimiento relativamente rápido una vez a la búsqueda tiene terminé

veo algunas posibles opciones para dónde y cómo implementar el almacenamiento en caché:

1. caché en el servidor (en sesión o caché de la aplicación), utilizar las devoluciones de datos o paneles de Ajax para facilitar la paginación eficiente, clasificación , filteri ng y buscando.

• PROS: Fácil de implementar, apoyar decente desde la infraestructura ASP.NET
• CONS: Muy hablador, que requieren mucha memoria en el servidor, los datos se pueden almacenar en caché más de lo necesario; prohíbe las prácticas de balanceo de carga

2. caché en el servidor (como el anterior) pero utilizando estructuras serializeable que se mueven fuera de la memoria después de un periodo de tiempo para reducir la presión de memoria en el servidor

• PROS: Uso eficiente de la memoria del servidor; capacidad de escalar utilizando equilibrio de carga;
• CONS: Soporte limitado de la infraestructura .NET; potencialmente frágil cuando las estructuras de datos cambian; coloca carga adicional en la base de datos; significativamente más complicado

3. caché en el cliente (utilizando la serialización JSON o XML), el uso del lado del cliente Javascript para paginar, ordenar, filtrar y seleccionar resultados.

• PROS: La experiencia del usuario puede acercarse a los niveles de "cliente enriquecido"; la mayoría de los navegadores pueden manejar JSON/XML de forma nativa: existen bibliotecas decentes para la manipulación (por ejemplo, jQuery)
• CONS: la solicitud inicial puede tardar mucho tiempo en descargarse; huella de memoria significativa en las máquinas del cliente; requerirá Javascript hechos a mano en un cierto nivel para implementar

4. caché en el cliente utilizando una representación comprimida/codificado de los datos - llamar de nuevo en el servidor para decodificar cuando se cambia de páginas, ordenar, filtrar y buscar .

• PROS: Impacto Máximo ahorro de memoria en el servidor; permite que el estado viva mientras el cliente lo necesite; uso de memoria ligeramente mejorado en el cliente a través de JSON/XML
• CONS: grandes conjuntos de datos que se mueven hacia adelante y hacia atrás entre el cliente/servidor; un rendimiento más lento (debido a la E/S de red) en comparación con el almacenamiento en caché puro del lado del cliente utilizando JSON/XML; mucho más complicado de implementar - un apoyo limitado de .NET/navegador

5. Algunos esquema de caché alternativa no he considerado ...

Answer 1

Para # 1, ¿ha considerado el uso de un servidor de estado (incluso SQL Server) o un mecanismo de caché compartida? Hay plenty de goodones a choose de, y Velocity se está poniendo muy maduro - probablemente RTM pronto. Un esquema de invalidación de caché que se basa en si el usuario crea una nueva búsqueda, accede a cualquier otra página además de la paginación de búsqueda, y finalmente un tiempo de espera estándar (20 minutos) debería ser bastante exitoso para eliminar su caché a un tamaño mínimo.

Referencias:

• SharedCache (FOSS)
• NCache ($995/CPU)
• StateServer (~$1200/server)
• StateMirror ("Enterprise pricing")
• Velocity (Free?)

Answer 2

Ya que dicen que todas las ideas son bienvenidas:

Hemos estado utilizando la biblioteca de almacenamiento en caché de la empresa con bastante éxito para el almacenamiento en caché de los conjuntos de resultados resultado LINQ.

http://msdn.microsoft.com/en-us/library/cc467894.aspx

Soporta caducidad de la caché personalizada, por lo que deben apoyar la mayor parte de sus necesidades (con un poco de código personalizado) allí. También cuenta con bastantes tiendas de respaldo, incluidas tiendas de respaldo encriptadas, si la privacidad de las búsquedas es importante.

Es bastante completo.

Mi recomendación es una combinación de # 1 y # 3:

1. caché de los resultados de la consulta en el servidor.
2. Haga que los resultados estén disponibles tanto en una página completa como en una vista JSON.
3. Guarde en caché cada página recuperada dinámicamente en el cliente, pero envíe una PETICIÓN cada vez que la página cambie.
4. Utilice ETAG para invalidar la caché del cliente.

Answer 3

Eche un vistazo a SharedCache - hace 1/2 bastante fácil y funciona bien en un sistema de carga equilibrada. Gratis, de código abierto, y lo hemos estado utilizando durante aproximadamente un año sin problemas.

Answer 4

Generando una idea bajo el esquema de almacenamiento en caché "alternativo". Esto no responde a su pregunta con una arquitectura de caché determinada, sino que vuelve a sus requisitos originales de su aplicación de búsqueda.

Incluso cuando implementa su propia memoria caché, su eficacia puede ser inferior a la óptima, especialmente a medida que su índice de búsqueda aumenta de tamaño. Las tasas de aciertos de caché disminuirán a medida que su índice crezca. En un determinado punto de inflexión, es posible que la búsqueda se ralentice debido a los recursos dedicados tanto a la búsqueda como al almacenamiento en caché.

La mayoría de los subsistemas de búsqueda implementan su propia arquitectura interna de caché como un medio de eficiencia en la operación. Solr, un sistema de búsqueda de código abierto construido en Lucene, mantiene su propia memoria caché interna para proporcionar una operación rápida. Existen otros sistemas de búsqueda que funcionarían para usted, y toman estrategias similares al almacenamiento en caché de resultados.

Le recomendaría que considere una arquitectura de búsqueda independiente si su índice de búsqueda lo justifica, ya que el almacenamiento en caché en una base de búsqueda por palabra clave es una operación compleja para implementar de manera efectiva.

Answer 5

Si puede esperar hasta marzo de 2010, .NET 4.0 viene con un nuevo System.Caching.CacheProvider, que promete muchas implementaciones (disco, memoria, SQL Server/Velocity como se mencionó).

Hay una buena presentación de diapositivas de la tecnología here. Sin embargo, es un poco "roll your own" o mucho de hecho. Pero probablemente se escriban muchos proveedores de código abierto y abierto para el modelo de Proveedor cuando se publique el marco.

Para los seis puntos que Estado, algunas preguntas surge

• Lo que está contenido en los resultados de búsqueda? ¿Simplemente encadenar datos o una gran cantidad de metadatos asociados con cada resultado?
• ¿Qué tan grande es el conjunto que está buscando?

¿Cuánta memoria usaría para almacenar todo el conjunto en la RAM? O al menos tener un caché de los 10 a 100 términos de búsqueda más populares. También ser inteligente y almacenar en caché las búsquedas relacionadas después de la primera búsqueda podría ser otra idea.

5-15 segundos para obtener un resultado es mucho tiempo para esperar una búsqueda, por lo que supongo que es algo parecido a una búsqueda de expedia.com donde se solicitan múltiples fuentes y se devuelve mucha información.

Desde mi experiencia limitada, el mayor problema con el lado del cliente almacenamiento en caché sólo se enfoque es Internet Explorer 6 or 7. Solo servidor y HTML es mi preferencia con todo el conjunto de resultados en la caché para paginación, caduca después de un período de tiempo razonable. Pero es posible que ya hayas probado esto y hayas visto que se ha comido la memoria del servidor.

Answer 6

Mientras analizaba sus opciones, tenga en cuenta que ningún usuario desea desplazarse por los datos. Impulsamos eso sobre ellos como un artefacto de tratar de construir aplicaciones sobre los navegadores en HTML, que intrínsecamente no se escalan bien. Hemos inventado todo tipo de hackers para falsificar el estado de la aplicación además de esto, pero es esencialmente un modelo roto.

Así que, por favor, considere implementar esto como un cliente real rica en Silverlight o Flash. No superarás esa experiencia de usuario, y es fácil guardar en caché datos mucho más grandes de lo que es práctico en una página web normal. Dependiendo del comportamiento esperado del usuario, su ancho de banda general podría optimizarse porque los viajes redondos al servidor obtendrán solo un ajustado conjunto de datos en lugar de cualquier sobrecarga de ASP.NET.