Amazon DVA-C02: Amazon DynamoDB & NoSQL-ontwerp — Studiegids

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

Onderdeel van de AWS Developer Associate DVA-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Datamodellering en toegangspatronen

Het ontwerpen van DynamoDB begint met toegangspatronen: elke query moet verwijzen naar een primary key, global secondary index (GSI) of local secondary index (LSI); het tabelontwerp wordt bepaald door hoe de applicatie items leest en schrijft, niet door hoe een relationeel schema gestructureerd zou zijn. Kies een partition key met een hoge cardinaliteit om ‘hot partitions’ te vermijden en gebruik een composite primary key (partition + sort key) wanneer je bereikquery’s (range queries) nodig hebt; Query-operaties vereisen gelijkheid op de partition key en een optionele KeyConditionExpression op de sort key. Geef voor SDK’s de voorkeur aan de DynamoDB Document-abstracties: gebruik DynamoDBDocumentClient met de AWS SDK for JavaScript v3 (marshall/unmarshall wordt voor je afgehandeld) of de DynamoDB Enhanced Client in Java om objecten te mappen naar attributen. Implementeer ‘single-table patterns’ alleen wanneer leespatronen sleutels delen en je itemtypes kunt coderen via een type-attribuut; gebruik ‘sparse GSIs’ om secundaire toegangspaden beschikbaar te maken door attributen alleen te schrijven naar items die ze nodig hebben. Een veelvoorkomende valkuil is het overmatig gebruik van Scan: het scannen van grote tabellen is duur en gepagineerd (LastEvaluatedKey); geef de voorkeur aan Query met een ProjectionExpression om het RCU-verbruik te verminderen. Gebruik voor conditionele schrijfacties UpdateItem met een ConditionExpression of TransactWriteItems voor atomiciteit over meerdere items; vang ConditionalCheckFailedException af en gebruik ‘back off with jitter’.

Indexen, query’s en transactionele patronen

Local secondary indexes worden alleen aangemaakt bij het creëren van de tabel, delen dezelfde partition key als de basistabel en verbruiken de leescapaciteit van de tabel voor query’s, terwijl GSIs na het aanmaken van de tabel kunnen worden toegevoegd, onafhankelijke capaciteit of on-demand facturering hebben en verschillende partition keys toestaan. Query-aanroepen gebruiken KeyConditionExpression en ExpressionAttributeNames/Values; projection expressions verminderen de gegevensoverdracht. GSIs zijn standaard ’eventually consistent’ en brengen extra schijfkosten met zich mee omdat elke schrijfactie naar de basistabel die geïndexeerde attributen projecteert, overeenkomstige GSI-schrijfacties creëert — plan WCUs dienovereenkomstig en monitor ConsumedWriteCapacityUnits voor de index. Gebruik voor ‘strong consistency’ GetItem of Query met ConsistentRead=true op de basistabel (GSIs ondersteunen geen ‘strongly consistent reads’). Transacties (TransactWriteItems en TransactGetItems) garanderen atomiciteit voor maximaal 25 items of een payload van 4 MB; gebruik ReturnValuesOnConditionCheckFailure om fouten te inspecteren. BatchWriteItem en BatchGetItem zijn beperkt tot respectievelijk 25 en 100 items en zijn niet-transactioneel; de code moet UnprocessedItems afhandelen door opnieuw te proberen met ’exponential backoff’. Een veelvoorkomende valkuil is het vergeten van de kosten en de ’eventual consistency’-implicaties van GSIs bij het migreren van relationele joins naar indexen.

Capaciteitsmodi, prestatietuning en probleemoplossing

Kies tussen ‘provisioned’ en ‘on-demand’ capaciteit op basis van voorspelbaarheid: ‘provisioned’ met Auto Scaling (Application Auto Scaling for DynamoDB) geeft controle over RCU/WCU en kosten voor stabiele workloads, terwijl ‘on-demand’ pieken in verkeer vereenvoudigt zonder capaciteitsplanning, maar tegen een hogere prijs per verzoek. Schakel Auto Scaling in met een ’target utilization’ en meerdere schaalbeleidsregels; monitor CloudWatch-metrics zoals ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors en ConditionalCheckFailedRequests om hotspots en ’throttling’ te detecteren. Gebruik ‘adaptive capacity’ om ’throttling’ op een enkele sleutel te beperken, maar wees er niet afhankelijk van — ontwerp voor een uniforme sleuteldistributie. Overweeg voor lees-intensieve workloads DAX voor leesacties in microseconden of caching met Amazon ElastiCache; gebruik voor schrijf-intensieve workloads ‘write sharding’ (prefixes of buckets) om schrijfacties over partities te verdelen. Los problemen op door ProvisionedThroughputExceededException te inspecteren en ’exponential backoff with jitter’ te implementeren in SDK-clients, schakel CloudWatch Contributor Insights in om ‘hot keys’ te vinden, en gebruik Parallel Scan voor grote, eenmalige analyses met gesegmenteerde workers. Onthoud de limieten voor itemgrootte (400 KB) en dat grote items de RCUs/WCUs verhogen; splits grote blobs indien nodig op naar S3, met de metadata in DynamoDB.

Streams, integraties, back-ups en operationele best practices

DynamoDB Streams leggen wijzigingen op itemniveau (INSERT, MODIFY, REMOVE) vast in volgorde per partitiesleutel en integreren rechtstreeks met Lambda via een event source mapping (configureer startingPosition als TRIM_HORIZON of LATEST, stel batchSize en maximumBatchingWindowInSeconds in, en stem bisectBatchOnError en maximumRetryAttempts af). Voor robuuste verwerking, gebruik Lambda met een Dead-Letter Queue (SQS of SNS) of routeer stream records naar Kinesis of Kinesis Data Firehose voor analyses. Schakel Time To Live (TTL) in voor het automatisch laten verlopen van items; merk op dat TTL-verwijderingen uiteindelijk worden verwerkt en niet moeten worden gebruikt voor onmiddellijke consistentie. Gebruik Point-in-Time Recovery (PITR) en on-demand back-ups voor disaster recovery; voor multi-region beschikbaarheid, gebruik Global Tables om wijzigingen over regio’s te repliceren. Pas IAM-rollen met minimale rechten (least-privilege) toe op services en verleen alleen de noodzakelijke acties dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream en dynamodb:ListStreams voor Lambda’s. Veelvoorkomende operationele valkuilen zijn het ontbreken van retry/backoff-logica in consumers, ontoereikende GSI-capaciteitsplanning en het niet monitoren van de Streams IteratorAge voor detectie van vertraging (lag); instrumenteer met CloudWatch Logs en X-Ray om end-to-end latency te traceren.

Praktijkvoorbeeld: Use-Case Scenario

Scenario: AcmeMedia beheert een metadata-catalogus in een enkele DynamoDB-tabel in us-east-1 die tientallen miljoenen items bevat. Een nieuw gelanceerde beeldverwerkingspipeline heeft een query met lage latentie nodig op basis van photographerId en een uploadTimestamp-bereik, en downstream Lambda-consumers moeten wijzigingen betrouwbaar verwerken.

Uitdaging: Voeg een efficiënt query-pad toe voor photographerId + timestamp-bereik zonder de tabel opnieuw te ontwerpen, zorg ervoor dat downstream Lambda-processen stream records verwerken met at-least-once semantiek, en vermijd hot partitions voor productieve fotografen.

Aanbevolen Aanpak:

Maak een GSI aan met de naam photographer-gsi met partitiesleutel photographerId en sorteersleutel uploadTimestamp; gebruik de UpdateTable API of de console om de GSI toe te voegen en specificeer ProvisionedThroughput of On-Demand facturering via UpdateTable en stel IndexStatus-monitoring in.
Neem bij het schrijven van items de attributen photographerId en uploadTimestamp op zodat de indexprojectie ‘sparse’ is; kies ProjectionType=INCLUDE met niet-sleutelattributen die nodig zijn voor queries om opslag- en schijfkosten te verlagen.
Configureer DynamoDB Streams als ENABLED op de tabel en maak een Lambda event source mapping aan met startingPosition=TRIM_HORIZON, een afgestemde batchSize (bijv. 100), bisectBatchOnError=true, maximumRetryAttempts=2, en stel een SQS-wachtrij in als een Dead-Letter Destination in de Lambda-functieconfiguratie.
Implementeer SDK client retries met jitter (gebruik de ingebouwde retry-strategie van de AWS SDK) en pas write sharding toe als een enkele photographerId nog steeds throttling veroorzaakt (prefix de photographerId met N buckets bij het schrijven en verwijder de prefix aan de client-zijde bij het lezen).

Rationale: Het toevoegen van een GSI maakt het vereiste toegangspatroon beschikbaar zonder de primaire basissleutel te wijzigen; door alleen de noodzakelijke attributen te projecteren, worden de GSI-schrijfkosten verlaagd. Streams + Lambda met DLQ- en retry-controles bieden een betrouwbare at-least-once verwerking, terwijl sharding beschermt tegen hot partitions veroorzaakt door verkeer met hoge kardinaliteit.

← Amazon API Gateway · Alle domeinen · CloudFormation →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →