Arquitectura de software: ¿Qué datos deben y no deben almacenarse en caché?

Datos que son algo invariables / que cambian lentamente y que a la vez son costosos de procesamiento (uso intensivo de la CPU) o del tiempo (latencia larga) para obtener de la fuente.

El almacenamiento en caché de los datos procesados ​​de la página web es un elemento típico para el procesamiento del servicio web de fondo.

Los nombres de usuario, los metadatos de usuario asociados, la información de perfil de usuario a la que normalmente se accede desde una base de datos distribuida es otro candidato.

Los cachés menos usados ​​recientemente (LRU) son buenos y fáciles de usar en el espacio de memoria local.

Memcached escala bien para grandes cachés compartidos en un entorno de procesamiento distribuido.

La creación de perfiles bajo carga se utiliza para identificar estructuras de datos para almacenar en caché. Básicamente, está buscando largos tiempos de espera, altas cargas de bases de datos y cargas de CPU procesando datos (uno puede almacenar en caché los datos procesados).

Luego, se debe determinar si el caché es local (mismo espacio de memoria, limitado en tamaño y más rápido) o distribuido (por ejemplo, Memcached, límites de memoria escalables, más lento con sobrecarga de E / S adicional involucrada en el transporte de datos de máquina a máquina, permite que las sesiones se muevan de máquina a máquina con una penalización mínima ya que los datos en caché no son locales para ninguna máquina específica).

Esto implica determinar exactamente cuántos elementos deben almacenarse en caché y cuál es el tamaño promedio de cada elemento.

Depende de lo que entiendas por caché.

Las memorias caché potencialmente obsoletas de estilo antiguo que dependían de cosas como los tiempos de espera de la memoria caché definitivamente se prestan para datos que rara vez cambian, como indican las otras respuestas.

Los cachés más inteligentes en realidad obtienen mayores ganancias en datos intensivos en escritura. Considere algunos ejemplos:

  • Cachés de CPU: al implementar protocolos de coherencia (por ejemplo, MOESI), los cachés de CPU mitigan el costo de los accesos y actualizaciones de DRAM, fusionando múltiples actualizaciones en una única actualización de línea de caché (por ejemplo, 64 bytes a la vez).
  • Cachés de aplicaciones: al alimentarse de las actualizaciones transaccionales de la base de datos (p. Ej., Utilizando un producto como GoldenGate), un caché puede mantener los datos en la memoria que están siendo cambiados por cualquier número de sistemas dispares y mantener esos datos sincronizados (p. Ej., Ver Oracle Coherence) a través de múltiples servidores, y uniendo múltiples transacciones en memoria, es posible no solo almacenar en caché los datos que están cambiando miles de veces por segundo, sino también aumentar drásticamente el rendimiento al hacerlo.

En aras de la divulgación completa, trabajo en Oracle. Las opiniones y opiniones expresadas en esta publicación son mías y no reflejan necesariamente las opiniones u opiniones de mi empleador.

Cualquier cosa relacionada con la seguridad y / o datos en tiempo real no debe almacenarse en caché.

Una forma de averiguar si hay datos específicos para almacenar en caché es perfilar un sistema bajo carga y ver dónde están los cuellos de botella. Esto es especialmente cierto para Enterprise Architecture cuando el software bajo prueba es “pegamento” que se integra con diferentes sistemas con diferentes características.

Como regla general, los datos deben almacenarse en caché cuando no se cambian con frecuencia sino que se leen con frecuencia.