AWS ElastiCache / SimpleQueue vs DynamoDB

Mi chiedo le motivazioni per l'utilizzo di ElastiCache / SimpleQueue rispetto al fatto che le tabelle "Cache" e "Queue" siano rispettivamente all'interno di DynamoDB.

Sembra che la latenza di rete ai servizi Cache / Coda trionferà molti dei guadagni in termini di prestazioni e che avere EC2 tratti Dynamo come il suo servizio cache / coda offrirebbe la stessa latenza e throughput (dal momento che Dynamo consente una latenza bassa fissa sotto qualsiasi caricare).

Si tratta principalmente del prezzo della dinamo rispetto ad altri servizi sotto carico?

Qualcuno ha dei numeri di latenza approssimativa che confronta Dynamo con ElastiCache / SQS?

Ci sono altre considerazioni più importanti che mi mancano che giustificano l'ulteriore complessità?

Grazie.

Stiamo usando DynamoDB ed ElastiCache Redis per diversi motivi.

DynamoDB:

• Ha un linguaggio di query che è in grado di fare cose più complesse (maggiore di, tra ecc.)
• È raggiungibile tramite un'API esterna rivolta a Internet (diverse regioni sono raggiungibili senza modifiche o infrastrutture proprie)
• Sono possibili autorizzazioni basate su tabelle o persino righe
• Scala in termini di dimensioni dei dati all'infinito
• Paghi per richiesta -> numeri di richiesta bassi significano fattura più piccola, numeri di richiesta alta significa fattura più alta
• Letture e scritture hanno costi diversi
• I dati vengono salvati ridondanti da AWS in più strutture
• DynamoDB è altamente disponibile e pronto all'uso
• Il ridimensionamento automatico è disponibile nel servizio stesso

ElastiCache Redis:

• Linguaggio di query semplice: nessuna funzionalità complessa
• È (pronto all'uso) non raggiungibile da altre regioni.
• Sei sempre limitato alla quantità di memoria (o alla somma di tutte le istanze primarie in un cluster)
• Il frazionamento su più istanze è possibile solo all'interno dell'applicazione: Redis non fa nulla qui (il cluster Redis aiuta qui, ma la logica di sharding è ancora all'interno del driver / sdk che stai utilizzando nella tua applicazione) - scale-in e scale- al momento non è possibile uscire senza tempi di fermo
• Paghi per istanza, indipendentemente dal carico o dal numero di richieste.
• Se si desidera la ridondanza dei dati, è necessario impostare la replica (non possibile tra aree diverse)
• È necessario utilizzare le repliche per l'alta disponibilità
• Nessuna scalabilità automatica disponibile (vedere la parte relativa al ridimensionamento affatto sopra)

Quindi il nostro setup per la maggior parte del tempo è: cache semplici con un elevato volume di richieste in Redis supportate da DynamoDB come memoria permanente e duratura. Con questo limitiamo i costi in quanto otteniamo uno sconto implicito per le nostre letture dal modello pay-per-instance di Redis, ma otteniamo anche il vantaggio della ridondanza di DynamoDB e siamo persino in grado di utilizzare il linguaggio di query DynamoDB per cose più complesse ( se ne abbiamo bisogno).

Spero possa aiutare!

Aggiornamento: con l'annuncio di Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ) stiamo cambiando per usare DAX così com'è (alla fine) esattamente quello che stavamo facendo con il combinazione di DynamoDB e Redis. Poiché DAX è completamente gestito da AWS e ci dà la possibilità di utilizzare sempre il linguaggio DynamoDB nella nostra applicazione, ma anche di ottenere i vantaggi da una cache di scrittura come Redis.

Il motivo principale per cui utilizziamo Elasticache anziché DynamoDB è la velocità: ottieni latenza di andata e ritorno sub 1ms per piccoli oggetti. La confezione è molto vicina alla tua macchina EC2 e la memoria è molto più veloce del disco, anche SSD.

Potrebbe esserci anche un vantaggio in termini di costi, dati i diversi modelli di prezzo, anche se non ho approfondito così tanti dettagli.

I redis / memcached sono archivi in ​​memoria e dovrebbero generalmente essere più veloci di DynamoDB per i dati di tipo cache / coda. Hanno anche utili elementi aggiuntivi come chiavi in ​​scadenza, Pub / Sub in Redis, ecc. Che Dynamo potrebbe non avere.