Evitare la dinamo a farfallaDB

Question

Sono un neofita del cloud computing, ma avevo una domanda se un meccanismo come quello che sto per descrivere esiste o è possibile creare?

Dynamodb ha erogato il throughput (ad esempio 100 scritture/secondo). Naturalmente, nel mondo reale l'applicazione del throughput della vita reale è molto dinamica e non sarà quasi mai pari a 100 scritture/secondo. Stavo pensando che sarebbe bello un qualche tipo di coda per dynamodb. Ad esempio, il mio dynamodb durante le ore di punta potrebbe ricevere 500 richieste di scrittura al secondo (5 volte quello che ho assegnato) e restituirebbe errori. C'è una coda che posso mettere tra client e database, quindi le richieste del client vanno in coda, il client viene riconosciuto e la sua richiesta è stata gestita, quindi la coda invia la richiesta a dynamodb ad una velocità di 100/scrive al secondo esattamente, quindi in questo modo non ci sono errori restituiti e non ho bisogno di aumentare il through put che aumenterà i miei costi?

Answer 1

Porre AWS SQS è la parte anteriore di DynamoDB risolverebbe questo problema per voi e non è un modello di progettazione insolito. SQS è già adatto per ridimensionare quanto è necessario e ingerire una grande quantità di messaggi con modelli di flusso imprevedibili.

È possibile inserire prima tutti i messaggi in SQS oppure utilizzare SQS come buffer di overflow quando si supera il valore di progettazione sul database DynamoDB.

Una o più istanze di lavoro possono leggere i messaggi dalla coda SQS e inserirli in DynamoDB esattamente al ritmo che si decide.

Se l'ordine dei messaggi in arrivo è estremamente importante, Kinesis è un'altra opzione che consente di importare i messaggi in arrivo e quindi inserirli in DynamoDB, nello stesso ordine in cui sono arrivati, a un ritmo definito dall'utente.

IMO, SQS sarà più semplice da utilizzare, ma Kines vi darà maggiore flessibilità se le vostre esigenze sono più complicate.

Answer 2

Questo non può essere realizzato utilizzando DynamoDB da solo. DynamoDB è progettato per carichi di lavoro uniformi, scalabili e prevedibili. Se vuoi mettere una coda davanti a DynamoDB, fallo tu stesso.

DynamoDB ha una piccola tolleranza per burst capacity, ma non è per uso prolungato. Si consiglia di leggere la sezione miglior pratiche Consider Workload Uniformity When Adjusting Provisioned Throughput, ma qui ci sono alcuni, quello che penso siano importanti, i paragrafi con un paio di cose sottolineate da me:

Per le applicazioni che sono stati progettati per l'utilizzo con i carichi di lavoro uniformi, partizione di DynamoDB l'attività di assegnazione non è evidente. Una disuniformità temporanea in un carico di lavoro può generalmente essere assorbita dalla franchigia di scoppio, come descritto in Use Burst Capacity Sparingly. Tuttavia, se l'applicazione deve supportare carichi di lavoro non uniformi su base regolare, è necessario progettare la tabella tenendo presente il comportamento di partizionamento di DynamoDB (vedere Understand Partition Behavior) e prestare attenzione quando si aumenta e si riduce il throughput predisposto su tale tabella.

Se si riduce la quantità di throughput assegnato per la tabella, DynamoDB non diminuirà il numero di partizioni. Si supponga di aver creato una tabella con una quantità molto maggiore di throughput assegnato rispetto a quella effettivamente necessaria per l'applicazione, quindi ridurre in seguito la velocità effettiva approvata. In questo scenario, il throughput assegnato per partizione sarebbe inferiore a quello che sarebbe stato se inizialmente si fosse creata la tabella con un throughput inferiore.

ci sono strumenti che aiutano con auto-ridimensionamento DynamoDB, come sebdah/dynamic-dynamodb che può essere merita di essere esaminata.