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


516

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?


12
Je ne sais pas pourquoi cela est marqué comme basé sur l'opinion alors qu'il ne l'est clairement pas. Il y a une bonne ou une mauvaise réponse ici.
Spencer

Réponses:


659

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


4
merci, c'est en effet un article très intéressant.
aurora


48
@iddqd ROFL! Mec, c'était hilarant. "Si vous êtes assez stupide pour ignorer totalement la fiabilité juste pour obtenir des repères, je vous suggère de diriger vos données vers /dev/null, ce sera très rapide" : D
Pascal Thivent

3
Merci pour la réponse sensible au battage médiatique.
Deamon

2
Espérons que BJ Clark ne choisira pas d'utiliser toutes ces technologies dans le même projet. Ce serait un peu une courbe d'apprentissage.
Adam Monsen

186

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.


10
pensées intéressantes ...
luigi7up

3
D'un autre côté, les capacités de requête et les jointures que vous décrivez ne devraient pas être un problème: si vous utilisez MongoDB, vous devez encore faire un travail pour concevoir vos collections et les données que vous y mettrez afin de ne pas avoir besoin de complexité JOINs et ainsi de suite. Quoi qu'il en soit, les bases de données ne sont pas un goulot d'étranglement et il existe des solutions de contournement comme Memcache pour certains cas d'utilisation. Si vous partez de zéro, vous constaterez peut-être que la conception et l'utilisation de MongoDB sont plus simples et plus rapides (en tant que développeur travaillant avec du code objet, je n'ai pas besoin d'un ORM). Bien sûr, vous devez écrire quelques scripts, mais en fait ce n'est pas si difficile et vous réutilisez le code
Aki

1
La plupart des gens n'utiliseront pas les bases de données NoSQL pour le cas d'utilisation très spécifique pour lequel ils ont été créés, réinventant ainsi de nombreuses roues par la suite. Le débat entre NoSQL et SQL montre que de nombreuses personnes expérimentent l'utilisation de NoSQL comme si elles remontaient 20 à 30 ans en arrière, à des temps pré-Codd, pré-relationnels et pré-SQL . Ou, comme le dit Michael Stonebraker: "Ce qui se passe arrive"
Lukas Eder

1
L'article 3, «et profitez d'un seul index» est-il toujours valable aujourd'hui? J'entre dans MongoDB maintenant et il semble d'après ce que j'ai lu / vu jusqu'à présent qu'il peut prendre en charge plusieurs index?
Jeach

1
@Jeach: Non, # 3 n'est plus vrai. MongoDB 2.6 a introduit l' intersection d'index .
Rob Garrison

26

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.


10
"Je choisirais mysql pour créer des forums comme ça." Vraiment? Je pense que des choses comme les forums seraient beaucoup plus faciles à écrire en utilisant une base de données orientée document qu'un relationnel (si vous l'écriviez à partir de zéro). Si vous n'avez pas spécifiquement besoin des fonctionnalités d'un SGBDR, je dirais que vous allez avec MongoDB ou une base de données similaire pour une facilité d'utilisation et une mise à l'échelle.
Sasha Chedygov,

2
CouchDB prend en charge ACID. couchdb.apache.org/docs/overview.html
Sonia

2018: MongoDB prend également en charge ACID
Nepoxx

10

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.


7

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)


7
Les transactions complexes ne fonctionnent pas dans MongoDB, mais elles fonctionnent dans d'autres bases de données NoSQL, comme MarkLogic (je suis également biaisé depuis que j'exécute la communauté de développeurs pour MarkLogic).
Eric Bloch

Merci pour l'allusion à MarkLogic - je ne le savais pas.
aurora

J'aimerais entendre mdirolf à ce sujet. Pourquoi MongoDB a-t-il choisi de ne pas implémenter de transactions?
Aki

7

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).


5
Merci pour votre réponse. intégrer un forum est un gâchis - nous l'avons déjà fait et avons décidé de ne pas recommencer: nous n'avons pas besoin de milliers de fonctionnalités mais d'une intégration complète dans notre logiciel.
aurora

4

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.


4

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.


3

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.


Merci, vous soulevez un point intéressant ici. Je serais vraiment intéressé par l'explication de Monty, car je ne suis pas sûr de la complexité des annulations de mises à jour sur plusieurs tables dans la logique d'application pure - je ne suis pas sûr, si c'est vraiment possible?
aurora

Je ne suis pas sûr non plus de la «meilleure» façon. Nous avons toujours juste suivi tout ce qui a été fait dans la base de données, puis nous l'avons autorisé ou annulé au niveau de l'application, dans le code. Nous n'avons jamais compté sur des transactions, nulle part, jamais. Mongo docs suggère d'utiliser des métadonnées pour suivre les parties de la transaction annulable qui se sont produites, l'état dans lequel la transaction est, au cas où elle se casserait et devrait être annulée. Ce qui est drôle, c'est que nous l'avions déjà fait avec MySQL et d'autres. Ce n'est pas beaucoup plus de travail et cela reste concentré sur ce qui se passe, quand, où et pourquoi, au lieu de le mettre en boîte noire.
FYA

Il y a une note à ce sujet sur le site Web de 10gen quelque part ... mentionnant comment les champs `` interlock '' ou `` cliquets '' sont utilisés manuellement pour indiquer l'état d'un processus en plusieurs étapes. Il me semble que si vous zoomez sur le moteur MySQL lui-même, la "transaction de bloc" se prolonge toujours en une série d'étapes, quoi qu'il arrive; c'est simplement que les verrouillages ou les cliquets sont effectués d'une manière beaucoup plus petite et plus rapide que le suivi manuel dans les champs de la base de données.
FYA

Nous n'avons pas encore trouvé un bon moyen de limiter le démon MongoDB - il engloutit presque toute la RAM disponible pour son index et stockage de données en mémoire, bien qu'il cède de la mémoire rapidement lorsque d'autres procs en ont besoin. Pourtant, il serait bien d'avoir une 'use_max_memory' ou d'autres limites facilement définissables pour s'assurer que MongoDB ne s'enfuit pas et n'envoie pas le serveur en swash thrashing (nous l'avons vu plusieurs fois, même dans la version la plus récente). Au moins MySQL accepte toutes sortes de limites définissables et d'indices de fonctionnement.
FYA

Pas directement lié, mais en quelque sorte: nous utilisions memcached mais y avons renoncé en raison du fiasco du pilote PHP Memcache / Memcached non résolu. Nous avons utilisé MongoDB comme clé temporaire rapide: val store (pour lequel cela fonctionnait très bien!) Jusqu'à découvrir à quel point apc_store () est rapide et facile. Si nous constatons que APC se remplit de crud temporaire (vs PHP précompilé stocké) que nous avons utilisé pour stach dans memcached, nous reviendrons à MongoDB pour le stockage key: val.
FYA

1

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!


MySQL + memcached vous donnera une cohérence éventuelle. Ce que je ne considère pas ACID dans un contexte RDMB.
R. van Twisk du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.