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.
Configuration de votre DAX cluster
Le DAX cluster est un cluster géré, mais vous pouvez ajuster ses configurations en fonction des exigences de votre application. En raison de son intégration étroite avec les opérations API DynamoDB, vous devez prendre en compte les aspects suivants lors de l'intégration de votre application. DAX
Dans cette section
DAXtarification
Le coût d'un cluster dépend du nombre et de la taille des nœuds qu'il a provisionnés. Chaque nœud est facturé pour chaque heure d'exécution dans le cluster. Pour plus d'informations, consultez Tarification Amazon DynamoDB
Les accès au cache n'entraînent aucun coût pour DynamoDB, mais ont un impact sur les ressources du cluster. DAX Les erreurs de cache entraînent des coûts de lecture dans DynamoDB et nécessitent des ressources. DAX Les écritures entraînent des coûts d'écriture DynamoDB et ont un DAX impact sur les ressources du cluster en ce qui concerne le proxy d'écriture.
Cache d'éléments et cache de requêtes
DAXgère un cache d'éléments et un cache de requêtes. Comprendre les différences entre ces caches peut vous aider à déterminer les caractéristiques de performance et de cohérence qu'ils offrent à votre application.
| Cache d'élément | Cache de requête |
|---|---|
| Purpose | |
|
Stocke les résultats GetItemet les BatchGetItemAPIopérations. |
Stocke les résultats des API opérations de requête et de numérisation. Ces opérations peuvent renvoyer plusieurs éléments en fonction des conditions de requête au lieu de clés d'éléments spécifiques. |
| Access type | |
|
Utilise un accès par clé. Lorsqu'une application demande des données en utilisant |
Utilise un accès basé sur des paramètres. DAXmet en cache le jeu de résultats |
| Cache invalidation | |
|
DAXréplique automatiquement les éléments mis à jour dans le cache d'éléments des nœuds du DAX cluster dans les scénarios suivants :
|
Le cache de requêtes est plus difficile à invalider que le cache d'éléments. Les mises à jour des éléments peuvent ne pas correspondre directement aux requêtes ou aux scans mis en cache. Vous devez ajuster soigneusement le cache de requêtes TTL pour garantir la cohérence des données. Les écritures DAX ou la table de base ne sont reflétées dans le cache de requêtes que lorsque la réponse précédemment mise en cache TTL expire et DAX qu'une nouvelle requête est exécutée sur DynamoDB. |
| Global secondary index | |
Comme l'GetItemAPIopération n'est pas prise en charge sur les index secondaires locaux ou les index secondaires globaux, le cache d'éléments ne met en cache que les lectures de la table de base. |
Le cache de requêtes met en cache les requêtes portant à la fois sur les tables et sur les index. |
Sélection TTL des paramètres pour les caches
TTLdétermine la période pendant laquelle les données sont stockées dans le cache avant qu'elles ne deviennent périmées. Après cette période, les données sont automatiquement actualisées lors de la prochaine demande. Pour choisir le bon TTL paramètre pour vos DAX caches, vous devez trouver un équilibre entre l'optimisation des performances des applications et la cohérence des données. Comme il n'existe pas de TTL paramètre universel qui fonctionne pour toutes les applications, le TTL réglage optimal varie en fonction des caractéristiques et des exigences spécifiques de votre application. Nous vous recommandons de commencer par un TTL réglage prudent en suivant ces directives prescriptives. Ajustez ensuite votre TTL réglage de manière itérative en fonction des données de performance et des informations de votre application.
DAXtient à jour la liste des objets les plus récemment utilisés (LRU) pour le cache d'éléments. La LRU liste indique le moment où les éléments ont été écrits pour la première fois ou lus pour la dernière fois depuis le cache. Lorsque la mémoire du DAX nœud est pleine, il DAX évacue les anciens éléments, même s'ils n'ont pas encore expiré, pour faire de la place à de nouveaux éléments. L'LRUalgorithme est toujours activé et n'est pas configurable par l'utilisateur.
Pour définir une TTL durée adaptée à vos applications, tenez compte des points suivants :
Comprenez vos modèles d'accès aux données
-
Charges de travail intensives en lecture : pour les applications présentant de lourdes charges de lecture et des mises à jour de données peu fréquentes, définissez une TTL durée plus longue afin de réduire le nombre d'erreurs de cache. Une TTL durée plus longue réduit également le besoin d'accéder à la table DynamoDB sous-jacente.
-
Charges de travail intensives en écriture : pour les applications soumises à des mises à jour fréquentes mais non écritesDAX, définissez une TTL durée plus courte pour garantir la cohérence du cache avec la base de données. Une TTL durée plus courte réduit également le risque de diffusion de données périmées.
Évaluez les exigences de performance de votre application
-
Sensibilité à la latence : si votre application nécessite une faible latence pour actualiser les données, utilisez une TTL durée plus longue. Une TTL durée plus longue maximise les accès au cache, ce qui réduit la latence de lecture moyenne.
-
Débit et évolutivité : une TTL durée plus longue réduit la charge sur les tables DynamoDB et améliore le débit et l'évolutivité. Cependant, vous devez trouver un équilibre entre cela et le besoin de up-to-date données.
Analyser l'éviction du cache et l'utilisation de la mémoire
-
Limites de mémoire cache : surveillez l'utilisation de la mémoire de votre DAX cluster. Une TTL durée plus longue peut stocker davantage de données dans le cache, ce qui peut atteindre les limites de mémoire et entraîner des expulsions LRU fondées.
Utilisez les métriques et la surveillance pour ajuster TTL
Passez régulièrement en revue les indicateurs, par exemple les accès et les échecs du cache, ainsi que l'utilisation CPU de la mémoire. Ajustez vos TTL paramètres en fonction de ces indicateurs afin de trouver un équilibre optimal entre les performances et l'actualité des données. Si les erreurs de cache sont importantes et que l'utilisation de la mémoire est faible, augmentez la TTL durée pour augmenter le taux de réussite du cache.
Tenez compte des exigences commerciales et de la conformité
Les politiques de conservation des données peuvent dicter la TTL durée maximale que vous pouvez définir pour les informations sensibles ou personnelles.
Comportement du cache si vous le définissez TTL sur zéro
Si vous définissez cette TTL valeur sur 0, le cache d'éléments et le cache de requêtes présentent les comportements suivants :
-
Cache d'éléments — Les éléments du cache sont actualisés uniquement lors d'une LRU expulsion ou d'une opération d'écriture directe.
-
Cache de requêtes : les réponses aux requêtes ne sont pas mises en cache.
Mise en cache de plusieurs tables avec un cluster DAX
Pour les charges de travail comportant plusieurs petites tables DynamoDB qui ne nécessitent pas de caches individuels, un DAX seul cluster met en cache les demandes relatives à ces tables. Cela permet une utilisation plus flexible et plus efficaceDAX, en particulier pour les applications qui accèdent à plusieurs tables et nécessitent des lectures hautes performances.
À l'instar du APIs plan de données DynamoDBDAX, les demandes nécessitent un nom de table. Si vous utilisez plusieurs tables dans le même DAX cluster, aucune configuration spécifique n'est nécessaire. Cependant, vous devez vous assurer que les autorisations de sécurité du cluster autorisent l'accès à toutes les tables mises en cache.
Considérations relatives à l'utilisation DAX avec plusieurs tables
Lorsque vous utilisez DAX plusieurs tables DynamoDB, vous devez tenir compte des points suivants :
-
Gestion de la mémoire — Lorsque vous utilisez DAX plusieurs tables, vous devez tenir compte de la taille totale de votre ensemble de données de travail. Toutes les tables de votre ensemble de données partageront le même espace mémoire que le type de nœud que vous avez sélectionné.
-
Allocation de ressources : les ressources du DAX cluster sont partagées entre toutes les tables mises en cache. Cependant, une table à fort trafic peut entraîner l'expulsion des données des tables plus petites voisines.
-
Économies d'échelle — Regroupez les petites ressources dans un DAX cluster plus large afin de répartir le trafic sortant selon un schéma plus stable. Pour le nombre total de ressources de lecture dont le DAX cluster a besoin, il est également économique de disposer de trois nœuds ou plus. Cela augmente également la disponibilité de toutes les tables mises en cache dans le cluster.
Réplication des données dans DAX les tables globales DynamoDB
DAXest un service basé sur une région, de sorte qu'un cluster n'est conscient que du trafic au sein de son propre cluster. Région AWS Les tables globales contournent le cache lorsqu'elles répliquent des données d'une autre région.
Une TTL durée plus longue peut faire en sorte que les données périmées restent plus longtemps dans votre région secondaire que dans la région principale. Cela peut entraîner des erreurs de cache dans le cache local de la région secondaire.
Le schéma suivant montre la réplication des données qui se produit au niveau de la table globale dans la région source A. Le DAX cluster de la région B n'est pas immédiatement conscient des données récemment répliquées depuis la région source A.
DAX : disponibilité dans les régions
Les régions qui prennent en charge les tables DynamoDB ne prennent pas toutes en charge le déploiement de clusters. DAX Si votre application nécessite une faible latence de lectureDAX, consultez d'abord la liste des régions compatibles DAX. Sélectionnez ensuite une région pour votre table DynamoDB.
DAXcomportement de mise en cache
DAXeffectue des métadonnées et une mise en cache négative. La compréhension de ces comportements de mise en cache vous aidera à gérer efficacement les métadonnées d'attribut des éléments mis en cache et des entrées de cache négatives.
-
Mise en cache des métadonnées : les DAX clusters conservent indéfiniment les métadonnées relatives aux noms d'attributs des éléments mis en cache. Ces métadonnées sont conservées même après l'expiration de l'élément ou son expulsion du cache.
Au fil du temps, les applications qui utilisent un nombre illimité de noms d'attributs peuvent entraîner un épuisement de la mémoire dans le DAX cluster. Cette limitation s'applique uniquement aux noms d'attributs de premier niveau, mais pas aux noms d'attributs imbriqués. Les exemples de noms d'attributs illimités incluent les horodatages et les sessions. UUIDs IDs Bien que vous puissiez utiliser les horodatages et les sessions IDs comme valeurs d'attribut, nous vous recommandons d'utiliser des noms d'attributs plus courts et plus prévisibles.
-
Mise en cache négative : si une erreur de cache se produit et que la lecture d'une table DynamoDB ne produit aucun élément correspondantDAX, ajoute une entrée de cache négative dans le cache d'éléments ou de requêtes correspondant. Cette entrée est conservée jusqu'à ce que la TTL durée du cache expire ou qu'une écriture soit effectuée. DAXcontinue de renvoyer cette entrée de cache négative pour les demandes futures.
Si le comportement de mise en cache négatif ne correspond pas au modèle de votre application, lisez directement la table DynamoDB DAX lorsqu'un résultat vide est renvoyé. Nous vous recommandons également de définir une durée de TTL cache plus courte pour éviter de laisser des résultats vides dans le cache et améliorer la cohérence avec le tableau.
