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

Je dirais qu'il faut utiliser un SGBDR si vous avez besoin de transactions complexes. Sinon, j'opterais pour MongoDB, qui est plus souple d'utilisation et qui peut évoluer en fonction des besoins. (Je suis cependant partial, car je travaille sur le projet MongoDB).

Answer 2

Les deux principales raisons pour lesquelles vous pourriez préférer Mongo sont les suivantes

• Flexibilité dans la conception des schémas (magasin de documents de type JSON).
• Évolutivité - Il suffit d'ajouter des nœuds pour que le système puisse évoluer horizontalement.

Il est adapté aux applications de big data. Le SGBDR ne convient pas au big data.

Answer 3

J'ai vu beaucoup d'entreprises utiliser MongoDB pour l'analyse en temps réel des journaux d'application. Sa liberté de schéma convient parfaitement aux journaux d'applications, où le schéma d'enregistrement a tendance à changer de temps en temps. En outre, son Collection plafonnée Cette fonction est utile car elle purge automatiquement les anciennes données pour que les données tiennent dans la mémoire.

C'est un domaine dans lequel je pense vraiment que MongoDB convient, mais MySQL/PostgreSQL est plus recommandé en général. Il y a beaucoup de documentations et de ressources pour les développeurs sur le web, ainsi que leurs fonctionnalités et leur robustesse.

Answer 4

Vous savez, tous ces trucs 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 cela est fait dans les classes logiques (et non dans la base de données) de toute façon" -- donc c'est la même chose encore une fois. Ce dont on a besoin, c'est d'un moteur de stockage/récupération des données à la fois stupide, mais incroyablement ordonné et rapide, pour 99% de ce que font les applications web.

Answer 5

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

Ce que je suggère, c'est de trouver votre meilleure combinaison : MySQL + Memcache est vraiment génial si vous avez besoin d'ACID et que vous voulez joindre certaines tables. MongoDB + Redis est parfait pour le stockage de documents. Neo4J est parfait pour les bases de données graphiques

Ce que je fais : Je commence avec MySQl + Memcache parce que j'y suis habitué, puis je commence à utiliser d'autres frameworks de base de données. Dans un même projet, vous pouvez combiner MySQL et MongoDB par exemple !