30 nov. 2025·8 min
Amazon DynamoDB förklarat: bygga skalbara system
Lär dig vad Amazon DynamoDB är, hur dess NoSQL-modell fungerar och praktiska designmönster för skalbara, låglatenssystem och mikrotjänster.
Lär dig vad Amazon DynamoDB är, hur dess NoSQL-modell fungerar och praktiska designmönster för skalbara, låglatenssystem och mikrotjänster.
Amazon DynamoDB är en helt hanterad NoSQL-databastjänst från AWS, utformad för applikationer som behöver konsekvent låg latens för läsningar och skrivningar i praktiskt taget vilken skala som helst. “Helt hanterad” betyder att AWS tar hand om infrastruktur—hårdvaruanskaffning, replikering, patchning och många driftuppgifter—så team kan fokusera på att leverera funktioner istället för att driva databasserver.
I grunden lagrar DynamoDB data som items (rader) i tabeller, men varje item kan ha flexibla attribut. Datamodellen förstås bäst som en blandning av:
Team väljer DynamoDB när de vill ha förutsägbar prestanda och enklare drift för arbetsbelastningar som inte passar bra för relationsdatabas-joins. Det används ofta för mikrotjänster (varje tjänst äger sin data), serverlösa appar med burstig trafik och händelsestyrda system som reagerar på datändringar.
Det här inlägget går igenom byggstenarna (tabeller, nycklar och index), hur man modellerar efter accessmönster (inklusive single-table-design), hur skalning och kapacitetslägen fungerar, samt praktiska mönster för att strömma ändringar in i en händelsestyrd arkitektur.
DynamoDB är organiserat kring några enkla byggstenar, men detaljerna spelar roll eftersom de bestämmer hur du modellerar data och hur snabba (och kostnadseffektiva) förfrågningar blir.
En tabell är den högsta behållaren. Varje post i en tabell är ett item (liknar en rad), och varje item är en uppsättning attribut (liknar kolumner).
Till skillnad från relationsdatabaser behöver items i samma tabell inte ha samma attribut. Ett item kan ha {status, total, customerId}, medan ett annat innehåller {status, shipmentTracking}—DynamoDB kräver inget fast schema.
Varje item identifieras unikt av en primärnyckel, och DynamoDB stödjer två typer:
I praktiken möjliggör kompositnycklar “grupperade” accessmönster som “alla order för en kund, nyast först”.
En Query läser items via primärnyckel (eller en indexnyckel). Den riktar sig mot en specifik partitionsnyckel och kan filtrera via sorteringsnyckelintervall—det här är den effektiva, föredragna vägen.
En Scan går igenom hela tabellen (eller indexet) och filtrerar efteråt. Det är lätt att börja med, men brukar vara långsammare och dyrare i stor skala.
Några begränsningar du märker tidigt:
Dessa grundprinciper ligger till grund för allt som följer: accessmönster, indexval och prestandaegenskaper.
DynamoDB beskrivs ofta både som en key-value-butik och en dokumentdatabas. Det är korrekt, men det hjälper att förstå vad vardera innebär i dagligt designarbete.
I grunden hämtar du data via nyckel. Ange primärnyckelvärdena så returnerar DynamoDB ett enskilt item. Denna nyckelbaserade uppslagning ger förutsägbar, låg latens för många arbetsbelastningar.
Samtidigt kan ett item innehålla nästlade attribut (maps och lists), vilket gör att det känns som en dokumentdatabas: du kan lagra strukturerade payloads utan att definiera ett styvt schema i förväg.
Items passar naturligt för JSON-liknande data:
profile.name, profile.address).Detta är en bra passform när en entitet vanligtvis läses som helhet—som en användarprofil, en kundvagn eller en konfigurationspaket.
DynamoDB stödjer inte server-side joins. Om din app behöver hämta “en order plus dess orderrader plus leveransstatus” i en enda läsväg, kommer du ofta att denormalisera: kopiera vissa attribut till flera items, eller bädda in små underrubriker direkt i ett item.
Denormalisering ökar skrivkomplexitet och kan skapa uppdateringsfanout. Vinsten är färre rundresor och snabbare läsningar—ofta avgörande för skalbara system.
De snabbaste DynamoDB-förfrågningarna är de du kan uttrycka som “ge mig den här partitionen” (och eventuellt “inom denna partition, ge mig detta intervall”). Därför handlar val av nyckel främst om hur du läser data, inte bara hur du lagrar det.
Partitionsnyckeln bestämmer vilken fysisk partition som lagrar ett item. DynamoDB hash:ar detta värde för att sprida data och trafik. Om många förfrågningar koncentreras på ett litet set partitionsnyckelvärden kan du skapa “heta” partitioner och nå genomströmgränser även om tabellen i stort är inaktiv.
Bra partitionsnycklar:
"GLOBAL")Med en sorteringsnyckel lagras items som delar samma partitionsnyckel tillsammans och ordnas efter sorteringsnyckeln. Detta möjliggör effektiva:
BETWEEN, begins_with)Ett vanligt mönster är att komponera sorteringsnyckeln, till exempel TYPE#id eller TS#2025-12-22T10:00:00Z, för att stödja flera frågeformer utan extra tabeller.
PK = USER#<id> (enkel GetItem)PK = USER#<id>, SK begins_with ORDER# (eller SK = CREATED_AT#...)PK = DEVICE#<id>, SK = TS#<timestamp> med BETWEEN för tidsfönsterOm din partitionsnyckel ligger i linje med dina högst volymmässiga frågor och distribuerar jämnt, får du konsekvent låg latens för läsningar och skrivningar. Gör den det inte, kompenserar du med scans, filter eller extra index—varje tillägg ökar kostnad och risk för heta nycklar.
Sekundära index ger DynamoDB alternativa frågevägar utöver tabellens primärnyckel. Istället för att omforma bas-tabellen varje gång ett nytt accessmönster uppstår kan du lägga till ett index som omnycklar samma items för en annan fråga.
Ett Global Secondary Index (GSI) har sin egen partitionsnyckel (och valfri sorteringsnyckel) som kan vara helt annorlunda än tabellens. Det är “globalt” eftersom det spänner över alla tabellpartitioner och kan läggas till eller tas bort när som helst. Använd en GSI när du behöver ett nytt accessmönster som inte passar den ursprungliga nyckeldesignen—t.ex. fråga order efter customerId när tabellen är keyed efter orderId.
Ett Local Secondary Index (LSI) delar samma partitionsnyckel som bas-tabellen men använder en annan sorteringsnyckel. LSI måste definieras vid tabellskapande. De är användbara när du vill ha flera sorteringsordningar inom samma enhetsgrupp (samma partitionsnyckel), som att hämta en kunds order sorterade efter createdAt vs status.
Projicering bestämmer vilka attribut DynamoDB lagrar i indexet:
Varje skrivning till bas-tabellen kan trigga skrivningar till ett eller flera index. Fler GSIs plus breda projiceringar ökar skrivkostnaden och kapacitetsförbrukningen. Planera index runt stabila accessmönster och håll projicerade attribut minimala när möjligt.
DynamoDB-skalning börjar med ett val: On-Demand eller Provisioned kapacitet. Båda kan nå mycket hög genomströmning, men de beter sig olika vid förändrad trafik.
On-Demand är enklast: du betalar per förfrågan och DynamoDB hanterar automatiskt varierande belastning. Det passar oförutsägbar trafik, tidiga produkter och burstiga arbetsbelastningar där du inte vill hantera kapacitet.
Provisioned innebär kapacitetsplanering: du specificerar (eller autoskalar) läs- och skrivgenomströmning och får mer förutsägbar prissättning vid jämn användning. Det är ofta billigare för kända, stabila arbetsbelastningar.
Provisioned throughput mäts i:
Din item-storlek och accessmönster bestämmer verklig kostnad: större items, stark konsistens och scans kan snabbt förbruka kapacitet.
Autoskalning justerar provisionerade RCUs/WCUs baserat på utnyttjandemål. Det hjälper vid gradvis tillväxt och förutsägbara cykler, men det är inte omedelbart. Plötsliga spikar kan fortfarande throttlas om kapaciteten inte hinner skala upp, och det kan inte lösa en het partitionsnyckel som koncentrerar trafik.
DynamoDB Accelerator (DAX) är en in-memory-cache som kan minska läslatens och avlasta upprepade läsningar (t.ex. populära produktsidor, sessionsuppslag, leaderboards). Den är mest användbar när många klienter upprepade gånger begär samma items; den hjälper inte skrivtunga mönster och ersätter inte noggrann nyckeldesign.
DynamoDB låter dig väga läsgarantier mot latens och kostnad, så det är viktigt att vara tydlig med vad “korrekt” betyder för varje operation.
Som standard använder GetItem och Query eventually consistent läsningar: du kan kortvarigt se ett äldre värde direkt efter en skrivning.
Med strongly consistent läsningar (ett alternativ för läsningar från bas-tabellen i en region) garanterar DynamoDB att du ser den senaste bekräftade skrivningen. Stark konsistens kostar mer i läskapacitet och kan öka tail-latens, så spara det för verkligt kritiska läsningar.
Stark konsistens är viktig för läsningar som styr irreversibla åtgärder:
För räknare är det säkraste ofta inte “stark läsning följt av skrivning”, utan en atomisk uppdatering (t.ex. UpdateItem med ADD) så att inkrement inte går förlorade.
DynamoDB-transaktioner (TransactWriteItems, TransactGetItems) ger ACID-semantik över upp till 25 items. De är användbara när du måste uppdatera flera items tillsammans—som att skriva en order och reservera lager—eller upprätthålla invariants som inte tål mellanliggande tillstånd.
Retries är norm i distribuerade system. Gör skrivningar idempotenta så att retries inte duplicerar effekter:
ConditionExpression (t.ex. “only create if attribute_not_exists”)Korrekthet i DynamoDB handlar mest om att välja rätt konsistensnivå och designa operationer så att retries inte förstör datan.
DynamoDB lagrar tabellens data över flera fysiska partitioner. Varje partition har begränsad genomströmning för läsningar och skrivningar, samt en gräns för hur mycket data den kan hålla. Din partitionsnyckel bestämmer var ett item bor; om för många förfrågningar riktas mot samma partitionsnyckelvärde (eller ett litet set värden) blir partitionen flaskhalsen.
Heta partitioner orsakas vanligtvis av nyckelval som koncentrerar trafik: en “global” partitionsnyckel som USER#1, TENANT#default eller STATUS#OPEN, eller tidsordnade mönster där alla skriver till “nu” under en partition.
Du ser typiskt:
ProvisionedThroughputExceededException) för en delmängd nycklarDesigna för distribution först, sedan för frågekomfort:
TENANT#<id> istället för en delad konstant).ORDER#<id>#<shard> för att sprida skrivningar över N shards, och fråga över shards när det behövs.METRIC#2025-12-22T10) för att förhindra att “alla skriver till senaste item.”För oförutsägbara spikar kan on-demand kapacitet absorbera belastningen (inom servicebegränsningar). Med provisioned kapacitet, använd autoskalning och implementera klient-sida exponentiell backoff med jitter vid throttling för att undvika synkroniserade retries som förstärker spiken.
DynamoDB-datamodellering börjar från accessmönster, inte från ER-diagram. Du designar nycklar så att de frågor du behöver blir snabba Query-operationer, medan allt annat antingen undviks eller hanteras asynkront.
“Single-table design” innebär att flera entitetstyper (användare, order, meddelanden) lagras i en tabell och använder konsekventa nyckelkonventioner för att hämta relaterad data i en enda Query. Det minskar cross-entity rundresor och håller latensen förutsägbar.
Ett vanligt tillvägagångssätt är kompositnycklar:
PK grupperar en logisk partition (t.ex. USER#123)SK ordnar items inom den gruppen (t.ex. PROFILE, ORDER#2025-12-01, MSG#000123)Detta låter dig hämta “allt för en användare” eller “bara order för en användare” genom att välja en sorteringsnyckelprefix.
För graf-liknande relationer fungerar en adjacency list bra: lagra kanter som items.
PK = USER#123, SK = FOLLOWS#USER#456För omvända uppslag eller verklig many-to-many, lägg till ett inverterat kant-item eller projicera till en GSI beroende på läsvägar.
För händelser och mätvärden, undvik obegränsade partitioner genom att bucketa:
PK = DEVICE#9#2025-12-22 (enhet + dag)SK = TS#1734825600 (tidsstämpel)Använd TTL för att automatiskt ta bort gamla punkter, och håll aggregeringar (tim-/dagssummeringar) som separata items för snabba dashboards.
Om du vill ha en djupare uppfräschning av nyckelkonventioner, se partition-key-and-sort-key-design.
DynamoDB Streams är DynamoDB:s inbyggda change data capture (CDC)-flöde. När det är aktiverat på en tabell producerar varje insert, update eller delete ett stream-record som downstream-konsumenter kan reagera på—utan att poll:a tabellen.
Ett stream-record innehåller nycklar och (valfritt) itemets gamla och/eller nya bild, beroende på stream view type du väljer (keys only, new image, old image, both). Records grupperas i shards, som du läser sekventiellt.
Ett vanligt upplägg är DynamoDB Streams → AWS Lambda, där varje batch records triggar en funktion. Andra konsumenter är också möjliga (egna konsumenter eller vidarekoppling till analys/loggsystem).
Typiska arbetsflöden inkluderar:
Detta håller primärtabellen optimerad för låg latens vid läs/skriv medan härledda arbeten flyttas till asynkrona konsumenter.
Streams ger ordnad bearbetning per shard (vilket ofta korrelerar med partitionsnyckeln), men ingen global ordning över alla nycklar. Leverans är at-least-once, så dubbletter kan förekomma.
För att hantera detta säkert:
Med dessa garantier i åtanke kan Streams göra DynamoDB till en robust ryggrad för händelsestyrda system.
DynamoDB är designat för hög tillgänglighet genom att sprida data över flera Availability Zones inom en region. För de flesta team ger de praktiska tillförlitlighetsvinsterna att ha en tydlig backupstrategi, förstå replikationsalternativ och övervaka rätt metrik.
On-demand backups är manuella (eller automatiserade) snapshots du tar när du vill ha en känd återställningspunkt—innan en migration, efter en release eller före en stor backfill. De är bra som "bokmärken".
Point-in-time recovery (PITR) fångar kontinuerligt ändringar så att du kan återställa tabellen till vilken sekund som helst inom retentionsfönstret. PITR är säkerhetsnätet för misstag, dåliga deploys eller felaktiga skrivningar.
Om du behöver multi-region-resiliens eller låg latens nära användare, replikerar Global Tables data över valda regioner. De förenklar failover-planering men inför fördröjning i korsregionsreplikering och konfliktlösningsöverväganden—så håll skrivmönster och item-ägandeskap tydliga.
Minst bör du larma på:
Dessa signaler visar ofta heta-partitionsproblem, otillräcklig kapacitet eller oväntade accessmönster.
Vid throttling, identifiera först accessmönstret som orsakar det, mildra genom att tillfälligt byta till on-demand eller öka provisioned kapacitet, och överväg sharding av heta nycklar.
Vid partiella störningar eller förhöjda fel, minska blast-ytan: inaktivera icke-kritisk trafik, försök igen med jitterad backoff och degradera gracilt (t.ex. servera cachade läsningar) tills tabellen stabiliseras.
DynamoDB-säkerhet handlar mest om att tajta åt vem som kan kalla vilka API-åtgärder, från var och på vilka nycklar. Eftersom tabeller kan innehålla många entitetstyper (och ibland många tenants) bör accesskontroll designas tillsammans med datamodellen.
Börja med identitetsbaserade IAM-policys som begränsar åtgärder (t.ex. dynamodb:GetItem, Query, PutItem) till minsta nödvändiga och scope:a dem till specifika table ARNs.
För finare kontroll, använd dynamodb:LeadingKeys för att begränsa åtkomst per partitionsnyckelvärde—användbart när en tjänst eller tenant bara ska läsa/skriva i sitt eget keyspace.
DynamoDB krypterar data i vila som standard med antingen AWS-ägda nycklar eller en kundhanterad KMS-nyckel. Om du har regelkrav, verifiera:
För kryptering i transit, se till att klienter använder HTTPS (AWS SDKs gör detta som standard). Om du terminera TLS i en proxy, verifiera att hoppet mellan proxyn och DynamoDB fortfarande är krypterat.
Använd en VPC Gateway Endpoint för DynamoDB så att trafiken hålls på AWS-nätverket och du kan applicera endpoint-policys för att begränsa åtkomst. Kombinera detta med egress-kontroller (NACLs, security groups och routing) för att undvika att “allt kan nå det publika internet”.
För delade tabeller, inkludera en tenantidentifierare i partitionsnyckeln (t.ex. TENANT#<id>), och tillämpa tenant-isolering med IAM-villkor på dynamodb:LeadingKeys.
Om du behöver starkare isolering, överväg separata tabeller per tenant eller per miljö, och använd delade-tabeller när operativ enkelhet och kostnadseffektivitet överväger striktare blast-radie-krav.
DynamoDB är ofta “billigt när du är precis, dyrt när du är vag.” Kostnader följer typiskt dina accessmönster, så det bästa optimeringsarbetet börjar med att göra mönstren explicita.
Din faktura formas huvudsakligen av:
En vanlig överraskning: varje skrivning till en tabell är också en skrivning till varje påverkat GSI, så “bara ett index till” kan multiplicera skrivkostnaden.
Bra nyckeldesign minskar behovet av dyra operationer. Om du ofta når efter Scan betalar du för att läsa data du ändå kastar.
Föredra:
Query efter partitionsnyckel (och eventuellt sorteringsnyckelvillkor)Om ett accessmönster är sällsynt, överväg att serva det via en separat tabell, ett ETL-jobb eller en cachead read-model snarare än ett permanent GSI.
Använd TTL för att automatiskt ta bort kortlivade items (sessions, temporära tokens, mellanliggande arbetsflöden). Det minskar lagring och håller index mindre över tid.
För append-tung data (events, loggar), kombinera TTL med sorteringsnyckeldesigner som låter dig fråga “endast senaste”, så du inte rutinmässigt rör kall historik.
I provisioned-läge, sätt konservativa baslinjer och skala med autoskalning baserat på verkliga metrik. I on-demand-läge, övervaka ineffektiva mönster (stora items, pratiga klienter) som driver förfrågningsvolym.
Behandla Scan som en sista utväg—när du verkligen behöver fulltabellsbearbetning, schemalägg den off-peak eller kör den som ett kontrollerat batchjobb med pagination och backoff.
DynamoDB briljerar när din applikation kan uttryckas som en uppsättning väl definierade accessmönster och du behöver konsekvent låg latens i stor skala. Om du kan beskriva dina läsningar och skrivningar i förväg (genom partitionsnyckel, sorteringsnyckel och ett fåtal index) är det ofta ett av de enklaste sätten att drifta en högtilgänglig datalager.
DynamoDB är ett starkt val när du har:
Sök andra lösningar om dina kärnkrav inkluderar:
Många team behåller DynamoDB för “heta” operationella läsningar och skrivningar, och lägger till:
Om du validerar accessmönster och single-table-konventioner spelar snabbhet roll. Team prototypbygger ibland kring den omgivande tjänsten och UI i Koder.ai (en vibe-coding-plattform som bygger webb-, server- och mobilappar från chatt) och itererar sedan på DynamoDB-nyckeldesignen när verkliga frågevägar framträder. Även om din produktionsbackend skiljer sig, hjälper snabba end-to-end-prototyper att avslöja vilka frågor som bör vara Query-operationer kontra vilka som av misstag skulle bli dyra Scan-jobb.
Validera: (1) dina toppfrågor är kända och nyckelbaserade, (2) korrekthetskraven matchar konsistensmodellen, (3) förväntade item-storlekar och tillväxt är förstådda, och (4) kostnadsmodellen (on-demand vs provisioned plus autoskalning) passar din budget.
DynamoDB är en helt hanterad NoSQL-databas på AWS utformad för konsekvent låg latens vid läsning/skrivning i mycket stora skalor. Team använder den när de kan definiera nyckelbaserade accessmönster (hämta efter ID, lista efter ägare, tidsintervall) och vill slippa driva databasinfrastruktur.
Den är särskilt vanlig i mikrotjänster, serverlösa appar och händelsestyrda system.
En tabell innehåller items (liknande rader). Varje item är en flexibel uppsättning attribut (liknande kolumner) och kan innehålla inbäddade data.
DynamoDB fungerar bra när en förfrågan vanligtvis behöver “hela entiteten”, eftersom items kan innehålla maps och lists (JSON-liknande strukturer).
En partitionsnyckel ensam identifierar ett item unikt (enkel primärnyckel). En partitionsnyckel + sorteringsnyckel (kompositnyckel) tillåter flera items att dela samma partitionsnyckel samtidigt som de blir unikt identifierbara och sorterade av sorteringsnyckeln.
Kompositnycklar möjliggör mönster som:
Använd Query när du kan ange partitionsnyckeln (och eventuellt en sorteringsnyckelvillkor). Det är den snabba, skalbara vägen.
Använd Scan endast när du verkligen behöver läsa allt; den går igenom hela tabellen eller indexet och filtrerar i efterhand, vilket oftast är långsammare och dyrare.
Om du skannar ofta är det en signal att din nyckel- eller indexdesign behöver justeras.
Sekundära index ger alternativa frågevägar.
Index ökar skrivkostnaden eftersom skrivningar replikeras in i indexet.
Välj On-Demand om trafiken är oförutsägbar, spikig eller om du inte vill hantera kapacitet. Du betalar per förfrågan.
Välj Provisioned om användningen är jämn/pålitlig och du vill ha mer förutsägbara kostnader. Kombinera med autoskalning, men kom ihåg att den inte alltid reagerar omedelbart på plötsliga spikar.
Som standard är läsningar eventually consistent, vilket betyder att du kortvarigt kan läsa äldre data direkt efter en skrivning.
Använd strongly consistent läsningar (när det är tillgängligt) för kritiska kontroller som måste vara aktuella, till exempel auktoriseringsbeslut eller tillstånd i ett arbetsflöde.
För korrekthet under konkurrens, föredra atomiska uppdateringar (t.ex. UpdateItem med ADD) framför read-modify-write-loopar.
Transaktioner (TransactWriteItems, TransactGetItems) ger ACID-garantier över upp till 25 items.
Använd dem när du måste uppdatera flera items tillsammans (t.ex. skapa en order och reservera lager) eller upprätthålla invariants som inte tål partiella uppdateringar.
De kostar mer och ökar latensen, så använd dem bara för flöden som verkligen behöver dem.
Hot partitions uppstår när för många förfrågningar riktas mot samma partitionsnyckelvärde (eller ett litet antal värden), vilket orsakar throttling även om tabellen i övrigt är underutnyttjad.
Vanliga åtgärder:
Aktivera DynamoDB Streams för att få ett ändringsflöde för inserts, updates och deletes. Ett vanligt mönster är Streams → Lambda för att trigga efterföljande arbete.
Viktenliga garantier att designa för:
Gör konsumenter (upsert per nyckel, använd villkorliga skrivningar eller spåra behandlade event-ID:n).