Amazon DVA-C02: Amazon DynamoDB und NoSQL-Design — Lernleitfaden

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

Teil des AWS Developer Associate DVA-C02 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Datenmodellierung und Zugriffsmuster

Das Design von DynamoDB beginnt mit den Zugriffsmustern: Jede Abfrage sollte auf einen Primärschlüssel, einen globalen sekundären Index (GSI) oder einen lokalen sekundären Index (LSI) abgebildet werden. Das Tabellendesign wird davon bestimmt, wie die Anwendung Elemente liest und schreibt, nicht davon, wie ein relationales Schema strukturiert wäre. Wählen Sie einen Partitionsschlüssel mit hoher Kardinalität, um „Hot Partitions“ zu vermeiden, und verwenden Sie einen zusammengesetzten Primärschlüssel (Partitionsschlüssel + Sortierschlüssel), wenn Sie Bereichsabfragen benötigen. Query-Operationen erfordern eine Gleichheitsbedingung für den Partitionsschlüssel und eine optionale KeyConditionExpression für den Sortierschlüssel. Bevorzugen Sie für SDKs die DynamoDB-Dokument-Abstraktionen: Verwenden Sie den DynamoDBDocumentClient mit dem AWS SDK for JavaScript v3 (Marshalling/Unmarshalling wird für Sie übernommen) oder den DynamoDB Enhanced Client in Java, um Objekte auf Attribute abzubilden. Implementieren Sie Single-Table-Patterns nur dann, wenn Lesemuster gemeinsame Schlüssel verwenden und Sie Elementtypen über ein Typ-Attribut kodieren können. Verwenden Sie „Sparse GSIs“ (dünn besetzte GSIs), um sekundäre Zugriffspfade bereitzustellen, indem Sie Attribute nur für die Elemente schreiben, die sie benötigen. Eine häufige Falle ist die übermäßige Nutzung von Scan: Das Scannen großer Tabellen ist teuer und paginiert (LastEvaluatedKey); bevorzugen Sie Query mit einer ProjectionExpression, um die RCU-Nutzung zu reduzieren. Für bedingte Schreibvorgänge verwenden Sie UpdateItem mit einer ConditionExpression oder TransactWriteItems für die Atomizität über mehrere Elemente hinweg. Behandeln Sie die ConditionalCheckFailedException und implementieren Sie einen Backoff mit Jitter.

Indizes, Abfragen und Transaktionsmuster

Lokale sekundäre Indizes werden nur bei der Tabellenerstellung angelegt, teilen sich denselben Partitionsschlüssel wie die Basistabelle und verbrauchen für Abfragen die Lesekapazität der Tabelle. GSIs hingegen können nach der Tabellenerstellung hinzugefügt werden, haben eine unabhängige Kapazität oder On-Demand-Abrechnung und erlauben unterschiedliche Partitionsschlüssel. Query-Aufrufe verwenden eine KeyConditionExpression und ExpressionAttributeNames/Values; Projection Expressions reduzieren die Datenübertragung. GSIs sind standardmäßig „eventually consistent“ und verursachen zusätzliche Schreibkosten, da jeder Schreibvorgang in der Basistabelle, der indizierte Attribute projiziert, entsprechende Schreibvorgänge im GSI erzeugt – planen Sie die WCUs entsprechend und überwachen Sie die ConsumedWriteCapacityUnits für den Index. Für starke Konsistenz (strong consistency) verwenden Sie GetItem oder Query mit ConsistentRead=true auf der Basistabelle (GSIs unterstützen keine stark konsistenten Lesevorgänge). Transaktionen (TransactWriteItems und TransactGetItems) garantieren Atomizität für bis zu 25 Elemente oder eine Nutzlast von 4 MB; verwenden Sie ReturnValuesOnConditionCheckFailure, um Fehlschläge zu untersuchen. BatchWriteItem und BatchGetItem sind auf 25 bzw. 100 Elemente beschränkt und nicht transaktional; der Code sollte UnprocessedItems durch Wiederholungsversuche mit exponentiellem Backoff behandeln. Ein häufiger Fallstrick ist das Vergessen der Kosten und der Implikationen der „eventual consistency“ von GSIs bei der Migration von relationalen Joins in Indizes.

Kapazitätsmodi, Leistungsoptimierung und Fehlerbehebung

Entscheiden Sie zwischen bereitgestellter (provisioned) und On-Demand-Kapazität basierend auf der Vorhersehbarkeit: Bereitgestellte Kapazität mit Auto Scaling (Application Auto Scaling for DynamoDB) gibt Kontrolle über RCU/WCU und Kosten für gleichmäßige Workloads, während On-Demand-Kapazität sprunghaften Datenverkehr ohne Kapazitätsplanung vereinfacht, jedoch zu höheren Preisen pro Anfrage. Aktivieren Sie Auto Scaling mit einer Zielauslastung und mehreren Skalierungsrichtlinien; überwachen Sie CloudWatch-Metriken wie ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors und ConditionalCheckFailedRequests, um Hotspots und Drosselung (Throttling) zu erkennen. Nutzen Sie die adaptive Kapazität, um das Throttling bei einzelnen Schlüsseln zu entschärfen, aber vermeiden Sie es, sich darauf zu verlassen – entwerfen Sie stattdessen für eine gleichmäßige Schlüsselverteilung. Für leselastige Workloads ziehen Sie DAX für Lesevorgänge im Mikrosekundenbereich oder einen Cache mit Amazon ElastiCache in Betracht; für schreiblastige Workloads verwenden Sie Write Sharding (Präfixe oder Buckets), um Schreibvorgänge auf Partitionen zu verteilen. Zur Fehlerbehebung untersuchen Sie die ProvisionedThroughputExceededException und implementieren exponentiellen Backoff mit Jitter in den SDK-Clients, aktivieren Sie CloudWatch Contributor Insights, um „Hot Keys“ zu finden, und verwenden Sie Parallel Scan für große, einmalige Analysen mit segmentierten Workern. Denken Sie an die Größenbeschränkung für Elemente (400 KB) und daran, dass große Elemente die RCUs/WCUs erhöhen; teilen Sie große Blobs bei Bedarf in S3 auf und speichern Sie die Metadaten in DynamoDB.

Streams, Integrationen, Backups und bewährte Betriebspraktiken

DynamoDB Streams erfassen Änderungen auf Elementebene (INSERT, MODIFY, REMOVE) in Reihenfolge pro Partitionsschlüssel und lassen sich über ein Event-Source-Mapping direkt in Lambda integrieren (konfigurieren Sie startingPosition als TRIM_HORIZON oder LATEST, legen Sie batchSize und maximumBatchingWindowInSeconds fest und passen Sie bisectBatchOnError und maximumRetryAttempts an). Für eine robuste Verarbeitung verwenden Sie Lambda mit einer Dead-Letter-Queue (SQS oder SNS) oder leiten Sie Stream-Datensätze zur Analyse an Kinesis oder Kinesis Data Firehose weiter. Aktivieren Sie Time To Live (TTL) für das automatische Ablaufen von Elementen; beachten Sie, dass TTL-Löschungen letztendlich verarbeitet werden und man sich für sofortige Konsistenz nicht darauf verlassen sollte. Nutzen Sie Point-in-Time Recovery (PITR) und On-Demand-Backups für die Disaster Recovery; für Multi-Region-Verfügbarkeit verwenden Sie Global Tables, um Änderungen über Regionen hinweg zu replizieren. Wenden Sie IAM-Rollen mit geringsten Rechten (Least Privilege) auf Services an und gewähren Sie Lambdas nur die notwendigen Aktionen dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream und dynamodb:ListStreams. Häufige betriebliche Fallstricke sind fehlende Wiederholungs-/Backoff-Logik in Consumern, unzureichende Kapazitätsplanung für GSIs und das Versäumnis, die IteratorAge von Streams zur Lag-Erkennung zu überwachen; instrumentieren Sie mit CloudWatch Logs und X-Ray, um die End-to-End-Latenz nachzuverfolgen.

Praktisches Problem: Anwendungsfallszenario

Szenario: AcmeMedia betreibt einen Metadatenkatalog in einer einzigen DynamoDB-Tabelle in us-east-1, die zig Millionen Elemente enthält. Eine neu eingeführte Bildverarbeitungs-Pipeline benötigt eine Abfrage mit geringer Latenz nach photographerId und einem uploadTimestamp-Bereich, und nachgelagerte Lambda-Consumer müssen Änderungen zuverlässig verarbeiten.

Herausforderung: Fügen Sie einen effizienten Abfragepfad für photographerId + Zeitstempelbereich hinzu, ohne die Tabelle neu zu gestalten, stellen Sie sicher, dass nachgelagerte Lambda-Prozesse Stream-Datensätze mit At-least-once-Semantik verarbeiten, und vermeiden Sie Hot Partitions für produktive Fotografen.

Empfohlener Ansatz:

1. Erstellen Sie einen GSI mit dem Namen photographer-gsi mit dem Partitionsschlüssel photographerId und dem Sortierschlüssel uploadTimestamp; verwenden Sie die UpdateTable-API oder die Konsole, um den GSI hinzuzufügen, und spezifizieren Sie die ProvisionedThroughput- oder On-Demand-Abrechnung über UpdateTable und richten Sie die Überwachung des IndexStatus ein.
2. Fügen Sie beim Schreiben von Elementen die Attribute photographerId und uploadTimestamp hinzu, damit die Indexprojektion dünn besetzt (sparse) ist; wählen Sie ProjectionType=INCLUDE mit den für Abfragen benötigten Nicht-Schlüsselattributen, um Speicher- und Schreibkosten zu reduzieren.
3. Konfigurieren Sie DynamoDB Streams als ENABLED für die Tabelle und erstellen Sie ein Lambda-Event-Source-Mapping mit startingPosition=TRIM_HORIZON, einer angepassten batchSize (z. B. 100), bisectBatchOnError=true, maximumRetryAttempts=2 und legen Sie eine SQS-Warteschlange als Dead-Letter-Ziel in der Lambda-Funktionskonfiguration fest.
4. Implementieren Sie SDK-Client-Wiederholungsversuche mit Jitter (verwenden Sie die integrierte Wiederholungsstrategie des AWS SDK) und wenden Sie Write Sharding an, falls eine einzelne photographerId immer noch Drosselung (Throttling) verursacht (stellen Sie der photographerId beim Schreiben ein Präfix aus N Buckets voran und entfernen Sie das Präfix beim Lesen clientseitig).

Begründung: Das Hinzufügen eines GSI legt das erforderliche Zugriffsmuster offen, ohne den primären Basisschlüssel zu ändern; die Projektion nur der notwendigen Attribute reduziert die GSI-Schreibkosten. Streams + Lambda mit DLQ- und Wiederholungssteuerungen bieten eine zuverlässige At-least-once-Verarbeitung, während Sharding vor Hot Partitions durch Traffic mit hoher Kardinalität schützt.

← Amazon API Gateway und Anwendungsintegration · Alle Domänen · CloudFormation und Infrastruktur als Code (SAM →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Amazon durchsuchen →