Tabeller, elementer og primærnøkler

En enkel primærnøkkel består av ett attributt kalt partisjonsnøkkelen (også kalt hash-nøkkelen). DynamoDB bruker en intern hash-funksjon på partisjonsnøkkelverdien for å avgjøre hvilken lagringspartisjon som inneholder elementet. Alle elementer med samme partisjonsnøkkelverdi lagres sammen.

Med en enkel primærnøkkel kan ingen to elementer i tabellen ha samme partisjonsnøkkelverdi – den identifiserer hvert element entydig. Denne utformingen passer for tabeller der du alltid får tilgang til data via en unik identifikator, for eksempel en bruker-ID eller ordre-ID.

En sammensatt primærnøkkel bruker både en partisjonsnøkkel og en sorteringsnøkkel (også kalt områdenøkkelen). Elementer med samme partisjonsnøkkel lagres sammen og sorteres etter sorteringsnøkkelverdien, noe som muliggjør områdespørringer innenfor en partisjon.

Denne utformingen er svært fleksibel: Flere elementer kan dele samme partisjonsnøkkel så lenge sorteringsnøklene er forskjellige. En tabell med navnet Orders kan for eksempel bruke CustomerId som partisjonsnøkkel og OrderDate som sorteringsnøkkel, slik at du kan spørre etter alle ordrene for en kunde sortert etter dato.

Å velge riktig partisjonsnøkkel er den viktigste designbeslutningen i DynamoDB. En god partisjonsnøkkel har høy kardinalitet (mange forskjellige verdier) og fordeler tilgangen jevnt på tvers av partisjonene. Dårlige valg fører til varme partisjoner, der én partisjon mottar uforholdsmessig mye trafikk og forårsaker struping.

Antimønstre som bør unngås: bruk av et boolsk flagg (bare to verdier), en dato som samler alle dagens skrivinger, eller et statusfelt med lav kardinalitet. Gode valg er bruker-ID, enhets-ID, tilfeldig UUID eller sammensatte verdier som tenantId#entityType.

De tre grunnleggende operasjonene for DynamoDB-elementer er:

• PutItem: skriver et nytt element eller erstatter fullstendig et eksisterende element med samme primærnøkkel
• GetItem: henter ett element ved hjelp av den nøyaktige primærnøkkelen (krever hele nøkkelen – partisjonsnøkkelen og, hvis den er sammensatt, sorteringsnøkkelen)
• DeleteItem: fjerner et element ved hjelp av den nøyaktige primærnøkkelen

Alle tre operasjonene er atomiske på elementnivå. Som standard bruker GetItem eventually consistent-lesinger. Hvis du legger til --consistent-read, tvinges en strongly consistent-lesing som alltid returnerer den sist skrevne verdien.

UpdateItem endrer bestemte attributter i et eksisterende element uten å erstatte det fullstendig, i motsetning til PutItem. Du kan legge til attributter, fjerne attributter eller utføre aritmetikk på Number-attributter atomisk (for eksempel øke en teller).

Betingelsesuttrykk lar deg angi at en operasjon bare skal lykkes hvis en betingelse er sann. Du kan for eksempel bare oppdatere statusen til et element hvis den nå er PENDING. Dette implementerer mønstre for optimistisk låsing uten transaksjoner og er en viktig designteknikk i DynamoDB.

Query henter elementer som deler samme partisjonsnøkkelverdi, eventuelt filtrert etter betingelser for sorteringsnøkkelen. Query er effektiv, fordi den bare leser den aktuelle partisjonen. Du kan bruke betingelser for sorteringsnøkkelen som begins_with, between, =, < og > for å begrense resultatene i partisjonen.

Scan leser hvert element i tabellen og bruker deretter et valgfritt filteruttrykk. Scan er kostbart for store tabeller og bør unngås i produksjonens spørringsmønstre. Hvis du ofte trenger Scan, bør du vurdere tabellutformingen på nytt eller legge til en Global Secondary Index.

DynamoDB lagrer tre kopier av dataene dine på tvers av flere AZ-er. Eventuelt konsistente lesinger (standardinnstillingen) kan returnere en litt utdatert verdi hvis en nylig skriving ennå ikke har blitt replikert til alle kopiene – men de bruker halvparten av lesekapasitetsenhetene sammenlignet med sterkt konsistente lesinger.

Sterkt konsistente lesinger returnerer alltid den sist bekreftede skrivningen, men koster dobbelt så mange RCU-er og er ikke tilgjengelige på Global Secondary Indexes. Velg eventuelt konsistente lesinger for arbeidsbelastninger med høy gjennomstrømming og mange lesinger, og sterkt konsistente lesinger bare når applikasjonen krever de aller nyeste dataene.

DynamoDB støtter ACID-transaksjoner via TransactWriteItems og TransactGetItems. En transaksjon kan gruppere opptil 100 skriveoperasjoner på tvers av flere elementer og til og med flere tabeller, slik at enten alle lykkes, eller alle rulles atomisk tilbake.

Bruk transaksjoner i scenarier som pengeoverføring mellom kontoer (trekk fra ett element og godskriv et annet) eller bestilling av et sete (kontroller tilgjengeligheten og reserver setet atomisk). Transaksjoner koster dobbelt så mange vanlige RCU-er/WCU-er, så bruk dem bare når atomisitet på tvers av flere elementer faktisk er nødvendig.

DynamoDBs grense på 400 KB per element påvirker datamodelleringen. For store datamengder (for eksempel bilder og store dokumenter) lagrer du de binære dataene i S3 og bare S3-objektnøkkelen i DynamoDB. For dypt nestede hierarkiske data modellerer du hver nodetype med sitt eget mønster for partisjonsnøkkel ved hjelp av single-table design – én tabell inneholder flere entitetstyper som skilles fra hverandre ved hjelp av prefikset for partisjonsnøkkelen og mønsteret for sorteringsnøkkelen.

Single-table design minimerer antallet tabeller og muliggjør effektiv tilgang basert på tilgangsmønstre ved å plassere relaterte elementer i samme partisjon. Dette er en avansert teknikk som reduserer driftsbelastningen og forbedrer ytelsen for komplekse tilgangsmønstre.

I denne leksjonen lærte du at DynamoDB-tabeller inneholder skjemaløse elementer med en grense på 400 KB, at enkle primærnøkler bare bruker en partisjonsnøkkel, mens sammensatte nøkler også har en sorteringsnøkkel for områdespørringer, og at partisjonsnøkler med høy kardinalitet forhindrer varme partisjoner. Bruk Query i stedet for Scan for effektiv tilgang. Deretter skal vi se nærmere på kapasitetsmodusene provisioned og on-demand.