Quand utiliser CouchDB sur MongoDB et vice versa

638

Je suis coincé entre ces deux bases de données NoSQL.

Dans mon projet, je vais créer une base de données dans une base de données. Par exemple, j'ai besoin d'une solution pour créer des tables dynamiques.

Ainsi, les utilisateurs peuvent créer des tableaux avec des colonnes et des lignes. Je pense que MongoDB ou CouchDB seront bons pour cela, mais je ne sais pas lequel. J'aurai également besoin d'une pagination efficace.

— Luke101
source

19

Je souhaite qu'ils modifient le système pour mieux faciliter la création de la question sur le sujet qu'ils recherchent et pour mieux diriger les utilisateurs vers cette question. Je n'ai aucune idée si cette question a été abordée et aucun moyen pratique de la retrouver.

— doub1ejack

45

Je souhaite qu'ils ajoutent la fonctionnalité de ce site Web où nous pourrions "voter" ou "diminuer" la raison elle-même donnée à cette question comme "hors sujet", ce qui pourrait aider à ramener ce type de questions à "sur le sujet".

— Sanjay

9

++ Je ne comprends pas pourquoi cela est hors sujet. La question n'avoir des réponses claires et objectives - l'OP ne demande pas d' avis , mais pour des informations objectives sur ces deux systèmes. user799188 a fourni une excellente réponse objective.

— user48956

3

Je suppose que les administrateurs ne font que regarder la question si elle contient un morceau de code et non le type d'information recherchée. En fait, vous pouvez toujours voter pour rouvrir la question.

— Tarun

11

La question vient de rouvrir. Bienvenue à tous ...

— Alexis Dufrenoy

523

De C, A & P (cohérence, disponibilité et tolérance de partition), lesquels sont les plus importants pour vous? Référence rapide, le guide visuel des systèmes NoSQL

MongodB: cohérence et tolérance de partition
CouchDB: disponibilité et tolérance de partition

Un article de blog, Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j, propose des scénarios ` ` Best used '' pour chaque base de données NoSQL comparée. Citant le lien,

MongoDB: si vous avez besoin de requêtes dynamiques. Si vous préférez définir des index, pas les fonctions de mappage / réduction. Si vous avez besoin de bonnes performances sur une grosse base de données. Si vous vouliez CouchDB, mais vos données changent trop, remplissant les disques.
CouchDB: pour accumuler des données, qui changent parfois, sur lesquelles des requêtes prédéfinies doivent être exécutées. Endroits où le contrôle de version est important.

Une comparaison récente (février 2012) et plus complète de Riyad Kalla,

MongoDB: réplication maître-esclave UNIQUEMENT
CouchDB: réplication maître-maître

Un article de blog (octobre 2011) par quelqu'un qui a essayé les deux, A MongoDB Guy Learns CouchDB a commenté que la pagination de CouchDB n'était pas aussi utile.

Un benchmark daté (juin 2009) de Kristina Chodorow ( membre de l'équipe derrière MongoDB ),

J'irais pour MongoDB.

J'espère que cela aide.

— user799188
source

8

D'après ce que je comprends, MongoDB n'est pas cohérent en aucune façon: ivoras.sharanet.org/blog/tree/…

— sheerun

2

Bonne info pour l'époque, mais c'est vraiment vieux ... beaucoup de choses ont changé (notamment les interfaces REST pour Mongo).

— rICh

4

Je pense que cela pourrait être un peu trompeur, mais le versioning dans couchdb n'est pas un argument. Le schéma de versioning utilisé par couchdb ne doit pas être utilisé comme versioning par exemple. Il est utilisé pour gérer les partitions. Au cours d'un compactage de base de données, les révisions seront supprimées comme dans le cas réellement supprimé. Et seules les chaînes de rév doivent rester dans la base de données. Si vous voulez gérer des versions dans couchdb, cela devrait être fait comme cela pourrait être fait dans mongodb.

— Loïc Faure-Lacroix

2

J'ajouterais à la liste que couchdb peut avoir des applications Web autonomes. Comme dans couchdb est en fait un serveur web.

— Loïc Faure-Lacroix

41

Je suis surpris de 332 votes pour une mauvaise réponse. MongoDB est CP par défaut et CouchDB est AP stackoverflow.com/questions/11292215/…

— adnan kamili

219

Les réponses compliquent surtout l'histoire.

Si vous prévoyez d'avoir un composant mobile ou si vous avez besoin que les utilisateurs de bureau travaillent hors ligne, puis synchronisent leur travail avec un serveur, vous avez besoin de CouchDB.
Si votre code ne fonctionnera que sur le serveur, alors allez avec MongoDB

C'est ça. À moins que vous n'ayez besoin de la capacité (impressionnante) de CouchDB pour se répliquer sur des appareils mobiles et de bureau, MongoDB a actuellement l'avantage de performance, de communauté et d'outillage.

— Ewan Makepeace
source

18

Concis, ils me plaisent comme ça.

— Ely

J'adore les réponses simples et non trop techniques comme celle-ci. Merci!

cette réponse convient à ceux qui recherchent le mobile, le offline et la synchronisation! merci

— Erik Kaplun

J'ai ri quand j'ai lu "répliquer sur un appareil mobile" lol, combien sont vos données?

— Daniel W.

3

"lol combien sont vos données?" - est-ce vraiment une chose? Je peux choisir CDB parce que mes données sont volumineuses - ou je peux le choisir parce qu'il a une meilleure réplication que les alternatives. Dans ce cas, nous filtrons les ensembles de données jusqu'à environ 100 Mo à 200 Mo par appareil. Est-ce une mauvaise chose?

— Ewan Makepeace

62

Très vieille question, mais elle est au-dessus de Google et je n'aime pas vraiment les réponses que je vois, alors voici les miennes.

Il y a bien plus à Couchdb que la possibilité de développer des CouchApps. La plupart des gens utilisent CouchDb dans une architecture Web classique à 3 niveaux.

Dans la pratique, le facteur décisif pour la plupart des gens sera le fait que MongoDb permet des requêtes ad hoc avec une syntaxe similaire à SQL alors que CouchDb ne le fait pas (vous devez créer des vues de carte / réduction qui désactive certaines personnes même si la création de ces vues est rapide pour le développement d'applications (ils n'ont rien à voir avec les procédures stockées).

Pour répondre aux points soulevés dans la réponse acceptée: CouchDb a un excellent système de versionning, mais cela ne signifie pas qu'il est uniquement adapté (ou plus adapté) aux endroits où le versionning est important. De plus, couchdb est très convivial pour l'écriture grâce à sa nature d'ajout uniquement (les opérations d'écriture reviennent en un rien de temps tout en garantissant qu'aucune donnée ne sera jamais perdue).

Une chose très importante qui n'est mentionnée par personne est le fait que CouchDb s'appuie sur des index b-tree. Cela signifie que si vous avez 1 "ligne" ou 20 milliards, le temps d'interrogation restera toujours inférieur à 10 ms. C'est un changeur de jeu qui fait de CouchDb une base de données à faible latence et facile à lire, et cela ne devrait vraiment pas être négligé.

Pour être juste et exhaustif, l'avantage de MongoDb sur CouchDb est l'outillage et le marketing. Ils ont des outils citoyens de première classe pour toutes les principales langues et plates-formes, ce qui facilite l'intégration et cela, ajouté à leurs requêtes ad hoc, rend la transition de SQL encore plus facile.

CouchDb n'a pas ce niveau d'outils - même s'il existe de nombreuses bibliothèques disponibles aujourd'hui - mais CouchDb est exposé en tant qu'API HTTP et il est donc assez facile de créer un wrapper dans votre langue préférée pour en parler. Personnellement, j'aime cette approche car elle évite les ballonnements et vous permet de ne prendre que ce que vous voulez (principe de ségrégation des interfaces).

Je dirais donc que l'utilisation de l'un ou de l'autre est en grande partie une question de confort et de préférence avec leurs paradigmes. L'approche CouchDb "convient", pour certaines personnes, mais si après avoir pris connaissance des fonctionnalités de la base de données (dans le guide officiel exhaustif ), vous n'avez pas votre moment "enfer ouais", vous devriez probablement passer à autre chose.

Je déconseille d'utiliser CouchDb si vous voulez simplement utiliser "le bon outil pour le bon travail". parce que vous découvrirez que vous ne pouvez pas simplement l'utiliser de cette façon et vous finirez par être énervé et écrire des articles de blog tels que "Où sont les jointures dans CouchDb?" et "Où est la gestion des transactions?". En effet, Couchdb est - paradoxalement - très transparent mais nécessite en même temps un changement de paradigme et un changement dans la façon dont vous abordez les problèmes pour vraiment briller (et vraiment travailler).

Mais une fois que vous avez fait cela, ça rapporte vraiment. J'aurais personnellement besoin de raisons très fortes ou d'un disjoncteur majeur sur un projet pour choisir une autre base de données, mais jusqu'à présent je n'en ai rencontré aucune.

— tobiak777
source

12

Mise à jour 2016: depuis la sortie de la version 2.0 en septembre 2016, CouchDb prend en charge les requêtes ad hoc

— prêtes à l'emploi

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.

N'est-ce pas vrai pour presque toutes les bases de données? De cette façon, cela est formulé implique le contraire.

— Shelvacu

38

Posez-vous ces questions vous-même? Et vous déciderez de votre sélection DB.

Avez-vous besoin d'un master-master ? Puis CouchDB. CouchDB prend principalement en charge la réplication maître-maître qui anticipe que les nœuds sont déconnectés pendant de longues périodes. MongoDB ne ferait pas bien dans cet environnement.
Avez-vous besoin d'un débit R / W MAXIMUM ? Puis MongoDB
Avez-vous besoin d'une durabilité ultime sur un seul serveur, car vous n'aurez qu'un seul serveur DB? Puis CouchDB.
Stockez -vous un ensemble de données MASSIVE qui a besoin d'être partagé tout en maintenant un débit insensé? Puis MongoDB.
Avez-vous besoin de force cohérence des données? Puis MongoDB.
Avez-vous besoin de haute disponibilité de la base de données? Puis CouchDB.
Espérez-vous plusieurs bases de données et plusieurs tables / collections? Puis MongoDB
Tu as un application mobile hors ligne et souhaitez synchroniser leurs données d'activité avec un serveur? Ensuite, vous avez besoin de CouchDB.
Avez-vous besoin d'une grande variété de moteurs requête ? Puis MongoDB
Avez-vous besoin d'une grande communauté pour utiliser DB? Puis MongoDB

— Somnath Muluk
source

# 9 est un lien virtuel entre CouchDB et MongoDB à partir de CouchDB 2.x.

— Flimzy

27

Je résume les réponses trouvées dans cet article:

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

MongoDB: meilleure interrogation, stockage de données en BSON (accès plus rapide), meilleure cohérence des données, plusieurs collections

CouchDB: meilleure réplication, avec réplication maître à maître et résolution des conflits, stockage de données en JSON (lisible par l'homme, meilleur accès via les services REST), interrogation via map-Reduce.

Donc en conclusion, MongoDB est plus rapide, CouchDB est plus sûr.

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

— Alexis Dufrenoy
source

7

Réponse utile, mais la conclusion est difficile à apprécier.

— Erik Kaplun

Qu'entendez-vous par «difficile à aimer»?

— Alexis Dufrenoy

23

Soyez conscient d'un problème avec des index uniques clairsemés dans MongoDB. Je l'ai frappé et il est extrêmement difficile de contourner ce problème.

Le problème est le suivant: vous avez un champ, qui est unique s'il est présent et vous souhaitez trouver tous les objets où le champ est absent. La façon dont les index uniques épars sont implémentés dans Mongo est que les objets où ce champ est manquant ne sont pas du tout dans l'index - ils ne peuvent pas être récupérés par une requête sur ce champ - {$exists: false}ne fonctionnent tout simplement pas.

La seule solution de contournement que j'ai trouvée est d'avoir une famille de valeurs null spéciale, où une valeur vide est traduite en un préfixe spécial (comme null :) concaténé en uuid. C'est un vrai casse-tête, car il faut prendre soin de transformer vers / à partir des valeurs vides lors de l'écriture / requête / lecture. Une nuisance majeure.

Je n'ai jamais utilisé d'exécution javascript côté serveur dans MongoDB (ce n'est pas conseillé de toute façon) et leur carte / réduire a des performances terribles quand il n'y a qu'un seul nœud Mongo. Pour toutes ces raisons, j'envisage maintenant de vérifier CouchDB, il convient peut-être plus à mon scénario particulier.

BTW, si quelqu'un connaît le lien vers le problème Mongo correspondant décrivant le problème d'index unique clairsemé - veuillez le partager.

— marque
source

3

Je suis désolé mais j'ai ce sentiment persistant que ce n'est pas une bonne idée et c'est un sentiment que j'ai appris à ne pas ignorer

— tempête de pluie

8

Eh bien, je ne peux pas contester un sentiment. Tout ce que je sais, c'est que j'avais besoin d'index uniques et clairsemés, en raison des champs facultatifs, qui sont uniques s'ils sont présents.

— marquez

37

Je comprends que vous avez un cas d'utilisation réel qui décrit le problème, mais qu'en est-il de mes tripes?

— Chev

14

Je ne sais pas. Qu'en est-il?

— marquez

2

ROTFL. +1 Alex Ford et marque pour vos commentaires hilarants. :-)) @mark, je ne suis pas sûr que les problèmes que vous citez justifient vraiment le passage de MongoDB à CouchDB. Je n'ai travaillé avec ni MongoDB ni CouchDB, mais mon instinct me dit que vous rencontrerez d'autres limitations complexes avec CouchDB et perdrez un peu plus de temps à les contourner. Si vous maîtrisez maintenant MongoDB, vous devriez probablement vous en tenir à cela. Mais encore une fois, je ne suis jamais allé au Nosql-land, c'est juste mon instinct qui parle.

— MiniQuark

6

Je suis sûr que vous pouvez avec Mongo (plus familier avec lui), et presque sûr que vous pouvez aussi avec un canapé.

Les deux sont orientés documentés (basés sur JSON), il n'y aurait donc pas de "colonnes" mais plutôt des champs dans les documents - mais ils peuvent être entièrement dynamiques.

Ils le font tous les deux, vous voudrez peut-être examiner d'autres facteurs sur lesquels utiliser: d'autres fonctionnalités qui vous intéressent, la popularité, etc.

Vous pouvez simplement l'essayer, je pense que vous devriez pouvoir faire fonctionner mongo en 5 minutes.

— dm.
source