Amazon DynamoDB non fornisce funzionalità inbuild per la regolazione automatica del throughput in base al carico dinamico. Fornisce API per aumentare o ridurre il throughput. I clienti vengono fatturati su base oraria per il read provisioning & read read.Come scalare automaticamente il throughput di Amazon DynamoDB?
Quali sono i diversi modi per modificare il throughput di dynamodb e ottenere vantaggi di risparmio?
La risposta di Chris è una risposta accurata. Solo per aggiungere alcuni punti della precedente esperienza con DynamoDB ...
La situazione con DynamoDB è diversa da EC2. Il servizio di calcolo elastico ha un'API supportata direttamente come servizio Web da Amazon per consentire all'utente di programmare come aumentare o diminuire secondo una logica come la domanda. Si programma ciò definendo una soglia di monitoraggio e attivando automaticamente la creazione o la cancellazione di istanze in un gruppo.
I server dati non funzionano allo stesso modo con i trigger per regolare la loro capacità. Ma la capacità di DynamoDB è molto flessibile e può essere controllata come ha sottolineato Chris. L'API per fornire questo è abbastanza buono da rendere uno fuori modifiche. O modifiche manuali equivalenti dalla console.
I diversi binding di linguaggio per programmare creare e aggiornare le azioni con DynamoDB è qui ...
http://docs.aws.amazon.com/cli/latest/reference/dynamodb/index.html
L'operazione importante modificare la capacità è qui ...
http://docs.aws.amazon.com/cli/latest/reference/dynamodb/update-table.html
Quindi questo ti dà la possibilità di aumentare o diminuire le ReadCapacityUnits o WriteCapacityUnits di ProvisionedThroughput.
Che va bene per una modifica prevista o una tantum. Ma non è la stessa cosa di uno strumento di flessibilità che ti consente di attivare automaticamente la modifica.
A livello di codice, ciò che è più probabile che si desideri è regolare la capacità in risposta al cambiamento di utilizzo nell'intervallo di tempo precedente. In particolare potrebbe essere necessario scalare rapidamente in risposta a un'impennata della domanda definendo un intervallo di tempo appropriato e una soglia inferiore e superiore da attivare.
una soluzione più completa per raggiungere questo obiettivo è descritto qui ...
https://aws.amazon.com/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/
La soluzione viene mantenuta da Sebastian Dahlgren e può essere trovato con tutte le istruzioni a ...
https://github.com/sebdah/dynamic-dynamodb
I vedi che la versione corrente è 1.18.5, che è più recente di quando l'ho usata per l'ultima volta.
A giudicare dalle versioni precedenti è semplice da configurare per mezzo di un file di stile proprietà dynamodb.conf ...
aver fornito credenziali e regione, le impostazioni più importanti sono
check-interval - per il throughput di prova in secondimin-provisioned-reads, max-provisioned-reads; reads-upper-threshold, reads-lower-threshold; increase-reads-with, decrease-reads-with - Queste sono tutte le percentualimin-provisioned-writes, max-provisioned-writes; writes-upper-threshold, writes-lower-threshold; increase-writes-with, decrease-writes-with - Queste sono tutte le percentualiQueste informazioni sono aggiornate?
Bene se guardi allo http://aws.amazon.com/new/ vedrai solo una modifica recente aggiuntiva che interessa DynamoDB che riguarda i documenti archiviati. La voce per Dynamic DynamoDB è l'ultima voce pubblicata relativa alle azioni di ridimensionamento. Quindi questa è la capacità di scalatura automatica DynamoDB meglio conservata in questo momento.
È possibile gestire il throughput a livello di programmazione tramite updateTable API o manualmente tramite la console.
Esistono anche strumenti come Dynamic DynamoDB, anche se è possibile eseguire il rollover della propria versione: si utilizza l'API updateTable e si esegue un processo in background per rilevare tali circostanze e chiamare updateTable in base alle esigenze.
Alcune cose a cui prestare attenzione quando si cambia la scala di DynamoDB:
come si può garantire che queste nuove partizioni vengano rimosse dopo un po 'di tempo? è richiesta l'invenzione manuale ?? –
Non è possibile, almeno fino a quando il team DynamoDB non lo implementa. È interamente gestito nel back-end. La soluzione alternativa è migrare su una nuova tabella. – Krease
Linee guida per DynamoDB Auto Scaling Script:
I clienti sono in carica su base oraria per il provisioning di lettura & throughput in scrittura. Di seguito è riportato il prezzo di Amazon Dynamo DB per l'UE (Regione Irlanda).
• Write Throughput: $ 0,00,735 mila all'ora per ogni 10 unità di scrittura Capacità • Leggi Throughput: $ 0,00,735 mila all'ora per ogni 50 unità di Leggi Capacità
Amazon Dynamo DB non fornisce funzionalità in-build per auto ottimizzare la velocità in base al carico dinamico. Fornisce API per aumentare o diminuire il throughput con alcune restrizioni come il throughput può essere diminuito due volte in un giorno e aumentato in qualsiasi momento in un giorno.
Quale sarà la fattura mensile di una tabella di produzione per capacità di lettura fissa di 2.000 lettura/secondo e 2.000 scrittura/secondo per 24 ore?
Calcolo: $ 0,00735 X 24 ore X 200 X 30 giorni {costo scrittura per mese} + $ 0,00735X 24 ore X 40 X 30 giorni {costo lettura per mese} = 1058,4+ 211,68 = Risolto 1270 $/mese.
Linee guida per la scrittura di utilità {lingue di programmazione supportate da Amazon} che regolano il rendimento della tabella e riducono le fatture mensili.
(A) Valore Iniziale: In sostanza, qui si deve guardare e decidere di leggere & throughput in scrittura per la tavola come un valore di inizializzazione dopo aver analizzato l'utilizzo medio considerando 15 giorni o 1 carico mese e aggiungere X% in più per lettura e Y% extra per scrivere in alto per sopportare un carico inaspettato. Throughput di lettura/scrittura iniziale = calcola il throughput di lettura basato sull'utilizzo medio + X {read}% o Y {write}% X & Y può essere compreso tra il 10% e il 30% in base all'osservazione.
(B) Misurazione del carico di picco: l'avviso sulle tabelle può essere impostato come quando il carico raggiunge il 50% -60% del throughput, è necessario intraprendere le azioni necessarie come richiamare l'API di incremento del throughput per aumentare il throughput tra il 30% e il 50% % del throughput di provisioning. *
(C) Sagomatura manuale: per carico pesante noto come carico/festival, la produttività deve essere impostata manualmente su 200% - 300% in più delle normali operazioni giornaliere fino al completamento del carico * * Una volta che l'orario lavorativo o il carico è finito. La produttività dovrebbe ridursi al valore iniziale.
Nota: il lettore può calcolare il risparmio mensile considerando 1000 lettura/scrittura per 16 ore. + 2.000 lettura/scrittura per 8 ore, fornito di utilità in atto.
Ora che AWS ha annunciato l'esecuzione pianificata dei servizi lambda, questi sembrano essere particolarmente adatti per il ridimensionamento automatico basato sul tempo. Ho scritto uno example of how to use this on medium. Example code è su github.
Jeff Bar ha recentemente scritto un blog in AWS blog ufficiale: "Auto Scala DynamoDB Con Dinamico DynamoDB":
https://aws.amazon.com/blogs/aws/auto-scale-dynamodb-with-dynamic-dynamodb/
Ha introdotto dinamica DynamoDB, uno strumento open source realizzato da sviluppatore indipendente per gestire questo automaticamente con il modello CloudFormation.
Penso che altre risposte abbiano svolto un ottimo lavoro, ma ho un approccio diverso alla scalabilità automatica di DynamoDB in una modalità guidata dagli eventi sfruttando gli allarmi di CloudWatch e l'operazione UpdateTable di DynamoDB per modificare la capacità fornita. Il seguente approccio non solo aiuta a ridurre i costi, ma incrementa la capacità per i carichi imprevisti.
Sommario:
allarmi Configurare CloudWatch sulle metriche DynamoDB per avvisare, sulla base di soglie e spingere gli allarmi per una coda SQS tramite argomento SNS. Un processo daemon che esegue il polling della coda SQS può elaborare tali avvisi e modificare la capacità fornita dalla tabella utilizzando l'operazione UpdateTable di DynamoDB e aggiornare le soglie di allarme di CloudWatch.
un particolare:
Si prega di notare che questo approccio richiederebbe 1. Comprensione dei servizi AWS come CloudWatch, SNS, SQS 2. buona quantità di tempo per l'implementazione nel linguaggio di programmazione preferito 3. Il mantenimento di un daemon per elaborare i messaggi SQS e modificare la capacità fornita.
Un'impostazione tempo:
ConsumedWriteCapacityUnits e ConsumedReadCapacityUnits metriche della tabella DynamoDB. Puoi usare questo documentation.algoritmo Daemon:
UpdateTable con il nuovo valore.È possibile utilizzare l'approccio sopra per aumentare o ridurre. Ad esempio, mantenere la soglia di allarme CloudWatch all'80% di ProvisionedWriteCapacityUnits e ogni volta che l'utilizzo supera l'80%, aumentare la capacità e impostare la soglia di allarme sull'80% del nuovo valore. Allo stesso modo è possibile ridimensionare quando il consumo scende al di sotto del x%.
Anche se questo è il punto cruciale, ci sarebbero molti punti da considerare in una soluzione di qualità della produzione.
UpdateTable.Infine, Neptune.io fornisce una soluzione SaaS pacchettizzata per l'autoscale DynamoDB utilizzando questa architettura. Vedi http://blog.neptune.io/one-click-autoscaling-of-dynamodb/ e http://blog.neptune.io/dos-and-donts-of-dynamodb-autoscaling/ per qualche lettura su questo.
P.S: Lavoro per Nettuno. E, posso aiutarti se hai bisogno di maggiori dettagli sull'implementazione.
Grazie per aver condiviso la tua affiliazione; ci piacciono le risposte di persone che sanno. Tuttavia, questo non spiega o mostra _how_ i tuoi indirizzi di prodotto _questo problema specifico_, quindi non è altro che una raccomandazione e un link a una risorsa esterna. Se vuoi solo fare pubblicità, sono sicuro che Stack Overflow (la compagnia) sarebbe felice di venderti il servizio. Tuttavia, noi (la comunità) preferiamo vedere le risposte effettive ai nostri problemi attuali. Vedi: [Come posso collegarmi a una risorsa esterna in un modo di community?] (// meta.stackexchange.com/questions/94022) – Mogsdad
@Mogsdad scusa per non essere stato chiaro nella mia prima risposta. Accetta il mio errore e modifica la risposta. Grazie! – Buchi
Sono felice di aver aiutato, e apprezzo lo sforzo ovvio. In bocca al lupo! – Mogsdad
Ho appena scoperto questo progetto che autoscale su e giù per il vostro DynamoDB e sembra meglio di dinamica Dynamo, perché utilizza le funzioni lambda, piuttosto che istanze EC2: processo
https://github.com/channl/dynamodb-lambda-autoscale
Questo è così bello. Grazie per la pubblicazione! – TimDog
Questo è ottimo, ma non vedo un modo per ridimensionare in modo selettivo le tabelle. È tutto o niente, a meno che non lo estenda? –
ho aggiunto nuove funzionalità a Rockeee Dynamic DynamoDB Lambda. Si può vedere questo progetto:
https://github.com/touchvie/dynamic-dynamodb-lambda
Spero che possa aiutarti.
Amazon aggiunto autoscaling per DynamoDB, vedere i dettagli here
AWS aggiunto il supporto scalatura automatica nativo per DynamoDB nel giugno 2017. Vedere l'annuncio here.
È possibile configurarlo utilizzando il codice (Java SDK example), ma se si dispone di poche tabelle, è possibile utilizzare Management Console. Fare clic nella configurazione della tabella e selezionare la scheda Capacità.L'immagine seguente mostra quali sono le opzioni:
AWS ha aggiunto il supporto nativo ridimensionamento automatico per DynamoDB nel mese di giugno 2017. Il seguente codice (source) fornisce un esempio di come configurare il ridimensionamento automatico utilizzando l'SDK Java:
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
public class EnableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Define the scalable target
RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
.withServiceNamespace(ns)
.withResourceId(resourceID)
.withScalableDimension(tableWCUs)
.withMinCapacity(5)
.withMaxCapacity(10)
.withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");
try {
aaClient.registerScalableTarget(rstRequest);
} catch (Exception e) {
System.err.println("Unable to register scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the target was created
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
System.out.println();
// Configure a scaling policy
TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration =
new TargetTrackingScalingPolicyConfiguration()
.withPredefinedMetricSpecification(
new PredefinedMetricSpecification()
.withPredefinedMetricType(MetricType. DynamoDBWriteCapacityUtilization))
.withTargetValue(50.0)
.withScaleInCooldown(60)
.withScaleOutCooldown(60);
// Create the scaling policy, based on your configuration
PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy")
.withPolicyType(PolicyType.TargetTrackingScaling)
.withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);
try {
aaClient.putScalingPolicy(pspRequest);
} catch (Exception e) {
System.err.println("Unable to put scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was created
DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
}
}
Questo codice richiede che venga fornito un ARN per un ruolo di servizio Scaling automatico applicazioni valido. Sostituisci SERVICE_ROLE_ARN_GOES_HERE con l'ARN effettivo.
Solo per vostro avviso. Esiste una limitazione di quante volte è possibile ridimensionare la capacità di DynamoDB in un solo giorno. Come mi ricordo 4 volte al giorno. Ma non sono sicuro della limitazione di scala. Ho affrontato quel problema. –
È possibile aumentare il throughput predisposto tutte le volte che è necessario. D'altra parte, la velocità di trasmissione approvata decrescente può essere eseguita non più di quattro volte per tabella in un solo giorno. [collegamento consultare doc ufficiale qui] (http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html) – chaco