Comportement de lecture du cache

Le shim ne doit mettre en cache que les appels de lecture finalement cohérents effectués vers DynamoDB. Cela inclut get_item, batch_get_item, query et scan. Il ne doit pas mettre en cache les appels de lecture fortement cohérents ou les appels de lecture transactionnels, car ces appels ne veulent pas nécessairement voir une version mise en cache des données.

Les entrées du cache doivent comprendre la signature de la demande afin d'identifier les demandes équivalentes ultérieures. La signature de chaque appel comprend tous les paramètres de la demande qui affectent le résultat. Pour un get_item appel, la signature inclut les ExpressionAttributeNames paramètres TableName KeyProjectionExpression,, et. Pour un appel de requête, il inclut les Limit paramètres TableName IndexNameKeyConditions,FilterExpression,ScanIndexForward,, et. Si deux appels à la même fonction ont la même signature, il est possible que le cache soit atteint.

Voici un exemple de flux logique pour un get_item appel :

• Vérifiez siConsistentRead=true. Dans ce cas, appelez directement la base de données et renvoyez le résultat. Les appels très cohérents ne doivent pas utiliser de cache.

• Calculez la signature de l'appel. Hachez ensemble les ExpressionAttributeNames paramètresTableName, KeyProjectionExpression, et pour obtenir une valeur de signature de chaîne unique.

• Vérifiez si une entrée de cache existe avec cette clé de signature. Si c'est le cas, il s'agit d'un accès au cache, alors renvoyez-le.

• Dans le cas contraire, passez l'appel à la base de données, récupérez le résultat, renseignez l'entrée de cache pour cette signature et renvoyez le résultat. Lorsque vous stockez l'article, spécifiez une date d'expiration (TTL).

Supposons, par exemple, que vous disposiez du code suivant :

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

À l'intérieurcache_client, le code calcule la signature de hachage de l'appel. La signature est dérivée du hachage de la concaténation des paramètresTableName,Key, ProjectionExpression et. ExpressionAttributeNames N'importe quel système de hachage peut être utilisé tant qu'il est déterministe et qu'il produit une valeur de chaîne unique. Dans ce cas, supposons qu'il soit réduit à0xad4c812a. Ce hachage identifie cet ensemble de paramètres.

Et si un autre appel identique est passé, sauf qu'il #attr1 est renommé #attribute1 ? Cet appel doit-il être considéré comme portant la même signature ? Idéalement, oui, parce que c'est sémantiquement identique, mais la surcharge liée à la détermination de l'équivalence sémantique pour chaque appel n'est tout simplement pas pratique. Il est beaucoup plus rapide de hacher les valeurs des paramètres à l'aveugle et d'exiger des correspondances exactes. La règle est la suivante : les appels sont éligibles à un accès au cache s'il s'agit en fait du même appel, mais pas s'il s'agit essentiellement du même appel.

À l'intérieurcache_client, le code recherche ensuite une entrée dans le cache d'éléments qui est stockée sous0xad4c812a. ElastiCache Si l'entrée existe, il s'agit d'un accès au cache. Dans le cas contraire, la valeur est extraite de la base de données et stockée dans le cache ElastiCache pour un accès ultérieur au cache.

Voici à quoi ressemble le cache pour trois get_item appels comportant trois ensembles différents de paramètres de table, de clé et de projection.

Pseudocode	ElastiCache calcul clé	ElastiCache valeur
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': … }

D'autres appels, tels que query etscan, fonctionnent de la même manière, mais des paramètres différents constituent leur signature.

Cette conception peut vous rappeler le fonctionnement d'un proxy de mise en cache HTTP. S'il voit à nouveau la même demande, il peut renvoyer la réponse de la demande précédente. La définition d'une même requête en HTTP repose principalement sur la chaîne de requête. Avec DynamoDB, le type d'appel et l'ensemble de paramètres transmis à la fonction influencent ses résultats.

Il reste encore une étape. Pour la mise en cache des éléments, il est important de maintenir un mappage entre la clé primaire de chaque élément et la liste des hachages utilisés activement pour mettre en cache cet élément. Cela entrera en jeu lors des opérations d'écriture, comme décrit dans la section suivante. Ainsi, en plus des clés et valeurs précédentes, il y aura des entrées de cache supplémentaires telles que celles-ci :

Opération	ElastiCache calcul clé	ElastiCache valeur
Suivre la liste des entrées pour le tableaut1, la clé k1	hash('list', t1, k1)	( 0xad4c812a, 0x045deaab )
Suivre la liste des entrées pour le tableaut1, la clé k2	hash('list', t1, k2)	( 0x9cda78af )