DynamoDB vs Redshift

DynamoDB e Amazon Redshift sono raramente alternative. DynamoDB è un database operativo — letture e scritture nell'ordine dei millisecondi a una cifra su chiavi note, al servizio del traffico live dell'applicazione. Redshift è "a fully managed, petabyte-scale data warehouse service in the cloud," costruito per scansionare e aggregare grandi dataset per reporting e analisi. I team che usano entrambi sono il caso normale, e AWS offre un'integrazione gestita per spostare i dati in una direzione tra i due.

Dovresti usare DynamoDB o Redshift?

Usa DynamoDB per i dati live dell'applicazione: ordini in fase di inserimento, sessioni lette, record recuperati per chiave. Usa Redshift quando qualcuno deve porre domande sull'intero dataset — ricavi per regione e mese, retention delle cohort, una dashboard che unisce più sorgenti. La domanda «qual dei due» di solito si risolve in «DynamoDB per il percorso di scrittura, Redshift per gli analisti», con l'integrazione zero-ETL nel mezzo.

DynamoDB vs Redshift in breve

Caratteristica	DynamoDB	Redshift
Carico di lavoro	Operativo (in stile OLTP) — letture e scritture ad alto volume per chiave	Analitico — scansioni e aggregazioni su grandi dataset
Modello dei dati	Item NoSQL senza schema fino a 400 KB; gli attributi variano per Item	Tabelle relazionali con colonne dichiarate, distribution key e sort key
Linguaggio di query	API nativa (`GetItem`, `Query`, `Scan`, …) più PartiQL	SQL completo, con il tooling BI e SQL che questo implica
Join e aggregazioni	Nessun join lato server; l'aggregazione non è un'operazione lato server	Join, window function, `GROUP BY` e il resto del SQL analitico
Pattern di accesso	Progettato intorno a chiavi note; le scansioni sono l'eccezione costosa	Progettato per scansionare — leggere molte righe è il caso normale
Latenza	Millisecondi a una cifra per richiesta	Da secondi a minuti per query analitica, su molti più dati
Scalabilità	Serverless; partizioni gestite da AWS	Workgroup serverless o cluster provisionati; capacità dimensionata sul carico di query
Freschezza	Read-your-write on demand	Fresca quanto ciò che la popola — l'integrazione zero-ETL deposita aggiornamenti ogni 15–30 minuti
Modello di prezzo	Per richiesta o capacità provisionata, più storage	Capacità di calcolo più storage; i warehouse serverless inattivi non vengono fatturati per il compute

Quando DynamoDB è la scelta migliore

Traffico live dell'applicazione. Letture e scritture prevedibili nell'ordine dei millisecondi a una cifra su chiavi note, a qualsiasi tasso di richiesta.
Schema che varia per Item. Item eterogenei in una tabella sono normali in DynamoDB; un warehouse vuole colonne dichiarate.
Operazioni serverless. Nessun cluster da dimensionare, patchare o mettere in pausa.
Percorsi intensivi in scrittura. DynamoDB assorbe scritture ad alto volume come lavoro principale; un warehouse è ottimizzato per bulk load e lettura.

Quando Redshift è la scelta migliore

Domande che attraversano l'intera tabella. Aggregare un anno di ordini è per natura una scansione, che è esattamente il pattern di accesso che DynamoDB ti chiede di evitare e per cui Redshift è progettato.
Join tra molte sorgenti. I warehouse fanno join. DynamoDB non ha join lato server.
Tooling BI. Redshift parla SQL su JDBC/ODBC, quindi si integra nelle dashboard esistenti e in "the same SQL-based tools and business intelligence applications that you use today."
Analisi che non deve disturbare la produzione. Eseguire analisi su una copia replicata tiene il carico lontano dalla tabella che serve i tuoi utenti.

Usarli insieme

Il pattern standard è unidirezionale: DynamoDB serve l'applicazione, una copia arriva in Redshift, gli analisti lavorano sulla copia. AWS supporta due percorsi — il comando COPY più vecchio, che carica direttamente "from Amazon S3 or Amazon DynamoDB into Amazon Redshift," e l'integrazione zero-ETL gestita, che mantiene la copia aggiornata da sola.

Cosa fa davvero l'integrazione zero-ETL

«Zero-ETL» suggerisce una vista live. Non è una, e i dettagli contano prima di progettare una dashboard su di essa.

È una pipeline di replica a tempo. AWS è preciso: "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." Poi "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." I dati in Redshift sono quindi fino a mezz'ora obsoleti. Va bene per il reporting giornaliero ed è sbagliato per tutto ciò che un utente dovrebbe vedere riflettere la sua ultima azione.

Point-in-time recovery è obbligatorio — e ora il motivo è evidente. Il prerequisito è formulato chiaramente: "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS documenta il requisito in un posto e il meccanismo in un altro, e non li collega, ma la policy basata su risorse che devi attaccare rivela il gioco — concede a redshift.amazonaws.com l'azione dynamodb:ExportTableToPointInTime. L'integrazione è costruita sulla macchina di export-to-S3 di DynamoDB, e quella macchina legge dal backup continuo. Niente PITR, niente export, niente integrazione.

Questo ha un effetto sul budget che la gente incontra tardi: abilitare PITR su una tabella grande è un costo permanente sulla dimensione della tabella, sostenuto per la pipeline di analisi anziché per il recovery. Prezza l'integrazione come «Redshift più PITR», non come Redshift da solo — il gratuito calcolatore dei prezzi DynamoDB dimensiona la parte storage prima che ti impegni.

Due vincoli che bloccano tabelle esistenti. Entrambi sono limitazioni documentate, e entrambi sono difficili da correggere dopo:

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." Un warehouse che consolida più Region non può tirarle tutte dentro tramite questo percorso.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." Le tabelle create con crittografia gestita da AWS devono cambiare le impostazioni di crittografia prima che un'integrazione possa essere creata.

Dove la forma dei tuoi dati ti morde. Gli Item DynamoDB sono per progettazione eterogenei; le tabelle warehouse hanno colonne. Una progettazione a tabella singola che tiene più tipi di entità sotto una convenzione di chiave di partizione non diventa uno star schema pulito per il fatto di essere replicata. Pianifica lavoro di modellazione in Redshift dopo che i dati sono arrivati — l'integrazione rimuove la pipeline, non il design dello schema.

Quando non ti serve ancora un warehouse

Non ogni aggregazione è un problema di analisi. Una grande parte di «dovremmo metterlo in Redshift» inizia come una singola domanda — quanti Item sono in questo stato, qual è il totale per questo cliente, quali chiavi di partizione dominano — posta occasionalmente, da un ingegnere, su una tabella.

Il Workbench SQL di DynoTable risponde a quella classe di domande direttamente su DynamoDB, on demand: SQL reale con COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING e DISTINCT, più INNER/LEFT JOIN. Il posizionamento è deliberatamente stretto — SQL entro le regole di pattern di accesso di DynamoDB. È un singolo SELECT; non ci sono CTE, niente UNION, niente window function e niente subquery scalari; un target di join deve essere una chiave di partizione o una chiave di partizione GSI. I risultati vengono trasmessi in streaming con un badge parziale e diventano esatti una volta che la query termina, e leggere i dati costa comunque le letture che costa.

Questo non è un sostituto di un warehouse, e i limiti sopra sono il confine onesto. Ma è una risposta più rapida di una pipeline di replica, un costo PITR e un design di schema — e ti dice se la domanda valeva un warehouse prima che costruisci uno. Eseguire query Workbench è una funzione a pagamento; l'editor e l'autocompletamento sono gratuiti. DynoTable è un'applicazione commerciale a codice chiuso; questa pagina descrive cosa fa, non come è costruita.

FAQ

Redshift può sostituire DynamoDB?

No, non per il traffico dell'applicazione. Redshift è un data warehouse costruito per scansionare e aggregare; non è progettato per servire lookup per chiave ad alto volume con latenza nell'ordine dei millisecondi a una cifra. I due girano in parallelo, con DynamoDB che serve l'applicazione e una copia replicata in Redshift che serve l'analisi.

Quanto sono freschi i dati DynamoDB in Redshift?

Con l'integrazione zero-ETL, fino a circa 30 minuti obsoleti. AWS documenta che dopo l'export completo iniziale "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." Trattalo come reporting near-real-time, non come vista live.

Perché l'integrazione zero-ETL richiede PITR?

Perché è costruita sull'export point-in-time di DynamoDB. La policy basata su risorse che l'integrazione richiede concede a Amazon Redshift l'azione dynamodb:ExportTableToPointInTime, e quell'export legge dal backup continuo che PITR mantiene. Abilitare PITR è quindi un costo reale e permanente dell'integrazione.

Correlati

Impara quando usare DynamoDB e perché le scansioni sono costose.
Confronta DynamoDB e PostgreSQL per la domanda relazionale operativa.
Modella i pattern di accesso in anticipo con la progettazione a tabella singola.
Dimensiona la parte storage e capacità con il gratuito calcolatore dei prezzi DynamoDB.
Scarica DynoTable per interrogare e aggregare le tue tabelle DynamoDB direttamente.

Riferimenti

Ultima verifica 2026-08-02 rispetto all'AWS Redshift Management Guide ufficiale e al DynamoDB Developer Guide.