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.
Cette section explique comment déterminer si vous utilisez efficacement votre table DynamoDB. Certains modèles d'utilisation ne sont pas optimaux pour DynamoDB et peuvent être optimisés du point de vue des performances et des coûts.
Rubriques
Effectuer moins d'opérations de lecture fortement cohérente
DynamoDB vous permet de configurer la cohérence de lecture pour chaque demande. Les demandes de lecture sont « éventuellement cohérentes » par défaut. Ces lectures sont facturées à 0,5 RCU pour un maximum de 4 Ko de données.
La plupart des éléments des charges de travail distribuées sont flexibles et peuvent tolérer une éventuelle cohérence. Cependant, certains modèles d'accès peuvent nécessiter des lectures fortement cohérentes. Les lectures fortement cohérentes sont facturées à 1 RCU pour un maximum de 4 Ko de données, ce qui multiplie les coûts de lecture par deux. DynamoDB vous offre la flexibilité nécessaire pour utiliser les deux modèles de cohérence au niveau de la même table.
Vous pouvez évaluer votre charge de travail et le code de votre application pour vérifier si les lectures fortement cohérentes ne sont utilisées que lorsque cela est nécessaire.
Réaliser moins de transactions pour les opérations de lecture
DynamoDB vous permet de regrouper certaines actions d' all-or-nothingune certaine manière, ce qui signifie que vous pouvez exécuter des transactions ACID avec DynamoDB. Toutefois, comme c'est le cas pour les bases de données relationnelles, il n'est pas nécessaire de suivre cette approche pour chaque action.
Une opération de lecture transactionnelle allant jusqu'à 4 Ko RCUs en consomme 2, contre 0,5 par défaut RCUs pour lire la même quantité de données de manière finalement cohérente. Les coûts des opérations d'écriture sont doublés, ce qui signifie qu'une écriture transactionnelle allant jusqu'à 1 Ko équivaut à 2. WCUs
Pour déterminer si toutes les opérations de vos tables sont des transactions, CloudWatch les mesures de la table peuvent être filtrées en fonction de la transaction APIs. Si APIs les transactions sont les seuls graphiques disponibles sous les SuccessfulRequestLatency métriques du tableau, cela confirmera que chaque opération est une transaction pour ce tableau. Sinon, si la tendance globale d'utilisation des capacités correspond à la tendance des API transactionnelles, pensez à revoir la conception de l'application, car elle semble dominée par les transactions APIs.
Effectuer moins d'analyses
L'utilisation intensive des opérations Scan est généralement liée à la nécessité d'exécuter des requêtes analytiques au niveau des données DynamoDB. L'exécution d'opérations Scan fréquentes sur une table de grande envergure peut s'avérer inefficace et coûteuse.
Une meilleure alternative consiste à utiliser la fonctionnalité Exporter vers S3 et à choisir un moment pour exporter l'état de la table vers S3. AWS propose des services tels qu'Athena, qui peuvent ensuite être utilisés pour exécuter des requêtes analytiques sur les données sans consommer la capacité du tableau.
La fréquence des opérations Scan peut être déterminée à l'aide de la statistique SampleCount sous la métrique SuccessfulRequestLatency pour Scan. Si les opérations Scan sont très fréquentes, les modèles d'accès et le modèle de données devraient être réévalués.
Raccourcir le nom des attributs
La taille totale d'un élément dans DynamoDB est la somme des longueurs de ses noms et valeurs d'attribut. Le fait d'avoir des noms d'attributs longs contribue non seulement aux coûts de stockage, mais peut également entraîner une augmentation du nombre RCU/WCU consumption. We recommend that you choose shorter attribute names rather than long ones. Having shorter attribute names can help limit the item size within the next 4KB/1KB boundary after which you would consume additional RCU/WCU de données d'accès.
Activer la durée de vie (TTL)
La durée de vie (TTL) permet d'identifier les éléments dont la date d'expiration est supérieure à celle que vous avez définie, et de les supprimer de la table. Si vos données augmentent au fil du temps et que des données plus anciennes ne sont plus pertinentes, l'activation du TTL au niveau de la table contribue à réduire la quantité de données et à diminuer les coûts de stockage.
Un autre aspect utile du TTL est que les éléments ayant expiré se trouvent dans vos flux DynamoDB. Par conséquent, au lieu de simplement supprimer les données obsolètes parmi toutes vos données, il est possible de consommer ces éléments du flux et de les archiver vers un niveau de stockage moins coûteux. En outre, la suppression d'éléments via le TTL n'entraîne aucun coût supplémentaire : il ne consomme pas de capacité, et il n'est pas nécessaire de passer un temps précieux à concevoir une application de nettoyage.
Remplacer les tables globales par des sauvegardes interrégionales
Les tables globales vous permettent de gérer plusieurs tables de réplica actives dans différentes régions. Elles peuvent toutes accepter des opérations d'écriture et répliquer des données entre elles. Il est facile de configurer des réplicas. La synchronisation est gérée pour vous. Les réplicas convergent vers un état cohérent grâce à une stratégie de type « priorité à la dernière écriture ».
Si vous utilisez des tables globales uniquement dans le cadre d'une stratégie de basculement ou de reprise après sinistre, vous pouvez les remplacer par une copie de sauvegarde interrégionale pour des objectifs de points de restauration et des exigences en matière de temps de restauration relativement modérés. Si vous n'avez pas besoin d'un accès local rapide ni d'une haute disponibilité de 99,999 %, la gestion d'un réplica de table globale n'est peut-être pas la meilleure approche pour le basculement.
Vous pouvez également envisager d'utiliser AWS Backup pour gérer les sauvegardes DynamoDB. Vous pouvez planifier des sauvegardes régulières et les copier entre les régions afin de répondre aux exigences de reprise après sinistre, d'une manière plus rentable que l'utilisation de tables globales.
