PricingLoginStart free
Serverlös backend med AWS Lambda & API Gateway · Lektion

Utforma DynamoDB-tabeller

Lär Er bästa praxis för att utforma effektiva DynamoDB-tabellscheman med fokus på partitionsnycklar och sorteringsnycklar för optimal prestanda.

Lektion 2 av 411 steg

Utforma DynamoDB-tabeller är en gratis lektion i Serverlös backend med AWS Lambda & API Gateway på CoddyKit. Detta är lektion 2 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för Serverlös backend med AWS Lambda & API Gateway, och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i Serverlös backend med AWS Lambda & API Gateway innehåller totalt 4 lektioner.

Varför DynamoDB-design är viktig

Välkommen till utformning av DynamoDB-tabeller! Till skillnad från traditionella relationsdatabaser är DynamoDB en NoSQL-databas som kräver ett annat sätt att utforma scheman.

  • Dess serverlösa natur och prestanda i stor skala beror i hög grad på hur du utformar tabellerna och väljer nycklar.
  • En väl utformad tabell ger snabb, konsekvent prestanda och kostnadseffektivitet.
  • En dåligt utformad tabell kan leda till långsamma frågor, höga kostnader och mycket operativt besvär.

Partition Key (PK)

Varje item i en DynamoDB-tabell identifieras unikt med sin primärnyckel. Den första delen av alla primärnycklar är Partition Key (kallas ibland Hash Key).

  • DynamoDB använder värdet för Partition Key som indata till en intern hashfunktion.
  • Funktionen avgör vilken fysisk partition (lagringsplats) där dina data lagras.
  • Bra Partition Keys fördelar data jämnt över partitionerna, förhindrar ”hot spots” och säkerställer skalbarhet.

Sort Key (SK)

Den andra delen av en primärnyckel, om du väljer att använda en sådan, är Sort Key (ibland kallad Range Key).

  • Objekt med samma Partition Key grupperas och sorteras efter värdet för sin Sort Key.
  • Det möjliggör effektiva intervallfrågor (t.ex. ”alla beställningar från en användare inom ett visst datumintervall”).
  • Kombinationen av Partition Key och Sort Key måste vara unik för varje objekt i tabellen.

Förstå primärnycklar

En tabells primärnyckel kan antingen vara en enkel primärnyckel (endast en Partition Key) eller en sammansatt primärnyckel (en Partition Key och en Sort Key).

  • Enkel primärnyckel: Idealisk när varje objekt behöver en unik identifierare, till exempel userId i en Users-tabell.
  • Sammansatt primärnyckel: Bäst för en-till-många-relationer eller när du behöver fråga efter objekt som delar samma partitionsnyckel men skiljer sig åt genom en sekundär identifierare, till exempel userId och orderId i en Orders-tabell.

En enkel PK i praktiken

Anta att vi har en Users-tabell där varje användare har ett unikt userId. Vi kan använda userId som den enkla Partition Key. Så här kan ett objekt läggas till:

import boto3

# This client is conceptual for illustration.
# In a real app, it would connect to your DynamoDB table.
class MockDynamoDBTable:
    def __init__(self, name):
        self.name = name
        self.items = {}

    def put_item(self, Item):
        pk = Item['userId']
        if pk in self.items:
            print(f"Warning: Item with userId '{pk}' already exists. Overwriting.")
        self.items[pk] = Item
        print(f"Item added/updated in '{self.name}': {Item}")

# Simulate a DynamoDB table named 'Users'
table = MockDynamoDBTable('Users')

def add_user_item():
    table.put_item(
        Item={
            'userId': 'user123',
            'username': 'Alice',
            'email': 'alice@example.com'
        }
    )

if __name__ == "__main__":
    add_user_item()

En sammansatt PK i praktiken

Föreställ dig nu en Orders-tabell där en användare kan ha flera beställningar. Vi skulle använda userId som Partition Key och orderId som Sort Key. Då kan vi hämta alla beställningar för en viss användare, sorterade efter orderId.

import boto3

# This client is conceptual for illustration.
# In a real app, it would connect to your DynamoDB table.
class MockDynamoDBTable:
    def __init__(self, name):
        self.name = name
        self.items = {}

    def put_item(self, Item):
        pk = Item['userId']
        sk = Item['orderId']
        if pk not in self.items:
            self.items[pk] = {}
        self.items[pk][sk] = Item
        print(f"Item added/updated in '{self.name}': {Item}")

# Simulate a DynamoDB table named 'Orders'
table = MockDynamoDBTable('Orders') # Assume PK: userId, SK: orderId

def add_order_item():
    table.put_item(
        Item={
            'userId': 'user123',
            'orderId': 'order456',
            'itemCount': 2,
            'totalAmount': 50.00,
            'orderDate': '2023-10-26'
        }
    )

if __name__ == "__main__":
    add_order_item()

Utforma för åtkomstmönster

Den viktigaste aspekten av DynamoDB-design är att förstå dina åtkomstmönster. Du bör utforma dina primärnycklar utifrån hur applikationen kommer att fråga efter data, inte bara utifrån hur datan ser ut.

  • Vilka frågor kommer du att ställa? (t.ex. ”Hämta alla produkter i en kategori”, ”Hämta en viss användares senaste inlägg”).
  • Vilka data kommer att returneras? (t.ex. ett enskilt objekt eller en lista med objekt).
  • Din Partition Key bör vanligtvis vara det attribut som du oftast frågar på för att hitta specifika objekt eller grupper av objekt.
  • Din Sort Key möjliggör flexibla frågor inom den gruppen (t.ex. intervallfrågor eller omvänd ordning).

Bästa praxis för val av nycklar

Att välja rätt nycklar är avgörande för prestandan:

  • Hög kardinalitet: Nycklar bör ha många unika värden för att förhindra ”hot spots” på en enskild partition.
  • Jämn fördelning: Värden bör nås ungefär lika ofta. Undvik nycklar där ett fåtal värden efterfrågas mycket oftare än andra.
  • Effektiva frågor: Utforma nycklarna så att de vanligaste frågorna kan besvaras med GetItem (endast PK) eller Query (PK + ett valfritt SK-villkor).
  • Undvik sökningar: Operationer som läser varje objekt i en tabell (Scan) är ineffektiva och kostsamma. Din design bör minimera behovet av dem.

Modellera en-till-många-relationer

Sammansatta primärnycklar passar utmärkt för att modellera en-till-många-relationer, som är mycket vanliga. Exempelvis kan en användare ha många inlägg:

  • Partition Key: USER#<userId> (ett vanligt mönster där nycklar förses med prefix för tydlighet).
  • Sort Key: POST#<postId>.
  • Med den här designen kan du hämta alla inlägg för en användare genom att bara fråga på Partition Key, och även hämta specifika inlägg genom att lägga till ett Sort Key-villkor.

Det här tillvägagångssättet håller relaterade data samlade, vilket möjliggör effektiv hämtning.

Designutmaning

Du utformar en tabell för att lagra användarkommentarer till olika artiklar. Dina huvudsakliga åtkomstmönster är:

  1. Hämta alla kommentarer för en viss artikel.
  2. Hämta alla kommentarer som skrivits av en viss användare.

Vilken primärnyckeldesign skulle bäst stödja att effektivt hämta alla kommentarer för en viss artikel?

Besvara frågan i den interaktiva lektionen

Sammanfattning av nyckeldesign

Bra jobbat! I den här lektionen har du lärt dig de grundläggande principerna för att utforma DynamoDB-tabeller:

  • Vikten av Partition Keys för datadistribution.
  • Nyttan med Sort Keys för sortering och intervallfrågor.
  • Hur Primary Keys (enkla eller sammansatta) unikt identifierar objekt.
  • Den avgörande rollen för åtkomstmönster när du fattar designbeslut.
  • Bästa praxis för att välja nycklar som säkerställer god prestanda och kostnadseffektivitet.

Att behärska dessa koncept är avgörande för att bygga skalbara och högpresterande serverless-applikationer med DynamoDB!

Gratis att börja

Lär dig Serverlös backend med AWS Lambda & API Gateway med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
12
Lektioner
48
Börja lära dig gratisVisa hela kursen

Vanliga frågor

Är lektionen ”Utforma DynamoDB-tabeller” gratis?

Ja – hela texten till ”Utforma DynamoDB-tabeller” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i Serverlös backend med AWS Lambda & API Gateway, kan Ni uppgradera till CoddyKit PRO. Kursen i Serverlös backend med AWS Lambda & API Gateway innehåller totalt 4 lektioner.

Vad lär jag mig i ”Utforma DynamoDB-tabeller”?

Lär Er bästa praxis för att utforma effektiva DynamoDB-tabellscheman med fokus på partitionsnycklar och sorteringsnycklar för optimal prestanda. Ni övar på Serverlös backend med AWS Lambda & API Gateway med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig Serverlös backend med AWS Lambda & API Gateway?

Du behöver inga förkunskaper. Utbildningen i Serverlös backend med AWS Lambda & API Gateway på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 2 av 4.

Hur lång tid tar lektionen ”Utforma DynamoDB-tabeller”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här Serverlös backend med AWS Lambda & API Gateway-lektionen?

Ja. Varje Serverlös backend med AWS Lambda & API Gateway-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Introduktion till DynamoDB
  2. Utforma DynamoDB-tabeller
  3. Integrering av Lambda och DynamoDB
  4. Frågor med sekundära index: GSI:er och LSI:er
← Tillbaka till Serverlös backend med AWS Lambda & API Gateway