Quando usare DynamoDB (e quando no)

DynamoDB è un database fantastico per i carichi di lavoro per cui è stato costruito e frustrante per tutti gli altri. La domanda decisiva non è «è web-scale?» — è «conosco i miei pattern di accesso in anticipo, e sono key-based?» Azzeccala e DynamoDB ti dà letture in pochi millisecondi a qualsiasi scala; sbagliala e combatterai per sempre con la mancanza di join e di query ad-hoc.

Quando dovrei usare DynamoDB?

Usa DynamoDB quando i tuoi pattern di accesso sono noti, key-based e ad alto volume, e vuoi una latenza prevedibile di pochi millisecondi a qualsiasi scala senza server da gestire. Evitalo per query ad-hoc, join ricchi o analisi sull'intero dataset, e quando i dati sono pochi e le forme delle query continuano a cambiare.

• Usa DynamoDB quando i tuoi pattern di accesso sono noti, key-based e ad alto volume — e vuoi una latenza prevedibile a qualsiasi scala senza server da gestire.
• Evitalo quando ti servono query ad-hoc, join ricchi o analisi sull'intero dataset, oppure quando i dati sono pochi e le forme delle query continuano a cambiare.
• Il compromesso di fondo: DynamoDB ti obbliga a progettare per le tue query in anticipo; in cambio non rallenta mai man mano che cresci.
• Non è un database relazionale con una sintassi diversa — modellarlo come tale è la fonte di dolore numero uno.

I segnali che favoriscono DynamoDB

DynamoDB brilla quando vale la maggior parte di questi:

• Conosci i tuoi pattern di accesso in anticipo. Puoi elencare le query esatte che fa l'app («prendi un utente per id», «elenca gli ordini di un utente dal più recente») e non cambiano a capriccio. DynamoDB è modellato attorno a quelle query.
• L'accesso è key-based. Cerchi gli Item tramite una partition key nota, non scansionando combinazioni arbitrarie di attributi.
• Scala e latenza prevedibile contano. DynamoDB offre prestazioni costanti di pochi millisecondi che la tabella contenga mille Item o un miliardo.
• Vuoi zero overhead operativo. Niente istanze, niente failover, niente vacuuming — è completamente gestito e scala a zero on-demand.
• Il throughput in scrittura è alto e irregolare. Log di eventi, telemetria IoT, stato di sessione/carrello, classifiche — carichi di lavoro ad alta append con una chiave chiara.

I segnali contrari

Ricorri invece a un database relazionale (o a un motore di ricerca/analisi) quando:

• Le tue query sono ad-hoc. Gli analisti suddividono i dati per colonne arbitrarie, oppure i requisiti cambiano ogni settimana. La flessibilità di SQL vince; DynamoDB avrebbe bisogno di un nuovo indice per ogni pattern.
• Ti servono join e aggregazioni reali sull'intero dataset. Reportistica, business intelligence, «somma il fatturato per regione per mese» — è un lavoro OLAP/relazionale.
• Il dataset è piccolo e a basso traffico. Qualche migliaio di righe su una tranquilla app di amministrazione non trae alcun beneficio dalla scala di DynamoDB e perde la comodità di SQL.
• Non riesci ancora a prevedere i pattern di accesso. Prodotto in fase iniziale che sta ancora trovando la sua forma? Uno schema relazionale che puoi re-interrogare liberamente è più indulgente finché i pattern non si stabilizzano.

Calcolare il costo prima di impegnarti

I prezzi di DynamoDB seguono letture, scritture e archiviazione — non le ore di istanza — quindi è economico per carichi di lavoro irregolari e serverless e può essere caro per scan pesanti e prolungati. Modella il tuo mix reale di letture/scritture con il calcolatore dei prezzi di DynamoDB prima di impegnarti; un carico di lavoro che tecnicamente sembra adatto dovrebbe risultare conveniente anche sul costo.

Una volta che hai deciso che è adatto

Il lavoro si sposta sulla modellazione. DynamoDB premia il progettare la tabella attorno alle tue query — vedi come modellare i dati in DynamoDB e single-table design — ed esplicitamente quando non ricorrere al single-table.

Trappole e prossimi passi

• Non modellare DynamoDB come un database relazionale — tabelle normalizzate che unisci in lettura è l'anti-pattern che punisce più duramente.
• Non sceglierlo per le analisi — abbinalo a uno store analitico (o esporta verso uno) per la reportistica invece di fare scan.
• Incerto sui pattern di accesso? Aspetta. Adottare DynamoDB prima di conoscere le tue query significa scegliere l'unico database che pretende che tu le conosca.
• Correlati: query vs scan mostra cosa ti dà davvero «l'accesso key-based».

Vuoi esplorare una tabella DynamoDB prima di scommetterci la tua app? Scarica DynoTable e connettiti ai tuoi dati direttamente.