Si vous venez du monde MySQL, MongoDB vous "semblera" beaucoup plus naturel à cause de son support de langage de type requête.
Je pense que c'est ce qui le rend si convivial pour beaucoup de gens.
CouchDB est fantastique si vous souhaitez utiliser le très bon support de réplication maître-maître avec une configuration multi-nœuds, éventuellement dans différents centres de données ou quelque chose du genre.
La réplication de MongoDB (jeux de répliques) est une configuration maître-esclave-esclave-esclave- *, vous ne pouvez écrire que sur le maître dans un jeu de répliques et lire à partir de l'un d'entre eux.
Pour une configuration de site standard, c'est très bien. Il correspond très bien à l'utilisation de MySQL.
Mais si vous essayez de créer un service global comme un CDN qui doit garder tous les nœuds globaux synchronisés même en lecture / écriture sur tous, quelque chose comme la réplication dans CouchDB va être un énorme avantage pour vous.
Alors que MongoDB a un langage de type requête que vous pouvez utiliser et que vous vous sentez très intuitif, CouchDB adopte une approche de «réduction de carte» et ce concept de vues. Cela semble étrange au début, mais au fur et à mesure que vous comprenez cela, cela commence vraiment à être intuitif.
Voici un bref aperçu donc cela a du sens:
- CouchDB stocke toutes vos données dans un b-tree
- Vous ne pouvez pas "interroger" dynamiquement avec quelque chose comme "SELECT * FROM utilisateur WHERE ..."
- Au lieu de cela, vous définissez des «vues» discrètes de vos données ... «voici une vue de tous mes utilisateurs», «voici une vue de tous les utilisateurs de plus de 10 ans» «voici une vue de tous les utilisateurs de plus de 30 ans» et bientôt.
- Ces vues sont définies à l'aide d'une approche de réduction de carte et sont définies comme des fonctions JavaScript.
- Lorsque vous définissez une vue, la base de données commence à alimenter tous les documents de la base de données à laquelle vous avez affecté la vue, à travers elle et à enregistrer les résultats de vos fonctions comme "index" sur ces données.
- Il y a quelques requêtes de base que vous pouvez faire sur les vues, comme demander une clé (ID) ou une plage d'ID spécifiques, indépendamment de ce que fait votre fonction de mappage / réduction.
- Lisez ces diapositives , c'est la meilleure clarification de la carte / réduction dans Couch que j'ai vue.
Donc, ces deux sources utilisent des documents JSON, mais CouchDB suit cette approche davantage «chaque serveur est un maître et peut se synchroniser avec le monde», ce qui est fantastique si vous en avez besoin, tandis que MongoDB est vraiment le MySQL du monde NoSQL.
Donc, si cela ressemble plus à ce dont vous avez besoin / voulez, allez-y.
Les petites différences comme le protocole binaire de Mongo par rapport à l'interface RESTful de CouchDB sont tous des détails mineurs.
Si vous voulez une vitesse brute et au diable la sécurité des données, vous pouvez faire fonctionner Mongo plus rapidement que CouchDB car vous pouvez lui dire de fonctionner à court de mémoire et de ne pas valider les choses sur le disque, sauf pour des intervalles clairsemés.
Vous pouvez faire la même chose avec Couch, mais son protocole de communication basé sur HTTP va être 2 à 4 fois plus lent que la communication binaire brute avec Mongo dans cette "vitesse sur tout!" scénario.
Gardez à l'esprit que la vitesse folle brute est inutile si un crash de serveur ou une panne de disque corrompt et détruit votre base de données dans l'oubli, de sorte que le point de données n'est pas aussi étonnant que cela puisse paraître (à moins que vous ne fassiez des systèmes de trading en temps réel sur le mur. Street, auquel cas regardez Redis).
J'espère que tout aide!