Quand utiliser MongoDB ou d'autres systèmes de base de données orientés documents? [fermé]
Nous offrons une plate - forme pour les clips vidéo et audio, les photos et les images vectorielles. Nous avons commencé avec MySQL comme backend de base de données et avons récemment inclus MongoDB pour stocker toutes les méta-informations des fichiers, car MongoDB correspond mieux aux exigences. Par exemple: les photos peuvent avoir des informations Exif, les vidéos peuvent avoir des pistes audio où nous voulons stocker les méta-informations, aussi. Les vidéos et les 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 les garder consultables.
Cependant, nous continuons à développer notre plate-forme et à ajouter des fonctionnalités. Maintenant, l'une des prochaines étapes sera de fournir un forum pour nos utilisateurs. La question qui se pose maintenant est: Utilisez la base de données MySQL, ce qui serait un bon choix pour stocker des forums et des forums, etc. ou utilisez MongoDB pour cela aussi?
La question est donc: quand utiliser MongoDB et quand utiliser un SGBDR. Que prendriez-vous, mongoDB ou MySQL, si vous avait le choix et pourquoi le prendriez-vous?
11 réponses
Dans NoSQL: si seulement c'était aussi facile , l'auteur écrit à propos de MongoDB:
MongoDB n'est pas un magasin de clés/valeurs, c'est un peu plus. Ce n'est certainement pas un SGBDR non plus. Je n'ai pas utilisé MongoDB en production, mais je l'ai utilisé un peu en construisant une application de test et c'est un kit très cool. Il semble être très performant et a, ou aura bientôt, la tolérance aux pannes et l'auto-sharding (aka il évoluera). Je pense que Mongo pourrait être la chose la plus proche d'un SGBDR de remplacement que j'ai vu jusqu'à présent. Cela ne fonctionnera pas pour tous les ensembles de données et les modèles d'accès, mais il est construit pour vos trucs CRUD typiques. Stocker ce qui est essentiellement un énorme hachage, et être capable 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 que vous ne faites aucune jointure (vous ne faites que sélectionner un tas de tables et mettre tous les objets ensemble, AKA ce que la plupart des gens font dans une application web), MongoDB serait probablement botter le cul pour vous.
, Puis, 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, utilisez-le. Optimisez quand vous en avez réellement besoin. Utilisez-le comme un magasin k / v, utilisez-le comme un SGBDR, mais pour l'amour de Dieu, construisez votre application de tueur! 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 chaude, et surtout, vos utilisateurs ne se soucient pas de tout cela.
Sur quoi vais-je construire ma prochaine application? Probablement Postgres. Vais-je utiliser NoSQL? Peut-être. Je pourrais aussi utiliser Hadoop et Hive. Je pourrais tout garder dans des dossiers plats. Peut-être que je vais commencer à pirater Maglev. je vais utiliser ce qui est le mieux pour le travail. Si j'ai besoin en rapport, Je n'utiliserai aucun NoSQL. Si j'ai besoin de mise en cache, je vais probablement utiliser Tokyo Tyrant. Si J'ai besoin D'acidité, Je n'utiliserai pas NoSQL. Si j'ai besoin d'une tonne de compteurs, j'utiliserai Redis. Si j'ai besoin de transactions, j'utiliserai Postgres. Si j'ai une tonne d'un seul type de documents, je vais probablement utiliser Mongo. Si j'ai besoin d'écrire 1 milliard d'objets par jour, j'utiliserais probablement Voldemort. Si j'ai besoin d'une recherche en texte intégral, j'utiliserais probablement Solr. Si j'ai besoin d'une recherche en texte intégral de données volatiles, Je probablement utiliser Sphinx.
J'aime cet article, je le trouve très instructif, il donne un bon aperçu du paysage NoSQL et du battage médiatique. Mais, et c'est la partie la plus importante, il est vraiment utile de vous poser les bonnes questions quand il s'agit de choisir entre SGBDR et NoSQL. Vaut la lecture à mon humble avis.
Après deux ans d'utilisation de MongoDb pour une application sociale, j'ai été témoin de ce que cela signifie vraiment de vivre sans SGBDR SQL.
- vous finissez par écrire des travaux pour faire des choses comme joindre des données à partir de différentes tables / collections, ce qu'un SGBDR ferait automatiquement pour vous.
- vos capacités de requête avec NoSQL sont considérablement paralysées. MongoDb peut être la chose la plus proche de SQL, mais il est encore extrêmement loin derrière. Faites-moi confiance. Les requêtes SQL sont super intuitives, flexibles et puissant. Les requêtes MongoDb ne le sont pas.
- les requêtes MongoDb peuvent récupérer des données d'une seule collection et profiter d'un seul index. Et MongoDb est probablement l'une des bases de données NoSQL les plus flexibles. Dans de nombreux scénarios, cela signifie plus d'allers-retours vers le serveur pour trouver les enregistrements associés. Et puis vous commencez à normaliser les données - ce qui signifie des travaux d'arrière-plan.
- le fait qu'il ne s'agisse pas d'une base de données relationnelle signifie que vous n'aurez pas de clé étrangère (considérée par certains comme mauvaise performance) contraint de s'assurer que vos données sont cohérentes. Je vous assure que cela finira par créer des incohérences de données dans votre base de données. Être préparé. Très probablement, vous commencerez à écrire des processus ou des vérifications pour garder votre base de données cohérente, ce qui ne fonctionnera probablement pas mieux que de laisser le SGBDR le faire pour vous.
- Oubliez les frameworks matures comme hibernate.
Je crois que 98% de tous les projets sont probablement bien meilleurs avec un SGBDR SQL typique qu'avec NoSQL.
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 altenatifs RDBMS appelés NoSQL data stores ( MongoDB, CouchDB, Voldemort ) sont très utiles pour les applications qui évoluent massivement et nécessitent un accès plus rapide aux données de ces grands magasins de données.
Et la mise en œuvre de ces bases de données sont plus simples que régulièrement des SGBDR. Comme ce sont des objets binaires simples à valeur clé ou de style document directement sérialisés sur le disque. Ces magasins de données n'appliquent pas les propriétés ACID et les schémas . Cela ne fournit aucune capacité transaction . Cela peut donc évoluer et nous pouvons obtenir un accès plus rapide (à la fois en lecture et en écriture).
Mais en revanche, 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 voudrais choisissez MySQL pour la création de forums pour ce genre de choses. Parce que cela ne va pas à grande échelle. Et c'est une application très simple (commune) qui a structuré les relations entre les données.
Notez que Mongo stocke essentiellement JSON. Si votre application traite beaucoup d'objets JS (avec imbrication) et que vous voulez conserver ces objets, il existe un argument très fort pour utiliser Mongo. Cela rend vos couches Dal et MVC ultra minces, car elles ne désemballent pas toutes les propriétés de l'objet JS et essaient de les intégrer de force dans une structure (schéma) dans laquelle elles ne s'intègrent pas naturellement.
Nous avons un système qui a plusieurs objets js complexes en son cœur, et nous aimons Mongo parce que nous pouvons tout persister vraiment, très facilement. Nos objets sont également plutôt amorphes et non structurés, et Mongo absorbe cette complication sans cligner des yeux. Nous avons une couche de reporting personnalisée qui déchiffre les données amorphes pour la consommation humaine, et ce n'était pas si difficile à développer.
Je dirais utiliser un SGBDR si vous avez besoin de transactions complexes. Sinon, J'irais avec MongoDB-plus flexible pour travailler avec et vous savez qu'il peut évoluer quand vous en avez besoin. (Je suis biaisé cependant - je travaille sur le projet MongoDB)
Qui a besoin de forums distribués et partagés? Facebook, Facebook peut-être, mais à moins que vous ne créiez un concurrent Facebook, utilisez Mysql, Postgres ou tout ce que vous êtes le plus à l'aise avec. Si vous voulez essayer MongoDB, ok, mais ne vous attendez pas à ce qu'il fasse de la magie pour vous. Il aura ses bizarreries et sa méchanceté générale, comme tout le reste, comme je suis sûr que vous avez déjà découvert si vous avez déjà travaillé dessus.
Bien sûr, MongoDB peut être hype et sembler facile à la surface, mais vous allez rencontrer problèmes que des produits plus matures ont déjà surmontés. Ne soyez pas attiré si facilement, mais attendez plutôt que "nosql" mûrisse ou meure.
Personnellement, je pense que "nosql" va se faner et mourir de la fragmentation, car il n'y a pas de normes définies (presque par définition). Donc, je ne vais pas parier personnellement sur elle pour des projets à long terme.
La seule chose qui peut sauver "nosql" dans mon livre, c'est si elle peut s'intégrer dans Ruby ou des langages similaires de manière transparente, et rendre la langue "persistante", 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 créez-vous un forum à partir de zéro? Il y a des tonnes de forums open source qui peuvent être modifiés pour répondre à la plupart des exigences, sauf si vous créez vraiment la prochaine génération de Forums (ce dont je doute).
Après avoir assisté à Devoxx 2011 et assisté à une présentation de 10Gen, j'ai écrit un petit blog comparant MongoDB aux bases de données SGBDR. MongoDB est l'un des dbs NoSQL populaires. Veuillez voir ci-dessous:
J'ai vu beaucoup d'entreprises utilisent MongoDB pour les analyses en temps réel à partir des journaux d'applications. Sa liberté de schéma convient vraiment aux journaux d'application, où le schéma d'enregistrement a tendance à changer de temps en temps. En outre, sa fonction Collection plafonnée est utile car elle purge automatiquement les anciennes données pour les conserver dans la mémoire.
C'est un domaine pour lequel je pense vraiment que MongoDB convient, mais MySQL/PostgreSQL est plus recommandé en général. Il y a beaucoup de documentations et les ressources des développeurs sur le web, ainsi que leur fonctionnalité et leur robustesse.
La raison principale 2 pour laquelle vous pourriez vouloir préférer Mongo est
- flexibilité dans la conception de schéma (magasin de documents de type JSON).
- évolutivité-il suffit d'ajouter des nœuds et il peut évoluer horizontalement assez bien.
Il convient aux applications de données volumineuses. SGBDR n'est pas bon pour les grandes données.
Vous savez, tout ce genre de choses sur les jointures et les 'transactions complexes' - mais C'est Monty lui-même qui, il y a de nombreuses années, a expliqué le "besoin" de COMMIT / ROLLBACK, en disant que 'tout ce qui est fait dans les classes logiques (et pas la base de données) de toute façon' - donc c'est la même chose Ce qui est nécessaire est un moteur de stockage/récupération de données stupide mais incroyablement bien rangé et rapide, pour 99% de ce que font les applications web.
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 votre meilleure combinaison: MySQL + Memcache est vraiment génial si vous avez besoin D'acide et que vous voulez rejoindre certaines tables MongoDB + Redis est parfait pour le magasin de documents Neo4J est parfait pour la base de données graphique
Ce que je fais: je commence avec MySQl + Memcache parce que je suis habitué, puis je commence à utiliser d'autres base de données-cadre. Dans un seul projet, vous pouvez combiner MySQL et MongoDB par exemple !