Question Quand utiliser CouchDB sur MongoDB et vice versa


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 tables avec des colonnes et des lignes. Je pense que soit MongoDB ou CouchDB sera bon pour cela, mais je ne suis pas sûr lequel. Je vais aussi avoir besoin d'une radiomessagerie efficace.


580
2017-09-15 13:32


origine


Réponses:


De C, A & P (Consistance, Disponibilité & Partition tolerance) 2 qui sont plus importants pour vous? Référence rapide, le Guide visuel pour les 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 contre CouchDB vs Redis vs Riak vs HBase vs comparaison Membase vs Neo4j a 'Meilleur utilisé'scénarios 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, ne pas mapper / réduire les fonctions. 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 des disques.
  • CouchDB: Pour accumuler, occasionnellement modifier des données, sur lesquelles des requêtes prédéfinies doivent être exécutées. Endroits où le contrôle des versions est important.

Un récent (février 2012) et plus comparaison complète par Riyad Kalla,

  • MongoDB: réplication maître-esclave SEULEMENT
  • CouchDB: réplication maître-maître

Un billet de blog (Oct 2011) par quelqu'un qui a essayé les deux, Un gars MongoDB apprend CouchDB a commenté que la radiomessagerie de CouchDB n'était pas aussi utile.

A daté (juin 2009) référence par Kristina Chodorow (une partie de l'équipe derrière MongoDB),

J'irais pour MongoDB.

J'espère que cela aide.


483
2017-09-16 05:37



Les réponses ci-dessus compliquent l'histoire.

  1. Si vous envisagez d'avoir un composant mobile, ou avez besoin que les utilisateurs de bureau travaillent hors ligne et synchronisent ensuite leur travail sur un serveur, vous avez besoin de CouchDB.
  2. Si votre code ne fonctionne que sur le serveur, alors allez avec MongoDB

C'est tout. À moins que vous n'ayez besoin de la capacité (impressionnante) de CouchDB pour répliquer sur les appareils mobiles et de bureau, MongoDB a l'avantage de la performance, de la communauté et de l'outillage présentement.


178
2018-02-18 03:29



Très vieille question mais c'est sur Google et je n'aime pas trop les réponses que je vois donc voici la mienne.

Couchdb offre beaucoup plus que la capacité de développer CouchApps. La plupart des gens utilisent CouchDb dans une architecture Web classique à trois niveaux.

En pratique, le facteur décisif pour la plupart des gens sera le fait que MongoDb permet une requête ad hoc avec une syntaxe SQL alors que CouchDb ne le fait pas (vous devez créer des vues map / reduce qui désactivent certaines personnes même si elles créent ces vues Rapid Application Development est convivial - 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 seulement adapté (ou plus adapté) pour les endroits où le versionning est important. En outre, couchdb est facile à écrire grâce à sa nature d'ajout seulement (les opérations d'écriture reviennent en un rien de temps tout en garantissant qu'aucune donnée ne sera 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 à 10ms. C'est un changeur de jeu qui fait de CouchDb une base de données à faible latence et à lecture facile, et cela ne devrait vraiment pas être négligé.

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

CouchDb n'a pas ce niveau d'outils - même si de nombreuses bibliothèques sont disponibles aujourd'hui - mais CouchDb est présenté comme une 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 de l'interface).

Donc, je dirais que l'utilisation de l'un ou l'autre est en grande partie une question de confort et de préférence avec leurs paradigmes. L'approche de CouchDb "convient", pour certaines personnes, mais si après avoir appris les caractéristiques de la base de guide officiel) tu n'as pas ton "enfer oui" moment, tu devrais probablement passer à autre chose.

Je déconseiller d'utiliser CouchDb si vous voulez juste utiliser "le bon outil pour le bon travail". parce que vous découvrirez que vous ne pouvez pas l'utiliser de cette façon et vous finirez par être énervé et écrire des billets 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, c'est vraiment payant. Personnellement, j'ai besoin de très bonnes raisons ou d'un bris d'accord majeur sur un projet pour choisir une autre base de données, mais jusqu'à présent, je n'en ai pas rencontré.


38
2018-06-04 16:38



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

  1. As-tu besoin maître-maître? Puis CouchDB. Principalement, CouchDB supporte la réplication maître-maître qui prévoit la déconnexion des nœuds pendant de longues périodes. MongoDB ne ferait pas bien dans cet environnement.
  2. As-tu besoin Rendement R / W MAXIMUM? Puis MongoDB
  3. Avez-vous besoin ultime durabilité à un seul serveur parce que vous allez seulement avoir un seul serveur DB? Puis CouchDB.
  4. Stockez-vous un Données MASSIVES définir qui a besoin de sharding tout en maintenant un débit fou? Puis MongoDB.
  5. Avez-vous besoin de forte cohérence de données? Puis MongoDB.
  6. Avez-vous besoin de haute disponibilité de la base de données? Puis CouchDB.
  7. Espérez-vous bases de données multiples et plusieurs tables / collections? Puis MongoDB
  8. Tu as un Utilisateurs hors connexion de l'application mobile et voulez synchroniser leurs données d'activité sur un serveur? Ensuite, vous avez besoin de CouchDB.
  9. Avez-vous besoin d'une grande variété de interroger moteur? Puis MongoDB
  10. Avez-vous besoin de grand communauté utiliser DB? Puis MongoDB

26
2017-08-11 17:04



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 dans BSON (accès plus rapide), meilleure cohérence des données, plusieurs collections

CouchDB: Meilleure réplication, avec maître pour maîtriser la réplication et la résolution des conflits, le stockage des données dans JSON (lisible par l'homme, un meilleur accès via les services REST), l'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


23
2018-05-28 14:11



Soyez conscient d'un problème avec les index uniques sparse dans MongoDB. Je l'ai frappé et il est extrêmement difficile de contourner le 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 sont implanté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 fonctionne tout simplement pas.

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

Je n'ai jamais utilisé l'exécution javascript côté serveur dans MongoDB (ce n'est pas conseillé de toute façon) et leur map / reduce a des performances terribles quand il n'y a qu'un seul nœud Mongo. Pour toutes ces raisons, je suis en train d'envisager de vérifier CouchDB, peut-être que cela correspond plus à mon scénario particulier.

BTW, si quelqu'un connaît le lien vers le problème de Mongo respectifs décrivant le problème de l'indice unique sparse - s'il vous plaît partager.


19
2018-02-03 22:05



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

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

Ils le font tous les deux vous pouvez vouloir regarder d'autres facteurs sur lesquels employer: d'autres dispositifs que vous vous intéressez, popularité, etc. Les perspicacités de Google, les publications d'emploi d'Indeed.com seraient des manières de regarder la popularité.

Vous pouvez juste essayer, je pense que vous devriez être en mesure d'avoir mongo en 5 minutes.


3
2017-09-15 15:49