Strömmande data med DynamoDB

Utveckla applikationer på AWS

Ricardo Sueiras

Principal Technologist

Grunderna i DynamoDB Streams

 

• Reagera på databasändringar i nära realtid.
• Bygger på händelsedrivna mönster.
• Varje infogning, ändring eller borttagning genererar en strömpost.
• Bygg reaktiva appar utan att polla tabellen.
• Inaktiverat som standard: aktivera med StreamSpecification.
• Varje ström har ett eget ARN, skilt från tabellens ARN.

Lagringsperiod

 

• Strömpostar sparas i 24 timmar.
  • Lagringstiden är fast och kan inte konfigureras.
• Att byta vytyp innebär att strömmen måste återskapas.
  • En ny ström genererar ett nytt ström-ARN.

Strömmar och DynamoDB läskapacitetsenheter

 

• Strömläsningar förbrukar INTE dina läskapacitetsenheter (RCU).
• Att aktivera strömmar påverkar inte det allokerade genomflödet.

Strömpostar

• Varje strömpost innehåller metadata som beskriver ändringen.
• Strömmar fångar tre händelsetyper:
  • INSERT
  • MODIFY
  • REMOVE

 

• Vytyper styr vilken data som ingår i varje post.
  • KEYS_ONLY: enbart partitions- och sorteringsnyckeln.
  • NEW_IMAGE: hela posten efter ändringen.
  • OLD_IMAGE: hela posten före ändringen.
  • NEW_AND_OLD_IMAGES: posten före och efter.
• NEW_AND_OLD_IMAGES är förstahandsvalet för granskning.
• Krävs för DynamoDB Global Tables.

• Strömmar bevarar ordningen per partitionsnyckel.
• Lambda bearbetar poster i batchar.
  • Sparar framsteg efter varje lyckad batch.
  • Misslyckade batchar körs om.
  • Återförsök fortsätter tills det lyckas eller posterna löper ut.

 

 

• Lambda är den vanligaste strömkonsumenten.
• Den använder en pollningsbaserad händelsekällsmappning.
• Läser poster från strömmen.
• Anropar din funktion med batchar av poster.

Arkitekturmönster

 

• Ett vanligt mönster från start till slut:
  • En post uppdateras i DynamoDB.
  • Ändringen genererar en strömpost.
  • Posten utlöser Lambda för bearbetning.

Skalning

 

• Strömmar är internt uppdelade i shards.
  • Liknar Kinesis Data Streams.
• Varje shard tillåter upp till två samtidiga konsumenter.
  • Att överskrida denna gräns är en vanlig orsak till läsningsbegränsning.

• Lambdas parallellkörning skalas med antalet shards.
• Justera bearbetningen med:
  • BatchSize: max antal poster per anrop.
  • MaximumBatchingWindow: väntetid innan en partiell batch.
  • MaximumRetryAttempts: återförsök innan felmål.
  • MaximumRecordAgeInSeconds: ignorera poster äldre än detta.
  • ParallelizationFactor: parallell bearbetning per shard (max 10).

Filtrering och rullande fönster

• Lambda stöder filterkriterier.
  • Ignorerar poster innan funktionen anropas.
  • Minskar onödiga anrop och kostnader.
• Lambda stöder rullande fönster (tumbling windows).
  • Aggregerar tillstånd över batchar i en shard.

 

Hantera dubblettposter

• Strömmar fångar varje ändring exakt en gång.
• Lambda bearbetar poster med at-least-once-semantik.
  • Återförsök kan bearbeta samma post igen.
• Designa konsumenter så att de är idempotenta.
• Ett vanligt mönster: lagra bearbetat eventID eller SequenceNumber.
  • Hoppa över poster du redan har hanterat.
  • Båda är stabila över återförsök.
  • Tillförlitliga idempotensnycklar.

 

Felhantering

 

• ReportBatchItemFailures kör bara om de poster som misslyckades.
• Hantera Lambda-fel med:
  • BisectBatchOnFunctionError för batchdelning.
  • Återförsöksinställningar.
  • Felmål för problembatchar som tömmer sina återförsök.

Integration mellan DynamoDB och Kinesis

 

• Tabeller kan skicka ändringar direkt till Kinesis Data Streams.
  • Via funktionen Kinesis Data Streams för DynamoDB.
  • En separat, parallell funktion – inte en kedjeintegrerad sådan.
  • Händelser flödar INTE genom DynamoDB Streams.
• Båda kan köras på samma tabell samtidigt.
  • De fungerar oberoende av varandra.
  • Möjliggör bredare strömmings- och analysarkitekturer.

Övervakning: vanliga problem

 

• Vanliga driftsproblem att hålla koll på:
  • Heta partitioner.
  • Misslyckade återförsök.
  • Dubbelbearbetning.
  • Begränsning och konsumentfördröjning.

Övervakning: CloudWatch-mätvärden

• Viktiga CloudWatch-mätvärden att övervaka:
  • Lambda Errors: synliggör kod- eller nedströmsproblem.
  • IteratorAge: höga värden indikerar långsamma konsumenter.
  • Begränsningsmätvärden: läsgränser som överskrids.
  • Batchbearbetningsfel: poster skickade till en DLQ.

 

Säkerhet

• Åtkomst till strömmar styrs med IAM-behörigheter.
• Strömmar ärver tabellens krypteringsinställningar.
  • Inklusive kryptering i vila på serversidan med KMS.
• Tillämpa minsta möjliga behörighetspolicyer för konsumenter och nedströmsprocessorer.

 

Nu kör vi en övning!

Utveckla applikationer på AWS