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

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

Je regarde maintenant ces solutions de stockage (je suis en faveur de MongoDB pour le moment), mais ces projets sont assez jeunes et je prévois donc que je vais devoir travailler assez dur pour convaincre mon manager que nous devrions l'adopter nouvelle technologie.

Ce que j'aimerais 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 géré les problèmes de migration auxquels vous avez dû faire face?

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

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

businessinsider utilise le mongo dans la production depuis plus d'un an maintenant. Ils l'utilisent pour tout, depuis les utilisateurs et les articles de blog, jusqu'à chaque image du site.

shopwiki l' utilise pour plusieurs choses, y compris des analyses en temps réel et une couche de mise en cache. Ils effectuent plus de 1 000 écritures par seconde dans une base de données assez volumineuse.

Si vous accédez à la page Déploiements de production de mongodb, vous verrez des personnes qui utilisent mongo en production.

Si vous avez des questions sur l'échelle ou la portée des déploiements de production, publiez sur notre liste d'utilisateurs et nous serons ravis de vous aider.

La BBC et meebo.com utilisent CouchDB en production, tout comme l'un de mes clients. Voici une liste d'autres personnes utilisant Couch: CouchDB à l'état sauvage

L'enjeu majeur est de savoir organiser ses documents et de ne plus penser en termes de données relationnelles.

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

Nous utilisons CouchDB en tant que remplaçant de MySQL pour nos boutiques (70,0000 articles / boutique, un total de 4 millions d'attributs de tous les articles, connexions croisées entre les articles).

Nos objectifs étaient les suivants:

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

2. Données précalculées rapides comme "combien de pièces ai-je avec cet attribut et ce filtre, adaptés à ces conditions"

faits:

1. Nos boutiques fonctionnent maintenant beaucoup plus rapidement qu'avec MySQL (et la base de données mysql nécessitait en outre 1 à 3 jours de pré-calcul (donc la mise à jour était deux fois par mois), ce qui rend les données prêtes pour le comptage et le filtrage des produits, CouchDB a besoin de 5 heures, donc nous pourrions mettre à jour les données produit tous les soirs)
2. La configuration (filtrée) de la distribution et des sauvegardes de données sur les nœuds de la boutique est rapide et facile

mais aussi:

1. Comprendre la carte / réduire et les limites de ne pas avoir de jointures est assez difficile
2. Aucune opération sur les données comme "supprimer où" ou "mettre à jour où" sans programmes externes
3. La réplication fonctionne bien, sauf en cas de problème; alors c'est vraiment difficile de trouver la raison (pour les débutants)
4. L'installation de CouchDB sans 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 Linux. Mais la communauté CouchDB est utile (#couchdb), et heureusement, il existe des entreprises (cloudant, iriscouch) qui offrent des services gratuits aux grandes entreprises.
5. CouchDB va de l'avant, il y a donc beaucoup de changements (améliorations) en cours qui pourraient changer leur façon de travailler. Mais les choses de base restent stables.

En conséquence: MySQL en tant que base de données pour la création et la maintenance 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 canapés de production ont parfois causé des problèmes après des mois de travail en raison d'une mauvaise configuration et de rotations de mémoire oubliées (la création de vues prend trop de temps ou se bloque, la réplication s'arrête), mais n'a jamais perdu de données et peut toujours être facilement réinitialisée.

J'utilise CouchDB en production. Actuellement, il stocke tous les champs «facultatifs» qui n'étaient pas dans le schéma de base de données d'origine. Et en ce moment, je pense à déplacer toutes les données vers CouchDB.

C'est une étape assez risquée, je l'avoue. D'abord parce que ce n'est pas encore la v1.0. Et deuxièmement, parce qu'il a faim d'espace disque. D'après mes calculs, le fichier CouchDB (avec index) est ~ 30 fois plus grand que la base de données MySQL avec les mêmes lignes. Mais je suis presque sûr que cela fonctionnera très bien.

CouchDB 0.11 (sorti fin mars) est une version freeze pour 1.0. Cela signifie que nous maintiendrons la compatibilité avec l'API actuelle pour 1.0, c'est donc le bon moment pour jeter un autre regard sur CouchDB si vous ne l'avez pas fait depuis un moment.

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

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

CouchDB est-il prêt pour la production?

Oui, voir InTheWild pour une liste partielle des projets utilisant CouchDB. Un autre bon aperçu est les études de cas CouchDB

Aussi, quelques liens:

• Re: état actuel de CouchDB?
• SimpleDB, CouchDB et autres "nouveaux" magasins de données - Commentaires

Nous utilisons couchdb en production et depuis, juste avant que le projet ne passe sous l'égide d'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 la façon dont vous pouvez simplement y ajouter toutes sortes de données et utiliser les vues pour sélectionner ce dont vous n'avez pas besoin en fonction de la situation.

La partie la plus difficile s'éloignait de l'état d'esprit dbms. Nous avons écrit nos propres utilitaires de migration lorsque le format de stockage a changé juste pour être sûr, donc ce n'était pas vraiment un problème.

Nous n'avons pas encore eu d'expériences négatives, mais encore une fois, nous n'avons pas eu la configuration sous aucune sorte de charge énorme. Je pense que les choses fonctionneraient plutôt bien puisque nous avons deux serveurs de type esclave qui se répliquent à partir d'un seul serveur maître qui obtient toutes les écritures. Je suis à peu près sûr que nous n'avons pas à le faire de cette façon pour que la réplication fonctionne correctement, mais c'est comme cela que nous l'avons configurée au début et elle est bloquée.

Nous utilisons CouchDB pour stocker les messages entrants et sortants mobiles et pour signaler ce trafic via certaines vues personnalisées que j'ai écrites. Le front-end est écrit en Python. Nous n'avons eu aucun vrai problème technique, et cela fonctionne depuis fin décembre. Le seul obstacle que j'ai rencontré était au départ de penser en termes de MapReduce, mais une fois que j'ai appris à le faire, tout le reste s'est bien passé.

Nous utilisons actuellement MongoDB en production comme couche de mise en cache ainsi que moteur de stockage pour l'importation et la manipulation de données de produit. Nous sommes une entreprise de commerce électronique gérant plus de deux millions de produits (plus de 100 millions d'attributs), couvrant plus de 10 distributeurs et sans MongoDB, cette tâche serait presque impossible.

Nous utilisons actuellement mongodb comme service de stockage de fichiers pour notre collaboration sur LAN. De plus, des projets comme trello utilisent mongodb comme magasin de données principal. J'ai utilisé couchdb plus tôt, mais pas en capacité de production.

Nous utilisons MongoDB en production dans notre service de backend mobile à savoir Netmera. Nous l'utilisons pour stocker toutes les données des utilisateurs et du contenu.

J'utilise CouchDB en production depuis près de 2 ans maintenant. Il n'y a pas de travail de migration car le projet a commencé directement avec l'implémentation de CouchDB. Il sert de base de données qui stocke les données d'un seul produit électronique du début à l'emballage.

Puisque nous vendons des capteurs avec une exigence de haute précision, nous faisons beaucoup de tests à différentes étapes et tous ces éléments seront stockés dans un seul document sur CouchDB.

Il y a une courbe d'apprentissage que j'ai apprise de mon expérience, qui consiste à tirer pleinement parti des vues (ou également appelées vues permanentes). Les vues doivent être un "petit filtre" d'une fraction de la base de données qui sera appelée souvent.

Ma base de données CouchDB n'est pas aussi folle qu'une autre société gigantesque. Mais jusqu'à présent, je vais toujours bien. Actuellement, j'ai 24 000 documents à 700 Mo.

La fonctionnalité de CouchDB que j'aime est la «réplication», «stocker les révisions d'un document».

J'avais lu beaucoup de bonnes critiques sur MongoDB et je voudrais l'essayer s'il y a une chance.

Nous utilisons mongodb en production pour

www.beachfront.io - près de 5 000 requêtes d'écriture par seconde www.beachfrontbuilder.com - 500 requêtes de lecture / écriture par seconde, maintiennent 10 millions de données utilisateurs et olap.

Le seul défi rencontré autour de l'archivage des données, nous l'avons surmonté en implémentant notre composant personnalisé.

Cette question a déjà accepté la réponse, mais maintenant, un jour de plus, une base de données NoSQL est en vogue pour bon nombre de ses excellentes fonctionnalités. C'est Couchbase; qui fonctionne comme CouchbaseLitesur la plate-forme mobile et Couchbase Servercôté serveur.

Voici quelques-unes des principales fonctionnalités de Couchbase Lite.

Couchbase Lite est un moteur de base de données léger, orienté document (NoSQL) et synchronisable, adapté à l'intégration dans des applications mobiles.

Léger signifie:

Embarqué: le moteur de base de données est une bibliothèque liée à l'application, pas un processus serveur distinct. Petite taille de code - importante pour les applications mobiles, qui sont souvent téléchargées sur des réseaux cellulaires. Temps de démarrage rapide - important car les appareils mobiles ont des processeurs relativement lents. Faible utilisation de la mémoire - les ensembles de données mobiles typiques sont relativement petits, mais certains documents peuvent contenir de grandes pièces jointes multimédias. Bonnes performances - les chiffres exacts dépendent bien sûr de vos données et de votre application.

Orienté document signifie:

Stocke les enregistrements au format JSON flexible au lieu d'exiger des schémas prédéfinis ou une normalisation. Les documents peuvent avoir des pièces jointes binaires de taille arbitraire, telles que du contenu multimédia. Le format des données d'application peut évoluer dans le temps sans avoir besoin de migrations explicites. L'indexation MapReduce fournit des recherches rapides sans avoir besoin d'utiliser des langages de requête spéciaux.

Syncable signifie:

Deux copies d'une base de données peuvent être synchronisées via un algorithme de réplication efficace, fiable et éprouvé. La synchronisation peut être à la demande ou continue (avec une latence de quelques secondes). Les appareils peuvent se synchroniser avec un sous-ensemble d'une grande base de données sur un serveur distant. Le moteur de synchronisation prend en charge les connexions réseau intermittentes et peu fiables. Les conflits peuvent être détectés et résolus, la logique de l'application contrôlant pleinement la fusion. Les arborescences de révision permettent des topologies de réplication complexes, y compris de serveur à serveur (pour plusieurs centres de données) et d'égal à égal, sans perte de données ni faux conflits. Couchbase Lite fournit des API natives pour le développement transparent iOS (Objective-C) et Android (Java). En outre, il comprend le plug-in Couchbase Lite pour PhoneGap,

Vous pouvez en savoir plus sur Couchbase Lite

et Couchbase Server

Cela va à la prochaine grande chose.

En parlant de production, le basculement / récupération sans couture nécessite tous les deux une baby-sitter
1- Couchbase, il n'y a pas de basculement / récupération sans couture, une intervention manuelle est requise.
le rééquilibrage prend trop de temps, trop de risques si plusieurs nœuds sont perdus.

2- Mongo avec des fragments, la récupération de données après avoir perdu un serveur de configuration, n'est pas une tâche facile

Adobe utilise MongoDB pour sa prochaine version d' Adobe Experience Manager (anciennement Day CQ ) comme moteur de base de données.

Plusieurs clients de l'agence dans laquelle je travaille utilisent CouchDB sur des projets pour de gros clients.

Les deux sont des bases de données formidables et viables, à mon avis. :)

Voici une liste des sites de production déployés avec mongoDB

• The New Yorks Times : l'utiliser dans une application de création de formulaire pour les soumissions de photos. Le manque de schéma de Mongo donne aux producteurs la possibilité de définir n'importe quelle combinaison de champs de formulaire personnalisés.
• SourceForge : est utilisé pour le stockage back-end sur les premières pages de SourceForge, les pages de projet et les pages de téléchargement pour tous les projets.
• Bit.ly
• Etsy
• IGN : alimente l'analyse de trafic en temps réel d'IGN et les API de contenu RESTful.
• Justin.tv : alimente les outils d'analyse internes de Justin.tv pour la viralité, la rétention des utilisateurs et les statistiques d'utilisation générales que les solutions prêtes à l'emploi ne peuvent pas fournir.
• Postérieur
• Intuit
• Foursquare : les bases de données Sharded Mongo sont utilisées pour la plupart des données sur foursquare.
• Business Insider : l'utilise depuis début 2008. Toutes les données du site, y compris les publications, les commentaires et même les images, sont stockées sur MongoDB.
• Github : est utilisé pour une application de reporting interne.
• Examinateur : migration de leur site de Cold Fusion et SQL Server vers Drupal 7 et MongoDB.
• Grooveshark : utilise actuellement Mongo pour gérer plus d'un million de sessions utilisateur uniques par jour.
• Buzzfeed
• Disque
• Evite : utilisé pour l'analyse et la création de rapports rapides.
• Squarespace
• Shutterfly : est utilisé pour diverses exigences de stockage de données persistantes dans Shutterfly. MongoDB aide Shutterfly à créer un service inégalé qui permet des relations plus profondes et plus personnelles entre les clients et ceux qui comptent le plus dans leur vie.
• Topsy
• Sharethis
• Mongohq : fournit une plateforme d'hébergement pour MongoDB et utilise également MongoDB comme back-end pour son service. Notre page des centres d'hébergement fournit plus d'informations sur MongoHQ et d'autres options d'hébergement MongoDB.

et plus...

Extrait de: http://lineofthought.com/tools/mongodb

Vous pouvez également consulter d'autres bases de données ou outils.

MongoDB a quelques problèmes avec l'octroi de licences aux entreprises, je ne suis pas sûr des détails mais notre service juridique nous a dit en termes non certains que nous n'étions pas autorisés à utiliser MongoDB dans aucun de nos produits.