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 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 correspond mieux aux exigences. Par exemple: les photos peuvent avoir des informations Exif , les vidéos peuvent avoir des pistes audio sur lesquelles nous voulons également stocker les méta-informations. 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 plateforme et à ajouter des fonctionnalités. Maintenant, l'une des prochaines étapes consistera à fournir un forum à nos utilisateurs. La question qui se pose maintenant est: utiliser la base de données MySQL, qui serait un bon choix pour stocker des forums et des messages de forum, etc. ou utiliser MongoDB pour cela aussi?

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

Dans NoSQL: si seulement c'était aussi simple que cela , l'auteur écrit sur 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 pour construire une application de test et c'est un kit très cool. Il semble être très performant et a, ou aura bientôt, une tolérance aux pannes et un partage automatique (alias il évoluera). Je pense que Mongo pourrait être la chose la plus proche d'un remplacement de SGBDR que j'ai vu jusqu'à présent. Cela ne fonctionnera pas pour tous les ensembles de données et modèles d'accès, mais il est conçu pour vos trucs CRUD typiques. La plupart des gens utilisent une base de données relationnelle pour stocker ce qui est essentiellement un énorme hachage et pouvoir sélectionner l'une de ces clés.Si votre base de données est 3NF et que vous n'effectuez aucune jointure (vous sélectionnez simplement un tas de tables et assemblez tous les objets, AKA ce que la plupart des gens font dans une application Web), MongoDB serait probablement un coup de pied pour vous.

Puis, en conclusion:

La vraie chose à souligner est que si vous êtes empêché de créer 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 ak / v, utilisez-le comme un rdbms, mais pour l'amour du ciel, construisez votre application tueur! Rien de tout cela n'aura d'importance pour la plupart des applications. Facebook utilise toujours beaucoup MySQL. Wikipedia utilise beaucoup MySQL. FriendFeed utilise beaucoup MySQL. NoSQL est un excellent outil, mais ce ne sera certainement pas votre avantage concurrentiel, cela ne rendra pas votre application intéressante et, surtout, vos utilisateurs ne s'en soucieront pas.

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

J'aime cet article, je le trouve très informatif, il donne un bon aperçu du paysage et du battage médiatique NoSQL. Mais, et c'est la partie la plus importante, cela aide vraiment de se poser les bonnes questions quand il s'agit de choisir entre RDBMS et NoSQL. Vaut la lecture à mon humble avis.

Lien alternatif vers l'article

Après deux ans d'utilisation de MongoDb pour une application sociale, j'ai été témoin de ce que signifie vraiment vivre sans SGBDR SQL.

1. Vous finissez par écrire des travaux pour faire des choses comme joindre des données de différentes tables / collections, quelque chose qu'un SGBDR ferait automatiquement pour vous.
2. Vos capacités de requête avec NoSQL sont considérablement réduites. MongoDb est peut-être la chose la plus proche de SQL, mais il est toujours extrêmement 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 récupérer des données à partir 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 plus d'allers-retours vers le serveur pour rechercher les enregistrements associés. Et ensuite, vous commencez à dénormaliser les données, ce qui signifie 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 (considéré par certains comme étant peu performant) des contraintes de clé étrangère pour garantir la cohérence de vos données. Je vous assure que cela va éventuellement 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 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.
5. 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 variantes du SGBDR appelées magasins de données NoSQL ( 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 le SGBDR ordinaire. Comme ce sont de simples objets binaires à valeur clé ou de style de document directement sérialisés en disque. Ces magasins de données n'appliquent pas les propriétés ACID et les schémas . Cela ne fournit aucune capacité de transaction . Cela peut donc évoluer à grande échelle et nous pouvons obtenir un accès plus rapide (en lecture et en écriture).

Mais en revanche, RDBM applique ACID et les schémas sur les données. Si vous souhaitez travailler avec des données structurées, vous pouvez continuer avec RDBM.

Je choisirais MySQL pour créer des forums pour ce genre de choses. Parce que cela ne va pas grandir. Et ceci 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 de nombreux objets JS (avec imbrication) et que vous souhaitez conserver ces objets, il existe un argument très solide pour utiliser Mongo. Cela rend vos couches DAL et MVC ultra minces, car elles ne déballent pas toutes les propriétés des objets JS et n'essaient pas de les forcer dans une structure (schéma) dans laquelle elles ne s'insèrent 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 s'imprègne de cette complication sans ciller. 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.

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? Peut-être Facebook, mais à moins que vous ne créiez un concurrent Facebook, utilisez simplement Mysql, Postgres ou tout ce qui vous convient le mieux. Si vous voulez essayer MongoDB, ok, mais ne vous attendez pas à ce qu'il fasse de la magie pour vous. Il aura ses caprices 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 y avez déjà vraiment travaillé.

Bien sûr, MongoDB peut être excité et sembler facile à la surface, mais vous rencontrerez des problèmes que les produits plus matures ont déjà surmontés. Ne vous laissez pas attirer si facilement, mais attendez plutôt que "nosql" mûrisse ou meure.

Personnellement, je pense que "nosql" se fanera et mourra de la fragmentation, car il n'y a pas de normes établies (presque par définition). Je ne parierai donc pas personnellement pour des projets à long terme.

La seule chose qui peut enregistrer "nosql" dans mon livre, c'est s'il peut s'intégrer de manière transparente dans Ruby ou des langages similaires, et rendre le langage "persistant", presque sans frais généraux de codage et de conception. Cela peut arriver, mais j'attendrai jusque-là, pas maintenant, ET cela doit être plus mature bien sûr.

Btw, pourquoi créez-vous un forum à partir de zéro? Il existe des tonnes de forums open source qui peuvent être modifiés pour répondre à la plupart des exigences, à moins que vous ne créiez vraiment la prochaine génération de forums (ce dont je doute).

J'ai vu que de nombreuses entreprises utilisent MongoDB pour des analyses en temps réel à partir des journaux d'applications. Son absence de schéma convient vraiment aux journaux d'application, où le schéma d'enregistrement a tendance à changer de temps à autre. En outre, sa fonction de collecte plafonnée est utile car elle purge automatiquement les anciennes données pour conserver les données dans la mémoire.

C'est un domaine auquel je pense vraiment que MongoDB convient, mais MySQL / PostgreSQL est plus recommandé en général. Il existe de nombreuses documentations et ressources de développement sur le Web, ainsi que leurs fonctionnalités et leur robustesse.

Les 2 principales raisons pour lesquelles vous voudrez peut-être préférer Mongo sont

• Flexibilité dans la conception de schéma (magasin de documents de type JSON).
• Évolutivité - Ajoutez simplement des nœuds et il peut évoluer assez bien horizontalement.

Il convient aux applications Big Data. RDBMS n'est pas bon pour les mégadonnées.

Vous savez, toutes ces 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, disant que «tout ce qui se fait dans les classes logiques (et pas la base de données) de toute façon '- c'est donc à nouveau la même chose. Ce dont nous avons besoin, c'est d'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 œil à 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'ACID et que vous souhaitez rejoindre certaines tables MongoDB + Redis est parfait pour le magasin de documents Neo4J est parfait pour la base de données de 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 seul projet, vous pouvez combiner MySQL et MongoDB par exemple!