Quand utiliser MongoDB ou d'autres systèmes de base de données orientés document?
Nous offrons une plate-forme pour les clips vidéo et audio, les photos et les graphiques vectoriels. Nous avons commencé avec MySQL comme base de données 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 des informations Exif , les vidéos peuvent avoir des pistes audio sur lesquelles nous souhaitons 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 idéal pour stocker ces données non structurées et les conserver consultables.
Cependant, nous continuons à développer notre plateforme et à ajouter des fonctionnalités. Une des prochaines étapes consistera à fournir un forum à nos utilisateurs. La question qui se pose maintenant est la suivante: utiliser la base de données MySQL, ce qui serait un bon choix pour stocker des forums et des posts sur le forum, etc. ou utiliser MongoDB pour cela également?
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?
Dans NoSQL: Si seulement c'était aussi simple que cela , 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 j’ai utilisé un peu pour créer 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 auto-sharding (c'est-à-dire qu'il va évoluer). Je pense que Mongo est peut-être la chose la plus proche d’un remplacement de SGBDR que j’ai vue jusqu’à présent. Cela ne fonctionnera pas pour tous les ensembles de données et tous les modèles d’accès, mais il est conçu pour votre matériel CRUD typique. Stocker ce qui est essentiellement un hachage énorme et pouvoir sélectionner l'une 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 en 3NF et que vous ne faites aucune jointure (vous ne faites que sélectionner un groupe de tables et assembler tous les objets, AKA, ce que la plupart des gens font dans une application Web), MongoDB ferait probablement des bêtises pour vous.
Puis, en conclusion:
Ce qu'il faut vraiment souligner, c'est que si vous ne pouvez pas créer quelque chose de vraiment 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 lorsque vous en avez réellement 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 importera à la plupart des applications. Facebook utilise toujours MySQL, beaucoup. Wikipedia utilise MySQL, beaucoup. FriendFeed utilise beaucoup MySQL. NoSQL est un excellent outil, mais il ne va certainement pas être votre avantage concurrentiel, il ne va pas rendre votre application attrayante, 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 aussi utiliser Hadoop et Hive. Je pourrais tout garder dans des fichiers plats. Peut-être que je vais commencer à pirater Maglev. J'utiliserai ce qui convient le mieux pour le poste. Si j'ai besoin de rapport, je n'en utiliserai aucun NoSQL. Si j'ai besoin de la mise en cache, je vais probablement utiliser Tokyo Tyrant. Si j'ai besoin d’ACIDity, je n’utiliserai pas NoSQL. Si j’ai besoin de beaucoup de jetons, 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'avais besoin d'écrire un milliard d'objets par jour, j'utiliserais probablement Voldemort. Si j’ai besoin d’une recherche en texte intégral, j’utiliserai probablement Solr. Si j’ai besoin d’une recherche en texte intégral sur des données volatiles, j’utiliserai probablement Sphinx.
J'aime cet article, je le trouve très instructif, cela donne un bon aperçu du paysage et du battage médiatique de NoSQL. Mais, et c'est la partie la plus importante, il est vraiment utile de se poser les bonnes questions lorsqu'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 signifie réellement vivre sans un SGBDR SQL.
- Vous finissez par écrire des tâches pour joindre, par exemple, des données de différentes tables/collections, comme le ferait automatiquement un SGBDR.
- 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 encore 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.
- 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 au serveur pour rechercher des enregistrements associés. Ensuite, vous commencez à dénormaliser les données, ce qui signifie des tâches en arrière-plan.
- Le fait qu'il ne s'agisse pas d'une base de données relationnelle signifie que vous ne devez pas (ce que certains pensent que cela fonctionne mal) une clé étrangère ne vous oblige pas à garantir la cohérence de vos données. Je vous assure que cela va éventuellement créer des incohérences dans les données de votre base de données. Soyez prêt. Très probablement, vous commencerez à écrire des processus ou des contrôles pour maintenir 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 hiberner.
Je pense 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 convient mieux au stockage de données non structurées. Et cela peut organiser vos données dans un format de document. Ces altenatifs SGBDR appelés NoSQL 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 grands magasins de données.
Et la mise en œuvre de ces bases de données est plus simple que le SGBDR classique. Dans la mesure où il s’agit de simples objets binaires à valeur de clé ou de style document, directement sérialisés dans le disque. Ces magasins de données n'appliquent pas les propriétés ACID , ni les schémas . . Ceci ne fournit aucune capacité de transaction . Cela peut donc s’amplifier et nous pouvons obtenir un accès plus rapide (en lecture et en écriture).
Mais, au contraire, RDBM applique ACID et les schémas sur les données. Si vous souhaitez utiliser des données structurées, vous pouvez utiliser 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 des relations structurées entre les données.
Notez que Mongo stocke essentiellement JSON. Si votre application traite de nombreux objets JS (avec imbrication) et que vous souhaitez les conserver, il existe un argument très fort pour l’utilisation de Mongo. Cela rend vos couches DAL et MVC ultra minces, car elles ne décompactent pas toutes les propriétés des objets JS et tentent de les insérer de force dans une structure (schéma) dans laquelle elles ne s'intègrent pas naturellement.
Nous avons un système qui regroupe plusieurs objets JS complexes et nous aimons Mongo car nous pouvons tout persister vraiment, très facilement. Nos objets sont aussi plutôt amorphes et non structurés, et Mongo absorbe cette complication sans cligner des yeux. 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.
Qui a besoin de forums partagés et partagés? Peut-être Facebook, mais à moins que vous ne créiez un concurrent sur Facebook, utilisez simplement Mysql, Postgres ou tout ce avec quoi vous êtes le plus à l'aise. Si vous voulez essayer MongoDB, d'accord, 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, car je suis sûr que vous avez déjà découvert si vous y aviez déjà vraiment travaillé.
Bien sûr, MongoDB peut faire l’hypothèse et sembler facile en surface, mais vous rencontrerez des problèmes que des produits plus matures ont déjà résolus. Ne soyez pas attiré aussi facilement, mais attendez plutôt que "nosql" mûrisse ou meure.
Personnellement, je pense que "nosql" va dépérir et mourir 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 puisse sauver "nosql" dans mon livre, c'est si elle peut s'intégrer de manière transparente dans Ruby ou des langages similaires, et rendre le langage "persistant", presque sans surcharge de code et de conception. Cela peut arriver, mais j'attendrai d'ici là, pas maintenant, ET il faut bien sûr qu'il soit plus mûr.
Btw, pourquoi créez-vous un forum à partir de zéro? Il existe une multitude de forums open source qui peuvent être adaptés à la plupart des besoins, à moins que vous ne créiez réellement la prochaine génération de forums (ce dont je doute).
Je dirais utiliser un SGBDR si vous avez besoin de transactions complexes. Sinon, je choisirais MongoDB - plus flexible, vous savez que cela peut évoluer à tout moment. (Je suis biaisé cependant - je travaille sur le projet MongoDB)
Les 2 principales raisons pour lesquelles vous voudrez peut-être préférer Mongo sont
- Flexibilité dans la conception du schéma (magasin de documents de type JSON).
- Évolutivité - Il suffit d’ajouter des nœuds pour qu’il soit parfaitement horizontal.
Il convient aux applications Big Data. Le SGBDR n'est pas bon pour le Big Data.
De nombreuses entreprises utilisent MongoDB pour les analyses en temps réel à partir des journaux d'applications. Son schéma de protection convient parfaitement aux journaux d'applications, où le schéma d'enregistrement a tendance à changer de temps en temps. En outre, sa fonctionnalité Capped Collection est utile car elle supprime automatiquement les anciennes données pour les conserver dans la mémoire.
C’est un domaine qui, à mon avis, convient parfaitement à MongoDB, 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.
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, en disant que "tout ce qui est fait dans les classes de logique (et pas la base de données) en tout cas '- alors c'est la même chose encore une fois. Ce qui est nécessaire, c'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 coup d'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’ACID et que vous souhaitez rejoindre certaines tables. MongoDB + Redis est parfait pour le magasin de documents Neo4J est parfait pour les bases de données graphiques
Ce que je fais: Je commence par MySQl + Memcache parce que je suis habitué à, puis je commence à utiliser un autre cadre de base de données. Dans un seul projet, vous pouvez combiner MySQL et MongoDB par exemple!