Évaluation de l’adéquation de DAX pour vos cas d’utilisation
Cette section explique quand et pourquoi utiliser DAX. L’utilisation de ces instructions vous aide à déterminer si l’intégration de DAX à DynamoDB est avantageuse pour les modèles de charge de travail, les exigences de performance et les besoins de cohérence des données. Cette section couvre également les scénarios dans lesquels DAX pourrait ne pas être adapté, par exemple les charges de travail lourdes en écriture et les données rarement consultées.
Dans cette section
Quand et pourquoi choisir DAX
Vous pouvez envisager d’ajouter DAX à votre pile d’applications dans plusieurs scénarios. Par exemple, utilisez DAX pour réduire la latence globale des demandes de lecture par rapport à DynamoDB ou pour minimiser les lectures répétées des mêmes données dans une table. La liste suivante présente des exemples de scénarios dans lesquels vous pouvez tirer parti de l’intégration de DAX à DynamoDB :
-
Exigence de haute performance
-
Lectures à faible latence : vous pouvez envisager d’utiliser DAX si votre application a besoin de temps de réponse en microsecondes pour des lectures cohérentes à terme. DAX peut également réduire considérablement le temps de réponse pour accéder aux données lues fréquemment.
-
-
Charges de travail intensives en lecture
-
Applications à forte intensité de lecture : pour les applications présentant un taux de lecture/d’écriture élevé, par exemple 10:1 ou plus, DAX augmente le nombre d’accès au cache et réduit le nombre de données périmées. Cela réduit le nombre de lectures par rapport à une table. Pour éviter de lire des données périmées dans le cache si votre application utilise beaucoup d’écriture, veillez à définir une Utilisation de la durée de vie (TTL) dans DynamoDB inférieure pour le cache.
-
Mise en cache des requêtes courantes : si votre application lit fréquemment les mêmes données, par exemple des produits populaires sur une plateforme de commerce électronique, DAX peut répondre à ces demandes directement à partir de son cache.
-
-
Schémas de trafic en rafale
-
Mise à l’échelle plus fluide des tables : DAX permet d’atténuer les impacts des pics de trafic soudains. DAX fournit une mémoire tampon pour augmenter verticalement la capacité des tables DynamoDB de manière progressive, ce qui réduit le risque de limitation de lecture.
-
Débit de lecture supérieur pour chaque élément : DynamoDB alloue des partitions individuelles pour chaque élément. Cependant, une partition commence à limiter les lectures d’un élément lorsqu’il atteint 3 000 unités de capacité de lecture (RCU). DAX vous permet de mettre à l’échelle les lectures d’un seul élément au-delà de 3 000 RCU.
-
-
Optimisation des coûts
-
Réduction des coûts DynamoDB : la lecture depuis DAX peut réduire le nombre de lectures envoyées à une table DynamoDB, ce qui peut avoir un impact direct sur les coûts. Avec un taux d’accès au cache élevé, le coût réduit de lecture des tables peut dépasser le coût d’un cluster DAX, ce qui se traduit par une nette réduction des coûts.
-
-
Exigences de cohérence des données
-
Cohérence éventuelle : DAX prend en charge les lectures cohérentes à terme. DAX convient donc aux cas d’utilisation où une cohérence immédiate n’est pas essentielle.
-
Mise en cache par écriture simultanée : les écritures que vous effectuez sur DAX sont des écritures simultanée. Une fois que DAX confirme qu’il a écrit un élément dans DynamoDB, il conserve la version de cet élément dans le cache d’éléments. Ce mécanisme d’écriture simultanée permet de maintenir une plus grande cohérence des données entre le cache et la base de données, mais utilise des ressources supplémentaires du cluster DAX.
-
Cas dans lesquels il est préférable de ne pas utiliser DAX
Bien que DAX soit puissant, il ne convient pas à tous les scénarios. La liste suivante présente des exemples de scénarios dans lesquels il n’est pas conseiller d’intégrer DAX à DynamoDB :
-
Charges de travail gourmandes en écriture : le principal avantage de DAX est d’accélérer les lectures, mais les écritures utilisent plus de ressources DAX que les lectures. Si votre application est principalement gourmande en écriture, les avantages de DAX peuvent être limités.
-
Lecture de données peu fréquente : si votre application accède aux données de manière peu fréquente ou à un large éventail de données rarement réutilisées (données à froid), il est probable que vous connaissez un faible cache hit ratio. Dans ce cas, la surcharge liée à la maintenance du cache peut ne pas justifier les gains de performances.
-
Lectures ou écritures groupées : si votre application effectue plus d’écritures groupées que d’écritures individuelles, vous devez écrire autour de DAX. En outre, pour les lectures groupées, vous devez exécuter des analyses de table complètes directement sur une table DynamoDB.
-
Exigences strictes en matière de cohérence ou de transaction : DAX transmet des lectures fortement cohérentes et des appels TransactGetItems à une table DynamoDB. Vous devez effectuer ces lectures autour du cluster DAX pour éviter d’utiliser les ressources du cluster. Les éléments lus de cette façon ne seront pas mis en cache ; par conséquent, le routage de ces éléments via DAX ne sert à rien.
-
Applications simples avec des exigences de performances modestes : pour les applications présentant des exigences de performances modestes et une tolérance à la latence directe de DynamoDB, la complexité et le coût liés à l’ajout de DAX peuvent ne pas être nécessaires. À lui seul, DynamoDB gère un débit élevé et fournit des performances à un chiffre en millisecondes.
-
Besoins d’interrogation complexes allant au-delà de l’accès clé-valeur : DAX est optimisé pour les modèles d’accès clé-valeur. Si votre application nécessite des fonctionnalités de requête complexes associées à un filtrage complexe, telles que les opérations de Requête et d’Analyse, les avantages de la mise en cache DAX peuvent être limités.
Dans ces situations, utilisez Amazon ElastiCache (Redis OSS). ElastiCache (Redis OSS) prend en charge les structures de données avancées, telles que les listes, les ensembles et les hachages. Il propose également des fonctionnalités telles que Pub/Sub, des index géospatiaux et des scripts.
-
Exigences de conformité : actuellement, DAX ne propose pas les mêmes accréditations de conformité que DynamoDB. Par exemple, DAX n’a pas encore obtenu l’accréditation SOC.
