DynamoDB è uno tra i servizi cloud al momento più popolari di Amazon Web Services. Si tratta di un database in cloud che è stato progettato internamente ad AWS e non deriva da altre piattaforme open source, anche se ha diversi punti di contatto con Apache Cassandra.
Si tratta in estrema sintesi di un database NoSQL di tipo key-value e ottimizzato per le prestazioni, in grado di gestire milioni di interrogazioni al secondo mantenendo una latenza molto bassa.
DynamoDB è adatto a vari tipi di applicazioni, in generale tutte quelle in cui un elevato numero di utenti deve accedere velocemente a una base dati comune (ad esempio per un’app mobile).
Non è adatto invece alle applicazioni in cui l’accento è meno sulla velocità nella consultazione e modifica dei dati e più sulle funzioni di analisi e aggregazione dei dati stessi. Premesso questo, la natura “velocistica” di DynamoDB si vede anche nel modello di pagamento previsto, che non si basa sul volume di dati memorizzati ma sul throughput delle query. E qui possono nascere alcune difficoltà per gli utenti meno abituati a questa logica.
La teoria dell’organizzazione delle informazioni in DynamoDB non è banale. Semplificando, la piattaforma cerca di distribuire le varie chiavi su diverse partizioni in modo che il carico di ciascuna sia più o meno costante e in linea con il throughput “prenotato” dal cliente. Se però una chiave genera traffico in eccesso, il sistema crea per essa una nuova partizione. E il costo del servizio aumenta. Se le chiavi “calde” sono troppe, il costo di DynamoDB può aumentare parecchio al di là delle previsioni iniziali.
Questo è il primo elemento di cui tenere conto nella gestione dei costi di DynamoDB: il parametro fondamentale è il throughput e la gestione delle chiavi è l’elemento che può sconvolgere gli equilibri. Un’operazione quindi molto consigliabile è tenere traccia delle chiavi che in un dato momento generano un picco nelle query alla piattaforma e quindi anche nei costi. A volte questi picchi sono legati a cattiva programmazione più che a una effettiva necessità di eseguire quelle query in quel momento.
In generale l’obiettivo nella gestione di un ambiente DynamoDB dovrebbe essere, dal punto di vista dei costi, ottimizzare l’utilizzo del throughput che si sta pagando. Il che vuol dire anche evitare di consumarlo inutilmente. Ci sono funzioni stesse di DynamoDB che lo permettono, come gli Stream. Gli Stream sono “flussi” che contengono tutte le modifiche apportate sequenzialmente ai dati di una tabella DynamoDB: consultandoli si possono eseguire analisi sulle variazioni (ad esempio quali chiavi sono consultate più di frequente) senza andare a operare sulla tabella stessa.
Sempre nell’ottica dell’ottimizzazione dei costi, AWS ha di recente introdotto per DynamoDB una funzione cosiddetta di Auto Scaling che fa variare dinamicamente il throughput “ufficiale” di un ambiente DynamoDB. L’utente indica un minimo e un massimo entro cui può variare e il sistema si adatta in tempo reale restando sempre dentro queste soglie.
Molta parte dell’ottimizzazione nell’utilizzo di DynamoDB sarà però legata alla nostra capacità di usare bene la piattaforma. Un elemento su cui vale la pena intervenire è la gestione “oculata” delle operazioni di scrittura, che sono più costose di quelle di lettura. Per questo conviene raggruppare fra loro gli aggiornamenti in scrittura ed eseguirli in batch, come anche evitare che una stessa chiave debba essere modificata più volte inutilmente.
