Quand utiliser MongoDB ou d'autres systèmes de base de données orientés documents ?

Question

Nous offrons une plateforme pour les clips vidéo et audio, les photos et les graphiques vectoriels. 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 répond mieux aux exigences. Par exemple : les photos peuvent avoir Exif les vidéos peuvent comporter des pistes audio pour lesquelles nous souhaitons également stocker les méta-informations. Les vidéos et les graphiques vectoriels ne partagent aucune méta-information commune, etc. Je sais donc que MongoDB est parfait pour stocker ces données non structurées et les rendre interrogeables.

Cependant, nous continuons à développer notre plateforme et à ajouter des fonctionnalités. L'une des prochaines étapes sera de fournir un forum à nos utilisateurs. La question qui se pose maintenant est la suivante : utiliser la base de données MySQL, qui serait un bon choix pour stocker les forums et les messages du forum, etc. ou utiliser MongoDB pour cela aussi ?

La question est donc de savoir quand utiliser MongoDB et quand utiliser un SGBDR. Que prendriez-vous, MongoDB ou MySQL, si vous aviez le choix et pourquoi le prendriez-vous ?

Answer 1

En NoSQL : Si seulement c'était aussi simple l'auteur écrit sur MongoDB :

MongoDB n'est pas un magasin clé/valeur, c'est bien plus. Il ne s'agit pas non plus d'un SGBDR. Je n'ai pas utilisé MongoDB en production, mais je l'ai utilisé un peu pour construire une application de test et c'est un outil très cool. Il semble très performant et dispose, ou disposera bientôt, de la tolérance aux pannes et de l'auto-sharding (c'est-à-dire qu'il sera évolutif). Je pense que Mongo est ce qui se rapproche le plus d'un remplacement de SGBDR que j'ai vu jusqu'à présent. Il ne fonctionnera pas pour tous les ensembles de données et tous les modèles d'accès, mais il est conçu pour les tâches typiques de CRUD. Stocker ce qui est essentiellement un énorme hash, et être capable de sélectionner n'importe laquelle de ces clés, est ce pour quoi la plupart des gens utilisent une base de données relationnelle. Si votre base de données est 3NF et que vous ne faites pas de jointures (vous sélectionnez simplement un groupe de tables et mettez tous les objets ensemble, ce que la plupart des gens font dans une application web), MongoDB serait probablement parfait pour vous.

Puis, dans la conclusion :

Ce qu'il faut retenir, c'est que si vous ne pouvez pas créer quelque chose de génial parce que vous ne pouvez pas choisir une base de données, vous vous y prenez mal. Si vous connaissez mysql, utilisez-le. Optimisez quand vous en avez vraiment besoin. Utilisez-le comme un magasin k/v, utilisez-le comme un rdbms, mais pour l'amour de Dieu, construisez votre application qui tue ! Rien de tout cela n'a d'importance pour la plupart des applications. Facebook utilise toujours MySQL, beaucoup. Wikipedia utilise MySQL, beaucoup. FriendFeed utilise MySQL, beaucoup. NoSQL est un outil formidable, mais il ne constituera certainement pas votre avantage concurrentiel, il ne fera pas de votre application un succès et, surtout, vos utilisateurs ne se soucieront pas de tout cela.

Sur quoi vais-je construire ma prochaine application ? Probablement Postgres. Est-ce que j'utiliserai NoSQL ? Peut-être. Je pourrais aussi utiliser Hadoop et Hive. Je pourrais tout garder dans des fichiers plats. Je vais peut-être commencer à bricoler sur Maglev. J'utiliserai ce qui est le mieux pour le travail. Si j'ai besoin d'un rapport, je n'utiliserai pas de NoSQL. Si j'ai besoin d'une mise en cache, je vais probablement utiliser Tokyo Tyrant. Si j'ai besoin d'ACIDity, 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 je dois écrire 1 milliard d'objets par jour, j'utiliserais probablement Voldemort. Si j'avais besoin d'une recherche plein texte, j'utiliserais probablement Solr. Si j'avais besoin d'une recherche plein texte sur des données volatiles, j'utiliserais probablement Sphinx.

J'aime cet article, je le trouve très instructif, il donne une bonne vue d'ensemble du paysage et de la hype NoSQL. Mais, et c'est la partie la plus importante, il aide vraiment à se poser les bonnes questions lorsqu'il s'agit de choisir entre un SGBD et un NoSQL. Cela vaut la peine d'être lu, à mon avis.

Autre lien vers l'article

Answer 2

Après deux ans d'utilisation de MongoDb pour une application sociale, j'ai pu constater ce que signifie réellement vivre sans SGBDR SQL.

1. Vous finissez par écrire des tâches pour faire des choses comme joindre des données provenant de différentes tables/collections, ce qu'un SGBDR ferait automatiquement pour vous.
2. Vos capacités d'interrogation avec NoSQL sont considérablement réduites. MongoDb est peut-être ce qui se rapproche le plus de SQL, mais il est encore très loin derrière. Croyez-moi. Les requêtes SQL sont super intuitives, flexibles et puissantes. Les requêtes MongoDb ne le sont pas.
3. Les requêtes MongoDb peuvent extraire des données d'une seule collection et tirer parti 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 davantage d'allers-retours vers le serveur pour trouver des enregistrements connexes. Et puis vous commencez à dé-normaliser les données - ce qui implique des travaux en arrière-plan.
4. Le fait qu'il ne s'agisse pas d'une base de données relationnelle signifie que vous n'aurez pas de contraintes de clés étrangères (considérées par certains comme peu performantes) pour garantir la cohérence de vos données. Je vous assure que cela va finir par créer des incohérences de données dans votre base de données. Soyez prêt. Vous commencerez très probablement à écrire des processus ou des contrôles pour assurer la cohérence de votre base de données, ce qui ne sera probablement pas plus performant que de laisser le SGBDR le faire pour vous.
5. Oubliez les cadres matures comme Hibernate.

Je pense que 98 % de tous les projets sont probablement bien meilleurs 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 il peut organiser vos données en format document. Ces alternatives de SGBDR appelées NoSQL les magasins de données ( MongoDB , CouchDB , Voldemort ) sont très utiles pour les applications qui évoluent massivement et nécessitent un accès plus rapide aux données à partir de ces magasins de données volumineuses.

Et la mise en œuvre de ces bases de données est plus simple que celle des SGBDR classiques. Puisqu'il s'agit de simples objets binaires de type clé-valeur ou document directement sérialisés sur le disque. Ces magasins de données n'appliquent pas le Propriétés de l'ACID et toute schémas . Cela ne fournit aucune transaction capacités. Ce système peut donc être étendu et nous pouvons obtenir un accès plus rapide (en lecture et en écriture).

En revanche, RDBM applique ACID et les schémas aux données. Si vous souhaitez travailler avec des données structurées, vous pouvez opter pour RDBM.

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

Answer 4

Notez que Mongo stocke essentiellement du JSON. Si votre application traite un grand nombre d'objets JS (avec imbrication) et que vous voulez faire persister ces objets, il y a de très bons arguments pour utiliser Mongo. Cela rend vos couches DAL et MVC ultra-minces, car elles n'ont pas à décompresser toutes les propriétés des objets JS et à essayer de les intégrer de force dans une structure (schéma) qui ne leur convient pas naturellement.

Notre système repose sur plusieurs objets JS complexes et nous aimons Mongo parce que nous pouvons tout faire persister très, très facilement. Nos objets sont aussi plutôt amorphes et non structurés, et Mongo absorbe cette complication sans sourciller. Nous avons une couche de rapport personnalisée qui déchiffre les données amorphes pour la consommation humaine, et ce n'était pas si difficile à développer.

Answer 5

Qui a besoin de forums distribués et partagés ? Peut-être Facebook, mais à moins que vous ne créiez un concurrent de Facebook, utilisez Mysql, Postgres ou tout autre système avec lequel vous êtes le plus à l'aise. 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 l'avez déjà découvert si vous avez vraiment travaillé dessus.

Bien sûr, MongoDB peut faire l'objet d'un battage médiatique et sembler facile en apparence, mais vous rencontrerez des problèmes que des produits plus matures ont déjà surmontés. Ne vous laissez pas séduire si facilement, mais attendez plutôt que le "nosql" arrive à maturité, ou meurt.

Personnellement, je pense que le "nosql" va s'étioler et mourir à cause de la fragmentation, car il n'y a pas de normes établies (presque par définition). Je ne parierai donc pas personnellement dessus pour tout projet à long terme.

La seule chose qui peut sauver "nosql" dans mon livre, c'est s'il peut s'intégrer dans Ruby ou des langages similaires de façon transparente, et rendre le langage "persistant", presque sans aucune surcharge dans le codage et la conception. Cela peut arriver, mais j'attendrai jusqu'à ce moment-là, pas maintenant, et il doit être plus mature bien sûr.

Au fait, pourquoi créez-vous un forum à partir de zéro ? Il existe des tonnes de forums open source qui peuvent être adaptés à la plupart des besoins, à moins que vous ne vouliez vraiment créer la prochaine génération de forums (ce dont je doute).