Amazon DVA-C02: Amazon DynamoDB et Conception NoSQL — Guide d'étude

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Fait partie du AWS Developer Associate DVA-C02 — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Amazon, ou passez des tests chronométrés sur ExamRoll.io.

Modélisation des données et modèles d’accès

La conception avec DynamoDB commence par les modèles d’accès : chaque requête doit correspondre à une clé primaire, un index secondaire global (GSI) ou un index secondaire local (LSI) ; la conception de la table est guidée par la manière dont l’application lit et écrit les éléments, et non par la structure d’un schéma relationnel. Choisissez une clé de partition à haute cardinalité pour éviter les partitions surchargées et utilisez une clé primaire composite (clé de partition + clé de tri) lorsque vous avez besoin de requêtes de plage ; les opérations Query exigent une égalité sur la clé de partition et une KeyConditionExpression optionnelle sur la clé de tri. Pour les SDK, privilégiez les abstractions DynamoDB Document : utilisez DynamoDBDocumentClient avec le AWS SDK for JavaScript v3 (le marshall/unmarshall est géré pour vous) ou le DynamoDB Enhanced Client en Java pour mapper des objets à des attributs. N’implémentez les modèles de table unique que lorsque les modèles de lecture partagent des clés et que vous pouvez encoder les types d’éléments via un attribut de type ; utilisez des GSI épars pour exposer des chemins d’accès secondaires en n’écrivant les attributs que sur les éléments qui en ont besoin. Un piège courant est la surutilisation de Scan : le balayage de grandes tables est coûteux et paginé (LastEvaluatedKey) ; préférez Query avec ProjectionExpression pour réduire l’utilisation de RCU. Pour les écritures conditionnelles, utilisez UpdateItem avec ConditionExpression ou TransactWriteItems pour l’atomicité sur plusieurs éléments ; gérez l’exception ConditionalCheckFailedException et appliquez une temporisation avec gigue.

Index, requêtes et modèles transactionnels

Les index secondaires locaux sont créés uniquement lors de la création de la table, partagent la même clé de partition que la table de base et consomment la capacité de lecture de la table pour les requêtes, tandis que les GSI peuvent être ajoutés après la création de la table, disposent d’une capacité indépendante ou d’une facturation à la demande, et autorisent des clés de partition différentes. Les appels Query utilisent KeyConditionExpression et ExpressionAttributeNames/Values ; les expressions de projection réduisent le transfert de données. Les GSI sont cohérents à terme (eventually consistent) par défaut et entraînent un coût d’écriture supplémentaire, car chaque écriture sur la table de base qui projette des attributs indexés crée des écritures GSI correspondantes — planifiez les WCU en conséquence et surveillez ConsumedWriteCapacityUnits pour l’index. Pour une forte cohérence, utilisez GetItem ou Query avec ConsistentRead=true sur la table de base (les GSI ne prennent pas en charge les lectures fortement cohérentes). Les transactions (TransactWriteItems et TransactGetItems) garantissent l’atomicité sur un maximum de 25 éléments ou une charge utile de 4 Mo ; utilisez ReturnValuesOnConditionCheckFailure pour inspecter les échecs. BatchWriteItem et BatchGetItem sont limités respectivement à 25 et 100 éléments et ne sont pas transactionnels ; le code doit gérer les UnprocessedItems en réessayant avec une temporisation exponentielle. Un écueil fréquent est d’oublier le coût et les implications de la cohérence à terme des GSI lors de la migration de jointures relationnelles vers des index.

Modes de capacité, optimisation des performances et dépannage

Choisissez entre la capacité provisionnée et la capacité à la demande en fonction de la prévisibilité : la capacité provisionnée avec Auto Scaling (Application Auto Scaling pour DynamoDB) donne le contrôle sur les RCU/WCU et les coûts pour les charges de travail stables, tandis que la capacité à la demande simplifie la gestion du trafic en rafales sans planification de capacité, mais à un prix par requête plus élevé. Activez l’Auto Scaling avec une utilisation cible et plusieurs politiques de mise à l’échelle ; surveillez les métriques CloudWatch comme ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors et ConditionalCheckFailedRequests pour détecter les points chauds (hotspots) et le throttling. Utilisez la capacité adaptative pour atténuer le throttling sur une seule clé, mais évitez de vous y fier — concevez pour une distribution de clés uniforme. Pour les charges de travail à forte lecture, envisagez DAX pour des lectures en microsecondes ou un cache avec Amazon ElastiCache ; pour une forte charge en écriture, utilisez la fragmentation en écriture (write sharding) (préfixes ou compartiments) pour répartir les écritures sur les partitions. Dépannez en inspectant l’exception ProvisionedThroughputExceededException et en implémentant une temporisation exponentielle avec gigue dans les clients SDK, activez CloudWatch Contributor Insights pour trouver les clés surchargées, et utilisez un Parallel Scan pour les analyses ponctuelles volumineuses avec des workers segmentés. N’oubliez pas les limites de taille des éléments (400 Ko) et que les éléments volumineux augmentent les RCU/WCU ; divisez les blobs volumineux dans S3 avec les métadonnées dans DynamoDB si nécessaire.

Flux, intégrations, sauvegardes et bonnes pratiques opérationnelles

Les DynamoDB Streams capturent les changements au niveau des éléments (INSERT, MODIFY, REMOVE) dans l’ordre par clé de partition et s’intègrent directement avec Lambda via un mappage de source d’événement (configurez startingPosition sur TRIM_HORIZON ou LATEST, définissez batchSize et maximumBatchingWindowInSeconds, et ajustez bisectBatchOnError et maximumRetryAttempts). Pour un traitement robuste, utilisez Lambda avec une file d’attente de lettres mortes (Dead-Letter Queue - SQS ou SNS) ou acheminez les enregistrements du flux vers Kinesis ou Kinesis Data Firehose pour l’analyse. Activez le Time To Live (TTL) pour l’expiration automatique des éléments ; notez que les suppressions TTL sont traitées de manière éventuelle et ne doivent pas être utilisées pour une cohérence immédiate. Utilisez la restauration à un instant donné (Point-in-Time Recovery - PITR) et les sauvegardes à la demande pour la reprise après sinistre ; pour une disponibilité multi-régions, utilisez les Global Tables pour répliquer les changements entre les régions. Appliquez des rôles IAM de moindre privilège aux services et n’accordez que les actions dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream et dynamodb:ListStreams nécessaires pour les Lambdas. Les pièges opérationnels courants incluent l’absence de logique de nouvelle tentative/backoff dans les consommateurs, une planification inadéquate de la capacité des GSI et le non-suivi de l’IteratorAge des Streams pour la détection de latence ; instrumentez avec CloudWatch Logs et X-Ray pour tracer la latence de bout en bout.

Problème pratique : Scénario d’utilisation

Scénario : AcmeMedia gère un catalogue de métadonnées dans une seule table DynamoDB dans us-east-1 contenant des dizaines de millions d’éléments. Un pipeline de traitement d’images récemment lancé nécessite une requête à faible latence par photographerId et par plage de uploadTimestamp, et les consommateurs Lambda en aval doivent traiter les changements de manière fiable.

Défi : Ajouter un chemin de requête efficace pour la plage photographerId + timestamp sans reconcevoir la table, garantir que les processus Lambda en aval traitent les enregistrements du flux avec une sémantique d’au moins une fois (at-least-once), et éviter les partitions surchargées (hot partitions) pour les photographes prolifiques.

Approche recommandée :

1. Créez un GSI nommé photographer-gsi avec la clé de partition photographerId et la clé de tri uploadTimestamp ; utilisez l’API UpdateTable ou la console pour ajouter le GSI et spécifiez une facturation ProvisionedThroughput ou On-Demand via UpdateTable et configurez la surveillance de l’IndexStatus.
2. Lors de l’écriture des éléments, incluez les attributs photographerId et uploadTimestamp pour que la projection de l’index soit clairsemée (sparse) ; choisissez ProjectionType=INCLUDE avec les attributs non-clés nécessaires aux requêtes pour réduire les coûts de stockage et d’écriture.
3. Configurez DynamoDB Streams sur ENABLED pour la table et créez un mappage de source d’événement Lambda avec startingPosition=TRIM_HORIZON, un batchSize ajusté (par ex., 100), bisectBatchOnError=true, maximumRetryAttempts=2, et définissez une file d’attente SQS comme destination de lettres mortes (Dead-Letter Destination) dans la configuration de la fonction Lambda.
4. Implémentez des nouvelles tentatives côté client SDK avec gigue (jitter) (utilisez la stratégie de nouvelle tentative intégrée du SDK AWS) et appliquez le partitionnement en écriture (write sharding) si un seul photographerId provoque toujours du throttling (préfixez photographerId avec N compartiments (buckets) à l’écriture et supprimez le préfixe à la lecture côté client).

Justification : L’ajout d’un GSI expose le modèle d’accès requis sans modifier la clé primaire de base ; projeter uniquement les attributs nécessaires réduit le coût d’écriture du GSI. Les Streams + Lambda avec une DLQ et des contrôles de nouvelle tentative fournissent un traitement fiable d’au moins une fois (at-least-once), tandis que le partitionnement (sharding) protège contre les partitions surchargées (hot partitions) dues à un trafic à haute cardinalité.

← Amazon API Gateway et Intégration d’applications · Tous les domaines · CloudFormation et Infrastructure en tant que code (SAM →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Amazon →