AWS MySQL RDS vs AWS DynamoDB [chiuso]


109

Uso MySQL da un bel po 'di tempo e mi trovo bene con la sua struttura e le query SQL ecc.

Attualmente sto realizzando un nuovo sistema in AWS e ho esaminato DynamoDB. Attualmente ne so solo un po '.

Uno è migliore dell'altro?

Quali sono i vantaggi di DynamoDB?

com'è la transizione dalle query MySQL ecc. a questo DB in stile piatto?

Risposte:


66

Puoi leggere la spiegazione di AWS al riguardo qui .

In breve, se si dispone principalmente di ricerca diretta query (e non Join query), DynamoDB (e altri NoSQL DB) è meglio. Se hai bisogno di gestire molti dati , sarai limitato quando usi MySQL (e altri RDBMS).

Non puoi riutilizzare le tue query MySQL né il tuo schema di dati, ma se spendi lo sforzo per imparare NoSQL, aggiungerai uno strumento importante alla tua cassetta degli attrezzi. Ci sono molti casi in cui DynamoDB offre la soluzione più semplice.


262

Davvero DynamoDB e MySQL sono mele e arance. DynamoDB è un livello di archiviazione NoSQL mentre MySQL viene utilizzato per l'archiviazione relazionale. È necessario scegliere cosa utilizzare in base alle effettive esigenze dell'applicazione. In effetti, alcune applicazioni potrebbero essere ben servite utilizzando entrambi.

Se, ad esempio, stai archiviando dati che non si prestano bene a uno schema relazionale (strutture ad albero, rappresentazioni JSON senza schema, ecc.) Che possono essere confrontati con una singola chiave o una combinazione chiave / intervallo, DynamoDB ( o qualche altro negozio NoSQL) sarebbe probabilmente la soluzione migliore.

Se disponi di uno schema ben definito per i tuoi dati che può adattarsi bene a una struttura relazionale e hai bisogno della flessibilità per interrogare i dati in diversi modi (aggiungendo gli indici se necessario, ovviamente), RDS potrebbe essere una soluzione migliore .

Il vantaggio principale dell'utilizzo di DynamoDB come archivio NoSQL è che si ottiene un throughput di lettura / scrittura garantito a qualsiasi livello richiesto senza doversi preoccupare di gestire un data store in cluster. Quindi, se la tua applicazione richiede 1000 letture / scritture al secondo, puoi semplicemente eseguire il provisioning della tua tabella DynamoDB per quel livello di throughput e non devi davvero preoccuparti dell'infrastruttura sottostante.

RDS ha lo stesso vantaggio di non doversi preoccupare dell'infrastruttura stessa, tuttavia se si finisce per aver bisogno di fare un numero significativo di scritture fino al punto in cui la dimensione dell'istanza più grande non sarà più al passo, si viene lasciati senza opzioni (puoi ridimensionare orizzontalmente per le letture utilizzando le repliche di lettura).

Nota aggiornata: DynamoDb ora supporta l'indicizzazione secondaria globale, quindi ora hai la possibilità di eseguire ricerche ottimizzate su campi dati diversi dall'hash o dalla combinazione di hash e chiavi di intervallo.


10
Se potessi votare la tua risposta di 100, lo farei.
Salil

Alcuni tipi di problemi in un modello di informazioni tendono bene a un tipo di implementazione NoSQL. Quando ti imbatti in tali problemi, chiediti se ha senso avere un database NoSQL. Alcune di queste entità sono: Log, dati di serie temporali, social
network

150

Abbiamo appena migrato tutte le nostre tabelle DynamoDB su RDS MySQL.

Sebbene l'utilizzo di DynamoDB per attività specifiche possa avere senso, costruire un nuovo sistema su DynamoDB è davvero una cattiva idea. I migliori piani, ecc., Hai sempre bisogno di quella flessibilità extra dal tuo DB.

Ecco i motivi per cui siamo passati da DynamoDB:

  1. Indicizzazione: è impossibile modificare o aggiungere chiavi al volo senza creare una nuova tabella.
  2. Query: le query sui dati sono estremamente limitate. Soprattutto se desideri eseguire query su dati non indicizzati. I join sono ovviamente impossibili, quindi devi gestire complesse relazioni di dati sul tuo livello di codice / cache.
  3. Backup: una procedura di backup così noiosa è una sorpresa deludente rispetto all'ottimo backup di RDS
  4. GUI - pessima UX, ricerca limitata, niente divertimento.
  5. Velocità: il tempo di risposta è problematico rispetto a RDS. Ti ritrovi a costruire un meccanismo di caching elaborato per compensarlo in luoghi in cui ti saresti sistemato per il caching interno di RDS.
  6. Integrità dei dati - Anche se il concetto di struttura dati fluida sembra carino all'inizio, alcuni dei tuoi dati sono meglio "scolpiti nella pietra". La digitazione forte è una benedizione quando un piccolo bug cerca di distruggere il tuo database. Con DynamoDB tutto è possibile e in effetti tutto ciò che può andare storto lo fa.

Ora usiamo DynamoDB come backup per alcuni sistemi e sono sicuro che lo useremo in futuro per attività specifiche e ben definite. Non è un cattivo DB, semplicemente non è il DB per servire il 100% del tuo sistema principale.

Per quanto riguarda i vantaggi, direi scalabilità e durata. Si ridimensiona in modo incredibile e trasparente ed è (più o meno) sempre alto. Queste sono davvero ottime caratteristiche, ma non compensano in alcun modo gli aspetti negativi.


11
Pro / contro molto specifici. Ottima risposta
stevendesu

10
Alcuni di questi non sono aggiornati. Ad esempio, 1 non è più vero.
mbroshi

2
Risposta molto ben documentata. Tuttavia, alcune di queste preoccupazioni possono essere specifiche per casi d'uso rari. Numero 2 - "I join sono ovviamente impossibili" - Le strutture dati di DynamoDB non dovrebbero avere alcuna relazione - punto. La tabella dovrebbe essere completamente denormalizzata. Ciò significa che alcuni attributi vengono duplicati. In questi casi, utilizzare un trigger dinamo o scritture condizionali. Se gli utenti non sono in grado di gestire la latenza per le scritture condizionali, inserire una coda SQS tra l'applicazione e la dinamo. Inoltre, il punto numero 6 è denominato erroneamente al punto che mette in dubbio l '"integrità" di DynamoDB - questa potrebbe non essere l'intenzione ...
doles

1
Dynamo manca ancora di flessibilità durante le query. Sebbene i GSI siano di grande aiuto, possiamo comunque modellare meglio i nostri dati con lo schema RDBMS.
Pavan

1
Aggiungerei che le capacità di query all'interno di DynamoDB hanno alcuni "trucchi". Ad esempio, se la tua chiave primaria è costituita da un solo hash, una query Dynamo può restituire solo 1 voce, non puoi fornire un intervallo a una chiave solo hash al momento della query, né puoi eseguire query senza conoscere l'hash specifico del oggetto che stai cercando. BatchGet accetta solo 100 richieste, 1 MB di dimensione della risposta totale o 1 MB di dimensione della query totale, a seconda dell'evento che si verifica per primo. La scansione offre una ricerca flessibile, ma è altamente inefficiente e costosa, restituendo l'intera tabella prima del filtraggio.
Brooks

12

Quando utilizzi DynamoDB dovresti anche sapere che gli elementi / record in DynamoDB sono limitati a 400 KB (vedi Limiti di DynamoDB ). Per molti casi d'uso questo non funzionerà. Quindi DynamoDB andrà bene per poche cose ma non per tutte. Lo stesso vale per molti degli altri database NoSQL.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.