Provisioneret kapacitet vs On-Demand-kapacitet

I tilstanden On-Demand skalerer DynamoDB automatisk for at håndtere ethvert trafikniveau uden kapacitetsplanlægning. Du betaler pr. anmodning: for hver RRU (læseanmodningsenhed) og WRU (skriveanmodningsenhed), der faktisk forbruges. Der er ingen klargjort kapacitet, der skal administreres, og ingen begrænsning på grund af klargjorte grænser.

Tilstanden On-Demand er ideel til: uforudsigelige arbejdsbelastninger eller arbejdsbelastninger med pludselige trafikstigninger, nye tabeller med ukendt trafik samt udviklings- og testmiljøer med sjælden adgang. Prisen pr. anmodning er højere end i tilstanden klargjort, så til stabile arbejdsbelastninger med høj gennemstrømning er tilstanden klargjort mere økonomisk.

Du kan når som helst skifte en tabel mellem tilstandene Provisioned og On-Demand ved hjælp af konsollen eller CLI. Du kan dog kun skifte tilstand én gang hver 24. time. Efter skift til On-Demand beholder tabellen den tidligere maksimale klargjorte kapacitet som sit indledende gennemstrømningsniveau. Det beskytter mod øjeblikkelig begrænsning, hvis trafikken allerede er høj.

En almindelig strategi er at bruge On-Demand under den første lancering, når trafikmønstrene er ukendte, og derefter skifte til Provisioned med Auto Scaling, når trafikken bliver forudsigelig, så omkostningerne reduceres.

DynamoDB's Auto Scaling justerer automatisk dine klargjorte RCU'er og WCU'er som reaktion på den faktiske trafik. Du angiver en målprocent for udnyttelse (f.eks. 70 %) samt et interval for minimums- og maksimumskapacitet. En politik for Application Auto Scaling overvåger tabellens forbrugte kapacitet og justerer den klargjorte kapacitet for at fastholde måludnyttelsen.

Auto Scaling reagerer på vedvarende ændringer i trafikken og kan bruge nogle minutter på at skalere op. Den håndterer ikke pludselige trafikstigninger godt – i sådanne tilfælde skal du enten forvarme kapaciteten manuelt eller bruge tilstanden On-Demand i stedet.

DynamoDB gemmer op til 5 minutters ubrugt klargjort kapacitet som burstkapacitet. Når trafikken i din tabel kortvarigt overstiger det klargjorte niveau, trækker DynamoDB på burstpuljen for at håndtere de ekstra anmodninger uden begrænsning. Når burstpuljen er opbrugt, bliver efterfølgende overskydende anmodninger begrænset.

Burstkapacitet er en kortvarig buffer og ikke en erstatning for korrekt kapacitetsplanlægning. Overvåg CloudWatch-metrikkerne ConsumedReadCapacityUnits og ConsumedWriteCapacityUnits for at opdage, hvornår din arbejdsbelastning konsekvent bruger burstkapacitet, og justér den klargjorte gennemstrømning derefter.

Når den klargjorte kapacitet er overskredet (og burstkapaciteten er opbrugt), returnerer DynamoDB ProvisionedThroughputExceededException. AWS SDK'erne indeholder indbygget genforsøgslogik med eksponentiel backoff og jitter, som automatisk forsøger begrænsede anmodninger igen.

Hvis du vil diagnosticere begrænsning, skal du kontrollere CloudWatch-metrikkerne SystemErrors og ThrottledRequests. Hvis bestemte partitionsnøgler begrænses, mens den samlede udnyttelse af tabellen er lav, har du et problem med en varm partition – omdesign partitionsnøglen, tilføj en sorteringsnøgle, eller brug skriveopdeling.

Sådan estimerer du kapaciteten til tilstanden Provisioned:

• Beregn maksimalt antal skrivninger pr. sekund × gennemsnitlig elementstørrelse / 1 KB (rundet op) = nødvendige WCU'er
• Beregn maksimalt antal læsninger pr. sekund × gennemsnitlig elementstørrelse / 4 KB (rundet op) = nødvendige RCU'er (stærkt konsistente); halver resultatet for eventualt konsistente læsninger
• Tilføj 20-30 % margen over maksimum for at absorbere stigninger, før burstkapaciteten er opbrugt

Eksempel: 1.000 skrivninger/sek. af elementer på 2 KB = 2.000 WCU'er. 5.000 læsninger/sek. af elementer på 8 KB (eventualt konsistente) = ceil(8/4) × 5.000 / 2 = 5.000 RCU'er.

DynamoDB Reserved Capacity giver dig mulighed for at købe et fast antal RCU'er og WCU'er for en periode på 1 eller 3 år og betale på forhånd for at få en betydelig rabat (op til 76 %) i forhold til On-Demand-priser. Reserveret kapacitet gælder for alle klargjorte tabeller i en Region og anvendes automatisk på dine timebaserede gebyrer.

Reserveret kapacitet gælder kun for tilstanden Provisioned – du kan ikke bruge den sammen med tilstanden On-Demand. Det er den bedste mulighed for omkostningsbesparelser ved stabile, forudsigelige arbejdsbelastninger, som du med sikkerhed kan forudsige over 1-3 år.

Brug denne vejledning, når du skal vælge kapacitetstilstand i spørgsmål til SAA-C03:

• On-Demand: uforudsigelig trafik, ny applikation, sjælden adgang, trafik med pludselige stigninger eller når du ønsker ingen kapacitetsadministration
• Provisioned: ensartet og forudsigelig trafik, fokus på omkostninger, villighed til at administrere kapacitet og mulighed for rabatter på Reserved Capacity
• Provisioned + Auto Scaling: forudsigeligt grundniveau med en vis variation, hvor du ønsker automatisk justering uden manuelle ændringer

På eksamen peger nøgleord som 'spiky', 'unpredictable' eller 'minimal operational overhead' på On-Demand, mens 'steady traffic' eller 'cost optimisation' peger på Provisioned.

DynamoDB's Adaptive Capacity omfordeler automatisk gennemstrømning fra kolde partitioner til varme partitioner i realtid. Hvis én partitionsnøgle modtager mere trafik end dens tildelte andel, låner den adaptive kapacitet gennemstrømning fra underudnyttede partitioner for at håndtere den varme partition – så længe den samlede tabelkapacitet ikke overskrides.

Adaptiv kapacitet er altid aktiveret og kræver ingen konfiguration. Den reducerer begrænsning af varme partitioner ved moderat ujævne adgangsmønstre. Ved stærkt skæve arbejdsbelastninger (f.eks. når én partitionsnøgle modtager 90 % af trafikken) er adaptiv kapacitet ikke tilstrækkelig – du skal omdesigne partitionsnøglen eller bruge skriveopdeling.

I denne lektion lærte du, at tilstanden Provisioned angiver faste RCU'er/WCU'er til forudsigelige arbejdsbelastninger til en lavere pris, at tilstanden On-Demand skalerer automatisk ved uforudsigelig trafik til en højere pris pr. anmodning, og at Auto Scaling justerer den klargjorte kapacitet baseret på målprocenter for udnyttelse. Næste emne er Global Secondary Indexes og Local Secondary Indexes til alternative forespørgselsmønstre.