Hvad er Amazon DynamoDB?

Question

Accepted Answer

**DynamoDB** er AWS's fuldt-managed **NoSQL** database — en key-value og document store med ydeevne i enkeltcifret millisekund ved enhver skala, med automatisk skalering og ingen servere at administrere. Det er designet til applikationer, der kræver høj ydeevne og skalerbarhed.

## Hvad DynamoDB er

```text
DynamoDB is a managed, serverless NoSQL database:
  → KEY-VALUE / DOCUMENT model (items in tables, flexible schema)
  → FAST — single-digit-millisecond latency at any scale
  → SCALABLE — handles massive throughput; scales automatically (serverless)
  → FULLY MANAGED — no servers, patching, or capacity planning (AWS handles it)
  → highly available and durable (replicated across AZs automatically)
```

## Centrale koncepter

```text
TABLE → a collection of items
ITEM → a record (like a row/document) with attributes
PRIMARY KEY → uniquely identifies items:
  PARTITION KEY (hash key) → determines which partition stores the item (distribution)
  optional SORT KEY → for ranges/sorting within a partition
SECONDARY INDEXES (GSI/LSI) → query by attributes other than the primary key
CAPACITY → on-demand (pay per request) or provisioned (set throughput)
```

## Design til adgangsmønstre (kritisk)

```text
⚠️ DynamoDB requires designing your data model around your ACCESS PATTERNS up front:
  → you query efficiently by PRIMARY KEY (and indexes) — NOT flexible ad-hoc queries
    like SQL; no joins
  → the PARTITION KEY must distribute data/load evenly (a "hot" key = a bottleneck)
  → model the table(s) to serve your queries efficiently (often single-table design)
→ Great when access patterns are known; poor for ad-hoc/complex relational queries.
```

## Hvorfor det betyder noget

Forståelse af DynamoDB er værdifuld, fordi det er en bredt anvendt managed NoSQL database på AWS, velegnet til applikationer med høj ydeevne og skalerbarhed, så det er brugbar AWS-viden.

DynamoDB's kernværdi er at levere en **fuldt-managed, serverless NoSQL database** med **enkeltcifret-millisekund ydeevne ved enhver skala** og automatisk skalering — hvilket eliminerer serveradministration, patching og kapacitetsplanlægning, mens det leverer konsistent hurtig ydeevne selv ved massiv skala.

Dette gør det attraktivt for applikationer, der har brug for høj gennemstrømning og skalerbarhed (højtrafik web-apps, gaming, IoT, realtids-systemer) uden database-operationelle overhead.

Forståelse af **centrale koncepter** (tabeller, elementer, **partition key** som distribuerer data, valgfrie sort keys, sekundære indekser til forespørgsel efter andre attributter, og kapacitetsmodi) er nødvendig for at bruge det.

Mest kritisk er forståelsen af, at DynamoDB kræver **at datamappen designes omkring adgangsmønstre på forhånd** er den vigtigste indsigt: i modsætning til SQL's fleksible ad hoc-forespørgsel, kan DynamoDB effektivt kun forespørges efter primary key og indekser (ingen joins, ingen fleksibel forespørgsel), partition key skal distribuere belastning jævnt (en "hot" key skaber en flaskehals), og du skal modellere tabeller til at serve dine specifikke forespørgsel (ofte single-table design).

Dette adgangsmønster-drevet design er fundamentalt anderledes end relationelle databaser og er essentielt at forstå — DynamoDB udmærker sig, når adgangsmønstre er kendte og velmodellerede, men egner sig dårligt til ad hoc eller komplekse relationelle forespørgsel.

At vide **hvornår DynamoDB passer** (kendte adgangsmønstre, behov for skala og ydeevne) versus hvornår en relationel database er bedre (komplekse forespørgsel, relationer, ad hoc-analyse) afspejler godt dømmekraft.

Da DynamoDB er en populær AWS database til skalerbare applikationer, og forståelse af det (dets managed/serverless natur, centrale koncepter, og især det kritiske adgangsmønster-drevet designmodel og dets trade-offs) er værdifuld for AWS arkitektur-beslutninger, er forståelse af DynamoDB værdifuld, praktisk relevant AWS-viden — en vigtig managed NoSQL mulighed hvor forståelse af dens ydeelse-fordele og dens karakteristiske design-krav (og begrænsninger kontra SQL) er nøglen til at bruge det hensigtsmæssigt.