Question MongoDB ou CouchDB - adapté à la production? [fermé]


Je me demandais si quelqu'un pouvait me dire si MongoDB ou CouchDB sont prêts pour un production environnement.

Je suis en train de regarder ces solutions de stockage (je préfère MongoDB pour le moment), mais ces projets sont assez jeunes et je pense que je vais devoir travailler assez fort pour convaincre mon manager que nous devrions l'adopter. nouvelle technologie.

Ce que je voudrais savoir, c'est:

  1. Qui utilise MongoDB ou CouchDB aujourd'hui dans un environnement de production?

  2. Comment utilisez-vous MongoDB / CouchDB?

  3. Quels problèmes (le cas échéant) avez-vous rencontrés lorsque vous avez adopté ce nouveau mécanisme de stockage (et comment les avez-vous surmontés)?

  4. Comment avez-vous traité les problèmes de migration auxquels vous avez dû faire face?

  5. Avez-vous de bonnes / mauvaises expériences avec l'une ou l'autre de ces solutions que vous aimeriez partager?


485


origine


Réponses:


Je suis le CTO de 10gen (développeurs de MongoDB) donc je suis un peu partial, mais je gère aussi quelques sites qui utilisent MongoDB en production.

interne du milieu des affaires utilise mongo en production depuis plus d'un an maintenant. Ils l'utilisent pour tout, depuis les utilisateurs et les billets de blog, jusqu'à chaque image sur le site.

shopwiki L'utilise pour quelques choses, y compris l'analyse en temps réel et une couche de mise en cache. Ils font plus de 1000 écritures par seconde à une base de données assez grande.

Si vous allez à la mongodb Production Deployments page vous verrez des gens qui utilisent mongo en production.

Si vous avez des questions sur l'ampleur ou la portée des déploiements de production, postez-les sur notre liste d'utilisateurs et nous serons heureux de vous aider.


270



le BBC et meebo.com utilisez CouchDB en production, tout comme l'un de mes clients. Voici une liste d'autres personnes utilisant Couch: CouchDB dans la nature

Le principal défi consiste à savoir comment organiser vos documents et arrêter de penser en termes de données relationnelles.


111



SourceForge utilise MongoDB. Voir cette présentation ou lire ici.


44



Nous exécutons CouchDB comme un remplacement pour MySQL pour nos boutiques (70.0000 articles / boutique, un total de 4 millions d'attributs de tous les articles, des connexions croisées entre les articles).

Nos objectifs étaient:

  1. Réplication facile d'un master-db à plusieurs clients avec différents documents.

  2. Données précalculées rapides telles que "combien de parties ai-je avec cet attribut et ce filtre, correspondant à ces conditions"

faits:

  1. Nos magasins tournent maintenant beaucoup plus vite qu'avec MySQL (et mysql-database nécessitait entre 1 et 3 jours de pré-calcul (donc deux fois par mois), rendant les données prêtes pour le comptage et le filtrage des produits, CouchDB a besoin de 5 heures, nous pourrions mettre à jour les données de produit chaque nuit)
  2. La configuration de la distribution de données (filtrée) et des sauvegardes vers les nœuds d'atelier est rapide et facile

mais aussi:

  1. Comprendre la carte / réduire et les limites de ne pas avoir de jointure est assez difficile
  2. Aucune opération sur des données telles que "delete where" ou "update where" sans programmes externes
  3. La réplication fonctionne bien, sauf s'il y a un problème; alors il est vraiment difficile de savoir quelle était la raison (pour les débutants)
  4. L'installation de CouchDB sans les binaires (oui, il y en a dans la nature, mais pas pour tous les OS / versions) pourrait être difficile, si vous n'êtes pas un geek de Linux. Mais la communauté CouchDB est utile (#couchdb) et, heureusement, il existe des entreprises (nuageuses, iriscouches) qui offrent des services du libre au grand business.
  5. CouchDB avance, il y a donc beaucoup de changements (améliorations) qui pourraient changer leur façon de travailler. Mais les choses basiques restent stables.

Par conséquent: MySQL en tant que base de données pour la création et le maintien de données est fiable et facile à comprendre et à gérer. Je pense que nous ne changerons pas cela. Mais je ne veux pas non plus manquer la puissance des vues CouchDB et la facilité de configuration de la réplication.

Les divans de production ont parfois causé des problèmes après des mois de travail en raison d'une mauvaise configuration et des logrotates oubliés (voir le bâtiment prend trop de temps ou se bloque, la réplication s'arrête), mais jamais perdu de données et peuvent facilement être réinitialisés.


34



J'utilise CouchDB en production. Actuellement, il stocke tous les champs "facultatifs" qui ne figuraient pas dans le schéma de base de données d'origine. Et maintenant, je pense à transférer toutes les données vers CouchDB.

C'est une étape risquée, je l'avoue. Premièrement, parce que ce n'est pas encore v1.0. Et deuxièmement, parce qu’il a besoin de beaucoup de ressources. Selon mes calculs, le fichier CouchDB (avec index) est environ 30 fois plus grand que la base de données MySQL avec les mêmes lignes. Mais je suis à peu près sûr que ça marchera très bien.


27



CouchDB 0.11 (publié à la fin du mois de mars) est une version avec gel des fonctionnalités pour la version 1.0. Cela signifie que nous allons maintenir la compatibilité avec l’API actuelle pour la version 1.0, c’est donc le bon moment pour revoir CouchDB si vous n’avez pas de temps.

le La version du code source de CouchDB 0.11 est disponible ici. Il y a installateurs binaires et autres goodies liés ici.


18



Je ne sais rien de MongoDB, mais de la FAQ CouchDB:

CouchDB est-il prêt pour la production?

Oui, voir Dans la nature pour une liste partielle de projets utilisant CouchDB. Un autre bon aperçu est Études de cas CouchDB

Aussi, quelques liens:


17



Nous utilisons le couchdb en production et, juste avant le projet, nous sommes passés sous le parapluie Apache.

Nous l'utilisons pour stocker tout ce que nous pourrions autrement utiliser un dbms, ainsi que toutes sortes de données non structurées. Personnellement, j'aime vraiment comment vous pouvez y jeter toutes sortes de données et utiliser les vues pour éliminer ce dont vous n'avez pas besoin en fonction de la situation.

Le plus difficile était de s'éloigner de l'état d'esprit du dbms. Nous avons écrit nos propres outils de migration lorsque le format de stockage a été modifié pour être sûr, ce qui n’a pas posé de problème.

Nous n’avons pas encore eu d’expériences négatives, mais là encore, nous n’avons pas eu la configuration sous quelque forme de charge que ce soit. je pense les choses marcheraient plutôt bien puisque nous avons deux serveurs de type esclave qui se répliquent à partir d'un seul serveur maître qui reçoit toutes les écritures. Je suis à peu près sûr que nous n'aurons pas à le faire pour que la réplication fonctionne correctement, mais c'est comme ça que nous l'avons mise en place au début et elle est restée bloquée.


16