Provisionerad kapacitet jämfört med On-Demand

I läget On-Demand skalar DynamoDB automatiskt för att hantera vilken trafiknivå som helst, utan någon kapacitetsplanering. Du betalar per förfrågan: för varje faktiskt förbrukad RRU (read request unit) och WRU (write request unit). Det finns ingen provisionerad kapacitet att hantera och ingen throttling på grund av provisionerade begränsningar.

On-Demand-läget passar bäst för: oförutsägbara arbetsbelastningar eller arbetsbelastningar med kraftiga trafiktoppar, nya tabeller där trafikmängden är okänd samt utvecklings- och testmiljöer med sporadisk åtkomst. Kostnaden per förfrågan är högre än i Provisioned-läget, så för stabila arbetsbelastningar med hög genomströmning är Provisioned-läget mer ekonomiskt.

Du kan när som helst växla en tabell mellan lägena Provisioned och On-Demand via konsolen eller CLI. Du kan dock bara växla läge en gång var 24:e timme. Efter växling till On-Demand behåller tabellen den tidigare högsta provisionerade kapaciteten som sin initiala genomströmningsnivå, vilket skyddar mot omedelbar throttling om trafiken redan är hög.

En vanlig strategi är att använda On-Demand under den första lanseringen när trafikmönstren är okända och sedan växla till Provisioned med Auto Scaling när trafiken blir förutsägbar, för att minska kostnaden.

DynamoDB Auto Scaling justerar automatiskt dina provisionerade RCU:er och WCU:er utifrån den faktiska trafiken. Du anger en målnivå för utnyttjandegraden (till exempel 70 %) och ett kapacitetsintervall med minimi- och maxvärde. En policy för Application Auto Scaling övervakar tabellens förbrukade kapacitet och justerar den provisionerade kapaciteten för att upprätthålla målnivån.

Auto Scaling reagerar på varaktiga trafikförändringar och kan behöva några minuter för att skala upp. Funktionen hanterar inte plötsliga trafiktoppar särskilt bra – för sådana toppar kan du antingen förvärma kapaciteten manuellt eller använda On-Demand-läget i stället.

DynamoDB sparar upp till 5 minuter av oanvänd provisionerad kapacitet som burst-kapacitet. När tabellens trafik tillfälligt överskrider den provisionerade nivån använder DynamoDB kapacitet från burst-poolen för att hantera de extra förfrågningarna utan throttling. När burst-poolen är tömd begränsas efterföljande överskridande förfrågningar genom throttling.

Burst-kapacitet är en kortsiktig buffert och ersätter inte korrekt kapacitetsplanering. Övervaka CloudWatch-måtten ConsumedReadCapacityUnits och ConsumedWriteCapacityUnits för att upptäcka när arbetsbelastningen regelbundet förbrukar burst-kapacitet, och justera den provisionerade genomströmningen därefter.

När den provisionerade kapaciteten överskrids (och burst-kapaciteten är förbrukad) returnerar DynamoDB ProvisionedThroughputExceededException. AWS SDK:erna innehåller inbyggd återförsökslogik med exponentiell backoff och jitter som automatiskt försöker skicka throttlade förfrågningar igen.

Kontrollera CloudWatch-måtten SystemErrors och ThrottledRequests för att diagnostisera throttling. Om specifika partitionnycklar throttlas medan tabellens totala utnyttjandegrad är låg har du ett problem med en het partition – utforma om partitionnyckeln, lägg till en sortnyckel eller använd write sharding.

Så här uppskattar du kapaciteten för Provisioned-läget:

• Beräkna antalet skrivningar per sekund vid toppbelastning × genomsnittlig objektstorlek / 1 KB (avrundat uppåt) = nödvändigt antal WCU:er
• Beräkna antalet läsningar per sekund vid toppbelastning × genomsnittlig objektstorlek / 4 KB (avrundat uppåt) = nödvändigt antal RCU:er (starkt konsistenta); halvera för eventual consistency
• Lägg till 20–30 % marginal över toppbelastningen för att hantera toppar innan burst-kapaciteten förbrukas

Exempel: 1 000 skrivningar/s av objekt på 2 KB = 2 000 WCU:er. 5 000 läsningar/s av objekt på 8 KB (eventual consistency) = ceil(8/4) × 5 000 / 2 = 5 000 RCU:er.

DynamoDB Reserved Capacity låter dig köpa ett fast antal RCU:er och WCU:er för en ett- eller treårsperiod och betala i förskott för en betydande rabatt (upp till 76 %) jämfört med On-Demand-priser. Reserved Capacity gäller för alla provisionerade tabeller i en region och tillämpas automatiskt på dina timkostnader.

Reserved Capacity gäller endast för Provisioned-läget – du kan inte använda det med On-Demand-läget. Det är det bästa alternativet för att sänka kostnaderna för stabila och förutsägbara arbetsbelastningar som du med tillförsikt kan prognostisera för ett till tre år.

Använd detta beslutsstöd för frågor om kapacitetslägen i SAA-C03:

• On-Demand: oförutsägbar trafik, ny applikation, sporadisk åtkomst, trafik med toppar, när du vill slippa all kapacitetshantering
• Provisioned: jämn och förutsägbar trafik, kostnadskänslighet, beredskap att hantera kapaciteten, möjlighet att få rabatt genom Reserved Capacity
• Provisioned + Auto Scaling: förutsägbar basnivå med viss variation, när du vill ha automatisk justering utan manuella ändringar

På provet signalerar nyckelord som 'spiky', 'unpredictable' eller 'minimal operational overhead' On-Demand, medan 'steady traffic' eller 'cost optimisation' signalerar Provisioned.

DynamoDB Adaptive Capacity omfördelar automatiskt genomströmning från kalla partitioner till heta partitioner i realtid. Om en partitionnyckel tar emot mer trafik än sin tilldelade andel lånar den adaptiva kapaciteten genomströmning från underutnyttjade partitioner för att hantera den heta partitionen – så länge tabellens totala kapacitet inte överskrids.

Adaptiv kapacitet är alltid aktiverad och kräver ingen konfiguration. Den minskar throttling av heta partitioner vid måttligt ojämna åtkomstmönster. För kraftigt snedfördelade arbetsbelastningar (till exempel när en partitionnyckel tar emot 90 % av trafiken) räcker adaptiv kapacitet inte till – du måste utforma om partitionnyckeln eller använda write sharding.

I den här lektionen har du lärt dig att Provisioned-läget anger fasta RCU:er/WCU:er för förutsägbara arbetsbelastningar till lägre kostnad, att On-Demand-läget skalar automatiskt för oförutsägbar trafik till ett högre pris per förfrågan, samt att Auto Scaling justerar den provisionerade kapaciteten utifrån målangivna utnyttjandegrader. Härnäst går vi igenom Global Secondary Indexes och Local Secondary Indexes för alternativa frågemönster.