Quand utiliser MongoDB ou d'autres systèmes de bases de données orientées document? [fermé]

Question

Nous offrons une plate-forme audio-vidéo et des clips, des photos et des vecteurs-grafics. Nous avons commencé avec MySQL comme base de base de données et a récemment inclus MongoDB pour stocker toutes les méta-informations de les fichiers, parce que MongoDB correspond mieux aux exigences. Par exemple: les photos peuvent avoir Exif informations, vidéos peuvent avoir des pistes audio-où nous voulons stocker à les méta-informations de aussi. Vidéos et graphiques vectoriels ne partagent aucune méta-information commune, etc., donc je sais que MongoDB est parfait pour stocker ces données non structurées et conserver une recherche.

Cependant, nous continuons à développer notre plate-forme et l'ajout de fonctionnalités. Maintenant, l'une des prochaines étapes consisteront à fournir un forum pour nos utilisateurs. La question qui se pose maintenant est: utiliser la base de données MySQL, ce qui serait un bon choix pour le stockage des forums et forum de messages, etc. ou utiliser MongoDB pour cela aussi

La question est: quand utiliser MongoDB et quand utiliser un SGBDR. Que voulez-vous prendre, MongoDB ou MySQL, si vous aviez le choix et pourquoi voudriez-vous prendre?

Answer 1

Dans NoSQL: Si seulement il était si facile , l'auteur écrit sur MongoDB:

  

MongoDB est pas un magasin clé / valeur, il est un peu plus. Il est certainement pas un SGBDR non plus. Je ne l'ai pas utilisé MongoDB dans la production, mais je l'ai utilisé un peu la construction d'une application de test et il est un morceau très cool du kit. Il semble être très performant et soit a, ou aura bientôt, la tolérance aux pannes et auto-sharding (alias elle échelle). Je pense que Mongo pourrait être le plus proche d'un remplacement de SGBDR que je l'ai vu jusqu'à présent. Il ne fonctionne pas pour tous les ensembles de données et des modèles d'accès, mais il est construit pour vos affaires CRUD typique. Le stockage ce qui est essentiellement un énorme hachage, et d'être en mesure de sélectionner sur l'une de ces clés, est ce que la plupart des gens utilisent une base de données relationnelle pour. Si votre DB est 3NF et vous ne faites pas des jointures (vous suffit alors de sélectionner un groupe de tables et de mettre tous les objets ensemble, AKA ce que la plupart des gens dans une application Web), MongoDB probablement botter le cul pour vous.

Alors, dans la conclusion:

  

La vraie chose à souligner est que si vous êtes retenu de faire quelque chose de super génial parce que vous ne pouvez pas choisir une base de données, vous le faites mal. Si vous connaissez mysql, juste utilise le. Optimiser lorsque vous avez réellement besoin. Utilisez-le comme un magasin k / v, l'utiliser comme un SGBDR, mais pour l'amour de Dieu, construire votre killer app! Rien de tout cela importera à la plupart des applications. Facebook utilise encore MySQL, beaucoup. Wikipedia utilise MySQL, beaucoup. FriendFeed utilise MySQL, beaucoup. NoSQL est un excellent outil, mais il ne va certainement pas être votre avantage concurrentiel, il ne va pas rendre votre application à chaud, et surtout, vos utilisateurs ne se soucient de tout cela.

     

Qu'est-ce que je vais construire ma prochaine application sur? Probablement Postgres. Est-ce que j'utiliser NoSQL? Peut être. Je pourrais aussi utiliser Hadoop et Ruche. Je pourrais tout garder dans des fichiers plats. Peut-être que je vais commencer à bidouiller sur Maglev. Je vais utiliser tout ce qui est le mieux pour le travail. Si je besoin de rapports, je ne vais pas utiliser tout NoSQL. Si je dois la mise en cache, je vais probablement utiliser Tokyo Tyran. Si je dois Acidité, je ne vais pas utiliser NoSQL. Si je besoin d'une tonne de compteurs, je vais utiliser Redis. Si j'ai besoin des transactions, je vais utiliser Postgres. Si j'ai une tonne d'un seul type de documents, je vais probablement utiliser Mongo. Si je dois écrire 1 milliards d'objets par jour, je serais probablement utiliser Voldemort. Si je besoin recherche en texte intégral, je serais probablement utiliser Solr. Si je besoin recherche en texte intégral des données volatiles, je serais probablement utiliser Sphinx.

J'aime cet article, je trouve très instructif, il donne un bon aperçu du paysage NoSQL et de battage. Mais, et c'est la partie la plus importante, il aide vraiment à vous poser les bonnes questions quand il s'agit de choisir entre SGBDR et NoSQL. À mon humble avis vaut le lire.

lien alternatif à l'article

Answer 2

Après deux ans à l'aide de MongoDB pour une application sociale, j'ai vu ce que cela signifie vraiment vivre sans SGBDR SQL.

1. Vous finissez par écrire des emplois pour faire des choses comme se joindre à des données de différentes tables / collections, quelque chose qui ferait un SGBDR pour vous automatiquement.
2. Vos capacités de requête avec NoSQL sont radicalement paralysés. MongoDB est peut-être la chose la plus proche de SQL, mais il est encore très loin derrière. Croyez-moi. les requêtes SQL sont super intuitive, flexible et puissant. les requêtes ne sont pas MongoDB.
3. requêtes de MongoDB peuvent récupérer des données à partir d'une seule collection et tirer profit d'un seul indice. Et MongoDB est probablement l'un des plus flexibles les bases de données NoSQL. Dans de nombreux scénarios, cela signifie plus de voyages-tour au serveur pour trouver des documents connexes. Et puis vous commencez à données dénormaliser -. Ce qui signifie des emplois de fond
4. Le fait que ce n'est pas une base de données relationnelle signifie que vous n'aurez pas (considéré par certains comme mauvais performants) contraint la clé étrangère pour assurer que vos données sont cohérentes. Je vous assure que ce va finalement créer des incohérences de données dans votre base de données. Préparez-vous. Très probablement, vous allez commencer à écrire des processus ou des chèques pour garder votre base de données cohérente, qui ne rempliraient probablement pas mieux que de laisser les SGBDR faire pour vous.
5. Oubliez les cadres matures comme mise en veille prolongée.

Je crois que 98% de tous les projets sont beaucoup mieux sans doute avec un SGBDR SQL typique qu'avec NoSQL.

Answer 3

  

pour stocker ces données non structurées

Comme vous l'avez dit, MongoDB est le mieux adapté pour stocker des données non structurées. Et cela peut organiser vos données en format de document. Ces altenatives SGBDR appelés NoSQL magasins de données ( MongoDB , CouchDB , Voldemort ) sont très utiles pour les applications qui Scales massivement et nécessitent un accès plus rapide des données de ces grands magasins de données.

Et la mise en œuvre de ces bases de données sont plus simples que le SGBDR régulière. Étant donné que ces sont simples objets binaires clé d'une valeur ou d'un style de document directement dans le disque sérialisé. Ces données ne stocke pas respecter les propriétés ACID , et les schémas . Cela ne fournit aucune transaction capacités. Donc, cela peut évoluer grand et nous pouvons obtenir un accès plus rapide (lecture et écriture).

Mais au contraire, RDBM applique ACID et les schémas sur les données. Si vous voulez travailler avec des données structurées vous pouvez aller de l'avant avec RDBM.

Je choisirais MySQL pour créer des forums pour ce genre de choses. Parce que cela ne va pas à l'échelle grande. Et cela est une application très simple (commune) qui a structuré les relations entre les données.

Answer 4

Notez que Mongo stocke essentiellement JSON. Si votre application traite avec beaucoup d'objets JS (avec imbrication) et que vous voulez persister ces objets alors il y a un argument très fort pour l'utilisation de Mongo. Il rend votre DAL et couches MVC ultra minces, car ils ne sont pas non emballage toutes les propriétés de l'objet JS et en essayant de les adapter-force dans une structure (schéma) qu'ils ne s'intègrent naturellement dans.

Nous avons un système qui a plusieurs objets complexes JS en son cœur, et nous aimons parce que nous pouvons Mongo persister tout vraiment, vraiment facilement. Nos objets sont également assez amorphes et non structurées, et Mongo absorbe cette complication sans sourciller. Nous avons une couche de reporting personnalisé qui déchiffre les données amorphes pour la consommation humaine, et cela n'a pas été si difficile à développer.

Answer 5

Je dirais que l'utilisation d'un SGBDR si vous avez besoin des transactions complexes. Sinon, j'irais avec MongoDB - plus flexible pour travailler avec et vous le savez peut évoluer quand vous avez besoin. (Je suis partial si - je travaille sur le projet MongoDB)

Answer 6

Qui a besoin distribué, des forums fragmentées? Peut-être que Facebook, mais à moins que vous créez un Facebook-concurrent, il suffit d'utiliser Mysql, Postgres ou tout ce que vous êtes plus à l'aise. Si vous voulez essayer MongoDB, ok, mais ne vous attendez pas à faire de la magie pour vous. Il aura ses bizarreries et méchancetés général, tout comme tout le reste, comme je suis sûr que vous avez déjà découvert si vous avez vraiment travaillé sur elle déjà.

Bien sûr, MongoDB peut être médiatisée et semble facile sur la surface, mais vous tomberez sur des problèmes qui les produits plus matures ont déjà surmontés. Ne vous laissez pas leurré si facilement, mais plutôt attendre « NoSQL » arrive à maturité, ou meurt.

Personnellement, je pense « NoSQL » va dépérir et mourir de la fragmentation, car il n'y a pas de normes établies (presque par définition). Je vais donc pas parier personnellement pour des projets à long terme.

La seule chose qui peut sauver « NoSQL » dans mon livre, est si elle peut intégrer dans les langues Ruby ou similaires de façon transparente et rendre le langage « persistant », presque sans frais généraux dans le codage et la conception. Cela peut arriver, mais je vais attendre jusque-là, pas maintenant, et il doit être plus mature bien sûr.

BTW, pourquoi vous créez un forum à partir de zéro? Il y a des tonnes de forums open source qui peut être modifié pour répondre à la plupart des exigences, à moins que vous créez vraiment la prochaine génération de forums (dont je doute).

Answer 7

Je l'ai vu à beaucoup d'entreprises utilisent MongoDB pour l'analyse en temps réel à partir des journaux d'application. Son schéma correspond vraiment pour freeness des journaux d'application, où le schéma d'enregistrement a tendance à changer de temps en temps. En outre, son la fonction de Capped Collection est utile, car elle purge automatiquement les anciennes données à conserver les données entrent dans la mémoire.

C'est un domaine que je pense vraiment MongoDB convient pour, mais MySQL / PostgreSQL est plus recommandé en général. Il sont beaucoup de ressources et de documentation développeur sur le web, ainsi que leur fonctionnalité et leur robustesse.

Answer 8

La 2 principale raison pour laquelle vous voudrez peut-être préférer Mongo sont

• La flexibilité dans la conception du schéma (type de document JSON magasin).
• Évolutivité -. Il suffit d'ajouter des nœuds et il peut évoluer horizontalement assez bien

Il convient aux grandes applications de données. SGBDR n'est pas bon pour les grandes données.

Answer 9

Vous savez, tout ce genre de choses sur les jointures et les « opérations complexes » - mais il était Monty lui-même qui, il y a plusieurs années, a expliqué loin le « besoin » COMMIT / ROLLBACK, en disant que « tout ce qui est fait dans les classes logiques (et non la base de données) de toute façon » - il est donc la même chose encore. Ce qui est nécessaire est un moteur de stockage / récupération stupide encore incroyablement bien rangé et rapide des données, pour 99% de ce que les applications Web font.

Answer 10

Comme dit précédemment, vous pouvez choisir entre beaucoup de choix, jetez un oeil à tous ces choix: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb -vs-Redis

Ce que je suggère est de trouver la meilleure combinaison: MySQL + Memcache est vraiment génial si vous avez besoin d'acide et que vous voulez joindre des tables MongoDB + Redis est parfait pour le magasin de documents Neo4j est parfait pour la base de données graphique

Qu'est-ce que je fais: je commence Mysql + Memcache parce que je suis habituée, alors je commence à utiliser d'autres cadre de base de données. Dans un seul projet, vous pouvez combiner MySQL et MongoDB par exemple!