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:
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.
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.
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:
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.
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.