Comportamiento de escritura en caché

Esta guía describe una caché de lectura completa en la que los elementos se almacenan en caché la primera vez que se leen. Una caché de escritura completa introduciría entradas en la memoria caché durante la operación de escritura, pero en esta guía no se sugiere hacerlo por dos motivos:

• Cuando se escribe un elemento, no hay indicios de que vaya a leerse pronto, y es un desperdicio escribir entradas en la caché que no se utilizan.

• Un elemento que está en caché puede guardarse en caché varias veces con diferentes claves de firma. Por ejemplo, diferentes expresiones de proyección dan como resultado entradas de caché diferentes. Por lo tanto, no está claro con qué clave de firma debes almacenar la entrada antes de recibir una solicitud. Podría considerarse más elegante almacenar en caché el elemento solo una vez en su totalidad y, si la solicitud especifica un ProjectionExpression parámetro, aplicar la proyección en tiempo real dentro del contenedor de almacenamiento en caché. Lamentablemente, esto añade una complejidad significativa porque requiere implementar una gramática no ProjectionExpression trivial. Es más fácil mantener el contenedor de almacenamiento en caché muy simple para que solo almacene en caché las solicitudes que se hayan realizado anteriormente y trate de evitar inventar una nueva respuesta en la medida de lo posible. Deje que la base de datos sea el único lugar en el que se interprete unaProjectionExpression. Esto elimina un modelo de caché fácil de escribir.

Sin embargo, las operaciones de escritura pueden ser inteligentes y pueden invalidar de forma proactiva cualquier entrada de la caché de elementos almacenada anteriormente que sea relevante para el elemento escrito. Esto mantiene la caché de elementos actualizada sin tener que esperar a que caduque el TTL. La entrada de la caché se rellena en la siguiente lectura.

nota

Una ventaja clave de esta integración de DynamoDB, en comparación con una integración de caché de base de datos relacional de diseño similar, es que cada escritura en DynamoDB siempre especifica las claves principales de los elementos que se están escribiendo. Una memoria caché de lectura completa puede controlar las llamadas de escritura e invalidar la caché de elementos de forma exacta e inmediata. Cuando se utiliza una base de datos relacional, una UPDATE sentencia no identifica los elementos que podrían verse afectados y no existe una forma pasiva de invalidar las entradas de fila almacenadas en caché que no sea mediante TTL.

Las llamadas de escritura implementan este flujo lógico:

• Realice la operación de escritura en la base de datos.

• Si la operación se realiza correctamente, extraiga la tabla y las claves principales para la escritura.

• Invalide cualquier entrada de la caché de elementos que sea relevante para las claves principales.

Se requiere un poco de limpieza para que este último paso sea posible. Las entradas de la caché de elementos se almacenan bajo el hash de su firma, por lo que es necesario saber qué claves invalidar. Para ello, mantenga en la caché un mapeo entre las claves principales de los elementos y la lista de firmas almacenadas asociadas a esa clave principal. Es esa lista de elementos la que debe invalidarse.

Esta es la tabla anterior:

Pseudocódigo	ElastiCache cálculo clave	ElastiCache valor
get_item(t1, k1, p1)	hash('get', t1, k1, p1) = 0xad4c812a	{ 'Item': … }
get_item(t1, k1, p2)	hash('get', t1, k2, p2) = 0x045deaab	{ 'Item': … }
get_item(t1, k2, p1)	hash('get', t1, k2, p1) = 0x9cda78af	{ 'Item': … }

Y la tabla de limpieza anterior:

Operación	ElastiCache cálculo clave	ElastiCache valor
Realice un seguimiento de la lista de entradas para la tablat1, clave k1	hash('list', t1, k1)	( 0xad4c812a, 0x045deaab )
Realice un seguimiento de la lista de entradas por tablat1, clave k2	hash('list', t1, k2)	( 0x9cda78af )

Supongamos que hay una operación de escritura en la tabla t1 y que el elemento tiene la clave principalk1. El siguiente paso es invalidar las entradas que son relevantes para ese elemento.

Esta es la lógica completa:

• Realice la operación de escritura en la base de datos.

• Si la operación se realiza correctamente, extraiga la tabla y la clave principal para la escritura.

• Extraiga de la memoria caché la lista de firmas hash almacenadas que están asociadas a esa clave principal.

• Invalide esas entradas de la caché de elementos.

• Elimine la lista de limpieza de esa clave principal.

Sería fantástico tener una forma de invalidar de forma proactiva las entradas de la caché de consultas como parte de las operaciones de escritura de elementos. Sin embargo, inventar un diseño para esto es extremadamente difícil porque es casi imposible determinar, de manera eficiente y confiable, qué resultados de consultas en caché se verían afectados por un elemento actualizado. Por este motivo, las entradas de la caché de consultas no tienen mejor opción que caducar mediante la configuración de TTL.