MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Raisons pour et contre le passage du serveur SQL à MongoDB

À mon avis, le format de vos données devrait être la principale préoccupation lors du choix d'un backend de stockage. Vous disposez de données à caractère relationnel ? Si oui, peut-on 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 documentaire que dans une base de données relationnelle, c'est juste fait différemment. Combien de types d'objets avez-vous et comment sont-ils lié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 ? Récupérez-vous 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 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 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 sur la cohérence d'écriture afin d'obtenir des performances. NoSQL n'est pas un paysage uniforme et d'autres produits, par ex. CouchDB a d'autres caractéristiques dans ce département. Certains sont également réglables.

Autant de questions qui doivent entrer dans le choix du stockage.

Quelques expériences

  • La création de rapports détaillés sur les données stockées peut être plus difficile lorsque vous utilisez MongoDB ou n'importe quelle base de données de documents et certains cas d'utilisation ont combiné RDBMS et document-db à cette fin.
  • Modèle de requête (très) différent. MongoDB diffère également des autres bases de données de documents.
  • Flexible pour changer le format/schéma des données pendant le développement
  • Territoire inconnu
  • degré variable de maturité des pilotes et des cadres
  • Rapide
  • Outils de produit et de gestion plus simples (à bien des égards) (par rapport à de nombreux produits RDBMS)
  • Plus de décalage d'impédance. Le stockage s'adapte aux données, et non l'inverse.
  • Moins de friction et accès plus direct aux données.
  • Domaine plus lié à la persistance (en fonction du "niveau" ORM de NoRM, de la quantité d'abstraction du backend. Je n'ai pas utilisé NoRM donc je ne peux pas répondre à cette question.)