Quand quelqu'un utiliserait-il MongoDB (ou similaire) sur un SGBD relationnel?

Je suis un peu confus à propos de tout ce qui concerne NoSQL. Quand choisiriez-vous d'utiliser quelque chose comme MongoDB par rapport à quelque chose comme Oracle ou MySQL? Je ne comprends pas vraiment la "différence" en ce qui concerne l'utilisation entre eux.

A ma connaissance, les bases de données de type NoSQL ne sont pas censées remplacer les SGBDR, mais que sont-elles censées faire exactement?

J'ai déjà utilisé CouchDB pour trois projets concernant les animaux domestiques.

• Un système de microblogging.
• Pour enregistrer des informations pour une petite application de prise de notes que j'ai faite.
• Une application de brainstorming à usage général.

La principale raison pour laquelle j'ai choisi cette option plutôt que MSSQL ou MySQL est la flexibilité que vous obtenez en l'utilisant. Pas de schéma rigide. Si, trois mois plus tard, vous avez besoin d'une certaine table pour avoir un champ supplémentaire, ceci et cela, il vous suffit de le modifier pour que tout se répande.

J'ai utilisé Beginning CouchDB by Apress pour apprendre à l'utiliser.

Par exemple, CouchDB utilise JSON pour communiquer avec la base de données. Si votre langue peut utiliser les données POST, vous pouvez l’utiliser pour communiquer avec la base de données.

Lisez également: Pourquoi devrais-je utiliser une base de données documentaire au lieu d'une base de données relationnelle? sur StackOverflow

Désolé d'ajouter une autre réponse, mais aucune des réponses ici n'est très satisfaisante. Cette réponse est spécifique à MongoDB (par opposition à la vaste gamme d’autres options de stockage de données qui ne sont pas des bases de données relationnelles).

Avantages:

• MongoDB a une latence inférieure par requête et consomme moins de temps CPU par requête car il effectue beaucoup moins de travail (par exemple, aucune jointure, transaction). En conséquence, il peut gérer une charge plus élevée en termes de requêtes à la seconde et est donc souvent utilisé si vous avez un nombre important d'utilisateurs.
• MongoDB est plus facile à partager (utiliser dans un cluster) car il n'a pas à se soucier des transactions et de la cohérence.
• MongoDB a une vitesse d’écriture plus rapide car il n’a pas à s’inquiéter des transactions ni des restaurations (et donc pas à s’inquiéter du verrouillage).
• MongoDB n'a pas de schéma au cas où vous auriez un cas d'utilisation spécial qui pourrait en tirer parti.

Les inconvénients:

• MongoDB ne supporte pas les transactions . C'est ainsi qu'il obtient la plupart de ses avantages.
• En général, MongoDB crée plus de travail (par exemple, plus de coûts de processeur) pour le serveur client . Par exemple, pour joindre des données, il faut émettre plusieurs requêtes et effectuer la jointure sur le client.
• Même en 2017, MongoDB prend moins en charge les outils que les bases de données relationnelles, tout simplement parce que celles-ci sont plus récentes. Il y a également moins d'experts MongoDB que leurs homologues relationnels.

Points souvent mal compris:

• MongoDB et les bases de données relationnelles prennent en charge l'indexation. Leurs performances de requête sont similaires en termes d’exécution de requêtes volumineuses .
• MongoDB ne supprime pas le besoin de migrer, ni plus précisément de mettre à jour vos données existantes au fur et à mesure de l'évolution de votre schéma. Par exemple: si vous avez une application qui s'appuie sur une table d'utilisateurs pour contenir certaines données et que vous modifiez cette table pour qu'elle contienne des données différentes (disons que vous ajoutez un champ d'image de profil), vous devez toujours:
  • Écrivez votre application pour gérer les objets pour lesquels cette propriété n'est pas définie OU
  • Ecrivez une migration unique pour définir une valeur par défaut pour cette propriété OU
  • Écrivez le code pour fournir une valeur par défaut au moment de la requête si ce champ n'est pas présent OU
  • Traiter le champ manquant d'une autre manière

Voler sans vergogne à Renesis (en fait, je fais cette réponse en CW):

Utiliser des SGBDR au lieu d'autres types:

• Lisez l’idée de "NoSQL" et d’autres types de bases de données:
  • NoSQL: Si seulement c'était aussi simple que cela
  • (ci-dessus est lié à) Quand utiliser MongoDB ou d'autres systèmes de base de données orientés document? ^{actuellement supprimé sur SO} ( plus )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-take-the-place-of-relational-databases-is-sql-going
  • Quand utiliser CouchDB et SGBDR?
• Les SGBDR font un usage intensif de l'indexation pour la performance. Sur des bases de données très volumineuses, cela peut avoir un effet négatif sur les performances ou même réduire le nombre optimal de lignes par base de données / fragments nécessitant davantage de matériel.
• Pas aussi idéal si vous stockez une quantité énorme de données mais lisez moins souvent
• Si vous n'avez pas beaucoup de relations étrangères, les bases de données relationnelles peuvent ne pas être idéales (stockage de documents)

Lorsque vos données ne sont pas relationnelles, l’utilisation de bases de données NoSQL peut présenter des avantages majeurs, tels que les performances et l’évolutivité (en fonction des circonstances, bien sûr). Certains modèles de conception tels que CQRS facilitent l'utilisation de données non relationnelles dans des domaines qui, de manière conventionnelle, nécessiteraient l'utilisation exclusive d'une base de données SQL.

Il est courant d'utiliser des bases de données telles que mongo pour les données en cache. Par exemple, si vous devez générer un rapport, vous pouvez effectuer une requête SQL complexe qui joint et agrège un ensemble de données à la volée, ou vous pouvez simplement extraire un document JSON de votre base de données Mongo qui contient déjà tout ce que vous devez générer. le rapport. Cela rend la lecture des données très facile (et rapide!), Mais peut rendre l’écriture des données assez compliquée (c’est là que CQRS entre en jeu).

Les bases de données telles que MongoDB sont très utiles lorsque vous savez généralement où se trouvent vos données (par opposition à la nécessité d'écrire plusieurs requêtes complexes). Avec Mongo, les données "liées" sont soit imbriquées dans les données parent, soit elles ont des clés primaires / étrangères. C'est très bien si, par exemple, vous avez des publications et des commentaires. En règle générale, vous n'allez pas afficher de commentaires en dehors du contexte d'un article. Il est donc logique que les commentaires soient contenus dans un article (de cette manière, vous obtenez tous les commentaires de l'article sans avoir à interroger une table distincte).

MongoDB est sans schéma. Cela signifie que, pour l’essentiel, il faudra utiliser la structure de données que vous lui envoyez.

D'un autre côté, si vous devez utiliser des fonctions d'agrégat et si vous avez besoin d'interroger des données de manière complexe, ce qui ne peut être réalisé à l'aide d'incorporation ou de relations simples en mongo, vous devez savoir qu'il est temps d'utiliser un SGBDR comme MySQL ou PostgreSQL.

MongoDB n'est pas destiné à remplacer SQL. Il répond simplement à des besoins différents, et MongoDB et un SGBDR peuvent être utilisés conjointement. À mon avis, MongoDB n'est pas tout à fait nécessaire si vous n'avez pas besoin que vos données soient flexibles ou intégrées dans un document parent. Le développement avec MongoDB est très amusant car il y a beaucoup moins d'étapes à franchir pour mettre en place un projet (disons dans Rails). Besoin de changer? Aucun problème. Ajoutez simplement un attribut à votre modèle. Terminé.

Je ne peux pas parler pour beaucoup d'autres bases de données NoSQL, même si je sais qu'elles sont généralement conçues de la même manière pour répondre à un besoin spécifique auquel un SGBDR ne peut pas répondre. Certains résident entièrement en mémoire ou peuvent être partagés ou redimensionnés très facilement. Je suis à peu près sûr que Cassandra est conçue pour continuer à fonctionner sans perte de données si un nœud tombe en panne. Redis est fondamentalement un magasin de valeurs de clé qui réside en mémoire (avec des écritures de disque périodiques pour la persistance), mais a également la possibilité de stocker des types de données comme des ensembles et de les trier.

La victoire majeure est lorsque vous souhaitez partager des données ou disposer de bases de données multi-maîtres. Vous pouvez partager des données dans MySQL, mais cela se révèle très pénible. Si vous effectuez de nombreuses écritures, il est souvent utile de répartir les données sur plusieurs serveurs. Le problème est que si vous voulez avoir une cohérence référentielle forte, il peut être très difficile, voire impossible, de rechercher le théorème CAP.

Les bases de données SQL ont une très bonne cohérence mais un support de partitionnement vraiment mauvais. Les bases de données NoSQL ont tendance à aller dans l'autre sens. Facile à partitionner mais souvent ce qu'on appelle la cohérence éventuelle. Si vous construisez un site de messagerie qui convient, pour une banque probablement pas OK.

L'atout est qu'il existe désormais plusieurs modèles pour stocker les données. Vous avez donc le choix entre implémenter les éléments, alors que vous n'aviez auparavant que des bases de données SQL.

SE Radio a eu quelques bons épisodes à ce sujet.

MongoDB fonctionne bien lorsque vous écrivez beaucoup de données et lorsque vos besoins en matière de requêtes ne sont pas trop compliqués. Par conséquent, MongoDB convient parfaitement lorsque vous implémentez CQRS avec l’approvisionnement en événements du côté de la commande - c’est-à-dire que votre magasin d’événements est une base de données MongoDB.

Du côté des requêtes, nous utilisons toujours une base de données SQL Server avec des vues et des services de données WCF en plus, en raison de sa flexibilité. Je pense que dans la plupart des cas, vous aurez vraiment besoin de la puissance d'une base de données relationnelle pour les requêtes.

La différence immédiate et fondamentale entre MongoDB et un SGBDR est le modèle de données sous-jacent. Une base de données relationnelle structure les données en tables et en lignes, tandis que MongoDB les structure en collections de documents JSON. JSON est un format de données auto-descriptif et lisible par l'homme. Conçu à l'origine pour des échanges légers entre navigateur et serveur, il est devenu largement accepté pour de nombreux types d'applications.

Les documents JSON sont particulièrement utiles pour la gestion des données pour plusieurs raisons. Un document JSON est composé d'un ensemble de champs qui sont eux-mêmes des paires clé-valeur. Cela signifie que chaque document JSON comporte sa propre conception de schéma lisible par l'homme, où qu'il soit, ce qui permet aux documents de passer facilement d'une application de base de données à une application cliente sans perdre leur signification.

JSON est également un format de données naturel à utiliser dans la couche application. JSON prend en charge une structure de données plus riche et plus flexible que les tables composées de colonnes et de lignes. Outre la prise en charge des types de champs tels que nombre, chaîne, booléen, etc., les champs JSON peuvent être des tableaux ou des sous-objets imbriqués. Cela signifie que nous pouvons représenter un ensemble de relations sophistiquées représentant plus précisément les objets avec lesquels nos applications travaillent. L'utilisation de documents JSON dans notre base de données signifie que nous n'avons pas besoin d'un mappeur relationnel d'objet entre notre base de données et les applications qu'elle sert. Nous pouvons conserver nos données sous la bonne forme

Si vos données nécessitent beaucoup d'interrogations, une solution NoSQL n'est pas satisfaisante et lorsque vous avez besoin d'un support transactionnel (ACID), un NoSql n'est pas la solution la mieux adaptée. Je pense que NoSQL brille quand vous avez beaucoup de lectures qui doivent être rapides et quand la structure est quelque peu adhoc, vous récupérez par document ou par structure de page, quelque chose comme ça. Mais beaucoup de solutions NoSQL s’améliorent assez rapidement et il y aura peut-être bientôt des lacunes. Quoi qu'il en soit, je pense que les bases de données relationnelles conviennent toujours à la plupart des applications.