Comportamiento de lectura en caché

El ajuste solo debería almacenar en caché las llamadas de lectura coherentes que eventualmente se realicen a DynamoDB. Esto incluye get_item, batch_get_item, query y scan. No debe almacenar en caché las llamadas de lectura muy coherentes ni las llamadas de lectura transaccionales, ya que esas llamadas no quieren ver una versión de los datos almacenada en caché.

Las entradas de la caché deben comprender la firma de la solicitud para identificar las solicitudes sucesivas o equivalentes. La firma de cada llamada consta de todos los parámetros de la solicitud que afectan al resultado. En el caso de una get_item llamada, la firma incluye los ExpressionAttributeNames parámetros TableName KeyProjectionExpression,, y. En el caso de una llamada de consulta TableNameIndexName, incluye los Limit parámetros KeyConditionsFilterExpression,ScanIndexForward,, y. Si dos llamadas a la misma función tienen la misma firma, es posible que se produzca un impacto en la memoria caché.

Este es un ejemplo de flujo lógico para una get_item llamada:

Por ejemplo, supongamos que tiene este código:

cache_client.get_item(
  TableName='test',
  Key={ 'PK': { 'S': '123' } },
  ProjectionExpression='#attr1, #attr2',
  ExpressionAttributeNames={
    '#attr1': 'agent',
    '#attr2': 'count'
  },
  ConsistentRead=False
)

En el interiorcache_client, el código calcula la firma hash de la llamada. La firma se obtiene al aplicar un hash a la concatenación de los parámetrosTableName,Key, ProjectionExpression y. ExpressionAttributeNames Se puede usar cualquier sistema hash siempre que sea determinista y produzca un único valor de cadena. En este caso, supongamos que el hash se reduce a. 0xad4c812a Este hash identifica este conjunto de parámetros.

¿Qué pasa si se hace otra llamada igual, excepto que #attr1 se cambia el nombre#attribute1? ¿Debe considerarse que esa llamada tiene la misma firma? Lo ideal sería que sí, porque es semánticamente idéntico, pero la sobrecarga de averiguar la equivalencia semántica en todas y cada una de las llamadas simplemente no es práctica. Es mucho más rápido codificar los valores de los parámetros a ciegas y se requieren coincidencias exactas. La regla es la siguiente: las llamadas son aptas para recibir visitas a la memoria caché si en realidad son la misma llamada, pero no si son básicamente la misma llamada.

En su interiorcache_client, el código ElastiCache busca una entrada en la caché de elementos en la que está almacenada0xad4c812a. Si la entrada existe, se trata de un error de caché. Si no es así, el valor se obtiene de la base de datos y se guarda en ella ElastiCache para una consulta posterior en la memoria caché.

Así es como se ve la caché para tres get_item llamadas que tienen tres conjuntos diferentes de parámetros de tabla, clave y proyección.

Otras llamadas, como query yscan, funcionan de la misma manera, pero sus firmas se componen de parámetros diferentes.

Este diseño puede recordarte cómo funciona un proxy de almacenamiento en caché HTTP. Si vuelve a ver la misma solicitud, puede devolver la respuesta de la solicitud anterior. La definición de la misma solicitud en HTTP se basa principalmente en la cadena de consulta. Con DynamoDB, el tipo de llamada y el conjunto de parámetros que se pasan a la función influyen en sus resultados.

Hay un paso más. Para el almacenamiento en caché de elementos, es importante mantener un mapeo entre la clave principal de cada elemento y la lista de hashes que se utilizan activamente para almacenar en caché ese elemento. Esto entrará en juego durante las operaciones de escritura, tal y como se describe en la siguiente sección. Por lo tanto, además de las claves y valores anteriores, habrá entradas de caché adicionales como las siguientes: