Comportement d'écriture en cache

Ce guide décrit un cache à lecture directe dans lequel les éléments sont mis en cache lors de la première lecture. Un cache à écriture directe enverrait des entrées dans le cache pendant l'opération d'écriture, mais ce guide ne suggère pas de le faire pour deux raisons :

• Lorsqu'un élément est écrit, rien n'indique qu'il sera bientôt lu, et il est inutile d'écrire des entrées de cache qui ne sont pas utilisées.

• Un élément mis en cache peut être mis en cache plusieurs fois sous différentes clés de signature. Par exemple, différentes expressions de projection génèrent des entrées de cache différentes. Par conséquent, il n'est pas clair sous quelle clé de signature vous devez stocker l'entrée avant qu'une demande n'arrive. Il peut être plus élégant de ne mettre en cache l'élément qu'une seule fois dans son intégralité et, si la demande spécifie un ProjectionExpression paramètre, d'appliquer la projection en direct dans le wrapper de mise en cache. Malheureusement, cela ajoute une complexité significative car cela nécessite l'implémentation d'une grammaire non trivialeProjectionExpression. Il est plus facile de garder le wrapper de mise en cache très simple afin qu'il ne mette en cache que les requêtes qui se sont produites précédemment, et d'essayer d'éviter autant que possible d'inventer une nouvelle réponse. Laissez la base de données être le seul endroit où ProjectionExpression un est interprété. Cela élimine un modèle de cache à écriture directe facile.

Cependant, les opérations d'écriture peuvent être intelligentes et elles peuvent invalider de manière proactive toutes les entrées du cache d'éléments stockées précédemment qui sont pertinentes pour l'élément écrit. Cela permet de maintenir le cache des articles à jour sans avoir à attendre l'expiration du TTL. L'entrée du cache est reremplie lors de la lecture suivante.

Note

L'un des principaux avantages de cette intégration DynamoDB, par rapport à une intégration de cache de base de données relationnelle conçue de manière similaire, est que chaque écriture dans DynamoDB indique toujours les clés primaires des éléments en cours d'écriture. Un cache à lecture directe peut surveiller les appels d'écriture et effectuer une invalidation exacte et immédiate du cache d'éléments. Lorsque vous utilisez une base de données relationnelle, aucune UPDATE instruction n'identifie les éléments susceptibles d'être affectés, et il n'existe aucun moyen passif d'invalider les entrées de ligne mises en cache autrement que par le biais du protocole TTL.

Les appels d'écriture implémentent ce flux logique :

• Effectuez l'opération d'écriture sur la base de données.

• Si l'opération est réussie, extrayez la table et les clés primaires pour l'écriture.

• Invalidez toutes les entrées du cache d'éléments pertinentes pour les clés primaires.

Un peu de ménage est nécessaire pour rendre cette dernière étape possible. Les entrées du cache des éléments sont stockées sous le hachage de leur signature. Il est donc nécessaire de savoir quelles clés invalider. Vous pouvez le faire en conservant dans le cache un mappage entre les clés primaires des éléments et la liste des signatures stockées associées à cette clé primaire. C'est cette liste d'éléments qui doit être invalidée.

Voici le tableau précédent :

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': … }

Et la table de ménage précédente :

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

Supposons qu'il existe une opération d'écriture sur la table t1 et que l'élément possède la clé primairek1. L'étape suivante consiste à invalider les entrées relatives à cet élément.

Voici la logique complète :

• Effectuez l'opération d'écriture sur la base de données.

• Si l'opération est réussie, extrayez la table et la clé primaire pour l'écriture.

• Extrayez du cache la liste des signatures de hachage stockées associées à cette clé primaire.

• Invalidez ces entrées du cache d'éléments.

• Supprimez la liste de gestion de cette clé primaire.

Ce serait fantastique d'avoir un moyen d'invalider de manière proactive les entrées du cache de requêtes dans le cadre des opérations d'écriture d'éléments. Cependant, il est extrêmement difficile d'inventer une conception pour cela, car il est presque impossible de déterminer, de manière efficace et fiable, quels résultats de requête mis en cache seraient affectés par un élément mis à jour. Pour cette raison, il n'y a pas de meilleure option pour les entrées du cache de requêtes que d'expirer via les paramètres TTL.