DynamoDB vs MongoDB NoSQL [chiuso]


172

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.


3
Se desideri consigli sulla struttura delle query, suggerirei di fornire un esempio del tuo schema insieme ai tuoi casi d'uso per l'accesso ai dati. Senza questi è difficile giudicare in forma.
James Wahlin,

In effetti, il modo in cui stai interrogando i dati potrebbe influenzare notevolmente la selezione di db back-end. Quanto sarebbe gerarchica la mia domanda n. 1.
zanlok,

3
Sono sorpreso che questa domanda non sia già stata chiusa classificando le persone SO. Di solito le domande che chiedono consigli vengono chiuse perché non chiedono aiuto per un problema molto specifico.
LS

Risposte:


67

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


grazie per aver pubblicato qui i tuoi articoli che mi hanno aiutato ad avere una visione più chiara e che sicuramente mi aiuterà nel momento in cui farò una decisione
jack.the.ripper

1
leggendo i tre motivi per cui si dovrebbe usare la dinamo rispetto a mongo, esiste una società che offre un servizio gestito che è più costoso rispetto al dynamoDB ma che potrebbe essere preso in considerazione nel caso in cui non si abbia un responsabile della manutenzione del nosql , il nome dell'azienda è mongoLab
jack.the.ripper

2
@Pedro Grazie mille per il promemoria. Forse sto usando MongoDB in modo inefficiente. Ho 1,4 milioni di record e ho occupato il disco 8G, ma dopo il trasferimento su DynamoDB, occupano solo 300 milioni di spazio di archiviazione. Potrei aver bisogno di un test e vedere quale sia l'archiviazione se migra quei dati su MongoLab :)
Mason Zhang

1
I collegamenti sono interrotti?
fedorqui 'SO smette di danneggiare'

@MasonZhang Sarà molto interessante vedere quale sia l'archiviazione se migra quei dati su MongoLab.
fuiiii,

164

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.


35
Se si deve confrontare il database con il database, è necessario confrontare solo le funzionalità del database. La soluzione ospitata non è una funzionalità di database. Se stai cercando un MongoDB ospitato, scegli MongoHQ e fanno tutto il lavoro grugnito che potresti voler evitare mentre ti concentri sul tuo lavoro principale.
Kabeer,

12
È vero, anche se il confronto dei costi iniziali che abbiamo fatto ha dimostrato che la dinamo è un buon affare. L'altro problema è che se devi ingrandire / ridimensionare la dinamo, è un clic di un pulsante. Se devi aggiungere il disco o ridimensionare un server mongo, ci sono tempi di inattività coinvolti, sia che tu debba farlo, o qualcun altro.
CargoMeister,

@Kabeer Sono tecnicamente d'accordo con te al 100%, ma nel mondo reale l'intero pacchetto è importante per prendere una decisione commerciale. In definitiva, questa è una decisione aziendale.
poitroae,

59

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.


sì, la mia preoccupazione principale è quella di aumentare la scala e la manutenzione nel tempo, a dire il vero personalmente, sento che mongoDB può fare il lavoro che sto solo pensando in termini di manutenzione a medio e lungo termine
jack.the.ripper

10
Tuttavia, un altro importante fattore di scala è l'utilizzo, non solo il conteggio dei documenti o la dimensione del db. @jack non "sente" ma si affida ai test, inclusa la piattaforma e l'hardware della distribuzione finale; una settimana trascorsa a riempire un paio di varianti di db con dati e benchmarking dovrebbe portare a decisioni informate che risparmiano molto dolore.
zanlok,

3
Fornire un prodotto / servizio professionale va ben oltre la semplice soluzione "questo può fare quella". Solo perché una macchina cheapo può eseguire Linux, MongoDB e milioni di dischi senza quasi soldi non equivale a grandi prestazioni nel mondo reale. 500.000 record (con uno schema SEMPLICE) sarebbero probabilmente un buon candidato per DynamoDB semplicemente perché l'OP non avrebbe costi di manutenzione (almeno per l'hardware) e il costo mensile sarebbe probabilmente molto inferiore al costo di un server nel corso di un anno o due.
cbmeeks,


16

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.


Dovresti davvero verificare quanto sia facile integrare cloudearch con stream dynamodb e lambda per raggiungere query full text o basate sulla posizione.
MrTJ,

4
Scegli il tuo database in base alle tue esigenze. Questa non è una scelta tra SQL e noSQL, ma tra DB orientato ai documenti, DB orientato ai grafici, DB valore-chiave, RDMBS .... Non esiste una scelta d'oro, e SQL non lo è certamente.
Vcarel,

14

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.


9

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


1
E una combinazione di Redis e MongoDB? È fantastico, penso.
Ismaestro,

Immagino di sì, non ho esperienza diretta su Redis ma di sicuro è ampiamente utilizzato a causa delle sue prestazioni, nei DB di memoria quasi sempre meglio dei DB basati su disco. Quindi penso che i dati a cui è necessario accedere a grande richiesta e alta frequenza dovrebbero andare a Redis. D'altra parte per grandi dati letargici dovrebbe essere usato MongoDB.
Rahul Kumar,

7

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.

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.