MongoDB su server EC2 o AWS SimpleDB?

Question

Quale scenario ha più senso: ospita diverse istanze EC2 con MongoDB installato, o piuttosto usa il webservice Amazon SimpleDB?

In caso di più istanze EC2 con MongoDB ho il problema di impostare l'istanza da solo.

Quando si utilizza SimpleDB ho il problema di bloccarmi nella struttura dati di Amazons, giusto?

Quali differenze ci sono in termini di sviluppo? Non dovrei essere in grado di cambiare solo il DAO dei miei livelli di servizio, o scrivere su MongoDB o AWS SimpleDB?

Answer 1

SimpleDB presenta alcuni limiti di scalabilità. È possibile ridimensionare solo in base allo sharding e ha una latenza maggiore rispetto a mongodb o cassandra, ha un limite di throughput e ha un prezzo più alto rispetto ad altre opzioni. La scalabilità è manuale (devi dividere).

Se sono necessarie opzioni di query più ampie e si dispone di una frequenza di lettura elevata e non si dispone di tanti dati, mongodb è migliore. Ma per la durabilità, è necessario utilizzare almeno 2 istanze del server mongodb come master/slave. Altrimenti puoi perdere l'ultimo minuto dei tuoi dati. La scalabilità è manuale. È molto più veloce di simpledb. Autosharding è implementato nella versione 1.6.

Cassandra ha opzioni di query deboli ma è resistente come postgresql. È veloce come mongo e più veloce con una maggiore dimensione dei dati. Le operazioni di scrittura sono più veloci delle operazioni di lettura su cassandra. Può scalare automaticamente sparando istanze ec2, ma è necessario modificare un po 'i file di configurazione (se non ricordo male). Se hai terabyte di dati, la cassandra è la soluzione migliore. Non è necessario dividere i tuoi dati, è stato progettato distribuito dal 1 ° giorno. Puoi avere un numero qualsiasi di copie per tutti i tuoi dati e se alcuni server sono morti, restituirà automaticamente i risultati da quelli attivi e distribuirà i dati del server morto ad altri. È altamente tollerante ai guasti. Puoi includere un numero qualsiasi di istanze, è molto più semplice scalare rispetto ad altre opzioni. Ha forti opzioni client .net e java. Hanno pool di connessioni, bilanciamento del carico, marcatura di server morti, ...

Un'altra opzione è hadoop per i big data ma non è in tempo reale come altri, è possibile utilizzare hadoop per datawarehousing. Né cassandra né mongo hanno transazioni, quindi se hai bisogno di transazioni postgresql è una soluzione migliore. Un'altra opzione è Amazon RDS, ma le prestazioni sono negative e il prezzo è elevato. Se si desidera utilizzare database o simpledb, potrebbe anche essere necessaria la memorizzazione nella cache dei dati (ad esempio: memcached).

Per le app Web, se i dati sono piccoli, raccomando mongo, se è grande, la cassandra è migliore. Non hai bisogno di uno strato di cache con mongo o cassandra, sono già veloci. Non consiglio simpledb, ma ti blocca anche su Amazon come hai detto tu.

Se si utilizza C#, java o scala è possibile scrivere un'interfaccia e implementarla per mongo, mysql, cassandra o qualsiasi altra cosa per il livello di accesso ai dati. È più semplice nei linguaggi dinamici (es. Rub, python, php). È possibile scrivere un provider per due di essi, se lo si desidera, e può modificare lo spazio di archiviazione, magari in fase di esecuzione, con una sola modifica della configurazione, sono tutti possibili. Lo sviluppo con mongo, cassandra e simpledb è più semplice di un database e sono privi di schemi, ma dipendono anche dalla libreria/connettore client che stai utilizzando. Il più semplice è mongo. C'è un solo indice per tabella in cassandra, quindi devi gestire altri indici tu stesso, ma con la versione 0.7 degli indici secondari di cassandra sarà possibile come so. Puoi anche iniziare con qualcuno di loro e sostituirlo in futuro se necessario.

Answer 2

Penso che tu abbia sia una questione di tempo che di velocità.

MongoDB/Cassandra saranno molto più veloci, ma dovrai investire per farli andare avanti.Ciò significa che dovrai eseguire/configurare le istanze del server per tutti e capire come funzionano.

D'altra parte, non è necessario un costo "per transazione" direttamente, si paga solo l'hardware che è probabilmente più efficiente per servizi più grandi.

Nel combattimento Cassandra/MongoDB ecco cosa troverai (basato sui test con cui sono stato coinvolto personalmente negli ultimi giorni).

Cassandra:

• Scaling/ridondanza è molto nucleo
• configurazione può essere molto intenso
• Per fare la segnalazione è necessario mappare-ridurre, per questo è necessario eseguire uno strato di Hadoop. Questo è stato un dolore per essere configurato e un dolore maggiore per diventare performante.

MongoDB:

• configurazione è relativamente facile (anche per il nuovo sharding, questa settimana)
• ridondanza è ancora "sempre lì"
• Map-ridurre è built-in ed è facile da ottenere dati.

Onestamente, dato il tempo di configurazione richiesto per i nostri 10s di GB di dati, siamo andati con MongoDB alla nostra fine. Posso immaginare di usare SimpleDB per i casi "deve avere questi problemi". Ma configurare un nodo per eseguire MongoDB è così ridicolmente semplice che potrebbe valere la pena di saltare la rotta "SimpleDB".

In termini di DAO, esistono già tonnellate di librerie per Mongo. Il framework Thrift per Cassandra è ben supportato. Probabilmente puoi scrivere una semplice logica per astrarre le connessioni. Ma sarà più difficile astrarre cose più complesse del semplice CRUD.

Answer 3

Ora 5 anni dopo non è difficile impostare Mongo su qualsiasi sistema operativo. Documentation è facile da seguire, quindi non vedo come configurare Mongo come un problema. Altre risposte hanno affrontato la questione della scalabilità, quindi cercherò di rispondere alla domanda dal punto di vista di uno sviluppatore (quali limitazioni ha ogni sistema):

Userò S per SimpleDB e M per Mongo.

• M è scritto in C++, S è scritto in Erlang (non il linguaggio più veloce)
• M è open source, installati in tutto il mondo, S è proprietario, può essere eseguito solo su Amazon AWS. Si dovrebbe anche pay for a whole bunch of staff per S
• S ha un intero gruppo di strange limitations. M limitations sono molto più ragionevoli.Più strane limitazioni sono:
  • dimensione massima di dominio (tabella) è 10 GB
  attributo
  • valore di lunghezza (dimensione di campo) è di 1024 byte
  • articoli massimi Select risposta - 2500
  • risposta massima dimensione per Select (la quantità massima di dati S possono ritornare voi) - 1Mb
• S supports only a few languages (Java, PHP, Python, ruby, .net), M supports way more
• supportano entrambi REST
• S ha una sintassi di query molto simile a SQL (ma molto meno potente). Con M hai bisogno di imparare una nuova sintassi che assomiglia a JSON (inoltre è semplice apprendere le basi)
• con M devi imparare come architetti il ​​tuo database. Perché molte persone pensano che il fatto di schematizzare significhi che si possa buttare qualsiasi cosa nel database ed estrarre ciò con facilità, potrebbero essere sorpresi dal fatto che Junk in, Junk out maxim funzioni. Suppongo che lo stesso sia in S, ma non posso rivendicarlo con certezza.
• entrambi non consentono la ricerca tra maiuscole e minuscole. In M puoi usare regex in qualche modo (brutto/nessun indice) per superare questa limitazione senza introdurre la logica del campo/applicazione in minuscolo.
• in S l'ordinamento può essere eseguito solo on one field
• a causa del tempo limite 5s count in S can behave strange. Se passano 5 secondi e la query non è terminata, si finisce con un numero parziale e un token che consente di continuare la query. La logica dell'applicazione è responsabile della raccolta di tutti questi dati.
• everything is a UTF-8 string, che lo rende un dolore nel culo per lavorare con valori non di stringa (come i numeri, date) a sostegno di tipo S. M è way richer.
• entrambi non hanno transazioni e join
• M supporta compression che è davvero utile per i negozi nosql, dove lo stesso nome di campo viene memorizzato di nuovo all-over.
• S supporta solo un indice singolo, M has single, compound, multi-key, geospatial etc.
• sia la replica di sostegno e sharding

Una delle cose più importanti che si dovrebbero prendere in considerazione è che SimpleDB ha un linguaggio di query molto rudimentale. Anche le cose di base come group by, sumaverage, distinct nonché di manipolazione dei dati non è supportato, in modo che la funzionalità non è davvero modo più ricco di Redis/Memcached. D'altra parte Mongo supporta un linguaggio di query ricco.