¿Debo almacenar en caché los datos o acceder a la base de datos?

No he trabajado con ningún mecanismo de almacenamiento en caché y me preguntaba cuáles son mis opciones en el mundo .net para el siguiente escenario.

Básicamente tenemos un Servicio REST donde el usuario pasa una ID de una Categoría (carpeta de pensamiento) y esta categoría puede tener muchas subcategorías y cada una de las subcategorías podría tener 1000 contenedores de medios (objetos de referencia de archivos de pensamiento) que contienen información sobre un archivo que puede estar en un servidor NAS o SAN (los archivos son videos en este caso). La relación entre estas categorías se almacena en una base de datos junto con algunas reglas de permiso y metadatos sobre las subcategorías.

Entonces, desde la perspectiva de la interfaz de usuario, tenemos un control de árbol cargado lento que es impulsado por el usuario haciendo clic en cada subcarpeta (piense en el explorador de Windows). Una vez que llegan a una URL del archivo de video, pueden ver el video.

El número de usuarios podría crecer hasta los 1000 y las subcategorías y videos podrían estar en los 10000 a medida que el sistema crezca.

La pregunta es ¿deberíamos continuar en la forma en que funciona actualmente donde cada solicitud llega a la base de datos o deberíamos pensar en almacenar en caché los datos?

Estamos usando IIS 6/7 y Asp.net.

Primero, asegúrese de que el código esté particionado de tal manera que su proveedor de datos pueda cambiarse fácilmente. Estamos hablando de segregación de interfaz y los otros principios SÓLIDOS aquí.

A continuación, debe conocer la respuesta a lo siguiente:

1) ¿Cambiarán los datos con frecuencia? 2) ¿La aplicación sondea su servicio REST con frecuencia para obtener estas actualizaciones? 3) ¿Se utiliza la base de datos para otros fines? 4) ¿Conoce algún problema de rendimiento actual? 5) ¿Su aplicación actualiza los datos? ¿Es necesario que esas actualizaciones se reflejen en la aplicación?

Lo interesante es que al usar la base de datos, técnicamente ya está almacenando en caché los datos. Eso es lo que hace una base de datos. Se necesita mucha I + D para hacer que la base de datos sea lo más rápida posible para recuperar datos. Utiliza su propia memoria caché para datos de uso frecuente, por ejemplo.

Entonces, pregúntese qué espera ganar intercambiando proveedores de caché. ¿Y cuáles son las limitaciones actuales que deben abordarse?

Si actualmente no está experimentando ninguna desaceleración, simplemente diría "no, no es necesario cambiar".

Es un tema realmente grande. Los cachés tienden a funcionar realmente bien cuando los datos necesitan ser distribuidos geográficamente, pero hay una gran sobrecarga en términos de administración.

Estoy haciendo un proyecto en el momento en que estoy tomando exactamente el mismo tipo de decisiones.

Mi solución hasta ahora es usar solo la base de datos y acertar con las solicitudes de sondeo de cada cliente. Suena asqueroso, pero se escala (en las pruebas) mucho más de lo que necesito, el código es muy simple.

Dicho esto, mi código usa una especie de patrón de repositorio que abstrae el proveedor de datos de la aplicación principal del código de la base de datos. Si quisiera intercambiar un proveedor de caché como GemFire, requeriría una cantidad muy pequeña de código para hacerlo.

Realmente no hay suficiente información, según los comentarios de Thorbjørn.

El almacenamiento en caché, cuando se hace mal, puede causarle mucho dolor a usted y a sus usuarios. Asegúrese de tener que preocuparse por el almacenamiento en caché antes de complicar demasiado su aplicación.

Entonces, en ausencia de información que indique que realmente necesita almacenar en caché, no almacene en caché.

[Regla general de optimización: si necesita preguntar si debo hacer algo, la respuesta es no] *
* Sería una declaración, no una pregunta, en la mayoría de los lugares donde la respuesta es sí.