Raisons pour et contre le passage du serveur SQL à MongoDB
Je sais que c'est une grande question et que ce n'est pas une réponse positive ou négative, mais nous développons des applications Web et étudions la possibilité d'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 est-ce que mongo n'est tout simplement pas la bonne solution et que les avantages de mongodb sont suffisants pour faire évoluer le développement de SQL?
À mon avis, le format de vos données devrait être la principale préoccupation lors du choix d’un back-end de stockage. Avez-vous des données de nature relationnelle? Si oui, est-ce possible et est-ce une bonne idée de modéliser les données dans des 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, cela se fait simplement différemment. Combien de types d'objets avez-vous et comment sont-ils liés? Est-ce que DBrefs à Mongodb peut faire l'affaire ou allez-vous manquer des clés étrangères tellement que ce sera douloureux? Quels sont vos modèles d'accès pour les données? Récupérez-vous simplement les données d'un type filtré par une valeur de champ ou disposez-vous de modes de récupération complexes?
Avez-vous besoin de l'intégrité transactionnelle d'ACID? Le domaine impose-t-il beaucoup de contraintes sur les données? Avez-vous besoin du facteur d'évolutivité d'une base de données de documents ou s'agit-il simplement d'une chose "géniale"?
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 sur la cohérence d'écriture pour obtenir des 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 accordables aussi.
Ce sont toutes des questions qui devraient entrer dans le choix du stockage.
Quelques expériences
- La génération de rapports détaillés sur les données stockées peut s'avérer plus difficile lorsque vous utilisez MongoDB ou une base de données de documents. Dans certains cas d'utilisation, SGBDR et document-db ont été combinés à cette fin.
- Modèle de requête (très) différent. MongoDB diffère également des autres documents-dbs.
- 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
- Vite
- Outils de gestion et de produit plus simples (à bien des égards) (par rapport à de nombreux produits SGBDR)
- Plus de mésappariement d'impédance. Le stockage correspond aux données, pas l'inverse.
- Moins de friction et un accès plus direct aux données.
- Domaine plus lié à la persistance (en fonction du "niveau" ORM de NoRM, en fonction de l'abstraction du backend. Je n'ai pas utilisé NoRM, je ne peux donc pas répondre à cette question.)
les inconvénients
- (le manque de/vision différente sur) durabilité (lire http://www.mikealrogers.com/2010/07/mongodb-performance-durability )
- Aucune transaction
- Pas de contraintes
- L'agrégation avec MapReduce est lente et vous devez écrire du code pour quelque chose comme group-by.
- La création de rapports est plus difficile, le développeur définit les relations, mais les analystes métier ne peuvent pas créer leurs propres requêtes, ils ne peuvent par exemple pas faire de "moins" ("sauf" dans le langage serveur SQL)
avantages
- vous pouvez facilement ajouter de nouvelles "colonnes" et "tables"
- la vitesse
- sharding (encore beta)
- le document correspond plus étroitement à un objet qu'à un ensemble de tables relationnelles, ce qui facilite le mappage
- Ça élargit l'esprit
Cela fait quelques jours que je fouille avec ça. Voici ce que je peux en dire:
POUR:
- Pas plus d'instructions SQL
- Votre base de données ressemble à vos classes et non l'inverse
- Votre "schéma" est plus flexible
- Balance bien
- Très facile de commencer avec
- <opinion> c'est cool </ opinion>
CONTRE:
- J'essaie actuellement d'implémenter un fournisseur d'adhésion et un fournisseur de rôles personnalisés pour mon application mongo, mais ma classe d'utilisateurs MemberShip possède des champs NULL lorsque je tente de le récupérer à partir de mongo.
- Quelque part, j'ai lu sur le pilote C # qu'il est relativement jeune mais qu'il se stabilise alors attendez-vous à des changements. (Bien que cela ne me retienne pas)
Une chose que j’ai remarquée qui manque dans les tutoriels: Initialisez vos listes à l’intérieur de votre objet, sinon une erreur sera générée lors de la tentative de sauvegarde (yourobj). La chose la plus sûre à faire est d’écrire dans votre classe un constructeur qui vous assure de ne pas avoir d’objets NULL dans votre objet. De cette façon, vous ne recevrez pas d'erreur si vous oubliez quelque chose.
Votre kilométrage peut varier, mais c’est un graphique rapide que j’ai rassemblé pour comparer la vitesse de mise à jour de plusieurs "lignes de tableau" (document non hiérarchique à plat dans MongoDB) avec et sans index pour nous donner une idée de la façon dont il évoluerait notre application.
Vous pourriez trouver quelques avantages et inconvénients d'utiliser une base de données NoSQL (MongoDB incluse) dans ce Mise en route avec NoSQL . Voici un résumé rapide: un modèle de données différent (si un mappage du modèle objet à "ce nouveau modèle" est nécessaire, cela fonctionnera-t-il correctement), un modèle de requête différent (les requêtes MongoDB sont assez performantes par rapport aux autres) , pas de transaction (vous avez cependant quelques opérations atomiques).
Quoi qu'il en soit, de mon point de vue, le changement le plus important concerne le modèle de données et la façon dont vous concevez votre application avec cette nouvelle approche.
J'utilise MongoDB sur AWS sous Atlas Cloud depuis plusieurs mois et deux avantages majeurs se dégagent:
- C'est ridiculement rapide comparé à nos bases relationnelles. Je vois rarement des documents rendus en plus de 15 ms, y compris l'aller-retour en Europe.
- Nous avons cessé de nous intéresser au schéma ou à la normalisation - nous prenons simplement nos modèles domian d'objet c # et les sérialisons dans la base de données, et cela semble fonctionner assez bien.