Datamodellering i DynamoDB

Partisjonsnøkkelen (PK) bestemmer den fysiske partisjonen (lagringsstedet) der dataene befinner seg.

• Entydighet: Hvis bare en PK brukes, må den være unik for hvert element.
• Distribusjon: En god PK fordeler data jevnt mellom partisjonene og forhindrer «hete partisjoner», som kan redusere ytelsen.
• Direkte tilgang: De kan bare spørre etter et element direkte hvis De kjenner partisjonsnøkkelen.

Når De bruker både en partisjonsnøkkel og en sorteringsnøkkel (SK), grupperes elementer med samme partisjonsnøkkel sammen og sorteres etter sorteringsnøkkelen.

• Unik kombinasjon: Kombinasjonen av PK og SK må være unik.
• Områdespørringer: Muliggjør effektive områdespørringer (for eksempel å hente alle bestillinger fra et bestemt datointervall for en bruker).
• Fleksibel sortering: Gjør det mulig å bruke ulik sortering innenfor samme partisjon.

I motsetning til relasjonsdatabaser, der De utformer tabeller og deretter finner ut hvilke spørringer som trengs, bør De med DynamoDB først liste opp alle applikasjonens tilgangsmønstre.

• Identifiser spørringer: Hvilke data trenger De? Hvordan skal De hente dem?
• Eksempler: «Hent brukerprofil etter userId», «List opp alle produkter etter category», «Finn alle kommentarer for en postId».

Tabellutformingen Deres (PK, SK, indekser) bør støtte disse mønstrene direkte.

Et vanlig og kraftig DynamoDB-mønster er design med én tabell. Det betyr at flere ulike entitetstyper (for eksempel Users, Orders og Products) lagres i én enkelt tabell.

• Fordeler: Reduserer driftsarbeidet, muliggjør effektive «mange-til-mange»-relasjoner og kan være mer kostnadseffektivt.
• Slik fungerer det: Bruker generiske attributtnavn som PK og SK samt prefikser (for eksempel USER#<id>, ORDER#<id>) for å skille mellom entitetstyper.

Hva om De trenger å spørre etter data ved hjelp av et attributt som ikke er en del av primærnøkkelen? Det er her globale sekundærindekser (GSI-er) kommer inn.

• Nye nøkler: En GSI har sin egen partisjonsnøkkel og en valgfri sorteringsnøkkel, som kan være hvilke som helst attributter fra grunntabellen.
• Uavhengig: Den er en helt separat tabell som DynamoDB vedlikeholder, slik at den kan støtte andre tilgangsmønstre.
• Eventuelt konsistent: GSI-er er eventuelt konsistente, noe som betyr at det kan ta litt tid før endringer blir spredd.

Lokale sekundærindekser (LSI-er) gjør det mulig å spørre etter data med en annen sorteringsnøkkel innenfor den samme partisjonsnøkkelen som grunntabellen.

• Samme PK, annen SK: LSI-er deler partisjonsnøkkel med grunntabellen, men har en annen sorteringsnøkkel.
• Sterkt konsistente: I motsetning til GSI-er støtter LSI-er sterkt konsistente lesinger.
• Begrenset: Må defineres når tabellen opprettes, og De kan ha opptil fem per tabell.

La oss modellere et enkelt scenario: brukere og innleggene deres. Vi ønsker å:

• Tilgangsmønster 1: Hente en brukers profil.
• Tilgangsmønster 2: Hente alle innlegg fra en bruker, sortert etter dato.

Med design med én tabell:

• PK: USER#<userId>
• SK: #METADATA# (for brukerprofilen), POST#<postId> (for innlegg)

Da kan De hente en brukers profil og innleggene deres med én enkelt spørring mot USER#<userId>-partisjonen.

Vi har gått gjennom det viktigste innen datamodellering i DynamoDB:

• Forstå hvordan partisjonsnøkler og sorteringsnøkler definerer datastrukturen.
• Utforme løsningen rundt tilgangsmønstre, ikke bare datarelasjoner.
• Utnytte fordelene ved design med én tabell for effektivitet.
• Bruke globale sekundærindekser (GSI-er) for ulike spørringer.
• Bruke lokale sekundærindekser (LSI-er) for alternativ sortering innenfor en partisjon.

Effektiv datamodellering er avgjørende for optimal ytelse og kostnad i DynamoDB!