Raisons pour et contre le passage de SQL Server à MongoDB

Question

Je sais que c'est une grande question et qu'il ne s'agit pas d'une réponse par oui ou par non, mais nous développons des applications Web et nous envisageons d'utiliser MongoDB pour notre solution de persistance. Nous combinons MongoDB avec NoRM pour le stockage des objets.

Ce que je veux savoir, c'est quels sont les pièges que vous avez rencontrés en passant de SQL à Mongo ? Quand est-ce que mongo n'est tout simplement pas la bonne solution et est-ce que les avantages de mongodb sont suffisants pour transférer le développement de SQL ?

Answer 1

À 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 qui sont de nature relationnelle ? Si oui, est-ce possible et est-ce une bonne idée de modéliser les données en documents ? La modélisation des données est aussi importante dans une base de données documentaire que dans une base de données relationnelle, elle est simplement effectuée différemment. Combien de types d'objets avez-vous et comment sont-ils reliés ? DBrefs dans Mongodb peut-il faire l'affaire ou les clés étrangères vous manqueront-elles tellement que ce sera douloureux ? Quels sont vos modèles d'accès aux données ? Recherchez-vous uniquement des données d'un type donné, filtrées par la valeur d'un champ, ou avez-vous des modes de recherche complexes ?

Avez-vous besoin d'une intégrité transactionnelle 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 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 souples en ce qui concerne la cohérence des écritures afin d'obtenir des performances. NoSQL n'est pas un paysage uniforme et d'autres produits, par exemple CouchDB, présentent d'autres caractéristiques dans ce domaine. Certains sont également réglables.

Ce sont toutes des questions qui doivent entrer en ligne de compte dans le choix du stockage.

Quelques expériences

• L'établissement de rapports détaillés sur les données stockées peut s'avérer plus difficile avec MongoDB ou toute autre base de données documentaire, et certains cas d'utilisation ont combiné un SGBDR et une base de données documentaire à cette fin.
• (Très) Modèle d'interrogation différent. MongoDB diffère également des autres bases de données documentaires.
• Possibilité de modifier le format et le schéma des données pendant le développement.
• Territoire inconnu
• degré variable de maturité des moteurs et des cadres
• Rapidement
• Des outils de production et de gestion plus simples (à bien des égards) que ceux de nombreux SGBDR.
• Plus de déséquilibre d'impédance. Le stockage s'adapte aux données, et non l'inverse.
• Moins de frictions et un accès plus direct aux données.
• Domaine plus lié à la persistance (selon le "niveau" ORM de NoRM, selon le degré d'abstraction du backend. Je n'ai pas utilisé NoRM donc je ne peux pas répondre à cette question).

Answer 2

Contre

1. (le manque de / la vision différente sur) durabilité (lire http://www.mikealrogers.com/2010/07/mongodb-performance-durability )
2. Aucune transaction
3. Aucune contrainte
4. L'agrégation avec MapReduce est lente et vous devez écrire du code pour quelque chose comme le group-by.
5. Le reporting est plus difficile, le développeur définit les relations mais les analystes commerciaux ne peuvent pas construire leurs propres requêtes, ils ne peuvent pas, par exemple, faire un "moins" ("except" dans le jargon des serveurs SQL).

pros

1. vous pouvez facilement ajouter de nouvelles "colonnes" et "tables".
2. vitesse
3. sharding (toujours en version bêta)
4. le document correspond plus étroitement à un objet qu'un ensemble de tables relationnelles, ce qui facilite le mappage.
5. Il élargit l'esprit

Answer 3

Votre kilométrage peut varier, mais voici un graphique rapide que j'ai créé 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 cela s'adapterait à notre application.

Answer 4

Je m'en sers depuis quelques jours maintenant. Voici ce que je peux en dire :

POUR :

• Plus d'instructions SQL
• Votre base de données ressemble à vos classes et non l'inverse.
• Votre "schéma" est plus flexible
• Bonne mise à l'échelle
• Très facile à utiliser
• < opinion>C'est cool< / opinion>

CONTRE :

• J'essaie actuellement d'implémenter un fournisseur d'adhésion et un fournisseur de rôle personnalisés pour mon application mongo mais, d'une manière ou d'une autre, ma classe utilisateur MemberShip a des champs NULL lorsque j'essaie de la récupérer dans mongo.
• J'ai lu quelque part que le pilote C# est relativement jeune mais qu'il se stabilise, alors attendez-vous à des changements. (Bien que cela ne me retienne pas)

J'ai remarqué une chose qui manque dans les tutoriels : Initialiser vos listes à l'intérieur de votre objet, sinon une erreur se produira lors de la tentative de .save(yourobj). La chose la plus sûre à faire est d'écrire un constructeur dans votre classe qui s'assure que vous n'avez pas d'objets NULL dans votre objet. De cette façon, vous n'obtiendrez pas d'erreur si vous oubliez quelque chose.

Answer 5

Vous trouverez peut-être quelques avantages et inconvénients de l'utilisation d'une base de données NoSQL (y compris MongoDB) dans ce document. Débuter avec NoSQL . Un résumé rapide serait : un modèle de données différent (pensez à un mappage du modèle objet à ce nouveau modèle, est-ce que cela fonctionnera bien), un modèle de requête différent (les requêtes MongoDB sont assez performantes comparées à d'autres), pas de transactions (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 manière dont vous concevez votre application avec cette nouvelle approche.