Serverløs backend med AWS Lambda & API Gateway · leksjon

Utforming av DynamoDB-tabeller

Lær beste praksis for utforming av effektive DynamoDB-tabellskjemaer, med vekt på partisjonsnøkler og sorteringsnøkler for optimal ytelse.

Leksjon 2 av 411 trinn

Utforming av DynamoDB-tabeller er en gratis leksjon i Serverløs backend med AWS Lambda & API Gateway på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Serverløs backend med AWS Lambda & API Gateway, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Serverløs backend med AWS Lambda & API Gateway inneholder totalt 4 leksjoner.

Hvorfor DynamoDB-utforming er viktig

Velkommen til utforming av DynamoDB-tabeller! I motsetning til tradisjonelle relasjonsdatabaser er DynamoDB en NoSQL-database som krever en annen tilnærming til skjemautforming.

Den serverløse arkitekturen og ytelsen i stor skala avhenger i stor grad av hvordan De utformer tabellene og velger nøkler.
En godt utformet tabell sikrer rask og forutsigbar ytelse samt kostnadseffektivitet.
En dårlig utforming kan føre til trege spørringer, høye kostnader og driftsproblemer.

Partition Key (PK)

Hvert item i en DynamoDB-tabell identifiseres entydig av primærnøkkelen. Den første delen av enhver primærnøkkel er Partition Key (noen ganger kalt Hash Key).

DynamoDB bruker verdien til Partition Key som inndata til en intern hash-funksjon.
Denne funksjonen avgjør den fysiske partisjonen (lagringsplasseringen) der dataene lagres.
Gode Partition Keys fordeler data jevnt mellom partisjonene, hindrer «hot spots» og sikrer skalerbarhet.

Sort Key (SK)

Den andre delen av en primærnøkkel, hvis De velger å bruke en, er Sort Key (noen ganger kalt en Range Key).

Elementer med samme Partition Key grupperes sammen og sorteres etter verdien i Sort Key.
Dette gjør effektive områdesøk mulig (for eksempel «alle bestillinger fra en bruker innenfor et datointervall»).
Kombinasjonen av Partition Key og Sort Key må være unik for hvert element i tabellen.

Forstå primærnøkler

En tabells primærnøkkel kan enten være en enkel primærnøkkel (bare en Partition Key) eller en sammensatt primærnøkkel (en Partition Key og en Sort Key).

Enkel primærnøkkel: Ideell når hvert element trenger en unik identifikator, for eksempel userId i en Users-tabell.
Sammensatt primærnøkkel: Best for én-til-mange-relasjoner eller når De må søke etter elementer som deler en felles partisjonsnøkkel, men har ulike sekundære identifikatorer, for eksempel userId og orderId i en Orders-tabell.

Enkel PK i praksis

La oss se på en Users-tabell der hver bruker har en unik userId. Vi kan bruke userId som enkel Partition Key. Et element kan legges til slik:

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()

Sammensatt PK i praksis

Se for Dem nå en Orders-tabell der en bruker kan ha flere bestillinger. Vi bruker userId som Partition Key og orderId som Sort Key. Da kan vi hente alle bestillingene til en bestemt bruker, sortert etter 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()

Utforming for tilgangsmønstre

Det viktigste aspektet ved utforming av DynamoDB er å forstå tilgangsmønstrene. De bør utforme primærnøklene etter hvordan programmet skal søke i dataene, ikke bare etter hvordan dataene ser ut.

Hvilke spørringer skal De kjøre? (for eksempel «Hent alle produkter i en kategori» eller «Hent en bestemt brukers nyeste innlegg»).
Hvilke data skal returneres? (for eksempel ett element eller en liste med elementer).
Partition Key bør vanligvis være attributtet De oftest søker etter for bestemte elementer eller grupper av elementer.
Sort Key gir fleksible søk innenfor denne gruppen (for eksempel områdesøk eller omvendt rekkefølge).

Beste praksis for valg av nøkler

Det er avgjørende for ytelsen å velge riktige nøkler:

Høy kardinalitet: Nøkler bør ha mange unike verdier for å hindre «hot spots» på én enkelt partisjon.
Jevn fordeling: Verdier bør aksesseres omtrent like ofte. Unngå nøkler der noen få verdier blir forespurt langt oftere enn andre.
Effektive spørringer: Utform nøkler slik at de vanligste spørringene kan utføres med GetItem (bare PK) eller Query (PK + valgfri SK-betingelse).
Unngå skanninger: Operasjoner som leser hvert element i en tabell (Scan) er ineffektive og kostbare. Utformingen bør minimere behovet for slike operasjoner.

Modellering av én-til-mange-relasjoner

Sammensatte primærnøkler egner seg svært godt til modellering av én-til-mange-relasjoner, som er svært vanlige. For eksempel kan en bruker ha mange innlegg:

Partition Key: USER#<userId> (et vanlig mønster der nøkler får et prefiks for å gjøre dem tydeligere).
Sort Key: POST#<postId>.
Med denne utformingen kan De hente alle innleggene til en bruker ved å søke bare på Partition Key, og også hente bestemte innlegg ved å legge til en Sort Key-betingelse.

Denne tilnærmingen holder relaterte data samlet og gjør uthenting effektiv.

Utformingsoppgave

De skal utforme en tabell for å lagre brukerkommentarer til ulike artikler. De viktigste tilgangsmønstrene er:

Hent alle kommentarer til en bestemt artikkel.
Hent alle kommentarer skrevet av en bestemt bruker.

Hvilken utforming av primærnøkkelen vil best støtte effektiv uthenting av alle kommentarer til en bestemt artikkel?

Besvar den i den interaktive leksjonen

Oppsummering av nøkkelutforming

Godt jobbet! I denne leksjonen har De lært de grunnleggende prinsippene for utforming av DynamoDB-tabeller:

Hvor viktige Partition Keys er for fordeling av data.
Hvordan Sort Keys kan brukes til sortering og områdesøk.
Hvordan primærnøkler (enkle eller sammensatte) identifiserer elementer unikt.
Hvilken avgjørende rolle tilgangsmønstre spiller for valgene i utformingen.
Beste praksis for valg av nøkler for å sikre god ytelse og kostnadseffektivitet.

Hvis De behersker disse konseptene, har De et godt grunnlag for å bygge skalerbare og effektive serverløse applikasjoner med DynamoDB!

Gratis å komme i gang

Lær deg Serverløs backend med AWS Lambda & API Gateway med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs: 12
Leksjoner: 48

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Utforming av DynamoDB-tabeller» gratis?

Ja – hele teksten i «Utforming av DynamoDB-tabeller» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Serverløs backend med AWS Lambda & API Gateway-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Serverløs backend med AWS Lambda & API Gateway inneholder totalt 4 leksjoner.

Hva lærer jeg i «Utforming av DynamoDB-tabeller»?

Lær beste praksis for utforming av effektive DynamoDB-tabellskjemaer, med vekt på partisjonsnøkler og sorteringsnøkler for optimal ytelse. Du øver på Serverløs backend med AWS Lambda & API Gateway med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Serverløs backend med AWS Lambda & API Gateway?

Ingen tidligere erfaring er nødvendig. Serverløs backend med AWS Lambda & API Gateway på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Utforming av DynamoDB-tabeller»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Serverløs backend med AWS Lambda & API Gateway-leksjonen?

Ja. Alle Serverløs backend med AWS Lambda & API Gateway-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

Introduksjon til DynamoDB
Utforming av DynamoDB-tabeller
Integrering av Lambda og DynamoDB
Spørringer med sekundærindekser: GSI-er og LSI-er

← Tilbake til Serverløs backend med AWS Lambda & API Gateway