Raisons pour et contre le passage de SQL server à MongoDB
Je sais que c'est une grande question et que ce n'est pas une réponse oui ou non, mais nous développons des applications web et cherchons à utiliser MongoDB pour notre solution de persistance. Combinaison de MongoDB avec NoRM pour le stockage d'objets.
Ce que je veux demander, c'est quels pièges avez-vous rencontrés avec le passage de SQL à mongo? Quand mongo n'est-il tout simplement pas la bonne solution et les avantages de mongodb sont-ils suffisants pour déplacer le développement de SQL?
6 réponses
À mon avis, le format de vos données devrait être la principale préoccupation lors du choix d'un backend de stockage. Avez-vous des données de nature relationnelle? Si oui, peut-elle et est-ce une bonne idée de modéliser les données dans les documents? La modélisation des données est aussi importante dans une base de données de documents que dans une base de données relationnelle, elle se fait différemment. Combien de types d'objets et comment sont-ils liés? Les DBrefs dans Mongodb peuvent-ils faire l'affaire ou vous manquerez tellement de clés étrangères que ce sera douloureux? Quels sont vos modèles d'accès pour les données? Est-ce que vous récupérez simplement des données d'un type filtré par une valeur de champ, ou avez-vous des modes de récupération complexes?
Avez-vous besoin de L'intégrité transactionnelle ACID? Le domaine d'appliquer beaucoup de contraintes sur les données? Avez-vous besoin du facteur d'évolutivité d'une base de données de documents ou est-ce juste une chose "cool" à avoir?
Quelles sont vos exigences en matière de cohérence et d'intégrité des données? Certaines solutions NoSQL et MongoDB en particulier sont assez lâches en écriture la cohérence afin d'obtenir les performances. NoSQL n'est pas un paysage uniforme et d'autres produits, par exemple CouchDB a d'autres caractéristiques dans ce département. Certains sont réglables aussi.
Ce sont toutes des questions qui devraient entrer dans le choix du stockage.
Certaines Expériences
- faire des rapports détaillés sur les données stockées peut être plus difficile lors de L'utilisation de MongoDB ou de toute base de données de documents et certains cas d'utilisation ont combiné SGBDR et document-db pour cela but.
- modèle de requête (très) différent. MongoDB diffère des autres documents-dbs aussi.
- Flexible pour changer le format/schéma de données pendant le développement
- territoire Inconnu
- degré de maturité variable dans les moteurs et les cadres
- rapide
- des outils de gestion et de produits plus simples (à bien des égards) (par rapport à de nombreux produits SGBDR)
- plus de décalage d'impédance. Le stockage correspond aux données, pas l'inverse.
- moins de friction et plus d'un accès direct aux données.
- domaine plus lié à la persistance (en fonction du "niveau" ORM de la norme, sur combien il abstrait le backend. Je n'ai pas utilisé NoRM donc je ne peux pas répondre à cela.)
Contre
- (le manque de / vision différente sur) durabilité (lire http://www.mikealrogers.com/2010/07/mongodb-performance-durability)
- aucune transaction
- aucune contrainte
- L'agrégation avec MapReduce est lente et vous devez écrire du code pour quelque chose comme group-by
- le Reporting est plus difficile, le développeur définit les relations mais les analystes métier ne peuvent pas construire leurs propres requêtes, ils ne peuvent pas par exemple faire un ' minus '('except' dans sql server lingo)
Avantages
- , vous pouvez facilement ajouter de nouveaux "colonnes" et "tables"
- vitesse
- sharding (encore bêta)
- le document correspond plus étroitement à un objet qu'à un ensemble de tables relationnelles, ce qui facilite le mappage
- , Il élargit l'esprit
J'ai fouiné avec ça il y a quelques jours. C'est ce que je peux dire à ce sujet:
Pour:
- Plus d'instructions SQL
- votre base de données ressemble à vos classes et non l'inverse
- Votre "schéma" est plus flexible
- échelles bien
- Très facile à démarrer avec
- C'est cool
Contre:
- j'essaie actuellement d'implémenter un fournisseur d'appartenance personnalisé et un fournisseur de rôle pour mon Mongo app mais en quelque sorte ma classe D'utilisateur D'adhésion a des champs NULL quand j'essaie de le récupérer de mongo.
- quelque part, j'ai lu à propos du pilote C# qu'il est relativement jeune mais stabilisant, alors attendez-vous à quelques changements. (Bien que cela ne me retiendrait pas)
Une chose que j'ai remarqué qui manque dans les tutoriels: Initialisez vos listes à l'intérieur de votre objet sinon il va lancer une erreur en essayant de .enregistrer (yourobj). La chose la plus sûre à faire est d'écrire un constructeur dans votre classe s'assure que vous n'avez aucun objet NULL à l'intérieur de votre objet. De cette façon, vous n'obtiendrez pas une erreur si vous oubliez quelque chose.
Votre kilométrage peut varier, mais c'est un graphique rapide que j'ai mis en place pour comparer la vitesse de mise à jour de plusieurs "lignes de table" (document plat non hiérarchique dans MongoDB) avec et sans index pour nous donner une idée de la façon dont il évoluerait pour notre application.
Vous trouverez peut-être quelques avantages et inconvénients de l'utilisation D'une base de données NoSQL (MongoDB inclus) dans cette Mise en route avec NoSQL. Un résumé rapide serait: un modèle de données différent (pensez que si un mappage du modèle objet à "ce nouveau modèle" est nécessaire, cela fonctionnera-t-il bien), un modèle de requête différent (les requêtes MongoDB sont assez capables par rapport aux autres), pas de transactions (vous avez des opérations atomiques cependant).
Quoi qu'il en soit, de mon point de vue le plus important le changement est le modèle de données et la façon dont vous concevez votre application avec cette nouvelle approche.
J'utilise MongoDB en cours D'exécution sur le Cloud Atlas sur AWS depuis de nombreux mois et deux avantages majeurs se distinguent:
- il est ridiculement rapide par rapport à nos dbs relationnels. Je vois rarement des documents retournés dans plus de 15ms, y compris le voyage aller-retour à travers l'europe.
- nous avons cessé de nous soucier du schéma ou de la dénormalisation-nous prenons simplement nos modèles domiens c# object et les sérialisons dans la base de données et cela semble plutôt bien fonctionner.