Datamodellering i DynamoDB

Partitionsnyckeln (PK) avgör den fysiska partitionen (lagringsplatsen) där era data finns.

• Unikhet: Om endast en PK används måste den vara unik för varje objekt.
• Fördelning: En bra PK fördelar data jämnt mellan partitionerna och förhindrar ”heta partitioner”, som kan försämra prestandan.
• Direkt åtkomst: Ni kan bara fråga efter ett objekt direkt om ni känner till dess partitionsnyckel.

När ni använder både en partitionsnyckel och en sorteringsnyckel (SK) grupperas objekt med samma partitionsnyckel tillsammans och sorteras efter sorteringsnyckeln.

• Unik kombination: Kombinationen av PK och SK måste vara unik.
• Intervallfrågor: Möjliggör effektiva intervallfrågor (till exempel att hämta alla beställningar för en användare inom ett visst datumintervall).
• Flexibel sortering: Möjliggör olika sorteringar inom samma partition.

Till skillnad från relationsdatabaser, där ni utformar tabeller och sedan tar fram frågor, bör ni i DynamoDB först lista alla åtkomstmönster för programmets data.

• Identifiera frågor: Vilka data behöver ni? Hur ska ni hämta dem?
• Exempel: ”Hämta användarprofil efter userId”, ”Lista alla produkter efter category”, ”Hitta alla kommentarer för ett postId”.

Tabellens utformning (PK, SK, index) bör direkt stödja dessa mönster.

Ett vanligt och kraftfullt mönster i DynamoDB är Single-Table Design. Det innebär att flera olika entitetstyper (till exempel Users, Orders och Products) lagras i en enda tabell.

• Fördelar: Minskar den operativa administrationen, möjliggör effektiva ”många-till-många”-relationer och kan vara mer kostnadseffektivt.
• Så fungerar det: Använder generiska attributnamn som PK och SK samt prefix (till exempel USER#<id>, ORDER#<id>) för att skilja entitetstyper åt.

Vad gör ni om ni behöver fråga efter data med hjälp av ett attribut som inte ingår i primärnyckeln? Då kommer globala sekundära index (GSI:er) till användning.

• Nya nycklar: Ett GSI har en egen partitionsnyckel och en valfri sorteringsnyckel, som kan vara vilka attribut som helst från bastabellen.
• Fristående: Det är en helt separat tabell som DynamoDB underhåller, vilket möjliggör andra åtkomstmönster.
• Eventual consistency: GSI:er är eventual consistent, vilket innebär att det kan ta en kort stund innan ändringar sprids.

Lokala sekundära index (LSI:er) gör det möjligt att fråga efter data med en annan sorteringsnyckel inom samma partitionsnyckel som i bastabellen.

• Samma PK, annan SK: LSI:er delar partitionsnyckel med bastabellen men har en annan sorteringsnyckel.
• Starkt konsistenta: Till skillnad från GSI:er stöder LSI:er starkt konsistenta läsningar.
• Begränsade: De måste definieras när tabellen skapas och ni kan ha högst 5 per tabell.

Vi modellerar ett enkelt scenario: användare och deras inlägg. Vi vill kunna:

• Åtkomstmönster 1: Hämta en användares profil.
• Åtkomstmönster 2: Hämta alla inlägg av en användare, sorterade efter datum.

Med en Single-Table Design:

• PK: USER#<userId>
• SK: #METADATA# (för användarprofilen), POST#<postId> (för inlägg)

Då kan ni hämta en användares profil och inlägg med en enda fråga mot partitionen USER#<userId>.

Vi har gått igenom grunderna i datamodellering för DynamoDB:

• Förstå hur partitionsnycklar och sorteringsnycklar definierar datastrukturen.
• Utforma lösningen utifrån era åtkomstmönster, inte bara datarelationerna.
• Kraften i Single-Table Design för effektivitet.
• Använda globala sekundära index (GSI:er) för olika typer av frågor.
• Använda lokala sekundära index (LSI:er) för alternativ sortering inom en partition.

Effektiv datamodellering är avgörande för optimal prestanda och kostnad i DynamoDB!