DynamoDB vs MongoDB NoSQL [chiuso]

Sto cercando di capire cosa posso usare per un progetto futuro, prevediamo di archiviare circa 500k record al mese nel primo anno e forse di più per i prossimi anni questa è un'applicazione verticale, quindi non c'è bisogno di usare un database per questo, questo è il motivo per cui ho deciso di scegliere un archivio dati noSQL.

La prima opzione che mi è venuta in mente è stata mongo db poiché è un prodotto molto maturo con molto supporto da parte della community, ma d'altra parte abbiamo ottenuto un nuovo prodotto che offre un servizio gestito ad alte prestazioni, lo svilupperò applicazione ma non esiste un piano di manutenzione (almeno per ora), quindi penso che sarà un enorme vantaggio poiché Amazon fornisce un modo elastico di ridimensionamento.

La mia principale preoccupazione riguarda la struttura delle query, non ho ancora esaminato le funzionalità di query di dynamoDB, ma dato che è l'archiviazione dei dati ak / v, ritengo che questo potrebbe essere più limitato di mongo db.

Se qualcuno ha avuto l'esperienza di spostare un progetto da mongoDB a DynamoDB, qualsiasi consiglio sarà totalmente apprezzato.

Di recente ho migrato il mio MongoDB su DynamoDB e ho scritto 3 blog per condividere alcune esperienze e dati su prestazioni, costi.

Migrare da MongoDB a AWS DynamoDB + SimpleDB

7 motivi per cui dovresti usare MongoDB su DynamoDB

3 motivi per cui dovresti usare DynamoDB su MongoDB

So che questo è vecchio, ma viene ancora fuori quando cerchi il confronto. Stavamo usando Mongo, ci siamo trasferiti quasi interamente a Dynamo, che è la nostra prima scelta ora. Non perché ha più funzionalità, non lo è. Mongo ha un linguaggio di query migliore, puoi indicizzarlo all'interno di una struttura, ci sono molte piccole cose. La superiorità di Dynamo sta in ciò che l'OP ha affermato nel suo commento: è facile. Non devi occuparti di nessun server. Quando inizi a configurare una soluzione mossa Mongo, diventa complicato. Puoi andare in una delle società di hosting, ma non è neanche economico. Con Dynamo, se hai bisogno di più throughput, fai semplicemente clic su un pulsante. È possibile scrivere script per ridimensionarli automaticamente. Quando è il momento di aggiornare Dynamo, è fatto per te. Questo è tutto un prezioso stress e tempo non speso. Se non

Quindi ora andiamo su Dynamo per impostazione predefinita. Mongo forse, se la struttura dei dati è abbastanza complicata da giustificarlo, ma probabilmente torneremmo a un database SQL. La dinamo è ottusa, devi davvero pensare a come la costruirai e probabilmente utilizzerai Redis in Elasticcache per farlo funzionare per cose complesse. Ma è sicuramente bello non averne cura. Tu codice. Questo è tutto.

Con 500.000 documenti, non c'è motivo di ridimensionare. Un tipico laptop con un SSD e 8 GB di RAM può facilmente fare 10 milioni di dischi, quindi se stai cercando di scegliere a causa del ridimensionamento della tua scelta non importa. Ti suggerirei di scegliere quello che ti piace di più, e forse dove puoi trovare il maggior supporto online.

Per i confronti di una rapida panoramica, mi piace molto questo sito Web, che ha molte pagine di confronto, ad esempio AWS DynamoDB vs MongoDB; http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

Risposta breve: iniziare con SQL e aggiungere NoSQL solo quando / se necessario. (a meno che non ti serva nulla oltre a domande molto semplici)

La mia esperienza personale: non ho usato MongoDB per le query, ma da aprile 2015 DynamoDB è ancora molto paralizzato quando si tratta di qualcosa al di là delle più elementari query chiave / valore. Lo adoro per le cose di base ma se vuoi un linguaggio di query, cerca una vera soluzione di database SQL.

In DynamoDB è possibile eseguire una query su un hash o su un tasto hash e range e si possono avere più indici globali secondari. Sto eseguendo query su una singola tabella con 4 possibili parametri di filtro e ordinando i risultati, questo è supportato (a malapena) attraverso l'uso degli indici secondari globali con espressioni di filtro. Il problema si presenta quando provi a ottenere i risultati totali corrispondenti al filtro, non puoi semplicemente cercare i primi 10 elementi corrispondenti al filtro, ma piuttosto controlla 10 articoli e potresti ottenere 0 risultati validi costringendoti a mantenere scansionando dalla chiave continua - dolore al collo e consuma troppa quota della tabella per leggere un semplice scenario.

Per essere precisi sul problema del limite con i filtri nella query, questo è dai documenti ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ):

In una risposta, DynamoDB restituisce tutti i risultati corrispondenti all'interno
l'ambito del valore limite. Ad esempio, se si emette una query
o una richiesta di scansione con un valore limite di 6 e senza filtro
espressione, l'operazione restituisce i primi sei elementi in 
tabella che corrisponde ai parametri della richiesta. Se fornisci anche a
FilterExpression, l'operazione restituisce gli elementi all'interno di 
primi sei elementi nella tabella che corrispondono ai requisiti del filtro.

La mia conclusione è che le query che coinvolgono FilterExpressions sono utilizzabili solo in occasioni molto rare e non sono scalabili perché ogni query può leggere facilmente la maggior parte o tutta la tabella che consuma troppe unità di lettura DynamoDB. Una volta che usi troppe unità di lettura, sarai limitato e vedrai scarse prestazioni.

Parere dell'esperto: nel summit di AWS del 9 aprile 2015 Brett Hollman, Manager, Solutions Architecture, AWS nel suo discorso sullo scallamento ai tuoi primi 10 milioni di utenti, sostiene di iniziare con un database SQL e di utilizzare NoSQL solo quando e se ha senso. Perché prima o poi probabilmente avrai bisogno di un server SQL da qualche parte nello stack. Le sue diapositive sono qui: http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users Vedi diapositiva 28.

Abbiamo scelto una combinazione di Mongo / Dynamo per un prodotto sanitario. Fondamentalmente mongo consente una ricerca migliore, ma la Dynamo ospitata è eccezionale perché è conforme HIPAA senza alcun lavoro aggiuntivo. Quindi ospitiamo la porzione mongo senza dati personali su una configurazione standard e consentiamo ad Amazon di gestire la parte HIPAA in termini di infrastruttura. Possiamo interrogare determinati elementi da mongo che richiamano documenti con puntatori (ID) del documento Dynamo correlabile.

Il motivo principale per cui abbiamo scelto di farlo usando mongo invece di ospitare l'intera applicazione sulla dinamo è stato per 2 motivi. In primo luogo, dovevamo preformare le ricerche basate sulla posizione che mongo è eccezionale in quel momento, Dynamo non lo era, ma ora hanno un'opzione.

In secondo luogo, alcuni documenti non erano strutturati e non sapevamo in anticipo quali sarebbero stati i dati, quindi ad esempio diciamo all'utente di inserire un documento nella raccolta "form" in questo modo: {"username": "user1", " email ":" me@me.com "}. E un altro utente inserisce questo nella stessa raccolta {"phone": "813-555-3333", "location": [28.1234, -83.2342]}. Con mongo possiamo cercare uno qualsiasi di questi campi dinamici e sconosciuti in qualsiasi momento, con Dynamo, puoi farlo ma dovresti creare un indice ogni volta che un nuovo campo è stato aggiunto che desideri ricercare. Quindi, se non hai mai avuto un campo telefonico nel tuo documento Dynamo prima e poi all'improvviso, qualcuno lo aggiunge, è completamente impenetrabile.

Ora questo fa apparire un altro punto in cui hai citato. A volte scegliere la soluzione giusta per il lavoro non significa sempre scegliere il prodotto migliore per il lavoro. Ad esempio, potresti avere un cliente che ha bisogno e utilizzerà il sistema che hai creato per oltre 10 anni. Scegliere una soluzione SaaS / IaaS che sia abbastanza buona da portare a termine il lavoro potrebbe essere un'opzione migliore in quanto puoi fare affidamento su Amazon per mantenere e mantenere i loro sistemi a lungo termine.

Ho lavorato su entrambi e tipo di fan di entrambi.

Ma devi capire quando usare cosa e per quale scopo.

Non credo sia una buona idea spostare tutto il database su DynamoDB, motivo per cui è difficile interrogare se non su chiavi primarie e secondarie, l'indicizzazione è limitata e la scansione in DynamoDB è dolorosa.

Preferirei un tipo ibrido di DB, in cui dovrebbero essere presenti estesi dati in grado di eseguire query, MongoDB, con tutte le sue funzionalità che non ti sentiresti mai costretto a fornire miglioramenti o modifiche.

DynamoDB è velocissimo (più veloce di MongoDB), quindi DynamoDB viene spesso utilizzato come alternativa alle sessioni in applicazioni scalabili. Le best practice di DynamoDB suggeriscono inoltre che se ci sono molti dati che vengono meno utilizzati, spostarli su un'altra tabella.

Supponiamo quindi di avere articoli o feed. Le persone hanno maggiori probabilità di cercare roba della scorsa settimana o roba di questo mese. è molto raro che le persone visitino i dati di due anni. A tal fine, DynamoDB preferisce archiviare i dati per mese o anni in diverse tabelle.

DynamoDB è apparentemente scalabile, cosa che dovrai fare manualmente in MongoDB. tuttavia si perderebbero le prestazioni di DynamoDB, se non si capisce la partizione della velocità effettiva e il funzionamento del ridimensionamento dietro la scena.

DynamoDB dovrebbe essere usato laddove la velocità è fondamentale, MongoDB ha invece troppe mani e funzionalità, qualcosa che manca a DynamoDB.

ad esempio, è possibile avere un set di repliche di MongoDB in modo tale che una delle repliche contenga un'istanza di dati di 8 (o qualunque altra) ora. Davvero utile, se hai incasinato qualcosa di grande nel tuo DB e vuoi ottenere i dati come prima.

Questa è la mia opinione però.

Ricorda, ho solo sperimentato MongoDB ...

Da quello che ho letto, DynamoDB ha fatto molta strada in termini di funzionalità. Era un archivio di valori-chiave super-base con capacità di archiviazione e query estremamente limitate. Da allora è cresciuto, ora supporta documenti di dimensioni maggiori + supporto JSON e indici secondari globali . Il divario tra ciò che DynamoDB e MongoDB offre in termini di funzionalità diminuisce ogni mese. Le nuove funzionalità di DynamoDB sono ampliate qui .

Gran parte dei confronti tra MongoDB e DynamoDB non sono aggiornati a causa della recente aggiunta delle funzionalità di DynamoDB. Tuttavia, questo post offre alcuni altri punti convincenti per scegliere DynamoDB, vale a dire che è semplice, bassa manutenzione e spesso a basso costo. Un'altra discussione qui sulle scelte del database era interessante da leggere, sebbene leggermente vecchia.

Il mio takeaway: se stai eseguendo query sul database o lavori in lingue non supportate da DynamoDB, usa MongoDB. Altrimenti, mantieni con DynamoDB.