Quando utilizzare DynamoDB (e quando non farlo)

DynamoDB è un database fantastico per i carichi di lavoro per cui è stato creato ed è frustrante uno per il resto. La domanda decisiva è "lo so i miei schemi di accesso in anticipo e sono basati su chiavi?" Capito bene e DynamoDB ti dà letture di millisecondi a una cifra su qualsiasi scala; sbagli e combatterai la mancanza di join e query ad hoc per sempre.

Quando dovrei usare DynamoDB?

Utilizza DynamoDB quando i tuoi modelli di accesso sono noti, basati su chiavi e ad alto volume, e tu desideri una latenza prevedibile di pochi millisecondi su qualsiasi scala con zero server gestire. Evitatelo per query ad hoc, rich join o analisi dell'intero set di dati e quando i dati sono piccoli con forme di query che continuano a cambiare.

• Utilizza DynamoDB quando i tuoi modelli di accesso sono noti, basati su chiavi e a volume elevato — e desideri una latenza prevedibile su qualsiasi scala senza server da gestire.
• Evitalo quando hai bisogno di query ad hoc, rich join o analisi generali set di dati o quando i dati sono piccoli e le forme delle query continuano a cambiare.
• Il mestiere principale: DynamoDB ti consente di progettare in anticipo per le tue query; in cambio lo non rallenta mai man mano che cresci.
• Non è un database relazionale con una sintassi diversa, modellandolo come tale la fonte numero 1 del dolore.

I segnali che favoriscono DynamoDB

DynamoDB brilla quando la maggior parte di questi regge:

• Conosci in anticipo i tuoi modelli di accesso. Puoi elencare le query esatte nell'app make ("ottieni un utente tramite ID", "elenca gli ordini di un utente dal più recente") e non cambiano per capriccio. DynamoDB è modellato intorno a queste query.
• L'accesso è basato sulla chiave. Puoi cercare gli elementi in base a una chiave di partizione nota, non tramite scansione per combinazioni arbitrarie di attributi.
• La scalabilità e la latenza prevedibile sono importanti. DynamoDB offre tutto millisecondo a una cifra coerente performance sia che la tabella contenga mille elementi o un miliardo.
• Vuoi zero costi operativi. Nessuna istanza, nessun failover, nessuna svuotamento — è completamente gestito e scalabile fino a zero su richiesta.
• Il throughput di scrittura è elevato e discontinuo. Registri eventi, telemetria IoT, session/cart stato, classifiche: aggiungi carichi di lavoro pesanti con una chiave chiara.

I segnali contrari

Utilizzare invece un database relazionale (o un motore search/analytics) quando:

• Le tue query sono ad hoc. Gli analisti suddividono i dati in colonne arbitrarie o i requisiti cambiano settimanalmente. La flessibilità di SQL vince; DynamoDB avrebbe bisogno di un nuovo indice per modello.
• Sono necessari join e aggregazioni reali nell'intero set di dati. Reporting, business intelligence, "somma dei ricavi per regione per mese": questo è un OLAP/relational lavoro. (La domanda una tantum su un tavolo live è un caso diverso: SQL Workbench di DynoTable esegue JOIN, GROUP BY, e aggregati sul lato client DynamoDB; è il carico di lavoro BI permanente che appartiene altrove.)
• Il set di dati è piccolo e con poco traffico. Qualche migliaio di righe su un'app di amministrazione silenziosa non trae alcun vantaggio dalla scala dell'DynamoDB e perde la comodità dell'SQL.
• Non è ancora possibile prevedere i modelli di accesso. Il prodotto in fase iniziale sta ancora trovando il suo posto forma? Uno schema relazionale che puoi interrogare nuovamente liberamente è più indulgente fino al i modelli si stabiliscono.

Confronta DynamoDB con altri database

"Devo usare DynamoDB o X?" di solito è la stessa domanda in abiti diversi: fa X lasciatemi rinviare la decisione sul modello di accesso, e cosa devo pagare per questo? DynamoDB lo è l'opzione che si rifiuta di lasciarti posticipare. Ogni confronto riportato di seguito si basa su quello commercio, non sulle liste di controllo delle funzionalità.

Relazionale: PostgreSQL, RDS e Aurora

Questo è il vero bivio e quello che la maggior parte delle squadre sbaglia. Un database relazionale ti consente scrivi la query dopo che hai i dati. DynamoDB no: il tavolo ha la forma di query prima che venga scritto un singolo elemento.

Scegli relazionale quando le forme di query sono ancora in movimento, quando hai bisogno di join o aggregati nell'intero set di dati o quando i dati sono sufficientemente piccoli da non poter essere scalati il problema che hai. Scegli DynamoDB quando i modelli sono stabiliti e basati su chiavi e tu Voglio che costino lo stesso su un miliardo di articoli che su mille.

RDS e Aurora non cambiano questo calcolo: sono motori relazionali gestiti, quindi ereditano la flessibilità di SQL e il suo modello di scalabilità. Ciò che cambia è l'operativo confronto: con Aurora Serverless vale l'argomento "nessun server da gestire" per DynamoDB molto più debole, e la decisione ricade nettamente sui modelli di accesso. Scaglie dell'aurora calcolare; DynamoDB rimuove il concetto.

Documento: MongoDB e DocumentDB

Entrambi memorizzano documenti simili a JSON, quindi sembrano intercambiabili con DynamoDB a distanza. Non lo sono. MongoDB indicizza qualsiasi campo ed esegue query ad hoc su di esso; DynamoDB dà la chiave di partizione, la chiave di ordinamento e gli indici dichiarati in anticipo.

Ciò rende MongoDB la soluzione migliore per l'evoluzione delle forme di query e DynamoDB la soluzione migliore per quelli conosciuti ad alto volume. DocumentDB si trova sul lato AWS della stessa linea: it parla MongoDB API, quindi trattalo come "flessibilità di MongoDB, modello operativo di AWS", e confrontarlo con DynamoDB esattamente sull'asse flessibilità-prevedibilità sopra.

Colonna larga: Cassandra

Cassandra è il parente architettonico più vicino di DynamoDB: chiave di partizione, clustering key e la stessa dura verità che una chiave di partizione errata è un bug di progettazione che non è possibile indicizzare la tua via d'uscita. Se stai scegliendo tra loro, i fattori decisivi raramente sono i modello di dati: sono loro chi lo gestisce e come paghi. Cassandra si opera (o si acquista gestita); DynamoDB consumi. Amazon Keyspaces è la via di mezzo gestita da Cassandra.

Poiché i modelli sono così vicini, la guida alla modellazione su questo sito trasferisce principalmente: il progettazione a tabella singola ragionamento sulle chiavi di partizione e i modelli di accesso si applicano a Cassandra quasi riga per riga.

In memoria: Redis

Redis e DynamoDB risolvono diversi problemi. Redis è basato sulla memoria ed è ottimizzato per l'accesso inferiore al millisecondo dati che puoi permetterti di perdere o ricostruire; DynamoDB è durevole per impostazione predefinita. Il comune la risposta alla produzione è entrambe le cose: DynamoDB come sistema di registrazione, Redis (o DAX, che è cache di lettura di DynamoDB) davanti ai tasti di scelta rapida.

Utilizzare solo Redis solo quando i dati sono veramente effimeri: contatori con limite di velocità, sessioni di breve durata, classifiche che puoi ricalcolare.

Ricerca: Elasticsearch e OpenSearch

Search e DynamoDB risolvono anche problemi diversi, per una ragione più acuta rispetto a Redis: DynamoDB non ha il testo completo cercare affatto. Query corrisponde all'uguaglianza delle chiavi e a un insieme ristretto di condizioni delle chiavi di ordinamento. Scan con FilterExpression legge ogni elemento e poi ne scarta la maggior parte: è un table walk con un filtro attivato, non una ricerca, e paghi per gli articoli letti anziché gli articoli restituiti. Non esiste una classifica di pertinenza, nessun analizzatore, nessuna corrispondenza fuzzy, no sfaccettatura.

Quindi la domanda non è mai "DynamoDB o un motore di ricerca". È "è necessario questo carico di lavoro ricerca e, in caso affermativo, cosa alimenta l'indice?" La forma standard è entrambe: DynamoDB come sistema di record, un cluster di ricerca accanto ad esso e flussi DynamoDB che trasportano ogni modifica nel file indice. Ciò acquista una ricerca reale e ti costa un secondo sistema da eseguire e un indice che lo sia coerenza eventuale con il tavolo.OpenSearch ed Elasticsearch sono la stessa decisione. OpenSearch è il fork di AWS Elasticsearch, diviso a 7.10 nel 2021 a causa del cambio di licenza di Elastic, e i due si sono allontanati a parte da allora. Nessuna di queste derive tocca questa domanda: "la ricerca dovrebbe vivere all'esterno". DynamoDB", si comportano in modo identico. Scegli tra loro su licenza, hosting e quale servizio gestito che desideri utilizzare, non su nulla che abbia a che fare con DynamoDB.

Raggiungi un motore di ricerca come negozio principale solo quando la ricerca è veramente il prodotto — log analytics, un catalogo il cui modello di accesso principale è il testo libero. Anche allora, la maggior parte delle squadre continua un archivio durevole dietro di esso, perché un indice di ricerca è una vista derivata di cui devi essere in grado ricostruire.

L'asse dei costi, nascosto dal confronto dei modelli

Tutti i confronti sopra riportati riguardano modelli di dati, ma di solito la sorpresa sul conto è questa strutturale: i motori relazionali fatturano per la capacità fornita, DynamoDB fattura per operazioni eseguite. Ciò rende DynamoDB economico per carichi di lavoro intensi e inattivi e costoso per la scansione prolungata: lo stesso carico di lavoro può vincere su un motore e perdere gravemente dall'altro senza alcuna modifica del codice tra di loro.

Il moltiplicatore che manca alle persone sono gli indici. Su un motore relazionale un indice aggiuntivo costa l'archiviazione e alcuni scrivono latenza; su DynamoDB ogni indice secondario è una scrittura extra completa del attributi proiettati. Abbiamo eseguito l'aritmetica su tre volumi di scrittura la guida agli indici — un GSI raddoppia il costo di scrittura, due tripli esso. Modella il tuo vero mix read/write nel calcolatore dei prezzi prima di impegnarti con una delle due parti.

Contare il costo prima di impegnarsi

I prezzi di DynamoDB seguono le letture, le scritture e l'archiviazione, non le ore di istanza, quindi è così economico per carichi di lavoro intensivi e serverless e può essere costoso per scansioni pesanti e prolungate. Modella il tuo vero mix read/write con Calcolatore prezzi DynamoDB prima di impegnarsi; un carico di lavoro che tecnicamente sembra adatto dovrebbe anche tenere conto dei costi.

Una volta deciso che è adatto

Il lavoro si sposta sulla modellistica. DynamoDB premia la progettazione della tabella intorno alle tue query — vedere come modellare i dati in DynamoDB e design a tabella singola - ed esplicitamente quando non è possibile raggiungere la tabella singola.

Insidie + passaggi successivi

• Non modellare DynamoDB come un database relazionale: tabelle normalizzate a cui ti unisci il tempo di lettura è l'anti-pattern che punisce più duramente.
• Non sceglierlo per l'analisi: abbinalo a un negozio di analisi (o esportalo in uno) per la reportistica invece della scansione.
• Non sei sicuro dei modelli di accesso? Aspetta. Adozione di DynamoDB prima di conoscere il tuo query è scegliere l'unico database che richiede di conoscerle.
• Correlato: query vs scan mostra cosa "accesso basato su chiave" in realtà ti compra.

Vuoi esplorare un tavolo DynamoDB prima di scommettere su di esso con la tua app? Scarica DynoTable e connettiti direttamente ai tuoi dati: è SQL Workbench esegue gli JOIN ad hoc e gli aggregati Lo stesso DynamoDB non lo farà.