DynamoDB Streams och globala tabeller

DynamoDB Streams samlar en tidsordnad sekvens av ändringar på objektnivå i en DynamoDB-tabell. Varje gång ett objekt skapas, uppdateras eller tas bort skriver DynamoDB en post i streamen som beskriver ändringen. Streamposter är tillgängliga i 24 timmar efter att de har skrivits.

Streams är grunden för händelsestyrda arkitekturer med DynamoDB. Vanliga användningsområden är att utlösa Lambda-funktioner för realtidsbearbetning, underhålla en granskningslogg, replikera data till en annan lagringsplats eller ogiltigförklara en cache när data ändras.

När du aktiverar en stream väljer du en StreamViewType som avgör vilka data varje streampost innehåller:

• KEYS_ONLY: endast primärnyckelattributen för det ändrade objektet
• NEW_IMAGE: hela objektet så som det ser ut efter ändringen
• OLD_IMAGE: hela objektet så som det såg ut före ändringen
• NEW_AND_OLD_IMAGES: både objektets tillstånd före och efter ändringen

Välj NEW_AND_OLD_IMAGES för granskning (för att se vad som ändrades), NEW_IMAGE för replikering eller cacheuppdateringar och KEYS_ONLY när du bara behöver veta vilket objekt som ändrades och hämtar det aktuella tillståndet separat.

Det vanligaste sättet att konsumera en DynamoDB Stream är med AWS Lambda. Lambda läser av streamen och anropar din funktion med en batch streamposter. Lambda hanterar automatiskt avläsning, checkpoint-hantering och nya försök.

Viktiga konfigurationsparametrar är batchstorlek (antal poster per anrop, upp till 10 000), bisect on error (delar en misslyckad batch för att isolera den felaktiga posten) och destination on failure (SQS eller SNS för poster som inte kan bearbetas). Lambda läser från varje shard parallellt, så parallelliteten motsvarar antalet shards i streamen.

Praktiska användningsområden för DynamoDB Streams på SAA-C03-examen:

• Replikering mellan regioner: Lambda läser streamen och skriver ändringarna till en tabell i en annan Region (innan Global Tables fanns var detta standardmönstret)
• Ogiltigförklaring av ElastiCache: när ett DynamoDB-objekt ändras ogiltigförklarar eller uppdaterar Lambda motsvarande cache-nyckel
• Synkronisering av sökindex: skicka objektändringar till OpenSearch Service för att aktivera fulltextsökning i DynamoDB-data
• Granskningsloggning: skriv varje ändring till S3 eller ett lager för regelefterlevnad
• Händelsestyrda mikrotjänster: utlös nedströms tjänster när specifika objekt ändras

DynamoDB Global Tables tillhandahåller fullt hanterad replikering i flera regioner med aktiv-aktiv-drift. Varje Region får en fullständig kopia av tabellen, och alla kopior kan ta emot skrivningar samtidigt. Skrivningar i valfri Region replikeras asynkront till alla andra Regioner inom ungefär 1 sekund.

Global Tables möjliggör två viktiga scenarier: läsningar och skrivningar med låg latens för användare över hela världen (varje användare skriver till och läser från närmaste Region) samt aktiv-aktiv-katastrofåterställning i flera regioner (programmet fortsätter att köras i valfri överlevande Region utan dataförlust utöver den senaste replikeringen).

För att skapa en Global Table skapar du först en tabell med DynamoDB Streams aktiverat (NEW_AND_OLD_IMAGES krävs internt för Global Tables). Därefter lägger du till replikregioner. AWS skapar en replikatabell i varje tillagd Region och börjar synkronisera data i båda riktningarna.

Global Tables (Version 2019.11.21) är den aktuella standarden och stöder On-Demand eller Provisioned capacity med Auto Scaling. Varje regionsreplik måste ha samma tabellnamn. Du kan lägga till eller ta bort Regioner från en Global Table när som helst.

Eftersom Global Tables tillåter skrivningar i flera Regioner samtidigt kan skrivkonflikter uppstå om två Regioner uppdaterar samma objekt nästan samtidigt. DynamoDB löser konflikter med metoden last-writer-wins, baserat på tidsstämplar som lagras i streamposterna.

I praktiken innebär det att två nästan samtidiga motstridiga uppdateringar leder till att den ena vinner och den andra skrivs över. Program bör utformas så att samtidiga skrivningar till samma objekt från olika Regioner undviks. Om konflikter är vanliga bör du överväga att dirigera alla skrivningar för en viss användare eller entitet till en enda hemregion.

Med Global Tables replikeras skrivningar i en Region automatiskt till alla andra Regioner. Varje replikerad skrivning förbrukar WCU:er i målregionerna – om du har 3 Regioner kostar en enda skrivning ungefär 3× WCU:er i alla Regioner sammanlagt. Planera kapaciteten därefter.

Läsningar i varje Region förbrukar den lokala replikans RCU:er. Eventually consistent-läsningar (standardinställningen) använder lokala data, medan strongly consistent-läsningar inte stöds mellan Regioner. För de flesta globala program är eventual consistency med en fördröjning på cirka 1 sekund mellan Regioner acceptabelt.

En viktig skillnad inför SAA-C03-examen: DynamoDB Global Tables är multi-active (alla Regioner accepterar både läsningar OCH skrivningar), medan RDS Read Replicas mellan regioner är read-only (du kan endast befordra en replik så att den kan ta emot skrivningar, vilket bryter replikeringen).

Använd DynamoDB Global Tables när du behöver: aktiv-aktiv-skrivningar i flera regioner, åtkomst under 100 ms globalt eller DR i flera regioner med zero RPO för NoSQL-data. Använd RDS-replikor mellan regioner när du behöver: global lässkalning för en relationsdatabas eller en varm DR-standby som du kan befordra vid failover.

Vanliga arkitekturmönster som kombinerar Streams och Lambda:

• Fan-out: Lambda läser streamen och publicerar till SNS, som distribuerar med fan-out till flera SQS-köer för oberoende konsumenter
• Aggregering: Lambda samlar ändringar och uppdaterar aggregerade totaler i en separat DynamoDB-tabell (till exempel det dagliga antalet order)
• Write-behind-cache: vid varje streamhändelse uppdaterar Lambda ElastiCache så att läsningar kan betjänas från cachen
• Avisering: streamen utlöser Lambda, som skickar ett SES-e-postmeddelande eller en SNS-pushavisering när ett specifikt villkor ändras

Som ett alternativ till DynamoDB Streams kan ni styra ändringar på objektnivå till en Amazon Kinesis Data Stream. Detta är användbart när ni behöver längre lagring (upp till 1 år jämfört med 24 timmar för inbyggda DynamoDB Streams), fler konsumenter eller integration med tjänster som läser från Kinesis.

Integrering med Kinesis Data Streams aktiveras per tabell och ersätter inte DynamoDB Streams – ni kan ha båda aktiverade samtidigt. Detta är en nyare funktion (2021) som utökar pipelinen för ändringshändelser i DynamoDB utan att anpassad replikeringslogik krävs.

I den här lektionen har ni lärt er att DynamoDB Streams fångar ändringar på objektnivå i 24 timmar och integreras med Lambda för händelsestyrd bearbetning, att Global Tables tillhandahåller multiaktiv replikering mellan flera regioner med konflikthantering enligt principen att den senaste skrivningen vinner, samt att integrering med Kinesis Data Streams förlänger lagringstiden bortom strömfönstret på 24 timmar. Härnäst utforskar vi Route 53-hostade zoner och typer av DNS-poster.