Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

DAXet modèles de cohérence DynamoDB

Amazon DynamoDB Accelerator DAX () est un service de mise en cache en écriture directe conçu pour simplifier le processus d'ajout d'un cache aux tables DynamoDB. Étant donné qu'il DAX fonctionne séparément de DynamoDB, il est important que vous compreniez les modèles de cohérence de DynamoDB DAX et de DynamoDB afin de vous assurer que vos applications se comportent comme prévu.

Dans de nombreux cas d'utilisation, la façon dont votre application utilise DAX affecte la cohérence des données au sein du DAX cluster, ainsi que la cohérence des données entre DynamoDB DAX et DynamoDB.

Cohérence entre les nœuds DAX du cluster

Pour garantir la haute disponibilité de votre application, nous vous recommandons de doter votre DAX cluster d'au moins trois nœuds. Puis, placez ces nœuds dans plusieurs zones de disponibilité d'une région.

Lorsque votre DAX cluster est en cours d'exécution, il réplique les données entre tous les nœuds du cluster (en supposant que vous avez provisionné plusieurs nœuds). Prenons l'exemple d'une application qui effectue une UpdateItem utilisation réussieDAX. Cette action entraîne la modification du cache d'éléments du nœud principal avec la nouvelle valeur. Cette valeur est ensuite répliquée sur tous les autres nœuds du cluster. Cette réplication est cohérente à terme et son exécution prend généralement moins d'une seconde.

Dans ce scénario, il est possible que deux clients lisent la même clé depuis le même DAX cluster mais reçoivent des valeurs différentes, en fonction du nœud auquel chaque client a accédé. Les nœuds seront tous cohérents une fois que la mise à jour aura été entièrement répliquée sur tous les nœuds du cluster. (Ce comportement est similaire à celui de la cohérence éventuelle de DynamoDB.)

Si vous créez une application qui utiliseDAX, cette application doit être conçue de manière à pouvoir tolérer à terme des données cohérentes.

DAXcomportement du cache d'éléments

Chaque DAX cluster possède deux caches distincts : un cache d'éléments et un cache de requêtes. Pour de plus amples informations, veuillez consulter DAX : comment ça marche.

Cette section aborde les implications de cohérence liées à la lecture et à l'écriture dans le cache d'DAXéléments.

Cohérence des lectures

Avec DynamoDB, par défaut, l'opération GetItem effectue une lecture éventuellement cohérente. Supposons que vous utilisez UpdateItem avec le client DynamoDB. Si vous tentez de lire le même élément tout de suite après, les données se présenteront peut-être comme avant la mise à jour. Cela est dû au temps nécessaire à la propagation vers tous les emplacements de stockage DynamoDB. La cohérence est généralement atteinte en quelques secondes. Si vous tentez à nouveau de lire, il est probable que vous verrez l'élément mis à jour.

Lorsque vous l'utilisez GetItem avec le DAX client, l'opération (dans ce cas, une lecture cohérente à terme) se déroule comme indiqué ci-dessous.

L'élément reste dans le cache des DAX éléments, sous réserve du paramètre Time to Live (TTL) et de l'algorithme le moins récemment utilisé (LRU) pour le cache. Pour de plus amples informations, veuillez consulter DAX : comment ça marche.

Toutefois, pendant cette période, DAX ne relit pas l'élément depuis DynamoDB. Si quelqu'un d'autre met à jour l'élément à l'aide d'un client DynamoDB, en le DAX contournant complètement, GetItem une demande utilisant DAX le client produit des résultats différents de ceux de la même GetItem demande utilisant le client DynamoDB. Dans ce scénario, DynamoDB conserve DAX les valeurs incohérentes pour la même clé jusqu'à ce que celle de TTL l'élément expire. DAX

Si une application modifie les données d'une table DynamoDB sous-jacente en les DAX contournant, l'application doit anticiper et tolérer les incohérences de données qui pourraient survenir.

Cohérence des écritures

DAXest un cache en écriture directe qui simplifie le processus de cohérence du cache d'DAXéléments avec les tables DynamoDB sous-jacentes.

Le DAX client prend en charge les mêmes API opérations d'écriture que DynamoDB PutItem (UpdateItem,, DeleteItemBatchWriteItem, et). TransactWriteItems Lorsque vous utilisez ces opérations avec le DAX client, les éléments sont modifiés à la fois dans DynamoDB DAX et dans DynamoDB. DAXmet à jour les éléments de son cache d'éléments, quelle que soit la TTL valeur de ces éléments.

Supposons, par exemple, que vous GetItem demandiez au DAX client de lire un élément de la ProductCatalog table. (La clé de partition est Id ; il n'y a pas de clé de tri.) Vous extrayez l'élément dont Id a la valeur 101. La valeur QuantityOnHand de cet élément est 42. DAXstocke l'article dans son cache d'articles avec un élément spécifiqueTTL. Pour cet exemple, supposons que la durée TTL est de 10 minutes. Puis, 3 minutes plus tard, une autre application utilise le DAX client pour mettre à jour le même élément afin que sa QuantityOnHand valeur soit maintenant41. En supposant que l'élément ne soit pas à nouveau mis à jour, les lectures de ce même élément qui se produisent au cours des dix minutes qui suivent retournent la valeur mise en cache deQuantityOnHand (soit 41).

Comment DAX les processus écrivent

DAXest destiné aux applications qui nécessitent des lectures de haute performance. En tant que cache d'écriture directe, DAX transmet vos écritures à DynamoDB de manière synchrone, puis réplique automatiquement et de manière asynchrone les mises à jour qui en résultent dans votre cache d'éléments sur tous les nœuds du cluster. Vous n'avez pas besoin de gérer la logique d'invalidation du cache, car elle s'DAXen charge à votre place.

DAXprend en charge les opérations d'écriture suivantes : PutItem UpdateItemDeleteItem,,BatchWriteItem, etTransactWriteItems.

Lorsque vous envoyez unPutItem, UpdateItemDeleteItem, ou une BatchWriteItem demande àDAX, les événements suivants se produisent :

Lorsque vous envoyez une TransactWriteItems demande àDAX, les événements suivants se produisent :

Si une écriture dans DynamoDB échoue pour une raison quelconque, y compris une limitation, l'élément n'est pas mis en cache. DAX L'exception relative à la défaillance est retournée au demandeur. Cela garantit que les données ne sont pas écrites dans le DAX cache à moins qu'elles ne soient préalablement écrites avec succès dans DynamoDB.

DAXcomportement du cache de requêtes

DAXmet en cache les résultats Query et les Scan demandes dans son cache de requêtes. Cependant, ces résultats n'affectent pas du tout le cache d'élément. Lorsque votre application émet une Scan demande Query ou avecDAX, le jeu de résultats est enregistré dans le cache des requêtes, et non dans le cache des éléments. Vous ne pouvez pas solliciter le cache d'élément en effectuant une opération Scan, car le cache d'élément et le cache de requête sont des entités distinctes.

Cohérence de query-update-query

Les mises à jour du cache d'éléments ou de la table DynamoDB sous-jacente n'ont pas pour effet d'invalider ou de modifier les résultats stockés dans le cache de requêtes.

Pour bien comprendre cette distinction, prenez en compte le scénario suivant. Une application utilise la table DocumentRevisions, qui a DocId comme clé de partition et RevisionNumber comme clé de tri.

Dans ce scénario, le jeu de résultats mis en cache pour l'opération Query émise à l'étape 3 est identique à celui qui a été mis en cache à l'étape 1. La raison en est que cela DAX n'invalide Query pas les ensembles de Scan résultats basés sur les mises à jour apportées à des éléments individuels. L'PutItemopération de l'étape 2 n'est reflétée dans le cache de DAX requêtes que lorsque le TTL for Query expire.

Votre application doit tenir compte de la TTL valeur du cache de requêtes et de la durée pendant laquelle elle peut tolérer des résultats incohérents entre le cache de requêtes et le cache d'éléments.

Lectures transactionnelles à cohérence forte

Pour effectuer une demande GetItem, BatchGetItem, Query ou Scan fortement cohérence, vous devez définir le paramètre ConsistentRead sur true. DAXtransmet des demandes de lecture très cohérentes à DynamoDB. Lorsqu'il reçoit une réponse de DynamoDB, il renvoie les résultats au clientDAX, mais il ne les met pas en cache. DAXne peut pas effectuer des lectures très cohérentes par lui-même car il n'est pas étroitement couplé à DynamoDB. Pour cette raison, toutes les lectures ultérieures DAX devraient finalement être des lectures cohérentes. Et toute lecture fortement cohérente subséquente doit être transmise à DynamoDB.

DAXgère les TransactGetItems requêtes de la même manière qu'il gère les lectures très cohérentes. DAXtransmet toutes les TransactGetItems demandes à DynamoDB. Lorsqu'il reçoit une réponse de DynamoDB, il renvoie les résultats au clientDAX, mais il ne les met pas en cache.

Mise en cache négative

DAXprend en charge les entrées de cache négatives à la fois dans le cache d'éléments et dans le cache de requêtes. Une entrée de cache négative se produit lorsque les éléments demandés DAX ne sont pas trouvés dans une table DynamoDB sous-jacente. Au lieu de générer une erreur, met en DAX cache un résultat vide et le renvoie à l'utilisateur.

Supposons, par exemple, qu'une application envoie une GetItem demande à un DAX cluster et qu'il n'existe aucun élément correspondant dans le cache d'DAXéléments. Cela DAX entraîne la lecture de l'élément correspondant dans la table DynamoDB sous-jacente. Si l'élément n'existe pas dans DynamoDBDAX, stocke un élément vide dans son cache d'éléments et renvoie l'élément vide à l'application. Supposons maintenant que l'application envoie un autre demande GetItem pour le même élément. DAXtrouve l'élément vide dans le cache d'éléments et le renvoie immédiatement à l'application. À aucun moment il ne consulte DynamoDB.

Une entrée de cache négative reste dans le cache d'DAXéléments jusqu'à ce que son élément TTL ait expiré, qu'LRUil soit invoqué ou que l'élément soit modifié à l'aide de PutItemUpdateItem, ouDeleteItem.

Le cache de DAX requêtes gère les résultats négatifs du cache de la même manière. Si une application exécute un Query ou Scan et que le cache de DAX requêtes ne contient aucun résultat mis en cache, DAX envoie la demande à DynamoDB. Si aucun élément ne correspond dans le jeu de résultats, DAX stocke un jeu de résultats vide dans le cache de requêtes et renvoie le jeu de résultats vide à l'application. Les Scan demandes suivantes Query produisent le même jeu de résultats (vide), jusqu'à ce que le jeu de résultats TTL correspondant à ce jeu de résultats ait expiré.

Politiques pour les écritures

Le comportement d'écriture directe de DAX convient à de nombreux modèles d'applications. Toutefois, le modèle d'écriture simultanée peut ne pas convenir à certains modèles d'application.

Pour les applications sensibles à la latence, l'écriture DAX entraîne un saut réseau supplémentaire. Une écriture dans DynamoDB DAX est donc un peu plus lente qu'une écriture directe dans DynamoDB. Si votre application est sensible à la latence d'écriture, vous pouvez réduire celle-ci en écrivant directement dans DynamoDB. Pour de plus amples informations, veuillez consulter Écriture directe.

Pour les applications nécessitant beaucoup d'écriture (telles que celles qui chargent des données en masse), vous ne souhaiterez peut-être pas écrire toutes les données, DAX car seul un faible pourcentage de ces données est lu par l'application. Lorsque vous y écrivez de grandes quantités de donnéesDAX, il doit invoquer son LRU algorithme pour libérer de la place dans le cache pour la lecture des nouveaux éléments. Cela réduit l'efficacité du cache DAX de lecture.

Lorsque vous écrivez un élément dansDAX, l'état du cache d'éléments est modifié pour s'adapter au nouvel élément. (Par exemple, il DAX peut être nécessaire d'expulser les anciennes données du cache d'éléments pour faire de la place au nouvel élément.) Le nouvel élément reste dans le cache d'éléments, sous réserve de l'LRUalgorithme du cache et des TTL paramètres du cache. Tant que l'élément persiste dans le cache d'éléments, DAX il n'est pas relu depuis DynamoDB.

Écriture simultanée

Le cache DAX d'éléments met en œuvre une politique d'écriture directe. Pour de plus amples informations, veuillez consulter Comment DAX les processus écrivent.

Lorsque vous écrivez un élément, assurez-vous que DAX l'élément mis en cache est synchronisé avec l'élément tel qu'il existe dans DynamoDB. Cela est utile pour les applications qui ont besoin de relire un élément de suite après l'avoir écrit. Toutefois, si d'autres applications écrivent directement dans DAX une table DynamoDB, l'élément du cache d'éléments n'est plus synchronisé avec DynamoDB.

Pour illustrer cela, prenons l'exemple de deux utilisateurs (Alice et Bob) qui utilisent la tableProductCatalog. Alice accède à la table en utilisantDAX, mais Bob la contourne DAX et y accède directement dans DynamoDB.

Dans ce scénario, Alice et Bob voient des représentations différentes du même élément ProductCatalog. C'est le cas jusqu'à ce que l'élément soit DAX expulsé du cache d'éléments ou jusqu'à ce qu'un autre utilisateur mette à jour à nouveau le même élément en utilisant. DAX

Écriture directe

Si votre application doit écrire de grandes quantités de données (par exemple lors d'un chargement de données en masse), il peut être judicieux de les contourner DAX et de les écrire directement dans DynamoDB. Une telle stratégie d'écriture non allouée réduit la latence d'écriture. Cependant, le cache d'éléments ne reste pas synchronisé avec les données dans DynamoDB.

Si vous décidez d'utiliser une stratégie d'annulation, n'oubliez pas qu'elle DAX remplit son cache d'éléments chaque fois que les applications utilisent le DAX client pour lire des données. Dans certains cas, vous pouvez en tirer des avantages, car seules les données les plus fréquemment lues sont mises à en cache (et non les données les plus fréquemment écrites).

Prenons l'exemple d'un utilisateur (Charlie) qui souhaite travailler avec une autre table, la GameScores table, en utilisantDAX. Sachant que la clé de partition de GameScores est UserId, tous les scores de Charlie ont le même UserId.

DAXn'actualise pas les ensembles de résultats dans le cache de requêtes avec les données les plus récentes de DynamoDB. Chaque jeu de résultats du cache de requête correspond au moment où l'opération Query ou Scan a été effectuée. Par conséquent, les résultats de l'opération Query de Charlie ne reflètent pas son opération PutItem. C'est le cas jusqu'à ce que DAX le jeu de résultats soit expulsé du cache de requêtes.