Tabeller, elementer og primærnøgler

Amazon DynamoDB er en fuldt administreret, serverløs nøgle-værdi- og dokumentdatabase, der er designet til svartider på encifrede millisekunder ved enhver skala. I modsætning til relationelle databaser er DynamoDB skemafri—hvert element kan have et forskelligt sæt attributter, så længe primærnøglen er til stede.

DynamoDB gemmer data i tabeller, som er containere på øverste niveau svarende til en SQL-tabel. Tabeller fordeles automatisk på flere lagringsnoder på tværs af AZ'er, hvilket giver indbygget redundans uden konfiguration fra din side.

En DynamoDB-tabel indeholder en samling af elementer, og hvert element er en samling af attributter. Attributter er værdier med typerne String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), List (L), Map (M) og Set (SS, NS, BS).

Hvert element i en tabel skal indeholde primærnøglens attributter—alle andre attributter er valgfri og kan variere mellem elementer. Et enkelt element må højst være 400 KB stort inklusive alle dets attributnavne og værdier.

En simpel primærnøgle består af en enkelt attribut kaldet partitionsnøglen (også kaldet hash-nøglen). DynamoDB anvender en intern hashfunktion på partitionsnøglens værdi for at afgøre, hvilken lagerpartition der indeholder elementet. Alle elementer med den samme partitionsnøgleværdi gemmes sammen.

Med en simpel primærnøgle kan to elementer i tabellen ikke have den samme partitionsnøgleværdi—den identificerer hvert element entydigt. Dette design passer til tabeller, hvor du altid tilgår data via en entydig identifikator, f.eks. et bruger-id eller en ordre-id.

En sammensat primærnøgle bruger både en partitionsnøgle og en sorteringsnøgle (også kaldet intervalnøglen). Elementer med den samme partitionsnøgle gemmes sammen og sorteres efter sorteringsnøglens værdi, hvilket muliggør intervalforespørgsler inden for en partition.

Dette design er meget fleksibelt: Flere elementer kan dele den samme partitionsnøgle, så længe deres sorteringsnøgler er forskellige. En tabel med navnet Orders kan f.eks. bruge CustomerId som partitionsnøgle og OrderDate som sorteringsnøgle, så du kan forespørge efter alle ordrer for en kunde sorteret efter dato.

Valget af den rigtige partitionsnøgle er den vigtigste designbeslutning i DynamoDB. En god partitionsnøgle har høj kardinalitet (mange forskellige værdier) og fordeler adgangen jævnt på tværs af partitioner. Dårlige valg fører til varme partitioner, hvor én partition modtager en uforholdsmæssigt stor trafikmængde, hvilket medfører begrænsning.

Antimønstre, du bør undgå: at bruge et boolesk flag (kun to værdier), en dato, der samler alle dagens skrivninger, eller et statusfelt med lav kardinalitet. Gode valg er bruger-id, enheds-id, et tilfældigt UUID eller sammensatte værdier som tenantId#entityType.

De tre grundlæggende DynamoDB-operationer for elementer er:

• PutItem: skriver et nyt element eller erstatter fuldstændigt et eksisterende element med den samme primærnøgle
• GetItem: henter ét element via dets nøjagtige primærnøgle (kræver hele nøglen—partitionsnøglen og, hvis den er sammensat, sorteringsnøglen)
• DeleteItem: fjerner et element via dets nøjagtige primærnøgle

Alle tre operationer er atomare på elementniveau. Som standard bruger GetItem eventuelt konsistente læsninger. Hvis du tilføjer --consistent-read, gennemtvinges en stærkt konsistent læsning, der altid returnerer den senest skrevne værdi.

UpdateItem ændrer specifikke attributter i et eksisterende element uden at erstatte det helt, i modsætning til PutItem. Du kan tilføje attributter, fjerne attributter eller udføre aritmetik på Number-attributter atomart (f.eks. øge en tæller).

Betingede udtryk lader dig angive, at en operation kun skal lykkes, hvis en betingelse er sand. Du kan f.eks. kun opdatere et elements status, hvis den aktuelt er PENDING. Dette implementerer mønstre for optimistisk låsning uden transaktioner og er en vigtig DynamoDB-designteknik.

Query henter elementer, der deler den samme partitionsnøgleværdi, og kan valgfrit filtrere efter betingelser for sorteringsnøglen. Query er effektiv, fordi den kun læser den målrettede partition. Du kan bruge betingelser for sorteringsnøglen som begins_with, between, =, < og > til at begrænse resultaterne i partitionen.

Scan læser hvert element i tabellen og anvender derefter et valgfrit filterudtryk. Scanninger er dyre for store tabeller og bør undgås i forespørgselsmønstre i produktion. Hvis du ofte har brug for Scan, bør du genoverveje dit tabeldesign eller tilføje et globalt sekundært indeks.

DynamoDB gemmer tre kopier af dine data på tværs af flere AZ'er. Eventualt konsistente læsninger (standardindstillingen) kan returnere en lidt forældet værdi, hvis en nylig skrivning endnu ikke er blevet distribueret til alle kopier – men de bruger halvt så mange læsekapacitetsenheder som stærkt konsistente læsninger.

Stærkt konsistente læsninger returnerer altid den senest bekræftede skrivning, men koster dobbelt så mange RCU'er og er ikke tilgængelige på Global Secondary Indexes. Vælg eventualt konsistente læsninger til arbejdsbelastninger med høj gennemstrømning og mange læsninger, og brug kun stærkt konsistente læsninger, når din applikation kræver de absolut nyeste data.

DynamoDB understøtter ACID-transaktioner via TransactWriteItems og TransactGetItems. En transaktion kan samle op til 100 skrivehandlinger på tværs af flere elementer og endda flere tabeller, så enten gennemføres de alle, eller også rulles de alle atomisk tilbage.

Brug transaktioner i scenarier som overførsel af penge mellem konti (træk beløbet fra ét element, og indsæt det på et andet) eller reservation af en plads (kontrollér tilgængeligheden, og reservér den atomisk). Transaktioner koster dobbelt så mange normale RCU'er/WCU'er, så brug dem kun, når atomaritet på tværs af flere elementer reelt er nødvendig.

DynamoDB's grænse på 400 KB pr. element påvirker datamodelleringen. For store datamængder (f.eks. billeder og store dokumenter) skal du gemme de binære data i S3 og kun gemme S3-objektnøglen i DynamoDB. For dybt indlejrede hierarkiske data skal du modellere hver nodetype med sit eget mønster for partitionsnøgler ved hjælp af modellering med én tabel – én tabel indeholder flere enhedstyper, som adskilles af præfikset for partitionsnøglen og mønsteret for sorteringsnøglen.

Modellering med én tabel minimerer antallet af tabeller og muliggør effektive adgangsmønstre ved at placere relaterede elementer i samme partition. Det er en avanceret teknik, der reducerer den operationelle arbejdsbyrde og forbedrer ydeevnen for komplekse adgangsmønstre.

I denne lektion lærte du, at DynamoDB-tabeller indeholder skemafrie elementer med en grænse på 400 KB, at enkle primærnøgler kun bruger en partitionsnøgle, mens sammensatte nøgler tilføjer en sorteringsnøgle til områdeforespørgsler, og at partitionsnøgler med høj kardinalitet forhindrer varme partitioner. Brug Query i stedet for Scan for at opnå effektiv adgang. Næste emne er kapacitetstilstandene klargjort og efter behov.