Quando utilizzare CouchDB su MongoDB e viceversa

638

Sono bloccato tra questi due database NoSQL.

Nel mio progetto creerò un database all'interno di un database. Ad esempio, ho bisogno di una soluzione per creare tabelle dinamiche.

Quindi gli utenti possono creare tabelle con colonne e righe. Penso che MongoDB o CouchDB andranno bene per questo, ma non sono sicuro di quale. Avrò anche bisogno di un paging efficiente.

— Luke101
fonte

19

Vorrei che modifichino il sistema per facilitare meglio la creazione della domanda sull'argomento che stanno cercando e per indirizzare meglio gli utenti a quella domanda. Non ho idea se questa domanda sia mai stata affrontata e nessun modo conveniente per rintracciarla.

— doub1ejack,

45

Vorrei che aggiungessero le funzionalità di questo sito Web in cui potremmo "votare" o "sottovalutare" il motivo stesso dato a questa domanda come "off-topic" che potrebbe aiutare a riportare questo tipo di domande su "on topic".

— Sanjay,

9

++ Non mi è chiaro perché questo sia fuori tema. La domanda ha avere risposte oggettive chiare - il PO non chiede opinione, ma per informazioni obiettive su questi due sistemi. user799188 ha fornito un'ottima risposta obiettiva.

— user48956

3

Immagino che gli amministratori guardino solo alla domanda se contiene qualche pezzo di codice e non al tipo di informazioni ricercate. A proposito, puoi sempre votare per riaprire la domanda.

— Tarun,

11

La domanda è appena stata riaperta. Bentornato a tutti ...

— Alexis Dufrenoy,

523

Di C, A e P (coerenza, disponibilità e tolleranza della partizione) quali 2 sono più importanti per te? Riferimento rapido, la guida visiva ai sistemi NoSQL

MongodB: Coerenza e tolleranza alle partizioni
CouchDB: disponibilità e tolleranza alla partizione

Un post sul blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j, presenta scenari "I migliori " per ogni database NoSQL confrontato. Citando il link,

MongoDB: se hai bisogno di query dinamiche. Se si preferisce definire gli indici, non mappare / ridurre le funzioni. Se hai bisogno di buone prestazioni su un database di grandi dimensioni. Se volevi CouchDB, ma i tuoi dati cambiano troppo, riempiendo i dischi.
CouchDB: per accumulare, occasionalmente, modificare dati, su cui devono essere eseguite query predefinite. Luoghi in cui il controllo delle versioni è importante.

Un confronto recente (febbraio 2012) e più completo di Riyad Kalla,

MongoDB: SOLO replica Master-Slave
CouchDB: replica Master-Master

Un post sul blog (ottobre 2011) di qualcuno che ha provato entrambi, A MongoDB Guy Learns CouchDB ha commentato che il paging del CouchDB non è altrettanto utile.

Un benchmark datato (giugno 2009) di Kristina Chodorow ( parte del team dietro MongoDB ),

Vorrei MongoDB.

Spero che sia d'aiuto.

— user799188
fonte

8

Da quello che ho capito MongoDB non è coerente in alcun modo: ivoras.sharanet.org/blog/tree/…

— sheerun

2

Buone informazioni per il momento, ma questo è davvero vecchio ... molti sono cambiati (comprese le interfacce REST per Mongo).

— rICh,

4

Penso che potrebbe essere un po 'fuorviante, ma il versioning in couchdb non è un argomento. Lo schema di controllo delle versioni utilizzato da couchdb non dovrebbe essere usato come controllo delle versioni. È usato per gestire le partizioni. Durante una compattazione del database, le revisioni verranno eliminate come in realtà eliminate. E solo le catene dei giri dovrebbero rimanere nel database. Se vuoi gestire le versioni in couchdb, dovrebbe essere fatto esattamente come in mongodb.

— Loïc Faure-Lacroix,

2

Aggiungerei all'elenco che couchdb può avere applicazioni web autonome. Come in couchdb è infatti un server web.

— Loïc Faure-Lacroix,

41

Sono sorpreso 332 voti per una risposta sbagliata. MongoDB è CP di default e CouchDB è AP stackoverflow.com/questions/11292215/...

— Adnan Kamili

219

Le risposte soprattutto complicano la storia.

Se prevedi di avere un componente mobile o hai bisogno che gli utenti desktop lavorino offline e quindi sincronizzino il loro lavoro con un server, hai bisogno di CouchDB.
Se il tuo codice verrà eseguito solo sul server, vai con MongoDB

Questo è tutto. A meno che tu non abbia bisogno della (fantastica) capacità di CouchDB di replicarsi su dispositivi mobili e desktop, MongoDB ha attualmente il vantaggio in termini di prestazioni, comunità e strumenti.

— Ewan Makepeace
fonte

18

Conciso, a modo loro mi piace.

— Ely,

Adoro semplici risposte non eccessivamente tecniche come questa. Grazie!

questa risposta lo inchioda per coloro che sono alla ricerca di dispositivi mobili, offline e sincronizzati! grazie

— Erik Kaplun,

Ho riso quando ho letto "replica su dispositivo mobile" lol quanto sono piccoli i tuoi dati?

— Daniel W.

3

"lol quanto sono piccoli i tuoi dati?" - è davvero una cosa? Potrei scegliere CDB perché i miei dati sono di grandi dimensioni o potrei sceglierli perché ha una replica migliore rispetto alle alternative. In questo caso filtriamo i set di dati fino a circa 100 Mb-200 Mb per dispositivo. È una brutta cosa?

— Ewan Makepeace,

62

Domanda molto vecchia, ma è in cima a Google e non mi piacciono le risposte che vedo, quindi ecco la mia.

Couchdb offre molto di più della possibilità di sviluppare CouchApps. La maggior parte delle persone usa CouchDb in una classica architettura web a 3 livelli.

In pratica, il fattore decisivo per la maggior parte delle persone sarà il fatto che MongoDb consente l'interrogazione ad-hoc con una sintassi simile a SQL mentre CouchDb non lo fa (devi creare una mappa / ridurre le viste che spengono alcune persone anche se creano queste viste è compatibile con lo sviluppo rapido di applicazioni - non hanno nulla a che fare con le procedure memorizzate).

Per affrontare i punti sollevati nella risposta accettata: CouchDb ha un ottimo sistema di controllo delle versioni, ma ciò non significa che sia adatto (o più adatto) per i luoghi in cui il controllo delle versioni è importante. Inoltre, couchdb è di facile scrittura grazie alla sua natura di sola aggiunta (le operazioni di scrittura ritornano in pochissimo tempo, garantendo che nessun dato verrà mai perso).

Una cosa molto importante che non è menzionata da nessuno è il fatto che CouchDb si basa su indici b-tree. Ciò significa che se si dispone di 1 "riga" o 20 miliardi, il tempo di interrogazione rimarrà sempre inferiore a 10 ms. Questo è un punto di svolta che rende CouchDb un database a bassa latenza e di facile lettura, e questo non dovrebbe assolutamente essere trascurato.

Per essere onesti ed esaustivi, il vantaggio di MongoDb rispetto a CouchDb è quello degli strumenti e del marketing. Hanno strumenti per cittadini di prima classe per tutte le principali lingue e piattaforme che rendono facile l'on-boarding e questo aggiunto alla loro query ad hoc rende ancora più semplice il passaggio da SQL.

CouchDb non ha questo livello di strumenti - anche se oggi ci sono molte librerie disponibili - ma CouchDb è esposto come API HTTP ed è quindi abbastanza facile creare un wrapper nella tua lingua preferita per parlarne. Personalmente mi piace questo approccio in quanto evita il gonfiore e ti consente di prendere solo quello che vuoi (principio di segregazione dell'interfaccia).

Quindi direi che usare l'uno o l'altro è in gran parte una questione di conforto e preferenza con i loro paradigmi. L'approccio di CouchDb "si adatta", per alcune persone, ma se dopo aver appreso le funzionalità del database (nella guida ufficiale esaustiva ) non hai il tuo momento "inferno sì", probabilmente dovresti andare avanti.

Scoraggerei l'uso di CouchDb se si desidera semplicemente utilizzare "lo strumento giusto per il lavoro giusto". perché scoprirai che non puoi semplicemente usarlo in quel modo e finirai per essere incazzato e scrivere post sul blog come "Where are join in CouchDb?" e "Dov'è la gestione delle transazioni?". In effetti, Couchdb è - paradossalmente - molto trasparente ma allo stesso tempo richiede un cambio di paradigma e un cambiamento nel modo in cui affronti i problemi per brillare (e lavorare davvero).

Ma una volta fatto, ripaga davvero. Personalmente avrei bisogno di ragioni molto valide o di un grosso problema su un progetto per scegliere un altro database, ma finora non ne ho incontrato nessuno.

— tobiak777
fonte

12

Aggiornamento 2016: dalla versione 2.0 rilasciata a settembre 2016, CouchDb supporta immediatamente le query ad hoc :)

— tobiak777,

1

CouchDb relies on b-tree indexes. This means that whether you have 1 "row" or 20 billions, the querying time will always remain below 10ms.

Questo non è vero per quasi tutti i database? In questo modo questo è espresso diversamente.

— Shelvacu,

38

Fai questa domanda tu stesso? E deciderai la tua selezione di DB.

Hai bisogno di master-master ? Quindi CouchDB. Principalmente CouchDB supporta la replica master-master che anticipa la disconnessione dei nodi per lunghi periodi di tempo. MongoDB non farebbe bene in quell'ambiente.
Avete bisogno di un rendimento MASSIMO R / W ? Quindi MongoDB
Hai bisogno della massima durata per server singolo perché hai un solo server DB? Quindi CouchDB.
Stai memorizzando un set di dati MASSIVE che necessita di sharding mantenendo una velocità di trasmissione folle? Quindi MongoDB.
Hai bisogno di una forte coerenza dei dati? Quindi MongoDB.
Hai bisogno di un'elevata disponibilità del database? Quindi CouchDB.
Stai sperando in più database e multi tabelle / raccolte? Quindi MongoDB
Hai utenti offline di un'app mobile e desideri sincronizzare i dati delle loro attività con un server? Quindi hai bisogno di CouchDB.
Hai bisogno di una grande varietà di motori di query ? Quindi MongoDB
Hai bisogno di una grande comunità per utilizzare DB? Quindi MongoDB

— Somnath Muluk
fonte

# 9 è un legame virtuale tra CouchDB e MongoDB a partire da CouchDB 2.x.

— Flimzy

27

Riassumo le risposte trovate in quell'articolo:

http://www.quora.com/How-does-MongoDB-compare-to-CouchDB-What-are-the-advantages-and-disadvantages-of-each

MongoDB: migliore query, archiviazione dei dati in BSON (accesso più veloce), migliore coerenza dei dati, più raccolte

CouchDB: migliore replica, con replica da master a master e risoluzione dei conflitti, archiviazione dei dati in JSON (leggibile dall'uomo, migliore accesso tramite i servizi REST), interrogazione tramite map-reduce.

Quindi, in conclusione, MongoDB è più veloce, CouchDB è più sicuro.

Inoltre: http://nosql.mypopescu.com/post/298557551/couchdb-vs-mongodb

— Alexis Dufrenoy
fonte

7

Risposta utile, ma la conclusione è difficile da apprezzare.

— Erik Kaplun,

Cosa intendi con "difficile da apprezzare"?

— Alexis Dufrenoy,

23

Fai attenzione a un problema con indici univoci sparsi in MongoDB. L'ho colpito ed è estremamente complicato risolvere il problema.

Il problema è questo: hai un campo, che è unico se presente e desideri trovare tutti gli oggetti in cui il campo è assente. Il modo in cui gli indici univoci sparsi vengono implementati in Mongo è che gli oggetti in cui manca quel campo non sono affatto nell'indice - non possono essere recuperati da una query su quel campo - {$exists: false}semplicemente non funziona.

L'unica soluzione che ho escogitato è avere una speciale famiglia di valori null, in cui un valore vuoto viene tradotto in un prefisso speciale (come null :) concatenato in un uuid. Questo è un vero mal di testa, perché bisogna occuparsi della trasformazione in / dai valori vuoti durante la scrittura / query / lettura. Un grosso fastidio.

Non ho mai usato l'esecuzione javascript sul lato server in MongoDB (non è comunque consigliato) e la loro mappa / riduzione ha prestazioni terribili quando c'è solo un nodo Mongo. Per tutti questi motivi, sto prendendo in considerazione di provare CouchDB, forse è più adatto al mio scenario particolare.

A proposito, se qualcuno conosce il link al rispettivo problema Mongo che descrive il problema dell'indice univoco sparso - per favore condividi.

— marchio
fonte

3

Mi dispiace ma ho questa fastidiosa sensazione che non sia una buona idea ed è una sensazione che ho imparato a non ignorare

— Eglestorm

8

Bene, non posso discutere con un sentimento. Tutto quello che so è che avevo bisogno di indici univoci sparsi, a causa dei campi opzionali, che sono unici se presenti.

— segna il

37

Capisco che hai un caso d'uso reale che descrive il problema, ma per quanto riguarda il mio istinto?

— Chev,

14

Non lo so. Che ne pensi?

— segna il

2

ROTFL. +1 Alex Ford e segna per i tuoi commenti esilaranti. :-)) @mark, non sono sicuro che i problemi che hai elencato giustifichino davvero il passaggio da MongoDB a CouchDB. Non ho lavorato né con MongoDB né con CouchDB, ma il mio istinto mi dice che incontrerai altre limitazioni complesse con CouchDB e perderai un po 'più di tempo a lavorarci attorno. Se ora hai imparato MongoDB, allora dovresti probabilmente attenerci. Ma ancora una volta, non sono mai stato in Nosql-land, questo è solo il mio istinto a parlare.

— MiniQuark,

6

Sono sicuro che puoi farlo con Mongo (più familiare) e abbastanza sicuro che puoi farlo anche con il divano.

Entrambi sono orientati alla documentazione (basati su JSON), quindi non ci sarebbero "colonne" ma piuttosto campi nei documenti, ma possono essere completamente dinamici.

Entrambi lo fanno, potresti voler esaminare altri fattori su cui utilizzare: altre funzionalità che ti interessano, la popolarità, ecc. Approfondimenti di Google, i post di lavoro di Indeed.com sarebbero modi di vedere la popolarità.

Potresti provarlo, penso che dovresti riuscire a far funzionare il mongo in 5 minuti.

— dm.
fonte